[v3] libstdc++/36104 namespace versioning, revisited

[François Dumont]

Hi

     I kept on working on this evolution and I finally wonder why we 
should consider algos and containers differently. A single family of 
macros for both elements would make it. Something like:

# define _GLIBCXX_1998 __cxx1998
# define _GLIBCXX_BEGIN_NAMESPACE_CONTAINER \
          namespace _GLIBCXX_1998 { _GLIBCXX_BEGIN_NAMESPACE_VERSION
# define _GLIBCXX_END_NAMESPACE_CONTAINER \
          } _GLIBCXX_END_NAMESPACE_VERSION

or maybe

# define _GLIBCXX_NORM __norm
# define _GLIBCXX_BEGIN_NAMESPACE_CONTAINER \
          namespace _GLIBCXX_NORM { _GLIBCXX_BEGIN_NAMESPACE_VERSION
# define _GLIBCXX_END_NAMESPACE_CONTAINER \
          } _GLIBCXX_END_NAMESPACE_VERSION

I have also plan to move all non std stuff used to implement algos in 
std::__detail namespace.

François

On 02/02/2011 10:17 PM, François Dumont wrote:
> Hi
>
>     I really appreciate this patch even if I was right in the middle 
> of my devs that was very impacted by it :-)
>
>     However it introduced a small regression. As far as I know 
> combining debug and parallel mode was possible. Mostly because the two 
> modes are playing in different areas, containers for debug mode and 
> algos for parallel. Why have you added this in the c++config file:
>
> # if defined(_GLIBCXX_DEBUG) && defined(_GLIBCXX_PARALLEL)
> #  error illegal use of multiple inlined namespaces
> # endif
>
>     Now I had plan to do just what you are describing in this mail 
> that is to say introduce real debug algos. I try to keep debug and 
> parallel mode compatible so here is what I have plan to do:
>
> #if defined(_GLIBCXX_DEBUG) or defined(_GLIBCXX_PROFILE) or \
>     defined(_GLIBCXX_PARALLEL)
> # define _GLIBCXX_STD_C __cxx1998
> # define _GLIBCXX_BEGIN_NAMESPACE_CONTAINER \
>          namespace _GLIBCXX_STD_C { _GLIBCXX_BEGIN_NAMESPACE_VERSION
> # define _GLIBCXX_END_NAMESPACE_CONTAINER \
>          } _GLIBCXX_END_NAMESPACE_VERSION
> # define _GLIBCXX_STD_A __cxx1998
> # define _GLIBCXX_BEGIN_NAMESPACE_ALGO \
>          namespace _GLIBCXX_STD_A { _GLIBCXX_BEGIN_NAMESPACE_VERSION
> # define _GLIBCXX_END_NAMESPACE_ALGO \
>          } _GLIBCXX_END_NAMESPACE_VERSION
> # if defined(_GLIBCXX_PARALLEL)
> #  if defined(_GLIBCXX_DEBUG)
> #   define _GLIBCXX_PARALLEL_A __parallel_algos
> #  else
> #   define _GLIBCXX_PARALLEL_A __parallel
> #  endif
> #  define _GLIBCXX_BEGIN_NAMESPACE_PARALLEL_ALGO \
>         namespace _GLIBCXX_PARALLEL_A { _GLIBCXX_BEGIN_NAMESPACE_VERSION
> #  define _GLIBCXX_END_NAMESPACE_PARALLEL_ALGO \
>            } _GLIBCXX_END_NAMESPACE_VERSION
> # else
> #  define _GLIBCXX_PARALLEL_A _GLIBCXX_STD_A
> # endif
> # if defined(_GLIBCXX_DEBUG) or defined(_GLIBCXX_PROFILE)
> #  undef _GLIBCXX_EXTERN_TEMPLATE
> #  define _GLIBCXX_EXTERN_TEMPLATE -1
> # endif
> #endif
>
> _GLIBCXX_PARALLEL_A defines the namespace containing the parallel 
> version of algos. When both debug and parallel mode are actives user 
> code will call debug algos that will then invoke parallel algos. I 
> also consider internal usage of algos, there are 2 situations:
> - usage of algos in containers: as there is already debug containers, 
> containers do not have to rely on debug algos. So _GLIBCXX_PARALLEL_A 
> will expose the parallel algos for containers so it will also be 
> defined when parallel mode is not active and will use normal algos then.
> - usage of algos outside containers: there are not a lot of usage of 
> this kind, for the moment I only detect usage of copy in 
> char_traits::copy but I haven't work on all algos yet. In this 
> situation I plan to simply directly use algos from std so that it will 
> get debug or/and parallel version when activated
>
> For profile mode I plan to introduce algos simply forwarding to normal 
> algos for the moment just to avoid introduction of additional macros.
>
> Does it sounds ok ?
>
> François
>
> On 01/30/2011 11:34 PM, Benjamin Kosnik wrote:
>> This takes care of the rest of the inline namespace issues outlined in
>> bugzilla, minus docs which I will complete posthaste.
>>
>> The main part of this patch is c++config.h, where the macros used to
>> activate inline namespaces change. In a nutshell, instead of always
>> using a macro on the top-level namespace (std) to push and pop
>> conditional namespaces, the top-level namespace (std) is
>> unconditionally defined and all inline namespaces have their own macro
>> for conditional use of the form:
>>
>> _GLIBCXX_BEGIN_NAMESPACE_*
>> _GLIBCXX_END_NAMESPACE_*
>>
>> I'm not John Pawson, but I'm hoping others agree with me that the new
>> style c++config.h is smaller, better, faster, easier to read. Most of
>> all the space dedicated to inline namespaces is...... almost nothing.
>> Comparatively, of course.
>>
>> In addition, several advantages:
>>
>> 1) top-level namespaces not being a macro mean that many standard
>> editors now properly indent the libstdc++ sources without extra work
>>
>> 2) full matrix of inline namespace combinations now work correctly with
>> each other: previously, versioned + debug did not work, etc. The
>> correct nesting of inline namespaces solves this general class of bugs.
>>
>> 3) all C++0x namespaces in std now are fair game to
>> profile/debug/parallel modes
>>
>> 4) the additional clarity in std namespace partitions for extended modes
>> means that it will be possible to add debug versions of things that are
>> now sequestered in parallel sub-namespaces. I wasn't quite sure how to
>> do this before, which was worrisome given the direction of work in both
>> debug and parallel mode.
>>
>>
>> tested x86_64/linux -fvisibility=hidden
>>
>> tested x86_64/linux
>> tested x86_64/linux -D_GLIBCXX_DEBUG
>> tested x86_64/linux -D_GLIBCXX_PROFILE
>> tested x86_64/linux -D_GLIBCXX_PARALLEL
>>
>> all below configured with --enable-symvers=gnu-versioned-namespace
>>
>> tested x86_64/linux
>> tested x86_64/linux -D_GLIBCXX_DEBUG
>> tested x86_64/linux -D_GLIBCXX_PROFILE
>> tested x86_64/linux -D_GLIBCXX_PARALLEL
>>
>>
>>
>
>