Subject: Re: <string.h> .vs. <String.h>
From: [email-masked]

31 Jan 1997 21:21:50 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Original-To: [email-masked]
Original-CC: [email-masked], [email-masked]
Original-Sender: [email-masked]

Hi, you wrote:

: > I have never heard about the .h-less includes!
: 
: I assure you, it's been there since at least 1993. See
: http://www.research.att.com/c++/ , which is an old (1995 April) draft of
: the working paper, but a decent approximation to the overall structure,
: at least, of the current document. See the libraries section.

My current project started in 1995 and is C only. Before that I programmed
mainly in Tcl/Tk for a while. And before that was my last C++ usage...

: It's possible. Actually, the C++ standard has yet another out for this:
: the C-standard headers are supposed to be "officially" included as
: <cstdio>, <cstring>, etc. (i.e. truly conformant programs are not
: supposed to use either <String.h> or <string.h>), which does solve the
: problem.

That could create problems, e.g. for a rather simply main() written in C,
but which has to be C++ compiled, if there are some C++ (shared) libraries
linked in, or else on some platforms constructors/destructors aren't called!

Also, I don't know if all current C++ implementations support the new names.

: But you can't make the same file return different things for C and C++,
: since it should be possible to
: 
:  #include <string.h>
:   .... strcpy(...) .... // error if you didn't include the C part
: 
: but at the same time,
: 
:  #include <String>
:  .... strcpy(...) ...   // MUST give an error, else namespace is polluted

You are right, but in this case I'd tolerate namespace pollution.
Those guys relying on your second example and confusing other people by
redefining strcpy for there own purposes should be punished anyway 8-)
OTOH someone trying to write portable code and accidentially using strcpy
without proper includes will miss a error/warning in this case, but
need to build/test on other (case sensitive) platforms anyway!

Also, if I haven't overlooked something, it wasn't mentioned yet that
the ODS-2 filesystem of VMS stores filenames uppercase only.
Jim Balter (hi!), did you run into this problem?

Another ugly hack would be to add a special case check into the C++
preprocessor, since it really sees <String.h> and <string.h>, no matter
how the file system on disk and the OS manage names, and can possibly
substitute e.g. <string.hxx> and leave <string.h> alone. The default for
this should be off, and if you experience the problem, use -DSTRING_H_HACK
or something like that, as the FAQ would need to explain.
Sine this would probably mean altering Makefiles or configure scripts,
an environment variable (CXX_STRING_H_HACK?) would be useful, too.

BTW, are there other known name clashes?

Bye, Heribert ([email-masked])
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".