This is the mail archive of the libstdc++@gcc.gnu.org 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]
Other format: [Raw text]

Re: More test results...


Jason Merrill <jason@redhat.com> writes:

| >>>>> "Phil" == Phil Edwards <phil@jaj.com> writes:
| 
| > On Wed, Mar 13, 2002 at 06:12:52PM +0000, Jason Merrill wrote:
| >> >>>>> "Phil" == Phil Edwards <phil@jaj.com> writes:
| >> 
| >> > I think the std_limits.h file became cleaner to read with that patch.
| >> > Must it be reverted?
| >> 
| >> I argued against it in an earlier note; I don't like that changing the
| >> value means changing the ABI.  Do you disagree?
| 
| > For the <limits> header?  I didn't think the ABI included things like the
| > values of numeric_limits<> on particular platforms.
| 
| No, but the patch under discussion changes several static data members to
| be inherited, so the mangled name is different.

Previously, those were implicitly generated -- thus duplicate in
each translation that referenced them.  Now, they are kept in a single
tranlation unit.  How can an application be affected?

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

I'm sure I understand you.  The standard specification of numeric_limits<>
implies that if *a* default-value is wrong for a user-defined-type then
the *entire* numeric_limits<> must be specialized for that type.  The
factorization introduced by Benjamin's patch doesn't change that
aspect, and introduces nothing new in that area.

| This might not actually be a problem in practice, but it makes me nervous.

I undertsand your skepticism but I don't think that patch changes the
ABI in a noticeable way for a moderately conforming program.

-- Gaby


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