This is the mail archive of the
mailing list for the libstdc++ project.
Re: A separate namespace for implementation functions?
- To: stephen at bregmasoft dot com
- Subject: Re: A separate namespace for implementation functions?
- From: Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>
- Date: 09 Jul 2001 20:17:27 +0200
- Cc: libstdc++ at gcc dot gnu dot org
- Organization: CMLA, ENS Cachan -- CNRS UMR 8536 (France)
- References: <01070913294000.31161@swebb-slack>
"Stephen M. Webb" <firstname.lastname@example.org> writes:
| I've been grooming some of the header files to remove unneeded functions
| (usually leftover workarounds for compilers that don't support partial
| specialization). This still leaves a whole slew of auxiliary support functions,
| especially for the implementation of Algorithms. Most of the time, these
| auxiliary support functions have uglified names so there are no name
| conflicts with userspace names, but the language itself provides a
| mechanism to do this.
The uglification question has nothing to do with namespace -- there
already have been some discussions on that topic. Macros for example
don't respect scopes.
| My question-of-the-day is this. Should these auxiliary functions be put
| in a separate namespace (say, std::impl)?
There is no need to.
| The advantages are that their
| use is a little clearer and someone is less likely to assume they can use
| such a function
Oh, anyone using an identifier of the form _[A-Z_].* knows that he/she
makes non-portabitlity assumptions.
| (they might use std::__copy_aux since it's obviously a
| standard function,
That is unlikely.
| but maybe hesitate at std::impl::__copy_aux).
We're not allowed to use std::impl. The identifier 'impl' is in the
| The only
| real disadvantage is that code must be touched.
For no gain.
| The isues to be addressed include:
| Should this even be done?
I think no.
For extentions, we have __gnu_cxx.