[config] MSVC feature-test macros
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
On 27 June 2018 at 23:21, Stephan T. Lavavej via Boost < boost@lists.boost.org> 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*
[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
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
-----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.
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.
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.
On Thu, Jun 28, 2018, 00:56 degski via Boost
On 27 June 2018 at 23:21, Stephan T. Lavavej via Boost < boost@lists.boost.org> 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.
participants (6)
-
degski -
Edward Diener -
Gavin Lambert -
Matt Calabrese -
mike.dev＠gmx.de -
Stephan T. Lavavej