extern "C" in C?
Scott Johnson
This may seem like a silly, even trivial idea...but why not add
C++ style linkage specification (extern "xxx" and extern "xxx" {...} )
to C? The change to the grammar would be pretty simple, methinks.
Why do this? If for no other reason, 'twould be nice to not have to
surround instances of extern "C" with #ifdef/#endif pairs when writing
headers which are to be included in both C and C++ code.
Secondly, it provides a good way for future C specifications (or
specific implementations) to deal with multi-language issues. On a
similar note, an implementation which consists of both a C and C++
compiler could allow extern "C++" in C code, and thus allow C code to
call mangled C++ functions. (Ignoring issues of overloading,
exceptions, references, and classes, of course... :) ) I am not
suggesting that extern "C++" be requried by the standard; the only
linkage specification that C would be required to support is its own.
Any comments as to why this is a completely silly idea? :)
Scott
Douglas A. Gwyn
In article <34BB15...@nospam.aracnet.com>,
Scott Johnson <sj_n...@nospam.aracnet.com> wrote:
>Any comments as to why this is a completely silly idea? :)
It's not silly, but also it's not necessarily (part of)
a proper solution to inter-language linkage issues.
So it may be premature to start "standardizing" such syntax.
Kaz Kylheku
>C++ style linkage specification (extern "xxx" and extern "xxx" {...} )
>to C? The change to the grammar would be pretty simple, methinks.
>
>Why do this? If for no other reason, 'twould be nice to not have to
>surround instances of extern "C" with #ifdef/#endif pairs when writing
>headers which are to be included in both C and C++ code.
Hahaha. Nice idea. But do you realize that if you added this feature to the C
language, you would then still have to use #ifdef/#endif to ensure that your
header files work with every C compiler that has not caught up yet?
:)
Using a macro like
#ifdef __cplusplus
#define CDECL extern "C"
#else
#define CDECL
#endif
or the trick
#ifdef __cplusplus
extern "C" {
#endif
/* declarations go here */
#ifdef __cplusplus
}
#endif
works well enough.
>Secondly, it provides a good way for future C specifications (or
>specific implementations) to deal with multi-language issues. On a
C is usually used as the lowest level language in a system that is above
assembly language. How often do you call Ada or Fortran routines from C?
Though I agree that there is sometimes a need to call a C++ function from C.
The whole linkage specification thing in C++ exists primarily to support
interoperability with C, evidenced by the fact that "C" is the only
specification that is supported. If you want to call some Fortran numerical
routines from C++, you still have to go beyond the standard.
What about issues of compatibility of the calling conventions? C and C++
are similar, and frequently are implemented together. The C++ compiler can
ranslate an extern "C" function declaration using the same mechanisms that it
uses for C++ declarations, and yet that declaration will be compatible with a
definition translated by the C compiler. In other words, the stuff under the
extern "C" specification is still C++; the similarity between C and C++ allows
the mechanism to work seamlessly. Furthermore, a C++ compiler is expected to
lay out structures and bit fields in the same manner as the accompanying C
implementation, and use the same representations for all basic types.
Linkages other than extern "C" can't be expected to work as as seamlessly and
successfully.
In practice, extern "C" works with dis-similar C++ implementations. By this I
mean this: say you have two or more C++ compilers for some platform; it's
normal for extern "C" to work in each of those implementations such that it
allows interoperability with the C libraries used on that platform. If you
have more than one C compiler, they are likely going to be compatible.
Yet the reverse cannot be the case; an extern "C++" specification is
ambiguous as to which compiler's mangling system should be used!
In other words, there is much more agreement about what C linkage means, for a
particular hardware platform and operating system, than C++ linkage.
Bradd W. Szonye
Scott Johnson wrote in message <34BB15...@nospam.aracnet.com>...
>[On adding extern "C" to C]
>Why do this? If for no other reason, 'twould be nice to not have to
>surround instances of extern "C" with #ifdef/#endif pairs when writing
>headers which are to be included in both C and C++ code.
>[More good reasons]
>Any comments as to why this is a completely silly idea? :)
Actually, I think it's a very good concession to C++ compatibility and C/C++
interoperability. I almost wonder why nobody's considered it before--at
least I haven't heard any such talk. It's been a while since I've looked
closely at extern "C" in C++, but I believe the meaning of anything besides
"C" and "C++" in the quotes is implementation-defined. The intent is to
allow linkage to C, Pascal, FORTRAN, BASIC, et cetera. (And extern "C++"
does exist in C++; it's roughly a no-op.)
Implementations with a shared C/C++ backend (and largely shared frontends)
could even define extern "C++" to allow use of the internal "mangling"
algorithms, although the lack of C++ style overloading in C could lead to
problems in practice.
I sometimes wish that C++ didn't hobble the linkage-directive so badly;
while it's nice for an implementation to define linkage to other languages
for procedural function calls, C++ disallows use of the directive in
conjunction with those features specific to C++ (such as member functions
and, I believe, template functions). This is a shame; it would be nice to
specify a class as, for instance, extern "Borland C++" or extern "PA-RISC"
or extern "C++ version 9 compatibility mode". Apparently the authors of C++
felt that there were too many possible abuses of the mechanism and strove to
limit it as much as possible.
Overall, I think that the linkage-directive *could* be a nice general way of
interfacing with other vendors' products, old-but-still-supported products,
variant compatible architectures, and specific calling-convention standards.
Use of the directives definitely limits portability in the wider sense, but
possibly helps interoperability for more specific, practical cases. While I
wouldn't want to see chaos in this area, I think that there's a definite
place for such a facility, and that it's a solution that works well for both
C and C++. At the very least it greatly eases the task of writing compatible
headers.
This note deals with C++ as much as C (if not more so), so I've cross-posted
to comp.std.c++. Please exercise care in following up.
---
Bradd W. Szonye
bra...@concentric.net
http://www.concentric.net/~Bradds
[ comp.std.c++ is moderated. To submit articles: try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html ]
[ Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++...@ncar.ucar.edu ]
Julian Pardoe
In article <69j3bf$qf4$1...@brie.direct.ca>, bi...@cafe.net (Kaz
Kylheku) wrote:
> The whole linkage specification thing in C++ exists primarily
> to support interoperability with C, evidenced by the fact that
> "C" is the only specification that is supported. If you want
> to call some Fortran numerical routines from C++, you still
> have to go beyond the standard.
Is 'extern "C"' support mandated by the standard or is this just
a QoI/implementation defined issue? If it's the latter then
even calling a C routine is going "beyond the standard" as much
as calling a Fortran routine.
I wish I could get a clear answer to my question about what you
can and can't do with 'extern "C"' in the C++ DIS. If anyone
here knows the full details perhaps they could mail me. I'm
worried that there are limitations that will make many C
libraries unusable from C++. In some cases being able to
anticipate this and write 'extern "C++"' in C code might help us
all. (Or do I mean 'intern "C++"'?)
-- jP --
Norman Diamond
In article <69j3bf$qf4$1...@brie.direct.ca>, bi...@cafe.net (Kaz Kylheku) writes:
>In article <34BB15...@nospam.aracnet.com>,
>Scott Johnson <sj_n...@nospam.aracnet.com> wrote:
>>why not add C++ style linkage specification (extern "xxx" and
>>surround instances of extern "C" with #ifdef/#endif pairs when writing
>>headers which are to be included in both C and C++ code.
>Using a macro like
> #ifdef __cplusplus
[details deleted]
>or the trick
> #ifdef __cplusplus
[details deleted]
>works well enough.
Nope, those tricks cause undefined behavior in C. If a program uses an
identifier that is reserved to the implementation, the implementation
might choose to define it as a 0 (which is good luck for you until you
try porting to a less friendly implementation) or might choose something
else and doesn't have to document its choice.
One would expect gc0x to invoke, perhaps, Quake :-)
--
<< If this were the company's opinion, I would not be allowed to post it. >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
J. Kanze
jb...@cix.compulink.co.uk ("Julian Pardoe") writes:
|> In article <69j3bf$qf4$1...@brie.direct.ca>, bi...@cafe.net (Kaz
|> Kylheku) wrote:
|>
|> > The whole linkage specification thing in C++ exists primarily
|> > to support interoperability with C, evidenced by the fact that
|> > "C" is the only specification that is supported. If you want
|> > to call some Fortran numerical routines from C++, you still
|> > have to go beyond the standard.
|>
|> Is 'extern "C"' support mandated by the standard or is this just
|> a QoI/implementation defined issue? If it's the latter then
|> even calling a C routine is going "beyond the standard" as much
|> as calling a Fortran routine.
In C++, support for `extern "C"' is mandated. What it actually means,
however, is pretty much up to the implementation. If there are two C
compilers available, with different linkage conventions, the C++
implementation is not required to support both. In fact, I believe that
a legal C++ implementation could document that the C compiler they
support is the one they will bring out fifty years from now.
All of which means that strictly speaking (not considering QoI), `extern
"C"' doesn't buy you anything. (Of course, that's also true of things
like volatile, but both volatile and `extern "C"' are useful in
practice.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: ka...@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orientée objet --
-- Beratung in objektorientierter Datenverarbeitung