This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
Re: gcc builtin functions, e.g. memcpy, and namespace std
On Thu, May 18, 2000 at 11:11:47PM +0200, Martin v. Loewis wrote:
> IMO, the fourth alternative is right:
>
> 4. Treat ::memcpy and std::memcpy identical, as any extern "C"
> function with a certain name should be the same function,
> regardless in which namespace they are defined.
That might be nice, except that it doesn't work in many cases.
All extern "C" functions of the same name in various namespaces
are allowed to collide at linktime. (Note that the standard also
allows an implementation to mangle extern "C" names just like C++
names, and that would be a feature in some environments.)
Regardless, the standard requires declared names in different
namespaces to be considered different for purposes of name lookup
even if they would collide at link time.
The standard makes a special exception for standard global names
in the C headers, which are "reserved", so that a conforming
program can't mention those names without including the header.
(That allows us what Plauger likes to call wiggle room.)
The problem is that in some cases a C function as declared in a
C header has been replaced by two different C++ functions, e.g.
in the case of strchr(), to fix a const-correctness hole.
Then, they *cannot* be the same.
For the case of memcpy, we really should do some balls-to-the-wall
template-based optimization, and completely map out the C headers'
version, but it would be sufficient to import it from the namespace
where it is defined to the other namespaces where we want it declared.
For the case of strchr, we don't have any choice. The C header
definition is just wrong, and has to be hidden.
Nathan Myers
ncm at cantrip dot org