NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/cplus/18687

Text File | 1993-01-04 | 4.7 KB | 85 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: 04 Jan 93 23:15:19 GMT
Organization: Microsoft Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 74

In article <[e-mail]> [e-mail] (Steve Clamage) writes:
|If an implementation uses the same library for C and C++, which is
|true for current implemenations, you can successfully do this:
|    extern "C" int puts(const char *);
|    int main() { puts("Hello world\n"); return 0; }
|You are just not assured the code will work.

How about implementations and programmers that want to continue to
share code between C and C++ implementations?  Let's say a program
that it created from some "C" files and some "C++" files, and each of
these files in turn calls some of the standard-C functions.  How are
you going to make this work?  Seems to me you are requiring
"C++ calling convention" of the standard-C functions called by the
C++ files, whereas the standard-C functions called from the "C" files
would have to follow "C" calling convention.  At the very least this
seems to me to be saying that you're requiring dual-entry stubs of
all the library functions.  And then how do these things coexist in
one library and get linked in correctly?  Can you point to even one
existing implementation that implements your proposed changes, and
which continues to allow mixed Cfile/C++file programs to be compiled and linked?

|Jim missing a point, I think.  Let's say, under his scenario, that I
|create a class with a member function getchar.  I am careful not to
|use <stdio.h>, and everything is fine.  A later programmer wants to use
|stdio as well as my class library, and the code won't compile.

I think you're missing the point.  "getchar" is one of a very few function
names in the ANSI-C library that has even a *plausible* use as a C++ function
name.  "free" being possibly the most plausible name to return to the C++
programmer name space.  Yet along with these few handful of functions that
have even *plausible* uses as names for C++ programmers you are insisting
that implementations change their implementation of some hundreds other
ANSI-C function names that *don't* have plausible use to C++ programmers.

|We have (at least) two choices.  Jim wants to leave the C headers alone,
|meaning that the names of all the C library functions are unavailable
|for use as class member functions.

Not what I said.  I said leave them alone except where you can show a very
good motivation for requiring a change.  No such motivation has been shown.
Rather, a plausible handful of function names out of the entirety of the
typically implausible ANSI-C function name set is being used erroneously
to try to motivate changing the rules on ALL the functions.  These changes
are not well motivated.  If you want to argue to change the implementation
of "free" and "getchar" or one of a handful of other functions, then so
argue, and we can debate whether the name-space "improvements" justify
the implementation impact and the conforming program impact.  But don't
try to argue that all should be forced to be non-macro just because you
really want to use a few as non-macro.

| The choice which was adopted says
|that some existing C code would have to be modified under some C++
|implementations -- you might have to use standard headers instead of
|homebrew declarations of standard functions.  I don't think you can make
|a case that either choice is just plain wrong; it is a judgement call.
|The C++ Committee made a judgement, and anyone is free to disagree.

My position as stated above was that the change was overreaching
and un-motivated in being so over-reaching.  Change what you have
good motivation to change, and leave the rest alone.

|A few weeks ago I asked for analyses of this situation, or of any other
|problem associated with the change in C library rules for C++.  I did
|not get any response.  I renew the request.  If the Committee has made
|a bad decision, this is the time to correct it.

Consider my arguments here as a response to your request.  My position
being that the committee made a bad proposed change decision by
over-generalizing from a few specific cases to all the ANSI-C functions.
If you look at the ANSI-C functions, only a tiny handful make plausible
sense to require as non-macros.  Change the ANSI-C base document in regards
those isolated few functions, if you insist.  Leave the rest of the ANSI-C
functions and base document alone.  Don't change the base document simply for
the sake of change.