NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/cplus/18374

Text File | 1992-12-23 | 4.7 KB | 92 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!microsoft!hexnut!jimad
From: [e-mail] (Jim Adcock)
Subject: Re: Standard library functions and macros
Message-ID: <[e-mail]>
Date: 23 Dec 92 21:41:39 GMT
Organization: Microsoft Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 81

In article <[e-mail]> uunet.ca!frumious!pat writes:
|Suppose the C++ standard said that standard library functions must
|have external linkage, and prohibited implementing them as macros.
|Would this change the meaning of any C programs if compiled as C++?

Yes, assuming by "the meaning" of a C program you mean "the intent
of the original C author."  For example, the original author can
do a '#undef putchar' with "the meaning" that in this compilation his/her
intent is that putchar be implemented out-of-line.  Under the proposed
required changes to C++ implementations, "the meaning" of the original
C author would be silently changed.  Thus someone porting this C program
to C++ finds [or worse, DOESN'T FIND!] that C++ silently changes the
intent of the original author.

Also, note that a conforming C implementation of these standard library
functions using macros can accept a superset of the parm types that a
C++ extern implementation or inline implementation can accept.  A macro
implementation is somewhat analogous to the C++ situation where a
templated function is used.  Thus, requiring that a macro *not* be
used for implementation requires that some possible conforming programs
will no longer be accepted.  Still, breaking such a program is a MUCH better
situation that silently accepting a program while changing "the meaning"
of that program.

Since its MUCH better to break a program than to silently change its meaning,
a better "solution" to this problem would be to change all the "C" standard
library function names to something new in C++.  Then an attempted call of
a standard library funcion/macro would be guaranteed to cause a compilation
error, rather than a silent change in meaning.  The porter would then simply
have to find and fix all these compilation errors.

Now if such approach sounds too onerous to you -- then I agree -- leave
"the meaning" of C standard library macro/functions ALONE!  Don't change
"the meaning" of the C standard library functions and ASSUME your silent
changes are going to work.  They won't always work, and porters will be
stuck trying to figure out what has changed where without having ANY
diagnostics to help them figure out what the problem is!

|Under this rule, it would still be possible (even easy) for compilers
|to substitute inline code for most calls to certain library
|functions.

The other side of the coin is that it then becomes impossible for
programmers to specify *whether or not* they want an inline implementation,
which is a stated intent of the original ANSI-C standard library
macro/function implementations.

|As Steve Clamage pointed out, you can call the function through a
|function pointer; this will probably cause the compiler to
|generate a true function call.

I'd say possibly, not probably.  Optimizing C++ compilers are becoming
better and better at figuring out and avoid gratuituous extra indirections.

|Going the other way, if the _implementation_ is prohibited from
|making putchar a macro, the _programmer_ should be permitted to
|make putchar a macro.  So the programmer who wants to force
|inline code for putchar can simply write the macro.  A particular
|implementation might choose to make this easier by providing
|a __putchar macro so the programmer could write
|
|   #define putchar(c) __putchar(c)

This doesn't help someone who is trying to port someone else's C code,
because such code is silently accepted with changed "meaning" so the
porter *never even knows* that this #define is needed to maintain original
intent.  Secondly, given the porter *does* put in such a #define, then
the next person to maintain this code after the porter, is stuck with
discovering that the first porter redefined the C++ meaning of these
functions to be the same as the original C meaning of these functions.
So then the next person has to somehow magically discover that the "meaning"
of these "standard" functions have been changed from the C++ standard have
been changed from the C standard....

I'd counterpropose why don't we all just *leave prior standards alone* unless
we have overwhelming reasons to change them.  The standard library function
names in C are reserved.  Leave them reserved, and leave them their C
"meanings".  There is no more reason why C++ people ought to be dinking
with these reserved words than any of the other reserved words from
C, such as "for" "if" "else" "struct" etc.