[SG10] Some small precedence for feature testing in C++

Richard Smith richard at metafoo.co.uk
Thu Aug 1 00:13:47 CEST 2013


On Wed, Jul 31, 2013 at 12:42 PM, Smith-Rowland, Edward M <
ESmith-rowland at alionscience.com> wrote:

> Greetings,
>
> It seems we are still casting about for an approach or an aesthetic for
> the feature test macros.
>
> It occurred to me that this has been broached before in C++: TR 29124 -
> Information Technology - Programming Languages C++ - Special math functions
> (based on ISO/IEC 14882) (
> http://www.open-std.org/JTC1/sc22/WG21/docs/papers/2010/n3060.pdf).
>
> In short, they use:
>   The following macro name shall be conditionally defined by the
> implementation:
>   __STDCPP_MATH_SPEC_FUNCS__ The value 201003L, intended to indicate
> conformance to this International Standard.
>
> Proposals to add new special math functions shall have the date value
> increased appropriately.  They also deemed it important to have the date be
> a long - perhaps to accommodate platforms with 16-bit integers.  Perhaps we
> should follow suite.
>
> They also have a macro to turn off extra math functions (or maybe opt in)
> but we aren't doing that. ;-)
>
> I don't know if this has been discussed before.  I don't know if we care
> about stylistic compatibility.  I kind of like compatibility personally.
>  We could however *add* an alias __cpp_lib_special_functions equal to
> __STDCPP_MATH_SPEC_FUNCS__.  Our macro would not be defined if the feature
> control macro,   __STDCPP_WANT_MATH_SPEC_FUNCS__, was set to 0 (or if the
> math special functions are otherwise unavailable).
>
> (FYI: The special function TR number is wrong on the ISO website)


We have two similar feature-test macros already in the standard (16.8/2):

__STDCPP_STRICT_POINTER_SAFETY__
__STDCPP_THREADS__

I think the inconsistency between our recommendations and these is
unfortunate. Should we consider using names of that style instead of our
existing __cpp_* names? The above names are guaranteed to be defined to 1
if the feature is available, so this wouldn't be an exact match for our
recommendations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/features/attachments/20130731/b72a8a06/attachment.html 


More information about the Features mailing list