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

Text File | 1992-12-24 | 3.4 KB | 75 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
From: [e-mail] (Jerry Schwarz)
Subject: Re: Standard library functions and macros
Message-ID: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jerry Schwarz)
Organization: Lucid, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 25 Dec 92 01:46:46 GMT
Lines: 62

In article <[e-mail]>, [e-mail] (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