This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: -frepo, search-mailing-list, precomp-hdrs, native-objects



> * I may have missed important announcements...
>   Could someone please clarify the current status of egcs
>   regarding template repository (-frepo ?), future plans, documentation.

-frepo is in there, but I'm not really a fan of it.  The Borland-like
approach to resolving template definitions, also present, does the same
thing faster (expand templates in each module, use weak symbols to resolve).
The price is more code bloat, but no extra link passes.  Folks might want
to try -frepo to get a smaller executable after they have finished
development; the repeated relinks -frepo gives you can be very slow,
especially for STL users.

There have been vast improvements in templates.  The main missing feature
(as far as I'm concerned), template member functions, has just been added
to the egcs snapshots.

> * How about reviving the old idea of pre-compiled headers.

It might happen some day, I don't know of anyone working on it.

> * The pain of C++ linkage.
>   Currently it is impossible to link C++ objects that are compiled
>   with different compilers. Reasons being: 
>      * name-mangling schemes
>      * virtual table implementations
>      * static initialization methods.
>      * ??
>   
>   Now, on platforms where the native compilers (Solaris' SunPro CC?)
>   has a published object implementation, is it possible for g++ to have
>   an option to compile an object that will be linkable with 'native objects'?

It is the wrong time to do this.  The reason is that in order to implement
the full standard, Sun (and everyone else) will need to break binary
compatibility.  This is why SunPro still doesn't have bool: that affects
name mangling and breaks linkage, and they have promised their customers
that they will break backward compatibility exactly once.  Since they must
do this, it would be a waste of effort to try to link to their current
code (we'd have to disable the bool type to do it, for one, at least as
far as mangling is concerned), since they are going to break it with
version 5 (or whatever they call their ANSI-compliant version).

Now, it would be possible one the "final" standard is agreed on, and specs
have been published on certain machines (e.g. Sun), to have a mode where
g++ and SunPro can link together.  But I would consider that very low
priority, e.g. if someone wants to pay a consultant to do the work.  Many
other tasks come first, like finishing the C++ language (namespaces is the
main missing feature, and implementing namespaces will break g++ binary
compatibility with older releases).






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]