Date: Wed, 31 Jul 2013 22:53:45 +0000
> 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.
There's another thing about our recommendations that doesn't match those:
ours aren't technically standard; they're just (hopefully) going to be
conventional.
But maybe that's too finicky a distinction. For all we know, maybe someday
consensus will support putting these conventions into the standard. We
certainly aren't going to want to rename them at that point; maybe we should
go with names that don't emphasize the difference.
On the other hand, there's also __cplusplus -- lower case, no "std", no
final underscores. We're following that example. :-)
There's no such thing as perfect consistency.
Clark
>
> __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.
There's another thing about our recommendations that doesn't match those:
ours aren't technically standard; they're just (hopefully) going to be
conventional.
But maybe that's too finicky a distinction. For all we know, maybe someday
consensus will support putting these conventions into the standard. We
certainly aren't going to want to rename them at that point; maybe we should
go with names that don't emphasize the difference.
On the other hand, there's also __cplusplus -- lower case, no "std", no
final underscores. We're following that example. :-)
There's no such thing as perfect consistency.
Clark
Received on 2013-08-01 00:54:04