Re: Can GCC guess where to find template definitions?

[Greg Comeau]

In article <4279f5ac$0$285$636a15ce@news.free.fr>,
James Kanze  <kanze@none> wrote:
>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).

You're thinking of Glockenspiel.  I recall we (Comeau Computing)
were the first with a cfront based compiler supporting templates,
but could be recalling it incorrectly.

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

Correct.

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

Agreed, and then some: It's been years already now since it's
been available for use with Comeau C++.
-- 
Greg Comeau / Comeau for the Mac?   Stay tuned.
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?