>-----Original Message----- >From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor >Sent: Thursday, June 26, 2008 3:31 PM >To: dev@stdcxx.apache.org >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 >_RWSTD_NO_VARIADIC_TEMPLATES #defined. > >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? Travis
