templates

[puzzlecracker]

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.

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.

 

[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.

 

[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?

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

 

[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]

  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).

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]

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 $$$$



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.

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.

 

[James Kanze]

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 $$$$

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.

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.

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]

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

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.

 

[Hendrik Schober]

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.

Schobi

 

[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]

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]

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. 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 <[email protected]> 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.)

 

[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]

James Kanze 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

 

[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]

[ ... ]

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.

 

[Jerry Coffin]

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.

"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.