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

Internet Message Format | 1992-12-24 | 5.0 KB

Path: sparky!uunet!synaptx!synaptics.com!daveg
From: [e-mail] (Dave Gillespie)
Newsgroups: comp.lang.c++
Subject: Re: Standard library functions and macros
Message-ID: <[e-mail]>
Date: 25 Dec 92 03:38:47 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Synaptics, Inc., San Jose, CA
Lines: 97
In-reply-to: [e-mail]'s message of 23 Dec 92 21:41:39 GMT

In article <[e-mail]> [e-mail] (Jim Adcock) writes:
> 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.

I have to disagree here.  Usually when language standards talk about
the "meaning" of a program, they are referring only to whether or not
it is correct, and what its behavior will be if it is correct.  As I
understand it, all the talk about macros in the C standard is there
purely to reserve to implementors the right to provide fast macro
implementations of library functions.

If the only effect of `#undef putchar' is to change whether or not
a fast macro or a slow equivalent function is used, i.e., if it only
affects performance and not results, then I'd say it's improper for
a standard to legislate it one way or another, or for a portable
program to depend on it.

Even if `putchar' were a function instead of a macro, don't compilers
sometimes inline-expand functions anyway?  A good optimizing compiler
ought to be able to do this, whether or not there are "inline"
declarations in the language.  As far as I know, there is no way in
C to require that a function be compiled out-of-line.  The only
language I can think of offhand that does provide for this is Common
Lisp.

I don't have a copy of the standard handy, but my K&R II uses language
like "if it is a macro" in its description of "putchar".  Doesn't that
imply that it is perfectly legal for a compiler to implement `putchar'
as a function, not a macro?

In fact, is there anything preventing a C implementation from putting

    static int putchar(int c) { return putc(c, stdout); }

in its <stdio.h> header?  Is there anything preventing a compiler
from expanding a call to "putchar" inline, given this definition?
(Urgh, I wish I had a copy of the standard around...)

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

Well, yes, but can a conforming, i.e., portable program depend on this?
My K&R says `int putchar(int c)'.  I have to assume that this is what
I have when I write a call to `putchar'.  Even if I have a whiz-bang
extended C compiler that allows me to pass other things to `putchar',
I have to assume any code that uses this will break when I move to
another compiler, be it a C++ compiler or just another vendor's C.

> Thus, requiring that a macro *not* be
> used for implementation requires that some possible conforming programs
> will no longer be accepted.

As I understand it, even if it's required for `putchar' and to `putc'
to be macros, it is still legal for their definitions to be

    #define putc(c,f) fputc(c,f)
    #define putchar(c) putc(c,stdout)

which means that a conforming program couldn't possibly pass anything
to `putchar' which it couldn't also pass to `fputc', which is certainly
allowed to be a function.

What other properties of `putchar' being a macro or not could a
conforming program depend on?

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

Could you please provide a quotation?

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

What has actually changed, that this next maintainer could perceive?
Okay, the performance has changed some, but performance can change even
when you install a new rev of the "same" compiler.

                                -- Dave
--
Dave Gillespie
  [e-mail], uunet!synaptx!daveg
  or: [e-mail]