[config] MSVC feature-test macros

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[config] MSVC feature-test macros

Boost - Dev mailing list
Hi Boost devs,

FYI, VS 2017 15.8 Preview 3 has been released, with support for feature-test macros. If you want to take advantage of the feature-test macros, please notify me immediately about any problems so I can get them fixed for the production release. Notes:

* __has_cpp_attribute is the one thing that isn't supported yet.

* There are minor changes coming for the production release of 15.8, notably L suffixing and an increase in the value for __cpp_deduction_guides.

* Library macros are defined by including any <meow> or <cmeow> header (but not <meow.h>). <ciso646> is the lightweight way to get all macros. This will be superseded by <version> in C++20, but that is not yet implemented.

* The macros are always provided regardless of the /std compiler option. (Of course their definedness and values vary.)

* We are defining __cpp_exceptions and __cpp_rtti, although those weren't picked up for C++20.

* The only fundamentally new ability that these macros provide is the ability to sense whether thread-safe statics are supported; this was previously controlled by a compiler option, but not reflected in any MSVC-specific macro.

* The macros respect all of our compiler options and library control macros - e.g. if std::byte's definition is suppressed (to avoid conflicts with the Windows SDK), then __cpp_lib_byte reflects that.

Hope this helps,
STL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] MSVC feature-test macros

Boost - Dev mailing list
On 27 June 2018 at 23:21, Stephan T. Lavavej via Boost <
[hidden email]> wrote:

> * The macros respect all of our compiler options and library control
> macros - e.g. if std::byte's definition is suppressed (to avoid conflicts
> with the Windows SDK), then __cpp_lib_byte reflects that.
>

I understand this is not really related, but on the issue of macros any
way. In rpcndr.h there's a macro "#define small char", that is well utterly
silly to high-jack that word (from the rest of the world), just for the
sake of defining a longer version of the char type.

degski
--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] MSVC feature-test macros

Boost - Dev mailing list
[degski]
> I understand this is not really related, but on the issue of macros any way.
> In rpcndr.h there's a macro "#define small char"

Yeah, that's a highly improper identifier to macroize. I scanned the Windows SDK back in Nov 2017 for such macros and reported a list of them - I'm checking on the status of that request now.

Thanks,
STL

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] MSVC feature-test macros

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Thu, Jun 28, 2018, 00:56 degski via Boost <[hidden email]> wrote:

> On 27 June 2018 at 23:21, Stephan T. Lavavej via Boost <
> [hidden email]> wrote:
>
> > * The macros respect all of our compiler options and library control
> > macros - e.g. if std::byte's definition is suppressed (to avoid conflicts
> > with the Windows SDK), then __cpp_lib_byte reflects that.
> >
>
> I understand this is not really related, but on the issue of macros any
> way. In rpcndr.h there's a macro "#define small char", that is well utterly
> silly to high-jack that word (from the rest of the world), just for the
> sake of defining a longer version of the char type.
>

Yes, especially when it could at least be a typedef. Another one I
encountered a while ago was "hyper" being a #define for a 64-bit int.

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] MSVC feature-test macros

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/28/2018 2:11 PM, Stephan T. Lavavej via Boost wrote:
> [degski]
>> I understand this is not really related, but on the issue of macros any way.
>> In rpcndr.h there's a macro "#define small char"
>
> Yeah, that's a highly improper identifier to macroize. I scanned the Windows SDK back in Nov 2017 for such macros and reported a list of them - I'm checking on the status of that request now.

What does Microsoft have against macros that are capitalized, which has
been the acknowledged convention for macros for a long time now.

>
> Thanks,
> STL


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] MSVC feature-test macros

Boost - Dev mailing list
> -----Original Message-----
> Edward Diener via Boost
> Sent: Thursday, June 28, 2018 10:37 PM
> [...]
> What does Microsoft have against macros that are capitalized, which has
> been the acknowledged convention for macros for a long time now.
I'd guess (or rather hope) that does macros predate that convention and now
they are afraid to break backwards compat (a notion very common to boost
too I might add).
But even so, I wonder what engineer thought that this was a good idea
for a macro name even then.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] MSVC feature-test macros

Boost - Dev mailing list
On 6/28/2018 6:16 PM, mike via Boost wrote:

>> -----Original Message-----
>> Edward Diener via Boost
>> Sent: Thursday, June 28, 2018 10:37 PM
>> [...]
>> What does Microsoft have against macros that are capitalized, which has
>> been the acknowledged convention for macros for a long time now.
> I'd guess (or rather hope) that does macros predate that convention and now
> they are afraid to break backwards compat (a notion very common to boost
> too I might add).
> But even so, I wonder what engineer thought that this was a good idea
> for a macro name even then.

It is evidently a newly added macro, so why would Microsoft continue to
add new macros which are not all uppercase letters ? Replicating their
stupidity for previously creating macros where the letters were not
uppercase is not a reason for continuing to do so.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [config] MSVC feature-test macros

Boost - Dev mailing list
On 29/06/2018 12:14, Edward Diener wrote:
> It is evidently a newly added macro, so why would Microsoft continue to
> add new macros which are not all uppercase letters ? Replicating their
> stupidity for previously creating macros where the letters were not
> uppercase is not a reason for continuing to do so.

You're mixing things up.  The objectionable "small" macro is older.

The new feature-test macros are new, but are safe from conflicts with
user code due to the leading double underscore.  And you can probably
blame Clang for the convention of lowercase feature macros.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost