From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Standard library functions and macros
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
Date: Fri, 25 Dec 92 01:46:46 GMT

In article <1992Dec23.214139.24948@microsoft.com>, jimad@microsoft.com (Jim Adcock) writes:

|> 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.
|> 

There is no such guarantee in standard C.  If there is a #include <stdio.h>
present, a compiler is free to inline putchar whether or not the user
does #undef putchar.  The constraint is in the other direction.  A
programmer can't use "putchar" in specific ways unless an #undef appears.

If Jim is saying that in a particular implementation the #undef has
this effect and believes that effect should be preserved, then nothing
stops an implementation from giving the #undef the same effect in C++,
although I suspect he will have to lobby his vendors very hard to
convince them to implement such a feature.

|> 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.
|> 

I'm not sure I understand this.  Is the intented example that 
there might be something like

	#define putchar __myputchar

And __myputchar would then be callable in different ways?   Are there
any such implementations?  In that case the equivalent C++ would be
to declare putchar variants in the header.   Under the currently
proposed rules this wouldn't be allowed either, but I would be more
willing to relax the rules in this direction if there is
a real need for alternative "putchars" or any other C library function.
Is anything like this actually done by existing implementations.

|> 
|> 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.
|> 

I've never seen such an intent expressed.  Where is it stated?

Contrary to the way Jim uses the word, I don't consider
whether a compiler inlines calls to a library function
part of the "meaning" of that function.  And neither
as far as I can tell does the standard.

  -- Jerry Schwarz
Newsgroups: comp.lang.c++