[config] [VC++ 14.0 aka 2015] Removing BOOST_MSVC_ENABLE_2014_JUN_CTP macro requirement.

Beman Dawes

18 Nov 2014 18 Nov '14

4:04 p.m.

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

Show replies by date

John Maddock

18 Nov 18 Nov

4:12 p.m.

...

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.

Mathias Gaunard

7:22 p.m.

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.

Beman Dawes

8:27 p.m.

On Tue, Nov 18, 2014 at 11:12 AM, 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

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

Stephan T. Lavavej

5:59 p.m.

[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

Peter Dimov

6:13 p.m.

New subject: [config] [VC++ 14.0 aka 2015] Removing BOOST_MSVC_ENABLE_2014_JUN_CTP macro requirement.

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.

Stephan T. Lavavej

7:38 p.m.

New subject: [config] [VC++ 14.0 aka 2015] Removing BOOST_MSVC_ENABLE_2014_JUN_CTP macro requirement.

[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 #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

Mathias Gaunard

7:27 p.m.

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.

Antony Polukhin

7:16 p.m.

2014-11-18 19:04 GMT+03:00 Beman Dawes : <...>

...

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)? -- Best regards, Antony Polukhin

Stephan T. Lavavej

7:33 p.m.

[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

Antony Polukhin

8:33 p.m.

2014-11-18 22:33 GMT+03:00 Stephan T. Lavavej :

...

[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

Beman Dawes

8:03 p.m.

On Tue, Nov 18, 2014 at 2:16 PM, Antony Polukhin wrote:

...

2014-11-18 19:04 GMT+03:00 Beman Dawes : <...>

...
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

3662

Age (days ago)

3662

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Antony Polukhin
Beman Dawes
John Maddock
Mathias Gaunard
Peter Dimov
Stephan T. Lavavej