This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: c_compatibility headers, include_next
- To: bkoz at redhat dot com
- Subject: Re: c_compatibility headers, include_next
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Fri, 08 Jun 2001 00:10:51 -0700
- Cc: libstdc++ at gcc dot gnu dot org, zackw at stanford dot edu, neil at daikokuya dot demon dot co dot uk
- Organization: CodeSourcery, LLC
- References: <200106080051.f580pLe18145@fillmore.constant.com>
>>>>> "Benjamin" == Benjamin Kosnik <bkoz@redhat.com> writes:
Benjamin> The question is this: is there a way to structure the
Benjamin> "C" compabitility headers so that
Benjamin> #if (we're being included by an include_next'd header)
Benjamin> // use "C" # include_next <foo.h> #else // use c++ #
Benjamin> include <cfoo> #endif
I can't think of any way to do this.
One appalling thing we could do is, instead of using #include_next,
calculate the right absolute path, taking into account all -ansi
stuff, of course. Ugly.
FYI, here is what KCC does:
string.h
--------
They do not provide this file. You just get the system <string.h>.
cstring
-------
#include <string.h>
namespace std {
using ::size_t;
using ::memchr;
...
}
I suggest that we should maybe go with this technique in that it is:
- Simple
- Certain to work in a way that users can understand in the
`string.h' case -- you get whatever you would have gotten
in C.
- Reasonably close to conformant: you can say `std::foo' for
all the right things, and you can say:
#include <string.h>
#include <cstring>
using namespace std;
and not get any weird overloading conflicts.
- KCC does not provide the additional overloads. We could, or
we could not. Note that KCC does not provide the extra
overloads for the math functions, etc. This is wrong, of
course, but at this point the key is to get something that
is plausibly working.
Simple, but reasonably effective.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com