Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Why export templates would be useful

Reply
Thread Tools

Why export templates would be useful

 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      03-30-2010
* Jerry Coffin:
> In article <4bb0ce73$0$11873$(E-Mail Removed)>,
> http://www.velocityreviews.com/forums/(E-Mail Removed)lid says...
>
> [ ... ]
>
>> Some people argue that export templates have no advantages
>> whatsoever. This is a huge lie. I have *never* seen these people
>> talking about the issue of template classes and functions not
>> having local scope, while regular classes and functions, as well as
>> export templates do. It's like they are cherry-picking and choosing
>> only those alleged advantages which people think export templates
>> have but which are not very relevant.

>
> While you're right that exported templates could sometimes provide
> some benefit, the benefit really was fairly minimal and the cost
> really was quite high. Worse, I believe their presence in the
> standard tended to stall (if not outright prevent) work on anything
> better.


In particular, modules. As I understand it.


> As such, removing export from the standard is almost
> certainly for the best, because it'll allow something better to be
> designed and put into use.



Hopefully.


Cheers,

- Alf
 
Reply With Quote
 
 
 
 
Brian
Guest
Posts: n/a
 
      03-31-2010
On Mar 29, 8:02*am, Juha Nieminen <(E-Mail Removed)> wrote:
> * Many people argue that there is *no* advantage in using export
> templates other than the questionable advantage of being able to
> separate the declaration from the implementation (which these people
> seem to argue is only a purely cosmetic feature).
>
> * However, I have *never* seen discussed the absolutely *major*
> advantage of export templates: That they have their own compilation
> unit, which means that they have access to their own file-local scope
> (which in turn can be used to increase the modularity of the program).
> This is something which is just not possible with regular templates.
>
> * For that reason I have argued that template classes and functions
> are actually *inferior* to regular classes and functions because the
> former cannot have file-local scope while the latter can. Export
> templates would solve this deficiency.
>
> * I have been thinking about what would be the simplest example which
> is implementable with export templates and which isn't with regular
> templates (at least not without global namespace contamination). How
> about this:
>
> //---------------------------------------------------
> // MyClass.hh
> export template<typename T>
> class MyClass
> {
> *public:
> * * MyClass();
> * * // other member functions here...};
>
> //---------------------------------------------------
>
> //---------------------------------------------------
> // MyClass.cc
> namespace
> {
> * * unsigned constructorCallCounter = 0;
>
> }
>
> template<typename T>
> MyClass<T>::MyClass()
> {
> * * ++constructorCallCounter;}
>
> //---------------------------------------------------
>
> * You *could* achieve the same effect with regular templates, but
> it would require adding a new name to global scope (accessible from
> anywhere). This may not be a very viable solution if the amount of
> stuff inside the nameless namespace above is large, nor is it very
> good design.
>
> * (And no, making 'constructorCallCounter' a static member of
> MyClass is *not* the same thing because it would mean that every
> distinct template instantiation would have its own separate
> 'constructorCallCounter', rather than it being shared among all
> of them.)
>
> * Can anyone come up with some objections to the example above?
> (Note that the example is not intended to be an example of actual
> usage, but instead the simplest possible example that demonstrates
> the issue.)



A few months ago I was asking a question in this thread:

http://groups.google.com/group/comp....b84e0cb88cef87


Here's a paragraph from that thread:

"In the past we added an option that allows users to
specify whether they want the code in header-only
(integrated) form or as two separate files. This was
in part because of some comments made by Kanze about
build times I think. Any thoughts on how to reconcile
this template use with that support? I'm not sure if
it's possible to keep supporting the separate header
and implementation approach with these changes."


Basically after deciding I needed to use class templates,
I was no longer able to support separated header and
implementation files. I asked if anyone had advice
on that, but didn't get a reply. I wondered if export
was the answer, but am not sure. Anyway, if exported
templates would help in that regard, they would be important
from a build perspective.


Brian Wood
http://webEbenezer.net
(651) 251-9384
 
Reply With Quote
 
 
 
 
Jerry Coffin
Guest
Posts: n/a
 
      03-31-2010
In article <hotkin$jfi$(E-Mail Removed)-september.org>, (E-Mail Removed)
says...
>
> * Jerry Coffin:


[ ... ]

> > While you're right that exported templates could sometimes
> > provide some benefit, the benefit really was fairly minimal and
> > the cost really was quite high. Worse, I believe their presence
> > in the standard tended to stall (if not outright prevent) work on
> > anything better.

>
> In particular, modules. As I understand it.


Yes, that's exactly what I had in mind.

> > As such, removing export from the standard is almost
> > certainly for the best, because it'll allow something better to be
> > designed and put into use.

>
>
> Hopefully.


Of course, the future is always uncertain. Nonetheless, I'd say the
chances of C++ getting a useful and usable module system increased
substantially when "export" was removed.

--
Later,
Jerry.
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      03-31-2010
* Juha Nieminen:
> On 03/30/2010 08:54 PM, Robert Fendt wrote:
>> If you want the reasons why more or less nobody in the compiler
>> business likes 'export' be put a bit more eloquently and by a
>> guy who really knows his stuff, may I recommend this text:
>>
>> Herb Sutter: "Why We Can't Afford Export"
>> (http://www.open-std.org/jtc1/sc22/wg...2003/n1426.pdf)

>
> Which is *exactly* what I'm talking about.
>
> See how many times he mentions the issue of regular templates not
> having a private compilation unit with file-local data, which makes them
> inferior to regular functions/classes as well as export templates which
> do. I'll wait.
>
> On the contrary, see for example the section named "Potential Benefits
> of Export", and see if you can find any reference whatsoever to export
> templates having file-local data. I'll save you the trouble: He
> conveniently skips that tidbit.
>
> Moreover, he writes things like "A subtle but important distinction
> to keep in mind is that the inclusion and export models really are
> different source code organization models. They’re about massaging and
> organizing your source code. They are not different instantiation
> models; this means that a compiler must do essentially the same work to
> instantiate templates under either source model,
> inclusion or export."
>
> Basically he is claiming that the only thing that export templates
> allow is reorganizing your code. This is BS. He conveniently doesn't
> make any mention about file-local scopes and how regular templates don't
> have one, which makes them inferior to export templates.
>
> I have the feeling that he does this on purpose.


He he, the great conspiracy to get rid of 'export'.

Not that the world isn't full of conspiracies, I mean, who hasn't participated
in tens if not hundreds of small conspiracies, and who trusts a lawyer
(regardless of country), a Norwegian sociologist, or an English politician?

But really, consider that what others consider important may not be the same as
what you consider important, and that it's practically impossible to mention
everything related to some issue X in every context where X is involved.

Also, consider that even if your ad hominem suggestion was true it would not be
a valid argument in favor of 'export', and also that there's no way to get
'export' reinstated in the language (not to mention getting it implemented).

Just relax: 'export' is gone, and perhaps we'll get something better later.


Cheers,

- Alf
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      03-31-2010
Alf P. Steinbach <(E-Mail Removed)> wrote:
> He he, the great conspiracy to get rid of 'export'.


Yeah. I apologize if I'm sounding a bit frustrated.

I suppose I'll just have to learn to live with the fact, even though I don't like it...

> Just relax: 'export' is gone, and perhaps we'll get something better later.


Seeing how long it has taken for C++0x to get ratified (it still hasn't), I don't have my hopes too high...
 
Reply With Quote
 
AnonMail2005@gmail.com
Guest
Posts: n/a
 
      03-31-2010
On Mar 29, 9:02*am, Juha Nieminen <(E-Mail Removed)> wrote:
> * Many people argue that there is *no* advantage in using export
> templates other than the questionable advantage of being able to
> separate the declaration from the implementation (which these people
> seem to argue is only a purely cosmetic feature).
>
> * However, I have *never* seen discussed the absolutely *major*
> advantage of export templates: That they have their own compilation
> unit, which means that they have access to their own file-local scope
> (which in turn can be used to increase the modularity of the program).
> This is something which is just not possible with regular templates.
>
> * For that reason I have argued that template classes and functions
> are actually *inferior* to regular classes and functions because the
> former cannot have file-local scope while the latter can. Export
> templates would solve this deficiency.
>
> * I have been thinking about what would be the simplest example which
> is implementable with export templates and which isn't with regular
> templates (at least not without global namespace contamination). How
> about this:
>
> //---------------------------------------------------
> // MyClass.hh
> export template<typename T>
> class MyClass
> {
> *public:
> * * MyClass();
> * * // other member functions here...};
>
> //---------------------------------------------------
>
> //---------------------------------------------------
> // MyClass.cc
> namespace
> {
> * * unsigned constructorCallCounter = 0;
>
> }
>
> template<typename T>
> MyClass<T>::MyClass()
> {
> * * ++constructorCallCounter;}
>
> //---------------------------------------------------
>
> * You *could* achieve the same effect with regular templates, but
> it would require adding a new name to global scope (accessible from
> anywhere). This may not be a very viable solution if the amount of
> stuff inside the nameless namespace above is large, nor is it very
> good design.
>
> * (And no, making 'constructorCallCounter' a static member of
> MyClass is *not* the same thing because it would mean that every
> distinct template instantiation would have its own separate
> 'constructorCallCounter', rather than it being shared among all
> of them.)
>
> * Can anyone come up with some objections to the example above?
> (Note that the example is not intended to be an example of actual
> usage, but instead the simplest possible example that demonstrates
> the issue.)


This is what we do which I think gets at the benefits you mentioned w/
o using export:

1. Separate the code into a header (*.h) and an implementation file
(*.tcc). For instance, a template of some container would be
separated into a MyContainer.h and MyContainer.tcc.

2. Particular instances of MyContainer would be "implemented" using a
stub header and implementation file. The header would just be a
typedef (e.g. MyContainerInt.h) and would include only MyContainer.h.
The header is purely for ease of use and not required. The
implementation file (e.g MyContainerInt.cpp) would explicitly
instantiate the class and would include the MyContainer.tcc file.
Using explicit instatiation gives you a separate compilation unit.

3. Users of the MyContainerInt would only include MyContainerInt.h.

We used the above with success for our in house implementation of
smart pointers.

HTH
 
Reply With Quote
 
Brian
Guest
Posts: n/a
 
      03-31-2010
On Mar 30, 2:30*pm, Jerry Coffin <(E-Mail Removed)> wrote:
> In article <4bb0ce73$0$11873$(E-Mail Removed)>,
> (E-Mail Removed) says...
>
> [ ... ]
>
> > * Some people argue that export templates have no advantages
> > whatsoever. This is a huge lie. I have *never* seen these people
> > talking about the issue of template classes and functions not
> > having local scope, while regular classes and functions, as well as
> > export templates do. It's like they are cherry-picking and choosing
> > only those alleged advantages which people think export templates
> > have but which are not very relevant.

>
> While you're right that exported templates could sometimes provide
> some benefit, the benefit really was fairly minimal and the cost
> really was quite high. Worse, I believe their presence in the
> standard tended to stall (if not outright prevent) work on anything
> better. As such, removing export from the standard is almost
> certainly for the best, because it'll allow something better to be
> designed and put into use.
>


At the least it's quite depressing that export gets
dumped without anything related being adopted.
How long is it going to take for someone to build
a better approach? Wouldn't it have made more
sense to keep export until it's clear that there
is a better approach?


Brian Wood
http://webEbenezer.net
(651) 251-9384
 
Reply With Quote
 
Brian
Guest
Posts: n/a
 
      03-31-2010
On Mar 30, 12:54*pm, Robert Fendt <(E-Mail Removed)> wrote:

>
> That said, nobody prevents you from writing an implementation of
> export. GCC is open source, just go for it. I wish you luck.
>


I think that's a poor suggestion. "When you're in a hole,
stop digging." "GCC development" is an oxymoron. Others
are working on C++ based alternatives, so there's no need
to mess around with GCC.


Brian Wood
http://webEbenezer.net
(651) 251-9384
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      03-31-2010
On 30 Mar, 20:30, Jerry Coffin <(E-Mail Removed)> wrote:
> In article <4bb0ce73$0$11873$(E-Mail Removed)>,
> (E-Mail Removed) says...


> [ ... ]


> > Some people argue that export templates have no advantages
> > whatsoever. This is a huge lie. I have *never* seen these
> > people talking about the issue of template classes and
> > functions not having local scope, while regular classes and
> > functions, as well as export templates do. It's like they
> > are cherry-picking and choosing only those alleged
> > advantages which people think export templates have but
> > which are not very relevant.


> While you're right that exported templates could sometimes
> provide some benefit, the benefit really was fairly minimal
> and the cost really was quite high.


Since when is improved encapsulation a "minimal" benefit. And
from a user point of view: I get the benefit, but the cost is
paid by the compiler vendor. (I know that that's somewhat
simplified, but you get the idea.)

> Worse, I believe their presence in the standard tended to
> stall (if not outright prevent) work on anything better.


That is a potential problem. I rather opposed namespaces in the
original standard for more or less the same reason. But as the
situation now stands, we're not going to get anything better
soon.

> As such, removing export from the standard is almost certainly
> for the best, because it'll allow something better to be
> designed and put into use.


Something better has already been proposed, but not adopted, for
lack of time. Perhaps if as much effort had been put into it as
was put into getting rid of export. (Had the proposal been to
replace export with something better, I'd not be opposed.)

--
James Kanze
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      03-31-2010
On 31 Mar, 15:07, Jerry Coffin <(E-Mail Removed)> wrote:
> In article <hotkin$(E-Mail Removed)-september.org>, (E-Mail Removed)
> says...
> > * Jerry Coffin:


> [ ... ]


> Of course, the future is always uncertain. Nonetheless, I'd
> say the chances of C++ getting a useful and usable module
> system increased substantially when "export" was removed.


The chances of getting a useful and usable module system would
be higher if the effort spent in getting rid of export had been
spent on improving the proposal for module.

--
James Kanze
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
useful setting in device manager (may be useful to know!) jameshanley39@yahoo.co.uk Computer Information 2 07-07-2008 04:28 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
how to Specializations of function Templates or Overloading Function templates with Templates ? recover C++ 2 07-25-2006 02:55 AM
Templates templates templates JKop C++ 3 07-21-2004 11:44 AM



Advertisments