stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
Subject RE: status of <type_traits> with gcc
Date Thu, 26 Jun 2008 22:55:34 GMT

>-----Original Message-----
>From: Martin Sebor [] On Behalf Of Martin Sebor
>Sent: Thursday, June 26, 2008 3:31 PM
>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 
>> 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.

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?


View raw message