This is the mail archive of the mailing list for the libstdc++ project.

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

Re: PR3042

>>>>> "Benjamin" == Benjamin Kosnik <> writes:

>> > Seconded.  The more I hear about the quirks of AIX linking semantics

> Yup. As much as I hate to keep this thread alive, I think the KDE and Qt 
> arugments advanced by David for keeping the same semantics as gcc.2.95.x 
> (which, IMHO, are broken) are a bit of a red herring: yes, these programs 
> are written in c++, but they don't really use the kinds of data 
> structures that have the difficulty.

You mean, they don't use static data member templates?

I don't see how you can consider the 2.95 semantics "broken".  They are
more conformant than Mark's proposal, in that more valid code can be
compiled.  The question is, how common is code which is accepted under the
status quo that would not be accepted under Mark's proposal?  Is it common
enough to justify the extra complexity in the compiler and for users?

I believe that the extra complexity for users is negligible.  I've
certainly never heard a complaint about it in practice.  I imagine that
most people using affected platforms are using -fno-implicit-templates or
-frepo already, or just not using templates.  Of course, that last will
probably change with template iostreams...which reminds me--we should tag
the standard instantiations provided in the library as 'extern template' so
that we don't do extra work generating redundant copies.  Maybe in 3.0.1.

WRT the extra complexity in the compiler, I have a rewrite of the linkage
code under way that should simplify this stuff significantly.

> That being said, at this point, now that most things are working, I'd 
> hate to see a significant linkage change at the last minute.



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