[config] [VC++ 14.0 aka 2015] Removing BOOST_MSVC_ENABLE_2014_JUN_CTP macro requirement.
As of the moment, the BOOST_MSVC_ENABLE_2014_JUN_CTP macro must be defined to eliminate a bunch of macros that should not apply to the Visual Studio 2015 Preview: BOOST_NO_CXX11_ALIGNAS [no value] BOOST_NO_CXX11_CHAR16_T [no value] BOOST_NO_CXX11_CHAR32_T [no value] BOOST_NO_CXX11_INLINE_NAMESPACES [no value] BOOST_NO_CXX11_NOEXCEPT [no value] BOOST_NO_CXX11_REF_QUALIFIERS [no value] BOOST_NO_CXX11_UNICODE_LITERALS [no value] BOOST_NO_CXX11_USER_DEFINED_LITERALS [no value] In other words, the only CXX11 macros that should be defined are: BOOST_NO_CXX11_ADDRESSOF [no value] BOOST_NO_CXX11_CONSTEXPR [no value] Unless someone objects strongly in the next few hours, I'm going to remove the need for the BOOST_MSVC_ENABLE_2014_JUN_CTP macro; it is just causing confusion at this point. --Beman
Unless someone objects strongly in the next few hours, I'm going to remove the need for the BOOST_MSVC_ENABLE_2014_JUN_CTP macro; it is just causing confusion at this point.
Fine by me - BTW everything I've tested locally so far with that release looks good (other than lots of new warnings), though the real test will come when they finish off constexpr and SFINAE-expression support. John.
On 18/11/2014 17:12, John Maddock wrote:
Unless someone objects strongly in the next few hours, I'm going to remove the need for the BOOST_MSVC_ENABLE_2014_JUN_CTP macro; it is just causing confusion at this point.
Fine by me - BTW everything I've tested locally so far with that release looks good (other than lots of new warnings), though the real test will come when they finish off constexpr and SFINAE-expression support.
My personal experience is that it's a bit brittle and can easily ICE whenever you use lambdas, in particular generic ones.
On Tue, Nov 18, 2014 at 11:12 AM, John Maddock <boost.regex@virgin.net> wrote:
Unless someone objects strongly in the next few hours, I'm going to remove
the need for the BOOST_MSVC_ENABLE_2014_JUN_CTP macro; it is just causing confusion at this point.
Fine by me
Done. "develop" changes pushed.
- BTW everything I've tested locally so far with that release looks good (other than lots of new warnings),
Yes, I've got some work ahead to clear new warnings in my code.
though the real test will come when they finish off constexpr and SFINAE-expression support.
Don't forget 2-phase name lookup, although that isn't going to be in this release AFAIK:-)
--Beman
[Beman Dawes]
As of the moment, the BOOST_MSVC_ENABLE_2014_JUN_CTP macro must be defined to eliminate a bunch of macros that should not apply to the Visual Studio 2015 Preview: BOOST_NO_CXX11_ALIGNAS [no value]
FYI, alignas has a limitation in Preview that will affect any attempt to use it in aligned_storage. Specifically, classes with alignas'ed data members can't be passed by value.
BOOST_NO_CXX11_REF_QUALIFIERS [no value]
Note that Preview's STL doesn't consistently support ref-qualifiers; I'm fixing this for RTM.
In other words, the only CXX11 macros that should be defined are: BOOST_NO_CXX11_ADDRESSOF [no value]
std::addressof() is in both 2013 and 2015 Preview. I recently found a minor issue, which I'm fixing for 2015 RTM - it didn't properly handle functions. For objects it worked fine in 2013. STL
Stephan T. Lavavej wrote:
std::addressof() is in both 2013 and 2015 Preview. I recently found a minor issue, which I'm fixing for 2015 RTM - it didn't properly handle functions.
I think that this is the reason we're defining the macro for it. https://github.com/boostorg/config/blob/master/test/boost_no_cxx11_addressof... We probably also need to test it with std::nullptr_t, as this is another corner case IIRC.
[STL]
std::addressof() is in both 2013 and 2015 Preview. I recently found a minor issue, which I'm fixing for 2015 RTM - it didn't properly handle functions.
[Peter Dimov]
I think that this is the reason we're defining the macro for it.
I could have fixed this years ago if somebody had told me.
We probably also need to test it with std::nullptr_t, as this is another corner case IIRC.
Works in 2013 (also with my new implementation): C:\Temp>type meow.cpp #include <stdio.h> #include <cstddef> #include <iostream> #include <utility> using namespace std; int main() { printf("%02d.%02d.%05d.%02d\n", _MSC_VER / 100, _MSC_VER % 100, _MSC_FULL_VER % 100000, _MSC_BUILD); nullptr_t np1; nullptr_t np2; nullptr_t * p1 = addressof(np1); nullptr_t * p2 = addressof(np2); cout << boolalpha; cout << (p1 == &np1) << endl; cout << (p2 == &np2) << endl; cout << (p1 != p2) << endl; } C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp && meow meow.cpp 18.00.31101.00 true true true STL
On 18/11/2014 18:59, Stephan T. Lavavej wrote:
[Beman Dawes]
As of the moment, the BOOST_MSVC_ENABLE_2014_JUN_CTP macro must be defined to eliminate a bunch of macros that should not apply to the Visual Studio 2015 Preview: BOOST_NO_CXX11_ALIGNAS [no value]
FYI, alignas has a limitation in Preview that will affect any attempt to use it in aligned_storage. Specifically, classes with alignas'ed data members can't be passed by value.
That's not surprising, given that it is the same limitation as __declspec( align( # ), and the reasons are because it's not compatible with the ABI. The annoying bit is that building a function type that takes such types by value is enough, you don't need to actually make a call to a function. This is since VC12 I think, at least VC10 didn't have this behaviour.
[Beman Dawes]
BOOST_NO_CXX11_CHAR16_T [no value] BOOST_NO_CXX11_CHAR32_T [no value]
[Antony Polukhin]
This two bother me. Are char16_t and char32_t really new types or just typedefs (like it was with wchar_t)?
They're real types in 2015 Preview, with no compiler options to select otherwise. The STL previously provided fake typedefs, for which I'm very, *very* sorry. STL
2014-11-18 22:33 GMT+03:00 Stephan T. Lavavej <stl@exchange.microsoft.com>:
[Beman Dawes]
BOOST_NO_CXX11_CHAR16_T [no value] BOOST_NO_CXX11_CHAR32_T [no value]
[Antony Polukhin]
This two bother me. Are char16_t and char32_t really new types or just typedefs (like it was with wchar_t)?
They're real types in 2015 Preview, with no compiler options to select otherwise. The STL previously provided fake typedefs, for which I'm very, *very* sorry.
Changelog for 2015 Preview is very impressive. Thanks for the big work! -- Best regards, Antony Polukhin
On Tue, Nov 18, 2014 at 2:16 PM, Antony Polukhin <antoshkka@gmail.com> wrote:
2014-11-18 19:04 GMT+03:00 Beman Dawes <bdawes@acm.org>: <...>
BOOST_NO_CXX11_CHAR16_T [no value] BOOST_NO_CXX11_CHAR32_T [no value]
This two bother me. Are char16_t and char32_t really new types or just typedefs (like it was with wchar_t)?
As STL said, they are real types in the 14.0 preview. I ran a specific test to verify this, as the distinction between real types an typedefs is important to some code I'm working on. --Beman
participants (6)
-
Antony Polukhin -
Beman Dawes -
John Maddock -
Mathias Gaunard -
Peter Dimov -
Stephan T. Lavavej