Re: Overloading vs. string functions, etc.

[Stephen M. Webb <stephen at bregmasoft dot com>]

On Fri, 25 May 2001, Andreas Jaeger wrote:
>
> I see.  Since - on Linux - we can change the C Library (glibc) to work
> correctly together with the C++ Library, could somebody explain in
> more detail to me what is allowed for glibc and what not?
> 
> We could fix this for the next glibc release if we all agree what
> needs to be done and how it should be done.
> 
> So, what can glibc do and what should glibc not do under C++
> compilation (and please explain why, I'd like to learn a bit;-):
> - Declare macros, e.g. for memcpy?
> - Declare inline functions like fabs or strlen?
> - Declare C functions and inline functions with throw()
> - anything else?

This is definitely the correct solution (I looked at doing it but the
glibc stuff is kind of intimidating).

The libstdc++ stuff I did for the Solaris 8 headers would just get reused
for this.  I did that on purpose.

What glibc needs to do is provide the correct and required declarations
in the std namespace in a set of separate header files.  When the
preprocessor symbol __cplusplus has the value 199711L or greater,
these header files are included by the regular C header files and their
names injected into the global namespace through using statements,
otherwise the regular C names are declared.

The C++ standard library would just forward these same headers.

As an example, there would be a file, say /usr/include/iso14882/cstring.h,
declaring extern "C" char* std::strcpy(char*, const char*).  The file
/usr/include/string.h will include <iso14882/cstring.h> if __cplusplus
> 199711L and will have a using std::strcpy statement, otherwise will declare
extern char* strcpy(char*, const char*) through whatever mechanism it does now.

The file /usr/include/g++-v3/cstring would simply include <iso14882/cstring.h>.

The glibc headers would be free to define whatever additional cruft is required
without contaminating the C++ headers.

Think of this as factoring out common include file subexpressions.

There are a few tricky spots:  watch out for size_t, ptrdiff_t, time_t,
struct tm and so forth.  Also, those library functions that differ between
C and C++ (strchr et al, the various math functions) and those macro/nomacro
specifications (errno, assert) might give some fun.

Really, it's the Right Thing To Do, but not for the 3.0 release.


__
Stephen M. Webb