C++ Logo


Advanced search

Re: [SG10] N4230 Nested namespace definition

From: James Dennett <jdennett_at_[hidden]>
Date: Tue, 24 Mar 2015 13:10:13 -0700
On Mon, Mar 23, 2015 at 3:24 PM, Nelson, Clark <clark.nelson_at_[hidden]>

> 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

-- James

Received on 2015-03-24 21:10:15