While VC10 supports nullptr (yay!), it doesn't support initializer lists or char16_t/char32_t. We picked up an <initializer_list> header from Dinkumware, but I forgot to remove it when I purged the code conditionally compiled under _HAS_INITIALIZER_LISTS from our sources. Oops. (This header doesn't actually do anything because the Core Language support is nonexistent.) We also picked up "typedef unsigned short char16_t;" and "typedef unsigned int char32_t;" from Dinkumware, but they're obviously fake and used in only one place ("typedef basic_string<char16_t> u16string;" and "typedef basic_string<char32_t> u32string;" in <string>). I should have purged this too, but I didn't realize that it would cause problems. See "C++0x Core Language Features In VC10: The Table" at http://blogs.msdn.com/vcblog/archive/2010/04/06/c-0x-core-language-features-... . Anything that's not in this table isn't supported by VC10. Also, the "Forward declared enums" row should say "No" for VC9 and VC10. Thanks, Stephan T. Lavavej Visual C++ Libraries Developer -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Tuesday, April 20, 2010 10:31 AM To: boost@lists.boost.org Subject: Re: [boost] [config] vc10 and BOOST_NO_DECLTYPE
The issue is whether the decltype keyword is too broken on VC10 to define BOOST_NO_DECLTYPE. I think it /may/ be, so we should define it just to be safe, at least for 1.43.
Eric, where do we stand on this? Does the VC10 decltype problem in the beta still exist in the final release of VC10?
decltype is still broken in the final release of VC10. e.g. the following code deduces the return type of getOne() to be one& rather than one, causing an error on the "res r" line. Bizarrely, this problem goes away if NO_CONSTRUCTOR is defined, as the return type is deduced correctly.
For the present I've added that to the BOOST_NO_DECLTYPE test case in SVN Trunk. Also defined BOOST_NO_DECLTYPE in trunk for VC10, but please do change this if there is consensus that it works "well enough". I've also stopped defining the following macros for VC10 as per ticket https://svn.boost.org/trac/boost/ticket/4110: BOOST_NO_CHAR16_T BOOST_NO_CHAR32_T BOOST_NO_INITIALIZER_LISTS BOOST_NO_NULLPTR If anyone thinks these should still be defined, please provide updated test cases. Cheers, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost