stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: STDCXX-509
Date Wed, 17 Oct 2007 04:45:07 GMT
Travis Vitek wrote:
> I came up with three solutions to STDCXX-509. I don't really like any of
> them, but here goes.

Thanks for taking the time to work on this!

>   1. Conditionally compile the change so that it is enabled for
> platforms
>      with _RWSTD_NO_OBJECT_MANGLING defined, leaving the initialization
>      issue for another day.
>   2. Back the change out completely.
>   3. Back the change out completely. Put the unions declarations into
>      <limits> and declare instances with names that differ from the old
>      names [__rw_flt_infinity becomes __rw_flt_infinity_bits]. Change
>      the <limits> macros [_RWSTD_FLT_INFINITY] to refer to the _C_val
>      member of the unions that are declared. The library code would
>      need to be changed back to using the macros again.
>   4. A Combination of options 1 and 3
>   5. Change the version number to 5.0.
> If you want my opinion,

I certainly do! :)

> I like option 3 the best. It appears that
> numeric_limits<> is instantiated in the library for most of the native
> types, so the fix will be in place for those.

The template is explicitly specialized for all scalar types, but
all its member functions should be inlined. Programs in which it
actually is inlined (I would expect those to be the majority)
will have references to the old constants. Those are the ones we
need to maintain compatibility for, and ideally also have a fix
for. IIUC, your (3) will maintain the same behavior for this class
of programs.

The ideal fix is to define the members so as to let really smart
compilers (AFAIK, there isn't one like it yet), to treat them as
constant expressions (i.e., as if they were literals). The C++ 0x
constexpr feature will require compilers to do that.

> Any other instantiation of
> numeric_limits<> that is compiled with the new header in place will also
> get the fix.

Yes, that would work for programs compiled against 4.2.

> The only code that won't have the fix is code that was
> compiled previously and doesn't use the numeric_limits<> definitions
> provided by the library.

Right. The ones where numeric_limits members like infinity() etc.
have been inlined.

> I've attached a patch that implements solution 3. It has limited testing
> on windows only. It does affect all platforms, which makes a very
> unattractive solution at this point.

I agree. The solution I've been toying with but hoping not to have
to resort to is to declare the constants extern "C" and mangle their
names to match those in 4.1.3. We need to make a change for at least
one platform (Windows) no matter what so why not do this?

Of course, all this will be moot if we really have as serious
a problem with binary compatibility on Windows as your last message
suggested. I hope that was just some fluke. Let's talk more tomorrow.


View raw message