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]

A separate namespace for implementation functions?



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


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