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

Text File | 1993-01-06 | 4.7 KB | 93 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 18:33:34 GMT
Organization: Microsoft Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 82

In article <[e-mail]> [e-mail] (Jerry Schwarz) writes:
|In article <[e-mail]>, [e-mail] (Jim Adcock) writes:
||> 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?
|
|I really don't understand Jim's concerns. All the vendors (of
|Unix compilers) I've looked at take a similar approach to this problem.
|As far as I can tell we would have no problem accomodating the currently
|proposed X3J16 requirements.

The questions I have been raising is how well you accomodate the requirements
of one of the two base docs -- namely the ANSI-C requirements.  I think you're
saying there is no problem -- the C++ is simply blowing off the ANSI-C
requirements.  I disagree with such an approach, because ANSI-C was
stated to be one of the base documents.  If you are not following this
doc, you should be honest and remove it as one of the base docs.

|Lucid supplies a large collection of header files with its
|compiler that allow use of the vendor (Sun) supplied C libraries.
|We share these headers between C++ and C without much problem.
|These headers check for #ifdef __cplusplus and "do the right thing".
|When compiling C++ they insert extern "C" as appropriate.
|In C++ modes we have also found it useful to define variants
|of some of the C functions using the static inline technique
|discussed previously by Steve.
|
|For example, in C++ modes our headers contain (after expansion of
|some macros that allow us to control variation between compilation modes)
|
|    typedef void (*__sigtype)(int);
|    typedef void (*__alt_sigtype)(int,int,struct sigcontext*,char*);
|
|    /* The C standard declaration */
|    extern "C" __sigtype signal(int,__sigtype) ;
|
|    /* A variant expected by Sun programmers */
|    extern "C++" inline __alt_sigtype signal(int __sig,  __alt_sigtype __h) {
|        return (__alt_sigtype)signal( __sig, (__sigtype)__h) ;
|    }

Seems to me that an inline call such as this requires a stub, either in
the library, or compile-time generated, if the programmer does anything
that prevents inline expansion of the inline function.  And such control
over inline expansion is precisely the control permitted deliberately
and explicitly in the base doc -- the ANSI-C base doc.  If C++ provides
something analogous to the ANSI-C statement to the effect that macro
implementations are backed up with "real" functions in the library.

|The extern "C" variant gets linked directly to Sun's C library
|without any problems. We don't need stubs.

What happens when you take a type-correct pointer to the above function,
for example, and invoke via that pointer?  I'd think you'd get a stub
generated -- ie the compiler lays down an out-of-line function to implement
the alt signal function.

|The variant was required because that is, in fact, the type of signal
|according to the Sun man pages
|
|When compiling in strict ANSI C mode, the header just expands to
|
|    typedef void (*__sigtype)(int);
|    __sigtype signal(int,__sigtype);

Seems to me that this example argues for my point-of-view -- that the
ANSI-C function names should continue to remain reserved for implementation,
so that implementations can continue to offer their implementation-specific
variations as required above.  Taking it out in strict mode but then
taking the name space back for the implementation in non-strict mode, as
in your example above, is merely a ruse.  It doesn't buy the programmer
any significant guarantee that the name space is available for their use.
Either implementations should not contaminate the name space at all, or
if that is not practical, then the name space should remain the implementations.
We should not resort to game playing, just to say "we passed conformance."
Such games don't by the programmer anything real.