This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: More test results...
Jason Merrill <jason@redhat.com> writes:
| >>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:
|
| >> No, but the patch under discussion changes several static data members to
| >> be inherited, so the mangled name is different. If the default is wrong
| >> for a type, it must be overridden in the (derived) specialization, so the
| >> mangled name depends on whether or not the default is correct.
|
| > Hmm. Well, numeric_limits only has meaning as a specialization. For the
| > required specializations, no derivation is required. It stands to reason
| > that non-required, user-defined specializations would also not be
| > derivations.
|
| True. But if it only has meaning as a specialization, why was the change
| useful in the first place?
On first sight, it was thought (admitely, wrongly) that the
ducplicate-symbol problem was coming from the library side whereas, in
fact, it was a compiler problem.
A reason why I approved it is that it contributes to reduce the footprint.
| > The idea that now __numeric_limits_base* is in the exported symbols list
| > is the bit that personally makes me nervous. I thought this was the part
| > that you were nervous about.
|
| I was concerned about changing the mangled name of, say,
|
| std::numeric_limits<std::string>::is_integer
How can a conforming program be affected, now that the corresponding
symbol definition is kept in a single place?
-- Gaby