Instead of namespace __gnu_cxx { namespace detail { } } would like to experiment with the form namespace __gnu_cxx::detail { } See N1524 from pre-Kona. Will attach for reference
Created attachment 8853 [details] proposal At Kona, this seemed uncontraversial.
Confirmed.
I still want this. Someday...
Created attachment 10444 [details] Implementation of condensed nested namespaces definition, includes testcase. I sent an email with some comments to gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00666.html
I'm encouraged by this work!!! Great news. The reason this would be useful is that then it would be possible to use a single macro to represent both scope and namespace. Ie, #define ACTIVE_SCOPE works for namespace ACTIVE_SCOPE { } and explicit qualifications like ACTIVE_SCOPE::obj; Anyway. -benjamin
Subject: Re: condensed nested namespaces "bkoz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | ------- Comment #5 from bkoz at gcc dot gnu dot org 2005-12-14 17:16 ------- | | I'm encouraged by this work!!! Great news. | | The reason this would be useful is that then it would be possible to use a | single macro to represent both scope and namespace. Ie, | | #define ACTIVE_SCOPE | | works for | | namespace ACTIVE_SCOPE | { | } | | and explicit qualifications like | | ACTIVE_SCOPE::obj; | | Anyway. I see what you mean. However, as ever, macro-based tehcniques just don't play nicely with othe scope rules. When I read the code, I don't want to be deceived. When I see namespace ACTIVE_SCOPE { /* blah blah */ } I really think of a named scope. Later, when I see ACTIVE_SCOPE::obj, I really think of the obj found in ACTIVE_SCOPE through usual rules. However, if ACTIVE_SCOPE is #defined to nothing, then that breaks down -- the obj found is not the one from the unnamed namespace through usual rules. So. while I believe this work can be useful, I'm not convinced that the macro-based techniques make a case for the extension that would require a different set of lookup rules. -- Gaby
Something like this is in the C++17 WP *** This bug has been marked as a duplicate of bug 65047 ***