This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Thoughts on __gnu_cxx



There's a hefty doxygen patch on the horizon, mostly fallout from the header
renaming.  One of the changes is that __gnu_cxx appears in doxygen output.
Since the SGI extensions are there now, as well as a few of our own,
this is plainly a desirable thing.

But __gnu_cxx is used for two purposes (and this will be noted in the doxygen
output, as long as that remains true).  It's used to hold extensions for
public users, but it's also used to hold implementation details not meant
for public use.

This is a bit of a dichotomy:  users can't easily tell the difference
between what's meant for them and what isn't.  Uglification doesn't help
them tell the difference, either:  __gnu_cxx::__verbose_terminate_handler()
is safe for users, but the name says otherwise.

I suggest looking at the libsupc++ code, where

  -  the implementation details are hidden in a '__cxxabiv1' namespace,
  -  an alias is set up, "namespace abi = __cxxabiv1;", and
  -  everything is accessed as abi::foo

Some possibilities:

Maybe we should leave the implemenation details in __gnu_cxx, and move
the public extensions to 'gnu' or 'gnu_cxx'?

Maybe we should leave everything in __gnu_cxx, and make gnu_cxx (or whatever)
an alias?

Maybe leave everything in __gnu_cxx, and make gnu_cxx a separate namespace
completely, which simply brings __gnu_cxx members into view via 'using'?
Or wraps them in non-uglified names?  Frex:

    namespace nifty_gnu_extensions
    {
        void verbose_terminate_handler()
        {
            __gnu_cxx::verbose_terminate_handler();
        }

        ... other bits ...
    }


Phil


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]