This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
A separate namespace for implementation functions?
- To: libstdc++ at gcc dot gnu dot org
- Subject: A separate namespace for implementation functions?
- From: Stephen M. Webb <stephen at bregmasoft dot com>
- Date: Mon, 9 Jul 2001 13:06:40 -0400
- Organization: CRYPTOCard Corporation
- Reply-To: stephen at bregmasoft dot com
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.
My question-of-the-day is this. Should these auxiliary functions be put
in a separate namespace (say, std::impl)? The advantages are that their
use is a little clearer and someone is less likely to assume they can use
such a function (they might use std::__copy_aux since it's obviously a
standard function, but maybe hesitate at std::impl::__copy_aux). The only
real disadvantage is that code must be touched.
The isues to be addressed include:
Should this even be done?
Should the implementation namespace be nested in std:: or separate?
What should the implementation namespace be called
(eg. "impl", "detail", "internal")?
Stephen M. Webb