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

[François Dumont <francois dot cppdevs at free dot fr>]

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