[SG10] N4230 Nested namespace definition

James Dennett jdennett at google.com
Tue Mar 24 21:10:13 CET 2015


On Mon, Mar 23, 2015 at 3:24 PM, Nelson, Clark <clark.nelson at intel.com>
wrote:

> The name __cpp_nested_namespace_definitions seems pretty obvious and
> non-controversial.
>
> But I don't think we've actually considered whether a new macro would be
> justified. How would a reasonable person write code that works both with
> and
> without this feature?
>
> #if __cpp_nested_namespace_definitions
> #define NND(x) x::
> #else
> #define NND(x)
> #endif
>
> #if !__cpp_nested_namespace_definitions
> namespace X { namespace Y {
> #endif
> void NND(X::Y) f()
> {
> }
> #if !__cpp_nested_namespace_definitions
> }}
> #endif
>
> Is it plausible that someone would write code like that? If they cared
> about
> portability to C++14, would they be more likely to just ignore this new
> feature, and write their code the old way?
>

A reasonable question... but why ask about it for just this one case?  I'd
think that this is true for many of the features for which we have feature
test macros.

__cpp_auto_deduction was one that came up most recently.  If you need
portability, you just don't rely on auto deduction from a
braced-initializer-list.  If you want a T, you use parens; if you want an
initializer_list<T>, you say so.

I've not surveyed the other macros with an eye towards which would be
useful for writing portable code.  My unsubstantiated guess is that a large
fraction aren't useful for portability, beyond just giving a clear #error
message.

-- James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/features/attachments/20150324/191288c9/attachment.html 


More information about the Features mailing list