🚀 go-pugleaf

In article <2q9v55$ted@bigblue.oit.unc.edu>, brandon@uncvx2.oit.unc.edu
(Brandon Van Every) wrote:

> Glenn M. Poorman (poorman@cc4032.pms.ford.com) wrote:
> : In article <2q65gv$oln@bigblue.oit.unc.edu>, brandon@uncvx2.oit.unc.edu (Brandon Van Every) writes:
> : Actually the function does not have to have "extern C" linkage.  It just
> : can't be a non-static member function.
> 
> I can't find anything in Stroustrup that says this will work.  The default
> linkage for all functions is "C++" (p. 524).  Given that, I'd say that not
> using "extern C" is rather risky.

The ARM does not, and the C++ standard will not guarantee that C code and
C++ code work together, regardless of the use of extern "C".

At present, some compilers use different, incompatible calling sequences, 
based on whether a function is defined with extern "C".  This flouts
the ARM's note which says that the linkage specification "does not
affect the semantics of the function".   IMO it will be a violation of the
eventual C++ standard, because the standard will allow passing a pointer
to a C-linkage function to a C++ function.  For example,

     extern "C" int f();
     extern "C++" void g(int (*)());
     void foo() {
            g(&f);     // perfectly valid mixing linkages
     }

The advice to use extern "C" is valid for the present.  I just wanted
to eliminate the impression that the ARM or the C++ standard is the
basis for this advice. Nor does the ARM sanction the peculiarity of a
compiler
which uses different calling conventions based on C-linkage.
--
Scott Turner
Liant Software Corp.
959 Concord St., Framingham, MA 01701  USA
(508)872-8700
pkt@lpi.liant.com