templates
puzzlecracker
C++ has been around since 1986, why templates are still regarded is a
new feature by most compiler vendors and not fully supported (for
example export feature). Look at other popular languages -- say Java,
CSharp --and templates , also known as generics, are fully implemented
and supported in latest releases. Yes, in C++ they are implemented
differently, yet not better. Then why C++ is so lagging behind. Can't
we get ourself together? It took us a decade to come up with the new
standard, yet it's still in the making -- Java 6.0 and .NET 3.0
blossomed in record time.
What's with C++? To me it's the best (and primordial) programming
language that manage to get stuck in 1969, finding it hard to make a
transition from boy to man!
Thanks.
Victor Bazarov
> C++ has been around since 1986, why templates are still regarded is a
> why C++ is so lagging behind. Can't
> What's with C++? [..]
The compiler designers and implementors must have been patiently waiting
for *you* to join them in the effort...
On the second thought, stick to making noise here, it's less damage this
way. And we like you. Honest. We do. What are we going to do if
you'd leave us to work on improving C++'s handling of templates? <sob>
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
James Kanze
> C++ has been around since 1986, why templates are still
> regarded is a new feature by most compiler vendors and not
> fully supported (for example export feature).
That is a real question. About the only answer I can give is
that I think that the vendors don't care about the standard (or
their users).
> Look at other popular languages -- say Java, CSharp --and
> templates , also known as generics, are fully implemented and
> supported in latest releases.
Two major differences. First, generics in Java (and I suppose
C#---I don't know the language) are several orders of magnitude
simpler than templates in C++. (And a lot less powerful.)
Second, neither language has a standard, and both have a
"primary provider", who more or less "standardizes" what he
wants, or in other words, what is easy for him to implement.
> Yes, in C++ they are implemented differently, yet not better.
They are specified differently, not just implemented
differently. As for better... C++ templates are significantly
more powerful than the templates in other languages, and that
does cause implementors problems.
> Then why C++ is so lagging behind. Can't we get ourself
> together? It took us a decade to come up with the new
> standard, yet it's still in the making -- Java 6.0 and .NET
> 3.0 blossomed in record time.
I'm tempted to say: it shows:-).
There's a major different: C++ has an ISO standard. Which
imposes a certain degree of stability. You can't change it
every six months.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
puzzlecracker
> That is a real question. About the only answer I can give is
> that I think that the vendors don't care about the standard (or
> their users).
Unless, templates won't gain a wide acceptance, there is no reason not
to implement them. Usually more useful features packed in the
compiler, translates into $$$$
> Two major differences. First, generics in Java (and I suppose
> C#---I don't know the language) are several orders of magnitude
> simpler than templates in C++. (And a lot less powerful.)
> Second, neither language has a standard, and both have a
> "primary provider", who more or less "standardizes" what he
> wants, or in other words, what is easy for him to implement.
Wouldn't be better if standardization committee was affiliated, if not
fully responsible, for the implementation, much like with C# and Java?
> > Yes, in C++ they are implemented differently, yet not better.
>
> They are specified differently, not just implemented
> differently. As for better... C++ templates are significantly
> more powerful than the templates in other languages, and that
> does cause implementors problems.
I agree, they're more powerful in essence, yet most its power has yet
to come to compiler vendors. At my current employer (as well as
previous) we don't have any code using templates; thought this is not
a representative sample set.
Thanks
Jeff Schwab
> Team,
Chief!
> C++ has been around since 1986, why templates are still regarded is a
> new feature by most compiler vendors and not fully supported (for
> example export feature).
The export feature never caught on because it requires much more
powerful linkers than people actually have, or else some heavy-handed
work-arounds in the build environment.
> Look at other popular languages -- say Java,
> CSharp --and templates , also known as generics, are fully implemented
> and supported in latest releases.Yes, in C++ they are implemented
> differently, yet not better.
Templates and generics are not the same thing. They're not even close,
except in syntax. Their nearest C++ relatives may be concept checks.
Whether templates are "better" is sort of an apples and oranges
comparison, but I'd certainly rather have C++ templates than Java generics.
> Then why C++ is so lagging behind. Can't
> we get ourself together? It took us a decade to come up with the new
> standard, yet it's still in the making -- Java 6.0 and .NET 3.0
> blossomed in record time.
"Us?" I wasn't aware you were on the ISO/IEC JTC1/SC22/WG21 committe.
Thank you for all your time and effort.
> What's with C++? To me it's the best (and primordial) programming
> language that manage to get stuck in 1969, finding it hard to make a
> transition from boy to man!
It's the best for some (OK, most) programming tasks, but certainly not
for all. It's kind of hard to write a practical client-side HTML form
validator in C++. By the way, I don't think "primordial" means what you
think it means.
Juha Nieminen
> Team,
>
> C++ has been around since 1986, why templates are still regarded is a
> new feature by most compiler vendors and not fully supported (for
> example export feature). Look at other popular languages -- say Java,
> CSharp --and templates , also known as generics, are fully implemented
> and supported in latest releases. Yes, in C++ they are implemented
> differently, yet not better. Then why C++ is so lagging behind. Can't
> we get ourself together? It took us a decade to come up with the new
> standard, yet it's still in the making -- Java 6.0 and .NET 3.0
> blossomed in record time.
Java and C# *don't* implement export templates, as defined by the C++
standard. Nothing even close.
Most modern C++ compilers implement almost everything in the C++
standard except export templates. That's not because all the compiler
developers are lazy. It's because it's a complicated problem (and not
something deemed very urgent, as people can live without).
puzzlecracker
New standard is coming: any thoughts as to its commercial acceptance?
I wonder how much of cli will be compilable as well as used in the
industry upon its release
Erik Wikström
>> That is a real question. About the only answer I can give is
>> that I think that the vendors don't care about the standard (or
>> their users).
>
> Unless, templates won't gain a wide acceptance, there is no reason not
> to implement them. Usually more useful features packed in the
> compiler, translates into $$$$
>
>
>> Two major differences. First, generics in Java (and I suppose
>> C#---I don't know the language) are several orders of magnitude
>> simpler than templates in C++. (And a lot less powerful.)
>> Second, neither language has a standard, and both have a
>> "primary provider", who more or less "standardizes" what he
>> wants, or in other words, what is easy for him to implement.
>
> Wouldn't be better if standardization committee was affiliated, if not
> fully responsible, for the implementation, much like with C# and Java?
Sure it would, will you pay them? The people who partake in the
standardisation effort does not get paid (at least not by ISO) to do so.
They do it on their own time and for their own money unless they can
convince some company to do it for them.
>> > Yes, in C++ they are implemented differently, yet not better.
>>
>> They are specified differently, not just implemented
>> differently. As for better... C++ templates are significantly
>> more powerful than the templates in other languages, and that
>> does cause implementors problems.
>
> I agree, they're more powerful in essence, yet most its power has yet
> to come to compiler vendors. At my current employer (as well as
> previous) we don't have any code using templates; thought this is not
> a representative sample set.
And what exactly is it that your compiler does not support (except for
export)? And what compiler are you using? Those compilers I've been
using supports templates quite well, while you might not be able to do
all the fancy MTP the standard allows you can do everything (except
export) that I've ever tried.
--
Erik Wikström
James Kanze
> > That is a real question. About the only answer I can give
> > is that I think that the vendors don't care about the
> > standard (or their users).
> Unless, templates won't gain a wide acceptance, there is no
> reason not to implement them. Usually more useful features
> packed in the compiler, translates into $$$$
> > Two major differences. First, generics in Java (and I
> > suppose C#---I don't know the language) are several orders
> > of magnitude simpler than templates in C++. (And a lot less
> > powerful.) Second, neither language has a standard, and both
> > have a "primary provider", who more or less "standardizes"
> > what he wants, or in other words, what is easy for him to
> > implement.
> Wouldn't be better if standardization committee was
> affiliated, if not fully responsible, for the implementation,
> much like with C# and Java?
Yes. It would be great. Get a fully conformant compiler for
free.
The problem is: who's going to pay for it? In the case of Java
or C#, one company pays, because they control the specification,
in their interest, not in yours. In the case of C++, it's an
official international standard, and anyone can participate.
There are some real users on the committee, and several
different, competing implementors, so it doesn't end up working
for just one large company.
> > > Yes, in C++ they are implemented differently, yet not
> > > better.
> > They are specified differently, not just implemented
> > differently. As for better... C++ templates are
> > significantly more powerful than the templates in other
> > languages, and that does cause implementors problems.
> I agree, they're more powerful in essence, yet most its power
> has yet to come to compiler vendors.
Are you kidding? All of the power (e.g. export) isn't always
there, but many of the techniques not available in Java are
implemented in just about every compiler. (Well, at least the
ones available to me: g++, Sun CC and VC++.)
> At my current employer (as well as previous) we don't have any
> code using templates; though this is not a representative
> sample set.
I'll say. I think I qualify as one of the most conservative
users in production code, but I (and every company I've worked
for) started using templates close to ten years ago.
(Experimental implementations were available over twenty years
ago.)
James Kanze
> puzzlecracker wrote:
> The export feature never caught on because it requires much
> more powerful linkers than people actually have, or else some
> heavy-handed work-arounds in the build environment.
Comeau seems to do it without any problems. With the system
standard linker.
> > Look at other popular languages -- say Java, CSharp --and
> > templates , also known as generics, are fully implemented
> > and supported in latest releases.Yes, in C++ they are
> > implemented differently, yet not better.
> Templates and generics are not the same thing. They're not
> even close, except in syntax. Their nearest C++ relatives may
> be concept checks. Whether templates are "better" is sort of
> an apples and oranges comparison, but I'd certainly rather
> have C++ templates than Java generics.
At the user level, generics work more or less like the earliest
stuff we did with templates. (In other words, they're about
twenty years behind.)
James Kanze
All of the major compiler vendors are actively working with the
committee, and for the most part, they're at least pretending
that they intend to implement whatever is standardized.
Jeff Schwab
> On Oct 1, 2:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>> puzzlecracker wrote:
>
>> The export feature never caught on because it requires much
>> more powerful linkers than people actually have, or else some
>> heavy-handed work-arounds in the build environment.
>
> Comeau seems to do it without any problems. With the system
> standard linker.
How does Comeau know, as it parses the template definition, which
instantiations will be necessary in a particular application? This
information cannot be known until link time, which is the first time the
whole application is seen by the same tool. At that point, during the
link, the compiler must be re-invoked, to compile whichever template
instantiations are needed by the various object files. Of course,
standard linkers do not re-invoke the compiler with lists of template
instantiations, so "export" does not work with them. Either all
tranlation units (that rely on exported template definitions) have to be
available at the same time, or else a special linker must be used. I
don't know whether Comeau is quietly using special, ancillary build
tools to augment the standard linker, or else imposing extra
requirements that disallow the separate compilation of TUs that rely on
exported template definitions, but it has to do one or the other.
>>> Look at other popular languages -- say Java, CSharp --and
>>> templates , also known as generics, are fully implemented
>>> and supported in latest releases.Yes, in C++ they are
>>> implemented differently, yet not better.
>
>> Templates and generics are not the same thing. They're not
>> even close, except in syntax. Their nearest C++ relatives may
>> be concept checks. Whether templates are "better" is sort of
>> an apples and oranges comparison, but I'd certainly rather
>> have C++ templates than Java generics.
>
> At the user level, generics work more or less like the earliest
> stuff we did with templates. (In other words, they're about
> twenty years behind.)
That's true in a trivial sense, but even then, templates were a lot more
powerful than generics are now. Templates have always provided an
in-language code generation mechanism that generics don't, even when
templates were just used to define generic container types. For
example, if you never instantiate a template, no code is generated for
it; the same is not true of a "generic" class in Java. Similarly, a
simple factory function like create<T>() cannot be implemented using
Java generics, because the "generic" parameters are only used to check
concepts, not to generate new code.
Paavo Helde
>
> New standard is coming: any thoughts as to its commercial acceptance?
As far as I have understood, one of the most important points the standards
committee considers for each new feature is its implementability. If they
would not do that, the standard would lose its credibility.
I believe they failed with the template export in this regard, and that's
why it is generally not implemented. Fortunately, this does not affect much
the usability of templates themselves.
> I wonder how much of cli will be compilable as well as used in the
> industry upon its release
What's cli?
Regards
Paavo
Pete Becker
> James Kanze wrote:
>> On Oct 1, 2:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>>> puzzlecracker wrote:
>>
>>> The export feature never caught on because it requires much
>>> more powerful linkers than people actually have, or else some
>>> heavy-handed work-arounds in the build environment.
>>
>> Comeau seems to do it without any problems. With the system
>> standard linker.
>
> How does Comeau know, as it parses the template definition, which
> instantiations will be necessary in a particular application? This
> information cannot be known until link time, which is the first time
> the whole application is seen by the same tool. At that point, during
> the link, the compiler must be re-invoked, to compile whichever
> template instantiations are needed by the various object files. Of
> course, standard linkers do not re-invoke the compiler with lists of
> template instantiations, so "export" does not work with them. Either
> all tranlation units (that rely on exported template definitions) have
> to be available at the same time, or else a special linker must be used.
Not necessarily. I haven't looked at how Comeau does it, but one
approach would be for a driver program to parse the error messages from
the linker to figure out which template instantiations to generate next.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)
Jeff Schwab
> On 2008-10-01 16:20:02 -0400, Jeff Schwab <je...@schwabcenter.com> said:
>
>> James Kanze wrote:
>>> On Oct 1, 2:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>>>> puzzlecracker wrote:
>>>
>>>> The export feature never caught on because it requires much
>>>> more powerful linkers than people actually have, or else some
>>>> heavy-handed work-arounds in the build environment.
>>>
>>> Comeau seems to do it without any problems. With the system
>>> standard linker.
>>
>> How does Comeau know, as it parses the template definition, which
>> instantiations will be necessary in a particular application? This
>> information cannot be known until link time, which is the first time
>> the whole application is seen by the same tool. At that point, during
>> the link, the compiler must be re-invoked, to compile whichever
>> template instantiations are needed by the various object files. Of
>> course, standard linkers do not re-invoke the compiler with lists of
>> template instantiations, so "export" does not work with them. Either
>> all tranlation units (that rely on exported template definitions) have
>> to be available at the same time, or else a special linker must be used.
>
> Not necessarily. I haven't looked at how Comeau does it, but one
> approach would be for a driver program to parse the error messages from
> the linker to figure out which template instantiations to generate next.
Snipped: "I don't know whether Comeau is quietly using special,
ancillary build tools to augment the standard linker..."
Victor Bazarov
> puzzlecracker <irons...@gmail.com> kirjutas:
>> I wonder how much of cli will be compilable as well as used in the
>> industry upon its release
>
> What's cli?
Common Language Infrastructure, see
http://en.wikipedia.org/wiki/Common_Language_Infrastructure or any MS
marketting spiel about it.
Hendrik Schober
> James Kanze wrote:
>> On Oct 1, 2:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>>> puzzlecracker wrote:
>>> The export feature never caught on because it requires much
>>> more powerful linkers than people actually have, or else some
>>> heavy-handed work-arounds in the build environment.
>> Comeau seems to do it without any problems. With the system
>> standard linker.
>
> How does Comeau know, as it parses the template definition, which
I wouldn't know, but from what I understand, it seems that
you cannot implement 'export' while sticking to the old
one-translation-unit-at-a-time approach anyway.
Schobi
Paavo Helde
> Paavo Helde wrote:
>> puzzlecracker <irons...@gmail.com> kirjutas:
>>> I wonder how much of cli will be compilable as well as used in the
>>> industry upon its release
>>
>> What's cli?
>
> Common Language Infrastructure, see
> http://en.wikipedia.org/wiki/Common_Language_Infrastructure or any MS
> marketting spiel about it.
Or maybe Command-Line Interface?
Honestly, I do not see how a MS clone of Java runtime engine would relate
to C++ templates :-S
Best regards
Paavo
Juha Nieminen
> As far as I have understood, one of the most important points the standards
> committee considers for each new feature is its implementability. If they
> would not do that, the standard would lose its credibility.
>
> I believe they failed with the template export in this regard, and that's
> why it is generally not implemented. Fortunately, this does not affect much
> the usability of templates themselves.
If I'm not mistaken, they made a proof of concept of export templates
to prove that they are implementable. And they have been fully
implemented by at least one compiler. So they are demonstrably
implementable.
AFAIK the reason why compilers haven't implemented it at large is
because fully supporting export templates usually requires a complete
restructuring of the compiler code, which in turn requires basically
rewriting the entire compiler from scratch. Compiler vendors are not too
happy about that.
So it's not so much about implementability, as how much work it would
require to implement them.
Of course one could argue that this just demonstrates that C++
compilers have been designed the wrong way in the first place, and that
current compilers drag historical design overhead from the past.
James Kanze
> On 2008-10-01 16:20:02 -0400, Jeff Schwab <j...@schwabcenter.com> said:
> > James Kanze wrote:
> >> On Oct 1, 2:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
> >>> puzzlecracker wrote:
> >>> The export feature never caught on because it requires much
> >>> more powerful linkers than people actually have, or else some
> >>> heavy-handed work-arounds in the build environment.
> >> Comeau seems to do it without any problems. With the system
> >> standard linker.
> > How does Comeau know, as it parses the template definition, which
> > instantiations will be necessary in a particular application? This
> > information cannot be known until link time, which is the first time
> > the whole application is seen by the same tool. At that point, during
> > the link, the compiler must be re-invoked, to compile whichever
> > template instantiations are needed by the various object files. Of
> > course, standard linkers do not re-invoke the compiler with lists of
> > template instantiations, so "export" does not work with them. Either
> > all tranlation units (that rely on exported template definitions) have
> > to be available at the same time, or else a special linker
> > must be used.
> Not necessarily. I haven't looked at how Comeau does it, but
> one approach would be for a driver program to parse the error
> messages from the linker to figure out which template
> instantiations to generate next.
You mean like CFront did:-).
The real problem isn't knowing which templates to instantiate.
There are tons of solutions for that. The real problem is
synthesizing the correct instantiation context once you've
decided to generate them. There is a sense in which Jeff is
right: the information in a typical object file (.o or .obj)
isn't sufficient, and that's all typical linkers deal with. But
there's no rule that a compiler can only generate object files;
if I look in a directory where I've compiled with VC++, I find
not only my sources, the .obj and the .exe, but also .ilk and
.pdb, and there's nothing to prevent compilers from doing
likewise under Unix. And there's nothing to prevent the
compiler from using some other mechanism---didn't Visual Age use
a data base for such things?
It's clear that you need more than the classical compile and
link. But that's why you invoke g++ instead of gcc (or CC
instead of cc---VC++ uses a different technique to decide what
to do, but you still invoke cl to link, and not link); the
driver invokes whatever additional steps are necessary.
James Kanze
In a certain sense, you can't implement templates with this
approach. The old one-translation-unit-at-a-time approach
doesn't allow for duplicate definitions.
I don't think it's the case with Comeau, but an implementation
could certainly require the sources for the templates to have
been compiled before compiling client code, or even require the
sources to be available when compiling client code. You'd loose
some of the advantages of export, but you'd still get one
important advantage: definitions in the client code (including
macros!) would not be used when compiling the template
instantiation, except for dependent names.
James Kanze
> puzzlecracker <ironsel2...@gmail.com> kirjutas:
> As far as I have understood, one of the most important points
> the standards committee considers for each new feature is its
> implementability. If they would not do that, the standard
> would lose its credibility.
> I believe they failed with the template export in this regard,
> and that's why it is generally not implemented. Fortunately,
> this does not affect much the usability of templates
> themselves.
Except for making templates unusable at the application level.
(And of course, export is implementable, since it has been
implemented. By a company with a lot less resources than
Microsoft or Sun.)
Jeff Schwab
> On Oct 1, 10:46 pm, Pete Becker <p...@versatilecoding.com> wrote:
>> On 2008-10-01 16:20:02 -0400, Jeff Schwab <j...@schwabcenter.com> said:
>>> James Kanze wrote:
>>>> On Oct 1, 2:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>>>>> puzzlecracker wrote:
>>>>> The export feature never caught on because it requires much
>>>>> more powerful linkers than people actually have, or else some
>>>>> heavy-handed work-arounds in the build environment.
>>>> Comeau seems to do it without any problems. With the system
>>>> standard linker.
>>> Either
>>> all tranlation units (that rely on exported template definitions) have
>>> to be available at the same time, or else a special linker
>>> must be used.
>> one approach would be for a driver program to parse the error
>> messages from the linker to figure out which template
>> instantiations to generate next.
> There is a sense in which Jeff is right:
Kind words.
> the information in a typical object file (.o or .obj)
> isn't sufficient, and that's all typical linkers deal with. But
> there's no rule that a compiler can only generate object files;
> if I look in a directory where I've compiled with VC++, I find
> not only my sources, the .obj and the .exe, but also .ilk and
> .pdb, and there's nothing to prevent compilers from doing
> likewise under Unix. And there's nothing to prevent the
> compiler from using some other mechanism---didn't Visual Age use
> a data base for such things?
>
> It's clear that you need more than the classical compile and
> link. But that's why you invoke g++ instead of gcc (or CC
> instead of cc---VC++ uses a different technique to decide what
> to do, but you still invoke cl to link, and not link); the
> driver invokes whatever additional steps are necessary.
This sounds like a perfect opportunity for a 3rd-party tool. I'm
curious: If there is just not much demand for "export", how did it get
through committee in the first place? It seems like a low-ROI feature.
James Kanze
> James Kanze wrote:
[...]
> I'm curious: If there is just not much demand for "export",
> how did it get through committee in the first place? It seems
> like a low-ROI feature.
There's a real need for it, if you're working on large projects.
But the vendors aren't motivated; the administrations for large
projects won't buy from realy small suppliers like Comeau, and
you can't use the fact that your vendor doesn't have it as an
argument to change vendors if the other's don't have it. So as
long as no one really offers it, the users suffer, but the
vendors aren't motivated to implement it.
Bo Persson
> On Oct 1, 11:50 pm, Hendrik Schober <spamt...@gmx.de> wrote:
>> Jeff Schwab wrote:
>>> James Kanze wrote:
>>>> On Oct 1, 2:58 pm, Jeff Schwab <j...@schwabcenter.com> wrote:
>>>>> puzzlecracker wrote:
>>>>> The export feature never caught on because it requires much
>>>>> more powerful linkers than people actually have, or else some
>>>>> heavy-handed work-arounds in the build environment.
>>>> Comeau seems to do it without any problems. With the system
>>>> standard linker.
>
>>> How does Comeau know, as it parses the template definition,
>>> which instantiations will be necessary in a particular
>>> application? [...]
>
>> I wouldn't know, but from what I understand, it seems that
>> you cannot implement 'export' while sticking to the old
>> one-translation-unit-at-a-time approach anyway.
>
> In a certain sense, you can't implement templates with this
> approach. The old one-translation-unit-at-a-time approach
> doesn't allow for duplicate definitions.
>
> I don't think it's the case with Comeau, but an implementation
> could certainly require the sources for the templates to have
> been compiled before compiling client code, or even require the
> sources to be available when compiling client code.
It has chosen the second approach. The compiler driver will make sure
that all needed instantiations are present, before it invokes the
linker. The source will be needed for anything missing at that point.
http://www.comeaucomputing.com/4.0/docs/userman/export.html
> You'd loose
> some of the advantages of export, but you'd still get one
> important advantage: definitions in the client code (including
> macros!) would not be used when compiling the template
> instantiation, except for dependent names.
And each specific instantiation might only have to be compiled once,
std::string or the iostreams, for example.
Bo Persson
Pete Becker
>
> And each specific instantiation might only have to be compiled once,
> std::string or the iostreams, for example.
>
Or not compiled at all, if they're explicitly instantiated in the library.
Hendrik Schober
> [...]
>
> This sounds like a perfect opportunity for a 3rd-party tool. I'm
> curious: If there is just not much demand for "export", how did it get
> through committee in the first place? It seems like a low-ROI feature.
My problem with templates is this:
In order to implement template A, you need template B and C,
which in turn need E, F, G, H, I and this drags in everything
up to Z... So whenever you change the marginally helper's
helper Z, you have to have to re-compile the whole application,
even though virtually nobody uses it. As James said, that's a
real PITA for every bigger project. (Up to this year I have
worked a lot for a 4MLoC project. We spent a lot of money on
some 3rd-party tool for distributed compilation to solve this
by throwing raw processing power at it.
According to people who implemented or used 'export', it is
(despite all the FUD spread about it) actually able to solve
this problem.
That's why I want to have it.
Schobi
Jerry Coffin
je...@schwabcenter.com says...
[ ... ]
> How does Comeau know, as it parses the template definition, which
> instantiations will be necessary in a particular application? This
> information cannot be known until link time, which is the first time the
> whole application is seen by the same tool. At that point, during the
> link, the compiler must be re-invoked, to compile whichever template
> instantiations are needed by the various object files. Of course,
> standard linkers do not re-invoke the compiler with lists of template
> instantiations, so "export" does not work with them. Either all
> tranlation units (that rely on exported template definitions) have to be
> available at the same time, or else a special linker must be used. I
> don't know whether Comeau is quietly using special, ancillary build
> tools to augment the standard linker, or else imposing extra
> requirements that disallow the separate compilation of TUs that rely on
> exported template definitions, but it has to do one or the other.
Comeau uses a pre-linker that can re-invoke the compiler to produce new
template instantiations when/if necessary.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry Coffin
@u65g2000hsc.googlegroups.com>, irons...@gmail.com says...
> Team,
>
> C++ has been around since 1986, why templates are still regarded is a
> new feature by most compiler vendors and not fully supported (for
> CSharp --and templates , also known as generics, are fully implemented
> differently, yet not better.
"Better" is (of course) a value judgement, rather than a technical
statement. Nonetheless, I think there's a pretty fair argument to be
made that C++ templates _are_ better, at least from the viewpoint that
they provide a superset of the capabilities of generics in Java or C#.
> Then why C++ is so lagging behind. Can't
> we get ourself together? It took us a decade to come up with the new
> standard, yet it's still in the making -- Java 6.0 and .NET 3.0
> blossomed in record time.
There are a couple of factors. First of all, Java and .Net are each
developed by a single company, without any requirement for consensus
from a large group of people, whereas C++ is a result of an ISO
committee, which is composed of representatives from several national
committees. Each of those, in turn, represents a number of different
interests, many with substantially different values and aims.
Second, Java and .Net are, in many ways, much more primitive than C++.
While they certainly add _some_ new features, most of what either
provides was present (and in some cases even more fully developed) in
much older languages such as Smalltalk and Lisp, most of them going back
for (at least) a few decades before anybody even dreamed of Java or
.Net.
> What's with C++? To me it's the best (and primordial) programming
> language that manage to get stuck in 1969, finding it hard to make a
> transition from boy to man!
My guess is that you started programming a lot later than 1969. I
started later than that, and even when I started things were a long ways
behind what I can expect from C++ today. With Fortran 66, it was
difficult to even do somthing as simple as reading data until you
reached the end of the file. Nowadys I'm concerned with at least some
level of internationalization. At that time, I had to use non-portable
tricks to get output with both upper and lower case English characters.