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

Text File | 1993-01-05 | 4.0 KB | 83 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!taumet!steve
From: [e-mail] (Steve Clamage)
Subject: Re: Standard library functions and macros
Message-ID: <[e-mail]>
Organization: TauMetric Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 5 Jan 1993 18:50:23 GMT
Lines: 72

[e-mail] (Jim Adcock) writes:

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

Not at all.  The C++ implementation is allowed to use C linkage for the
C library functions.  It is merely not required to do so.

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

There is not and never was any claim that you can choose any C and any
C++ implementation arbitrarily and create a mixed program.  The compilers
have to agree on a number of implementation details.  If a C++
implementation isn't compatible with the C implementation you intend to
use, don't buy it.

The existence proof you requested:  My company provides a mixed C/C++
implementation (Oregon C++).  We arrange things so that code compiled
with our compiler in either C or C++ mode can be mixed with code
compiled with the "native" C compiler for the OS.  You can also mix C
code compiled with the native headers and the native compiler with code
compiled with our headers and our compiler (in any mixture of C and C++).
Our headers use inline functions for some functions which are macros in
the native C headers, and even contain code along these lines:
    #if __cplusplus
    inline T somefunc(args) { ... }
    #else
    #define somefunc(args) ...
    #endif
This kind of thing simply isn't a problem.

If you write standard-conforming source code, you can use the C code
as C++ code provided you also follow the C++ rules.  Examples:  A
strictly-conforming C program need not declare certain kinds of
functions, or may provide non-prototype declarations.  This won't work
for C++; you have to provide prototypes.  A strictly-conforming C
program may assume that sizeof('a')==sizeof(int); you may not make this
assumption in C++.  A strictly-conforming C program may use identifiers
with the names "class" or "virtual"; a C++ program may not.

A new C++ rule is that for portability you should include standard headers
rather than declaring the standard functions yourself.  We can argue
about whether this constitutes an unacceptable burden on the programmer.
The C++ committee concluded it did not, after careful consideration for
over a year by many people.  If you disagree, it would help to supply
some sort of statistics or even a survey to back up your opinion.

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

Posting to this newsgroup is not a submission to the C++ committee.
Your organization is a member of the committee; write a concrete
proposal (i.e., specific changes to the Working Paper) and give it
to one of your representatives.
--

Steve Clamage, TauMetric Corp, [e-mail]