Re: Can GCC guess where to find template definitions?

[James Kanze]

Paul Pluzhnikov wrote:
> James Kanze <kanze@none> writes:

>>Why g++ never implemented this, I'll never know, given that it
>>is pretty much standard practice in the world where g++ is
>>most used.

> It is not at all a *standard* practice, though it is used by
> Sun, SGI and IBM compilers.

And the older C++ compilers for HP/UX.  In just about any CFront
derived compiler, in fact.

So how widespread does it take for something to be considered a
de facto standard.  We had it on Sun, SGI, IBM and HP/UX, at
least.  We even had it on the first Windows compiler to support
templates (a port of CFront by some Irish company whose name
I've forgotten).

> However, under certain usage scenarios all of the above
> compilers "break" (as in unable to link otherwise well-formed
> program), and debugging the reasons why they break is
> extremely painful (as is debugging any tool that thinks it is
> smarter then the programmer that is using it).

> They also wreak complete havoc on automatic dependency
> detection tools, such as ClearCase make.

The way it worked certainly wasn't without problems.  I know
that whenever you'd get really strange runtime errors, the first
thing you did was a make clean, then a total rebuild, because
there were problems in dependancy management (with CFront,
templates weren't always reinstantiated with they should have
been).  But a lot of code was written using the model, and all
of the Unix compilers I know except g++ (admittedly, that's just
Sun CC and the EDG front-end used by Comeau) continue to support
it, for reasons of backward compatiblity, if nothing else.

My argument that g++ should have supported it isn't based on any
intrinsic qualities of the model.  It's based on the fact that
there is (or was) an extensive code base which used it.

> IMHO, letting the programmer control exactly what is compiled
> when via explicit source modification is a much better option.

Never.  You'd ban makefiles?  I'd rather see them become more
intelligent, working with the compiler and the editor, so that
if all I change in a header is to modify a comment, they don't
recompile the world.

>>Dixit certain implementers (Microsoft?).  The few people I
>>know who have actually used export say only good things about
>>it.  It's not a miracle worker, but it does improve
>>encapsulation and compile times.

> They probably could have used a whole lot of other, much more
> portable techniques and achieved better compile-time speedup
> and better encapsulation.  One of the definitive books on the
> subject is "Large-Scale C++ Software Design" by John Lakos

A bit dated, but definitely required reading.  But irrelevant to
the point in question.  Export works, when implemented
correctly.  It reduces compile times, at least in some cases,
and it provides significantly better decoupling.  It's part of
the standard, and given that the standard has been around for 7
years now, there's really no excuse for any vendor not to have
implemented it.  (And obviously, g++ isn't alone here.)

--
James Kanze                                 mailto: james.kanze@free.fr
Conseils en informatique orientée objet/
                       Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34