This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Thoughts on __gnu_cxx
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- To: Phil Edwards <pedwards at dmapub dot dma dot org>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: 26 Jan 2002 05:48:28 +0100
- Subject: Re: Thoughts on __gnu_cxx
- Organization: CodeSourcery, LLC
- References: <200201252111.QAA23870@dmapub.dma.org>
Phil Edwards <pedwards@dmapub.dma.org> writes:
[...]
| 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.
That is what we have documentations for ;-). If a uglified name is
documented as an extension and usable in public code, then that it is.
| 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
You cannot use namespace-alias in an extension-namespace-definition.
| 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?
But, concretely what are we supposed to gain?
I think documenting __gnu_cxx as containing implementations codes (not
supposed to be used in public code) and documented extensions usable
in public code should be sufficient.
-- Gaby