In article <[EMAIL PROTECTED]>, James Kanze <[EMAIL PROTECTED]> wrote: >Paul Pluzhnikov wrote: > > James Kanze <[EMAIL PROTECTED]> 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? _______________________________________________ Help-gplusplus mailing list Help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
