Scott Johnson wrote in message <34BB15A5.3984@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
bradds@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-c++@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++-request@ncar.ucar.edu                             ]