stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: status of <type_traits> with gcc
Date Fri, 27 Jun 2008 22:44:49 GMT
Travis Vitek wrote:
>> -----Original Message-----
>> From: Martin Sebor [] On Behalf Of Martin Sebor
>> Sent: Thursday, June 26, 2008 3:31 PM
>> To:
>> Subject: Re: status of <type_traits> with gcc
>> Travis Vitek wrote:
>>> Martin Sebor wrote:
>>>> I'm getting compilation errors with gcc 4.3. Is the implementation
>>>> supposed to be stable at this point with any compiler or are there
>>>> still some major issues?
>>> I just did a sync of 4.3.x and a build with CXXFLAGS="-std=gnu++0x
>>> -D_RWSTD_EXT_CXX_0X" and didn't run into any problems with 
>> <type_traits>
>>> or the 20.meta.*.cpp tests (though 20.forward.cpp and
>>> 26.valarray.cassign.cpp both fail to compile).
>>> I did another build without those flags and I do see some 
>> compile errors
>>> in both the traits and tuple code. I'll fix the traits issues.
>> Thanks. I hadn't realized I needed -std=gnu++0x and was getting
>> a ton of errors. That, and I also forgot to reconfigure to get
>> Btw., to make using C++ 0x easier we might want to automatically
>> #define _RWSTD_EXT_CXX_0X when the __GXX_EXPERIMENTAL_CXX0X__
>> macro is #defined (and #undef _RWSTD_NO_VARIADIC_TEMPLATES and
>> other config macros #defined as a result of the absence of the
>> option during configuration).
> Yeah, but some of these options might break compatibility.

I suspect it's unrealistic for us to try to constrain the C++ 0x
implementation by the rules of binary compatibility while the spec
is still in development or between pre-C++ 0x compilers and those
that provide the essential C++ 0x core features that the library
depends on.

Just like gcc users who choose to compile with -std=gnu++0x
cannot expect libstdc++ implementation of C++ 0x to stay stable
across compiler releases (either at the ABI level or at source
level), neither will be able to users of stdcxx until the final
standard is in place.

> Imagine an exported function that takes an rvalue reference parameter.
> The library would be configured without rvalue references, but then the
> user 'enables' c++0x support by compiling with -std=gnu++0x. Now they
> might get a link error, right?

I don't see how they could. There's no such thing as rvalue
references in today's C++ and I can't think of any way to
emulate them. Enabling C++ 0x support (e.g., using gcc's
-std=gnu++0x option) will only add new overloads taking
rvalue references; it won't remove any.


View raw message