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

Text File | 1993-01-06 | 6.1 KB | 119 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!microsoft!wingnut!jimad
From: [e-mail] (Jim Adcock)
Subject: Re: Standard library functions and macros
Message-ID: <[e-mail]>
Date: 06 Jan 93 19:02:03 GMT
Organization: Microsoft Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 108

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

Agreed.  An implementation that uses C calling convention for its
library functions shouldn't need stubs, as long as the parms to the
C++ standard definition of the function remains identical to the C
standard definition.  If the C++ implementation uses a different
calling convention than the C implementation, then you have to have
the stubs.

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

I'm simply arguing that it must be reasonable to maintain such dual-
implementation compatibility.  If the C++ committee makes decisions that
make such dual-compatibility onerous, then I say they are clearly making
a mistake.

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

Depends on what you consider a problem.  The C++ side of your implementation
does not support the semantics called out in one of the base documents,
namely the ANSI-C base document.  If this is not a problem, then why
call the ANSI-C document a base document?

Whenever C++ fails to implement the requirements of the ANSI-C side of
the base docs, you make it less likely that C programmers will make the
effort to move their code to C++.  Thus the dual mode C/C++ implementations
and programmers written half ANSI-C half C++ will continue indefinitely.

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

No, I do not disagree with this part of the decision.  I simply disagree
that it makes sense to return the vast majority of the standard functions
namespace to the programmer.  On the contrary I claim that the vast majority
of these names should remain in the implementation space, because implementing
them as macros, or providing alt implementations, as in the Sun example,
remain useful and viable options to the implementation.  Whereas the vast
majority of the names in question represent deliberately "decorated" or
"mangled" names if you will that have little or no applicability to the
C++ programmer as useful member function names, or even global names.
So in the vast majority of cases your suggested changes destroy utility
on the implementor's side without corresponding increase in utility on
the programmer's side.  This is clearly a bad trade-off.  Again, if you
want to go through the functions in a sensible manner, and choose certain
names such as "free" that have plausible utility to the end programmer,
and insist on non-macro and non-overloaded implementation of these functions,
such that the name-space remains available to the programmer, then I would
agree with such a thoughtful, well-considered, measured approach.  I just
disagree with the blanket changes that have been proposed to date.

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

You did not call for a submission to the C++ committee.  You issued
an open request for responses in this forum, and I responded in this
forum.  Now you continue to make excuses to discount such responses.
If you do not wish to consider responses in this forum, then do not
call for such responses here.  Make such [rhetorical] calls in committee,
and leave this forum alone.

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

I have written up a concrete proposal in the past, and the committee
did not give it any more reasoned consideration than you give my
comments here.  I will not so waste my efforts again.