From: jimad@microsoft.com (Jim Adcock)
Subject: Re: Standard library functions and macros
Date: 31 Dec 92 19:02:17 GMT
Organization: Microsoft Corporation

In article <921231032705_76336.3114_EHJ60-1@CompuServe.COM> 76336.3114@CompuServe.COM (Kevin Dean) writes:
|Why should function names be reserved?  They are functions, after all, and
|are thus outside the definition of the language.  

"Reserved" in the same sense that ANSI-C reserved them -- that is if you
#include the corresponding ANSI-C standard header, then the function
names in that standard header become reserved.  If this is not acceptible,
then simply don't include that standard header file.  Standard functions
are indeed part of the definition of the language.  Any compiler that
does not implement the required standard libraries and functions and 
cannot be said to be a conforming implementation of the language.

ANSI-C standard function names should continue to be reserved under the
same conditions as ANSI-C because ANSI-C represented a three-way contract
between standardizers, implementors, and programmers.  Implementations and
programmers using those implementations have written code under the assumption
that these agreements would be maintained, not broken.  ANSI-C is a base
document to the ANSI-C++ effort, and thus should only be changed when
in conflict with ARM, which is the overriding base document.  Standardization
efforts such as ANSI-C and ANSI-C++ are suppose to standardize on common
practice, not implement new practice out of whole cloth.  In the case of
the ANSI-C standard libraries, ANSI-C is clearly the standard practice.
Again, neither the C++ programmer nor the standardizers need to use the
ANSI-C headers nor standard functions if they do not agree to that
existing standard practice.  The C++ standardizers could invent the own,
differently named header files, for example, if they insist on inventing
new standard practice.

|If they have to be
|overridden or defined as macros, can't they just be inlined?  Off the top
|of my head, I can only think of the assert() macro that couldn't be
|rewritten as an inline function because it has to dump context-sensitive
|information like file and line number if it's to be of any use.

A simple additional example is 3rd party debugging mallocs.  If the
standardization committee insists on inline implementations, not macros,
such 3rd party libraries would suddenly no longer be supportable.
Again, my claim is that there is a lot of work that has been done under
the "legal" guidelines of ANSI-C that would be broken by now requiring
new additional constraints prohibiting macro implementations.

|The reason I say this is that reserving the function names can make for
|severe maintenance headaches.  Suppose I have a class that has member
|functions read() and write() and the C-standard read() and write() have
|been redefined as macros by the compiler.  What then?  

The compiler does not redefine read() and write() as macros.  You do --
by #including the corresponding ANSI-C headers.  If you do not accept
the rules laid down by ANSI-C, you can simply choose not to #include the
ANSI-C header that laid down those rules.  You can still get to
the function implementations of read() and write() simply by declaring
such without #including the ANSI-C headers.  ANSI-C guarantees that
implementations provide the function implementations in addition to the
macro implementations if the macros are defined at all.

If the ANSI-C++ standardization committee wanted to include differently-named
headers in addition to the ANSI-C headers, and the new ANSI-C++ headers follow
rules specific to C++, then I'd see no problem.  Existing code and conventions
would continue to compile and execute correctly, macro implementations of
assert and malloc or whatever could continue to do their thing, and
people writing new code could simply choose to use the C++ headers.
The ANSI-C++ standard could even declare the C headers obsolecent, so
that the next version of the C language [god help us all ;-] wouldn't 
have to support the ANSI-C rules at all.