joerg.barfurth@attglobal.net (Joerg Barfurth) writes:

> Francis Glassborow <francis.glassborow@ntlworld.com> wrote:
>
> > I am away from home and my well thumbed copy of the standard but I think
> > that:
> >
> > extern "C" {
> > typedef void (cfntype)(void *);
> > }
> >
> > class X
> > {
> >   static cfntype baz;
> > ...
> > };
> >
> > deals with that case.
>
> 7.5/4 says:
> "A C language linkage is ignored for the names of class members and the
> member function types of class member functions."

Hmmm... reading this again, I note something:

The text says "... is ignored for the *names* of class members ...", not
"... is ignored for class members ..."

So Francis Glasborrow may indeed be right here:
In the example above, baz has a C++ _name_, but a C linkage _type_.

But from this reading, even

extern "C"
{
  class C
  {
    static void foo();
  };
}

should be affected. And I'm not even sure about

extern "C"
{
  class C2
  {
    void foo(); // Member function!
  };
}

where I have problems with the concept of C linkage member functions.
However, what does the following define?

class X;
extern "C" void (X::*foo)();

However, the template problem still remains. But maybe this could
be solved by introducing template typedefs:

extern "C" template<class T> void fp(T);
// fp<T> is the type "C function taking T and returning void"

template<class T> fp<T> foo;
// declare template function (fixes C linkage type, C++ linkage name)

template<class T> void foo(T) // and define it
{
  // ...
}

[...]

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

How linkage is achieved between languages seems to be something beyond the
scope of the C++ standard.

It may be more correct to specify linkage standards in general, apart from
implementations. If that were the case, the role of the C++ standard
(should) then be to conform to standards for linking.

If there is no such standard, then we are left with a compromise that is, at
best, limited to giving specific compiler/linker implementations some clue
about linkage with some specific language.

-------------------------

"Joerg Barfurth" <joerg.barfurth@attglobal.net> wrote in message
news:1eys049.1mtaactofnng2N%joerg.barfurth@attglobal.net...
Hans Aberg <remove.haberg@matematik.su.se> wrote:

> I am disregarding the fact that the compilers always must somehow be tuned
> together.

But that is the key point. Maybe it is the only point.

You can really talk about achieving linkage only between
implementations, not languages. Thus to realize what linkage
specifications promise, you need implementations of the languages
concerned, plus compatibility effort by at least one of the
implementors.

For sustaining the compatibility, you either need collaboration of both
or some third party defining and evolving an ABI.

IMO 7.5/9 says it all.

> It seems me that the standard is flawed, as what is called "linkage to the
> language X" does not mean that one can actually link to code written in
> the language X.

AFAICT it is only in 7.5/3 that the standard explicitly mentions
"linking to code written in the programming language X", with "X" ==
"C". Otherwise 'language linkage' is used as a technical term. It really
means only that there is a string attached to each name and function
type. The name simply reflects the intened use.

OTOH the standard requires support for "C" language linkage, with
specific changes to the semantics within C++. But it simply cannot
require "that one can actually link to code written in the language C",
as there needn't be any C implementation on the same platform - at least
its existence shouldn't be mandated by the C++standard.

> There are two ways around this: One is to change the name
> to say "pseudo-linkage", so that it becomes explicitly clear that it is
> merely a way for the C++ compiler can attach language labels onto the code
> so that the linker might use it for linking.

I don't think "pseudo-linkage" captures it any better. I agree that
"language linkage" raises expectations that implementations of the
"linkage tag" need not fulfill.

> Another way would be to strengthen the requirement so that linkage to the
> language X actually means that one can link code to that language (even
> though, clearly, it still depends on the two compiler being tuned
> together).

Would you then also require that such a compiler exists. Would a
C++-implementation become nonconforming when production of the C
compiler it collaborates with is terminated.

>   extern "C" short foo(int);
> is not legal unless one has specified conversion operators
>   extern "C++" int -> extern "C" int
>   extern "C" short -> extern "C++" short

Who would have to specify them where ?

> The spin off if forcing such conversion operators to be explicit in the
> language is that the types of the different languages need not be tuned
> together: In the example, it does not matter anymore that the integral
> types of the two different languages are the same.

You still need a language in which to specify the needed bridging code.
And that should be part of which language ? And once you have that, it
suffices to support linkage to the bridging language on either end.

> One could also go a
> step further, and use it to tune together different compilers of the same
> language, that is, if it is somehow possible to indicate in the "extern"
> declaration the name of the compiler.

I don't think there is anything to prevent this now. In fact I think you
could make a fully conforming compiler that additionally supports
'extern "g++ 3.0"', 'extern "WinAPI"' or 'extern "stdcall"   '.

Regards, J   rg

--
J   rg Barfurth                         joerg.barfurth@attglobal.net
<<<<<<<<<<<<< using std::disclaimer;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Software Developer                    http://www.OpenOffice.org
StarOffice Configuration              http://www.sun.com/staroffice

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <1eytm7g.12quiy6u3s1qwN%joerg.barfurth@attglobal.net>,
joerg.barfurth@attglobal.net (Joerg Barfurth) wrote:
>Even if a language linkage does allow linking to code written in a given
>language, that does not mean that C++-declarations under that language
>linkage are textually equivalent to declarations of the same entity in
>the other language.

What is needed is that the linker recognizes which language the object
belongs -- assuming that the linker is enough advanced to recognize
languages. (I think that some linkers may not be that advanced, only able
to recognize names, which then must be suitably mangled by the compiler
writer. This is something I do not know much about, though.)

>Thus in=20
>  extern "C" int foo();
>
>'int' is the C++-Type int and is not necessarily identical to type int
>in all linkable C implementations.

So assume that the linker is able to recognize languages. Then in
  extern "C" A f(B) { ... }
one must decide what to hand over to the linker. The C++ compiler then
need to insert the suitable conversion operators, so it works together
with the other functions. If A and B are C++ types, then there must be
conversion functions
  extern "C++" B -> extern "C" B
  extern "C" A   -> extern "C++" A
because the linker will only recognize the variation where A and B both
are extern "C", or where both are extern "C++".

It probably does not work so, because currently, the linking business is a
mess from point of view of logical structure. But I think that if one
should require linkers to recognize languages, then this is the equation
that one make use of.

 Thus the same function may need to be
>declared as=20
>  long foo(void);
>
>in C.
>
> a C++ implementation might define that
>
>  extern "Pascal" void foo(short);
>
>can be used to declare and call in C++ code a function that is defined
>in some Pascal dialect as
>
>  procedure foo( i : Integer ) BEGIN { ... } END
>
>Thus you also don't need any 'conversion operators' to define a
>conversion between homonymous types having different binary
>representations.

I am not sure what you saying here: If the compiler does not insert the
correct conversions functions, then the linker won't do it, so the
functions will just be handed a bunch of binary data which they cannot
compute properly with.

In fact, I had a compiler (now defunct Symantec of MacOS) which allowed
one to use different settings for the floats (IEEE or MacOS native), but
it would not hand over the settings information to the linker. So if the
libraries were compiled with different settings than your code, floating
point computations would produce strange results even though that the code
is 100% correct.

So sure, every type must have a correct conversion to a type in the other
language in this high level approach, even though one can make it by
language design choice more explicit or implicit.

One other way to go is to rely on knowledge of the binary implementations
used in the other language. For example, Pascal implements strings with
one byte indicating the length followed by the string characters. So if
one knows that the C/C++ bytes that your characters are one byte long,
then one can within C/C++ use unsigned char* representing Pascal types.
Thus, one would write
  extern "Pascal" unsigned char* f(unsigned char*);
Now if the linker dopes not check the types of the functions, it would
just pass the unsigned char* data directly over to the function f, and it
would work.

But this is essentially a low-level hack, with no capability to check the
correctness of the linking.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3b8a6dae$0$1883@news.denver1.Level3.net>, "Justin Randall"
<jrandall@verant.com> wrote:

>How linkage is achieved between languages seems to be something beyond the
>scope of the C++ standard.

>It may be more correct to specify linkage standards in general, apart from
>implementations. If that were the case, the role of the C++ standard
>(should) then be to conform to standards for linking.

>If there is no such standard, then we are left with a compromise that is, at
>best, limited to giving specific compiler/linker implementations some clue
>about linkage with some specific language.

The primitive linkers seems to be the problem:

In fact, if one could assume that C++ compilers came with their own
"pre-linker", then much more could be achieved. For example, template
functions could be treated as ordinary functions, if one assumes that the
pre-linker knows how to compute the template offsets. In some of the other
problems with the static analysis of references would go away, I think.

So if one could assume that linkers can recognize languages and perhaps
dialects, too, then one could do more with this "extern" directive.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:

> I am disregarding the fact that the compilers always must somehow be tu=
ned
> together.

But that is the key point. Maybe it is the only point.

You can really talk about achieving linkage only between
implementations, not languages. Thus to realize what linkage
specifications promise, you need implementations of the languages
concerned, plus compatibility effort by at least one of the
implementors.=20

For sustaining the compatibility, you either need collaboration of both
or some third party defining and evolving an ABI.=20

IMO 7.5/9 says it all.

> It seems me that the standard is flawed, as what is called "linkage to =
the
> language X" does not mean that one can actually link to code written in
> the language X.=20

AFAICT it is only in 7.5/3 that the standard explicitly mentions
"linking to code written in the programming language X", with "X" =3D=3D
"C". Otherwise 'language linkage' is used as a technical term. It really
means only that there is a string attached to each name and function
type. The name simply reflects the intened use.

OTOH the standard requires support for "C" language linkage, with
specific changes to the semantics within C++. But it simply cannot
require "that one can actually link to code written in the language C",
as there needn't be any C implementation on the same platform - at least
its existence shouldn't be mandated by the C++standard.

> There are two ways around this: One is to change the name
> to say "pseudo-linkage", so that it becomes explicitly clear that it is
> merely a way for the C++ compiler can attach language labels onto the c=
ode
> so that the linker might use it for linking.

I don't think "pseudo-linkage" captures it any better. I agree that
"language linkage" raises expectations that implementations of the
"linkage tag" need not fulfill.
=20
> Another way would be to strengthen the requirement so that linkage to t=
he
> language X actually means that one can link code to that language (even
> though, clearly, it still depends on the two compiler being tuned
> together).=20

Would you then also require that such a compiler exists. Would a
C++-implementation become nonconforming when production of the C
compiler it collaborates with is terminated.

>   extern "C" short foo(int);
> is not legal unless one has specified conversion operators
>   extern "C++" int -> extern "C" int
>   extern "C" short -> extern "C++" short

Who would have to specify them where ?
=20
> The spin off if forcing such conversion operators to be explicit in the
> language is that the types of the different languages need not be tuned
> together: In the example, it does not matter anymore that the integral
> types of the two different languages are the same.=20

You still need a language in which to specify the needed bridging code.
And that should be part of which language ? And once you have that, it
suffices to support linkage to the bridging language on either end.

> One could also go a
> step further, and use it to tune together different compilers of the sa=
me
> language, that is, if it is somehow possible to indicate in the "extern=
"
> declaration the name of the compiler.

I don't think there is anything to prevent this now. In fact I think you
could make a fully conforming compiler that additionally supports
'extern "g++ 3.0"', 'extern "WinAPI"' or 'extern "stdcall"=B4'.=20

Regards, J=F6rg

--=20
J=F6rg Barfurth                         joerg.barfurth@attglobal.net
<<<<<<<<<<<<< using std::disclaimer;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Software Developer                    http://www.OpenOffice.org
StarOffice Configuration              http://www.sun.com/staroffice

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote:

> I am away from home and my well thumbed copy of the standard but I thin=
k
> that:
>=20
> extern "C" {
> typedef void (cfntype)(void *);
> }
>=20
> class X
> {
>   static cfntype baz;
> ...
> };
>=20
> deals with that case.

7.5/4 says:
"A C language linkage is ignored for the names of class members and the
member function types of class member functions."

It does not say "non-static class member functions."  The subsequent
example may be misleading, as it supplies a non-static member function
and a static data member which happens to be a pointer to a C function.

Thus the closest workaround you can get is:

  class X
  {
    static cfntype& baz;
  ...
  };

And elsewhere

  extern "C"=20
  static=20
  void X_baz(void*) { /* ...*/ }
 =20
  cfntype & X::baz =3D X_baz;

Here X::baz is a C++- member name naming a C function, as intended.

Regards, Joerg

--=20
J=F6rg Barfurth                         joerg.barfurth@attglobal.net
<<<<<<<<<<<<< using std::disclaimer;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Software Developer                    http://www.OpenOffice.org
StarOffice Configuration              http://www.sun.com/staroffice

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <1eys049.1mtaactofnng2N%joerg.barfurth@attglobal.net>,
joerg.barfurth@attglobal.net (Joerg Barfurth) wrote:
>> Another way would be to strengthen the requirement so that linkage to t=
>he
>> language X actually means that one can link code to that language (even
>> though, clearly, it still depends on the two compiler being tuned
>> together).=20
>
>Would you then also require that such a compiler exists. Would a
>C++-implementation become nonconforming when production of the C
>compiler it collaborates with is terminated.

I leave that one to the standardization committee to figure out. :-)

Clearly, if there is no compiler of that other language available, trying
to link to it is meaningless, at least in the sense that it is not
possible to produce a running program for it.

With all a language additions that are added to C++, it seems reasonable
to require that it is detectable whether the feature is available, but
availability of feature is not a requirement by the standard.

Now, linking is a special chapter, as it is not a language feature or
something that the language normally has control over: It think that on
many platforms, the linker is supplied externally to the compilers. So it
is then difficult to tell whether supported compilers are available.

>>   extern "C" short foo(int);
>> is not legal unless one has specified conversion operators
>>   extern "C++" int -> extern "C" int
>>   extern "C" short -> extern "C++" short
>
>Who would have to specify them where ?

These must be known to the linker.

>> The spin off if forcing such conversion operators to be explicit in the
>> language is that the types of the different languages need not be tuned
>> together: In the example, it does not matter anymore that the integral
>> types of the two different languages are the same.=20
>
>You still need a language in which to specify the needed bridging code.
>And that should be part of which language ? And once you have that, it
>suffices to support linkage to the bridging language on either end.

My guess is that the compiler would be required to supply conversions for
basic types. For compound types, one can supply conversion operators in
any language available (but most likely assembler or C++).

The main point is that
  extern "C++" int
and
  extern "C" int
need not anymore have the same underlying binary structure.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg <remove.haberg@matematik.su.se> wrote:

> >>   extern "C" short foo(int);
> >> is not legal unless one has specified conversion operators
> >>   extern "C++" int -> extern "C" int
> >>   extern "C" short -> extern "C++" short

> The main point is that=20
>   extern "C++" int
> and
>   extern "C" int
> need not anymore have the same underlying binary structure.

Even if a language linkage does allow linking to code written in a given
language, that does not mean that C++-declarations under that language
linkage are textually equivalent to declarations of the same entity in
the other language.

Thus in=20
  extern "C" int foo();

'int' is the C++-Type int and is not necessarily identical to type int
in all linkable C implementations. Thus the same function may need to be
declared as=20
  long foo(void);

in C.

This may seem confusing for C, but it becomes clear when you consider
that

  extern "Pascal"=20
  procedure foo(i : Integer) forward;

is not well-formed C++, while a C++ implementation might define that

  extern "Pascal" void foo(short);

can be used to declare and call in C++ code a function that is defined
in some Pascal dialect as

  procedure foo( i : Integer ) BEGIN { ... } END

Thus you also don't need any 'conversion operators' to define a
conversion between homonymous types having different binary
representations. A C++ declaration is only concerned with C++ types,
even under a language linkage that is not 'extern "C++"'. Thus we
needn't require builtin support for type 'Boolean' to link to Pascal
code.

All that is needed is a mapping from one type system to the other which
allows finding the corresponding declaration in the other language. This
means that there needn't be any code or operational definitions, but
only descriptions of correspondence. If there only are matches for a
subset of the type system(s), then that means that only for declarations
from that subset linkage can be achieved.

Of course there isn't anything to prevent builtin conversions either.
Maybe a linker could automatically build stubs that do type conversions
and adjusts calling conventions. But I don't think that could be
considered a core part of what language linkage is intende for.

Regards, J=F6rg

--=20
J=F6rg Barfurth                         joerg.barfurth@attglobal.net
<<<<<<<<<<<<< using std::disclaimer;  <<<<<<<<<<<<<<<<<<<<<<<<<<<<
Software Developer                    http://www.OpenOffice.org
StarOffice Configuration              http://www.sun.com/staroffice

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <1eytm7g.12quiy6u3s1qwN%joerg.barfurth@attglobal.net>,
Joerg Barfurth <joerg.barfurth@attglobal.net> wrote:
>Hans Aberg <remove.haberg@matematik.su.se> wrote:
>> >>   extern "C" short foo(int);
>> >> is not legal unless one has specified conversion operators
>> >>   extern "C++" int -> extern "C" int
>> >>   extern "C" short -> extern "C++" short
>
>> The main point is that
>>   extern "C++" int
>> and
>>   extern "C" int
>> need not anymore have the same underlying binary structure.
>
>Even if a language linkage does allow linking to code written in a given
>language, that does not mean that C++-declarations under that language
>linkage are textually equivalent to declarations of the same entity in
>the other language.
>
>Thus in
>  extern "C" int foo();
>
>'int' is the C++-Type int and is not necessarily identical to type int
>in all linkable C implementations.

Agreed.

>Thus the same function may need to be
>declared as
>  long foo(void);
>
>in C.

Agreed.  Perhaps even in C++ :)

>This may seem confusing for C, but it becomes clear when you consider
>that
>
>  extern "Pascal"=
>  procedure foo(i : Integer) forward;
>
>is not well-formed C++, while a C++ implementation might define that
>
>  extern "Pascal" void foo(short);
>
>can be used to declare and call in C++ code a function that is defined
>in some Pascal dialect as
>
>  procedure foo( i : Integer ) BEGIN { ... } END

Sure, the C++ side still needs to be C++.

>Thus you also don't need any 'conversion operators' to define a
>conversion between homonymous types having different binary
>representations. A C++ declaration is only concerned with C++ types,
>even under a language linkage that is not 'extern "C++"'. Thus we
>needn't require builtin support for type 'Boolean' to link to Pascal
>code.

We may not need them in the core C++ language itself, but that
doesn't mean they don't need to be somewhere.

>All that is needed is a mapping from one type system to the other which
>allows finding the corresponding declaration in the other language. This
>means that there needn't be any code or operational definitions, but
>only descriptions of correspondence. If there only are matches for a
>subset of the type system(s), then that means that only for declarations
>from that subset linkage can be achieved.

This is left vague in the Standard, but purposely so,
so I agree what you say seems possible.

>Of course there isn't anything to prevent builtin conversions either.
>Maybe a linker could automatically build stubs that do type conversions
>and adjusts calling conventions. But I don't think that could be
>considered a core part of what language linkage is intende for.

It may not be core w.r.t intent, but it sure it core as to
an expected implementation detail.
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <t3ofp6ft60.fsf@watts.itp.tuwien.ac.at>, Christopher Eltschka
<celtschk@web.de> writes
>class X
>{
>  // ...
>private:
>  extern "C" static void baz(void*);
>    // to be passed to C functions per pointer
>};

I am away from home and my well thumbed copy of the standard but I think
that:

extern "C" {
typedef void (cfntype)(void *);
}

class X
{
  static cfntype baz;
...
};

deals with that case.



Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9lfb5f$7so$1@panix3.panix.com>, Greg Comeau
<comeau@panix.com> writes
>>However, as long as such
>>things as size and alignment are compatible, C++ can require that a C++
>>compiler supports calling a function written in C.
>
>I think I disagree.  I mean, I think it can try hard for it,
>but don't think it does go that full mile in the current C++ language
>specification.  Maybe I'm misunderstanding you though.

No, I am sure we are in agreement. C & C++ compilers must be compatible
for a C++ program to link in a call to a function implemented and
compiled by a C compiler.

Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3B7B9376.BADA6A60@lmf.ericsson.se>,
Attila Feher  <Attila.Feher@lmf.ericsson.se> wrote:
>Wuppp.  I tought (all the posts here made me understand) it has been
>standardized.  My apologies.  So FORTRAN (whatever) extern is not
>standard.

It's not required.

>I was also a bit surprised, because (was it Scott Meyers?)
>one of my books said it is only extern "C", which is standard covered...

extern "C++" is required too
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries.  Have you tried it?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3B7B9376.BADA6A60@lmf.ericsson.se>, Attila Feher
<Attila.Feher@lmf.ericsson.se> writes
>Wuppp.  I tought (all the posts here made me understand) it has been
>standardized.  My apologies.  So FORTRAN (whatever) extern is not
>standard.  I was also a bit surprised, because (was it Scott Meyers?)
>one of my books said it is only extern "C", which is standard covered...

Not quite, 17.4.3.1.3 requires that both extern "C" and extern "C++" be
supported.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1308011259440001@du132-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>In article <9l62tf$c2g$1@panix3.panix.com>, comeau@comeaucomputing.com wrote:
>>IMO, it gets fuzzy, but the thing is that the liberty for
>>it to "do the right thing" does exist.  I'm not sure what you
>>mean by "special Pascal compiler" since usually so-called
>>"LanguageX calling convention" is a slippery beast in itself,
>>and so one usually is talking about calling conventions
>>for a specific release of a specific compiler (though clearly
>>some convention are popular).
>
>I am disregarding the fact that the compilers always must somehow be tuned
>together.

Ok (it seem you want to go somewhere with this).

>Then there is the question how much the linker should check for the
>accuracy of the linking. In the example I gave, I figure that as Pascal
>does not have name overloading, perhaps the linker would just be handed
>down a function name, assuming that the binary argument is correct. Then
>there would be no problems with
>  extern "Pascal" void f(unsigned char*);
>as the argument is untyped by the time the linker sees the function a
>Pascal type.

If I understand what you've said, yes, I think that's possible.

>In article <KZEHKGBgCqd7EwcR@ntlworld.com>, Francis Glassborow
><francisG@robinton.demon.co.uk> wrote:
>>... the C++ compiler has no idea
>>what will link to C. That is an issue for the programmer, knowing what
>>the compilers require. There is no reason that even this will link to C
>>object code:
>>
>>extern "C" int foo(int, int);
>
>It seems me that the standard is flawed, as what is called "linkage to the
>language X" does not mean that one can actually link to code written in
>the language X. There are two ways around this: One is to change the name
>to say "pseudo-linkage", so that it becomes explicitly clear that it is
>merely a way for the C++ compiler can attach language labels onto the code
>so that the linker might use it for linking.

There probably is a terminology issue here, but I don't think that
means (or at least has to mean) it is flawed.  Either way the
semantics (or lack thereof) need to be described.  Anyway, I agree,
there often seem to be confusion in the part of the standard.

>Another way would be to strengthen the requirement so that linkage to the
>language X actually means that one can link code to that language (even
>though, clearly, it still depends on the two compiler being tuned
>together). Then
>  extern "C" short foo(int);
>is not legal unless one has specified conversion operators
>  extern "C++" int -> extern "C" int
>  extern "C" short -> extern "C++" short
>
>The spin off if forcing such conversion operators to be explicit in the
>language is that the types of the different languages need not be tuned
>together: In the example, it does not matter anymore that the integral
>types of the two different languages are the same. One could also go a
>step further, and use it to tune together different compilers of the same
>language, that is, if it is somehow possible to indicate in the "extern"
>declaration the name of the compiler.

A problem that I have with this is that to link to Language X can't
actually mean to link to Language X because often Language X doesn't
describe what linking to it actually means.  So it would seem
wrong for Standard C++ to do so.  I mean, how could it?
(I think you may actually say so above, but I didn't get it.)
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout

Tasty C99/C++ Combo: Dinkumware libs + Comeau Compilers == WOW!!!

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9l8qvc$7ig$1@panix3.panix.com>, comeau@comeaucomputing.com wrote:
>A problem that I have with this is that to link to Language X can't
>actually mean to link to Language X because often Language X doesn't
>describe what linking to it actually means.

Strictly speaking only if the language describes how it should be
converted into binary code, at least in the linking part.

>  So it would seem
>wrong for Standard C++ to do so.  I mean, how could it?
>(I think you may actually say so above, but I didn't get it.)

The standard (in 7.5) already speaks about "linking to a language".

It seems though that objects in a language have an interface which is used
when linking together with other objects. So linking to another language
would mean something like being compatible with that interface of the
objects of that language. Then this interface is created via language
constructs. So it seems that one should be able to create a definition of
some sort expressing this compatibility condition on the language level
(even though I am not sure what exactly this formulation should be).

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1408010919180001@du136-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>The standard (in 7.5) already speaks about "linking to a language".
>
>It seems though that objects in a language have an interface which is used
>when linking together with other objects. So linking to another language
>would mean something like being compatible with that interface of the
>objects of that language. Then this interface is created via language
>constructs. So it seems that one should be able to create a definition of
>some sort expressing this compatibility condition on the language level
>(even though I am not sure what exactly this formulation should be).

In fact all C++ can do is provide tool s for C++ to link with other
languages extern "Fortran" doesn't specify that C++ code can be called
from Fortran, what it does is to provide a mechanism whereby C++ can
call Fortran functions. The closeness of C and C++ means that it can
often work the other way round without C doing much, however, for
example,  how will C handle on exception that has been thrown by some
function called by an extern "C" function definition? That is not
actually C++'s problem.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <AFhFdLA6bWe7EwlG@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>In fact all C++ can do is provide tool s for C++ to link with other
>languages extern "Fortran" doesn't specify that C++ code can be called
>from Fortran, what it does is to provide a mechanism whereby C++ can
>call Fortran functions.

(BTW, the standard recommends: extern "FORTAN", I recall.)

Sure C++ can ensure that it is possible to call C++ from say Pascal by
  extern "Pascal" a f(b x) {
    // C++ definition
  }
and adding provisions that the C++ global objects must be initialized
before their use, and terminated after their last use if the program is
terminated normally (plus proper exception handling and perhaps some). --
This question came up before, and I recall it was said that Ada has some
such provisions.

Then it becomes possible to call C++ from that other language. And it
hinges only on the C++ standard and not on the standard of that other
language.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

remove.haberg@matematik.su.se (Hans Aberg) writes:

| In article <AFhFdLA6bWe7EwlG@ntlworld.com>, Francis Glassborow
| <francisG@robinton.demon.co.uk> wrote:
| >In fact all C++ can do is provide tool s for C++ to link with other
| >languages extern "Fortran" doesn't specify that C++ code can be called
| >from Fortran, what it does is to provide a mechanism whereby C++ can
| >call Fortran functions.
|
| (BTW, the standard recommends: extern "FORTAN", I recall.)
                                            ^^

Certainly -not- :-) :-)

FORTRAN (in all capitals) is a generic name to designate any version
of that language released before 1977 (inclusive) and Fortran any
version after 1990 (inclusive). So you've got two extern
specifications.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1408010919180001@du136-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>In article <9l8qvc$7ig$1@panix3.panix.com>, comeau@comeaucomputing.com wrote:
>>A problem that I have with this is that to link to Language X can't
>>actually mean to link to Language X because often Language X doesn't
>>describe what linking to it actually means.
>
>Strictly speaking only if the language describes how it should be
>converted into binary code, at least in the linking part.

Which is why C++ doesn't strictly speak that. :)

>>  So it would seem
>>wrong for Standard C++ to do so.  I mean, how could it?
>>(I think you may actually say so above, but I didn't get it.)
>
>The standard (in 7.5) already speaks about "linking to a language".

Sure, but the implementations details are beyond the scope of
the standard, and rightly so IMO.

>It seems though that objects in a language have an interface which is used
>when linking together with other objects. So linking to another language
>would mean something like being compatible with that interface of the
>objects of that language. Then this interface is created via language
>constructs. So it seems that one should be able to create a definition of
>some sort expressing this compatibility condition on the language level
>(even though I am not sure what exactly this formulation should be).

But, for instance, C doesn't define what its full interface is,
so being able to say what it is from C++ doesn't follow.
Even if there are languages for where this could be done,
and I agree it could be done at least in part, it seems like
it would be at the wrong level for a number of reasons.
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout

Tasty C99/C++ Combo: Dinkumware libs + Comeau Compilers == WOW!!!

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:
[SNIP]
> FORTRAN (in all capitals) is a generic name to designate any version
> of that language released before 1977 (inclusive) and Fortran any
> version after 1990 (inclusive). So you've got two extern
> specifications.

Although I am not using Fortran this made me curious: what on Earth
could force the C++ comitee to come up with such "intuitive" kind of
disctinction?  I mean why isn't Fortan77 and Fortan90+ or something
which actually tells the difference?  If I get a code, should look into
it, see "FORTRAN" everywhere I wil never ever realize that the reason
why it does not work is that it is supposed to be now "Fortran"...

Just curious, since in other cases I always saw the community to take
extra care on being "easy to get".

Attila

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <AFhFdLA6bWe7EwlG@ntlworld.com>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In fact all C++ can do is provide tool s for C++ to link with other
>languages extern "Fortran" doesn't specify that C++ code can be called
>from Fortran, what it does is to provide a mechanism whereby C++ can
>call Fortran functions. The closeness of C and C++ means that it can
>often work the other way round without C doing much, however, for
>example,  how will C handle on exception that has been thrown by some
>function called by an extern "C" function definition? That is not
>actually C++'s problem.

I agree with issues of say exception handling, but still
feel C++ allows linkage specifications to be bi-directional.
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout

Tasty C99/C++ Combo: Dinkumware libs + Comeau Compilers == WOW!!!

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <fly9omp9ba.fsf@pizza.cmla.ens-cachan.fr>, Gabriel Dos Reis
<dosreis@cmla.ens-cachan.fr> wrote:
>| (BTW, the standard recommends: extern "FORTAN", I recall.)

>Certainly -not- :-) :-)

>FORTRAN (in all capitals) is a generic name to designate any version
>of that language released before 1977 (inclusive) and Fortran any
>version after 1990 (inclusive). So you've got two extern
>specifications.

Sorry, verse 7.5:2 says that the use of the FORTRAN/Fortran names is
vintage dependendent -- I should have looked it up. :-)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Attila Feher <Attila.Feher@lmf.ericsson.se> writes:

| Gabriel Dos Reis wrote:
| [SNIP]
| > FORTRAN (in all capitals) is a generic name to designate any version
| > of that language released before 1977 (inclusive) and Fortran any
| > version after 1990 (inclusive). So you've got two extern
| > specifications.
|
| Although I am not using Fortran this made me curious: what on Earth
| could force the C++ comitee to come up with such "intuitive" kind of
| disctinction?

The C++ committee didn't make that '"intuitive" kind of distinction'.
It is not its business to legislate anything about Fortran or FORTRAN.

The C++ Standard just says in a note (a non normative text):

   it is recommended that the spelling be taken from the document
   defining that language, for example Ada (not ADA) and Fortran or
   FORTRAN (depending on the vintage).

Anyway, since the meaning is implementation-defined, you will have to
read the doucmentation accompanying your implementation to see how to
spell it.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9lclar$cs6$1@panix3.panix.com>, Greg Comeau
<comeau@panix.com> writes
>I agree with issues of say exception handling, but still
>feel C++ allows linkage specifications to be bi-directional.

Of course it allows it, but it is up to the language in which the call
is made to decide what is allowed.  C++ cannot force a C compiler to
allow linkage to a C++ implemented function. However, as long as such
things as size and alignment are compatible, C++ can require that a C++
compiler supports calling a function written in C.

This is very much language law at the extreme:)



Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3B7A3FAF.1E5AD4B2@lmf.ericsson.se>,
Attila Feher  <Attila.Feher@lmf.ericsson.se> wrote:
>Gabriel Dos Reis wrote:
>> FORTRAN (in all capitals) is a generic name to designate any version
>> of that language released before 1977 (inclusive) and Fortran any
>> version after 1990 (inclusive). So you've got two extern
>> specifications.
>
>Although I am not using Fortran this made me curious: what on Earth
>could force the C++ comitee to come up with such "intuitive" kind of
>disctinction?  I mean why isn't Fortan77 and Fortan90+ or something
>which actually tells the difference?  If I get a code, should look into
>it, see "FORTRAN" everywhere I wil never ever realize that the reason
>why it does not work is that it is supposed to be now "Fortran"...

The C++ Standard doesn't place a requirement for how "FORTRAN"
should be spelled, it is only mentioned as a suggestion.
It's up to the implementation (including to reject it).
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries.  Have you tried it?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <F46UitAWXre7Ew2z@ntlworld.com>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <9lclar$cs6$1@panix3.panix.com>, Greg Comeau
><comeau@panix.com> writes
>>I agree with issues of say exception handling, but still
>>feel C++ allows linkage specifications to be bi-directional.
>
>Of course it allows it, but it is up to the language in which the call
>is made to decide what is allowed.

Agreed.

>C++ cannot force a C compiler to
>allow linkage to a C++ implemented function.

Agreed.

>However, as long as such
>things as size and alignment are compatible, C++ can require that a C++
>compiler supports calling a function written in C.

I think I disagree.  I mean, I think it can try hard for it,
but don't think it does go that full mile in the current C++ language
specification.  Maybe I'm misunderstanding you though.
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries.  Have you tried it?

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:
>
> Attila Feher <Attila.Feher@lmf.ericsson.se> writes:
>
> | Gabriel Dos Reis wrote:
> | [SNIP]
> | > FORTRAN (in all capitals) is a generic name to designate any version
> | > of that language released before 1977 (inclusive) and Fortran any
> | > version after 1990 (inclusive). So you've got two extern
> | > specifications.
> |
> | Although I am not using Fortran this made me curious: what on Earth
> | could force the C++ comitee to come up with such "intuitive" kind of
> | disctinction?
>
> The C++ committee didn't make that '"intuitive" kind of distinction'.
> It is not its business to legislate anything about Fortran or FORTRAN.
>
> The C++ Standard just says in a note (a non normative text):
>
>    it is recommended that the spelling be taken from the document
>    defining that language, for example Ada (not ADA) and Fortran or
>    FORTRAN (depending on the vintage).
>
> Anyway, since the meaning is implementation-defined, you will have to
> read the doucmentation accompanying your implementation to see how to
> spell it.

Wuppp.  I tought (all the posts here made me understand) it has been
standardized.  My apologies.  So FORTRAN (whatever) extern is not
standard.  I was also a bit surprised, because (was it Scott Meyers?)
one of my books said it is only extern "C", which is standard covered...

Thanx for the info, I somehow absolutely misunderstood this part of the
thread.

Attila

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Bobby Schmidt wrote:
>
> In my Sep 2001 column for CUJ, I conjecture that the C++ standard's
> authors explicitly intend `extern "C"` to let C++ code call C code, but
> do not explicitly intend it to allow C code to call C++. The standard
> may tolerate C calling C++ -- and indeed, many C++ implementations
> allows such calls -- but the standard does not explicitly guarantee or
> even endorse this behavior.
>
> Scott Meyers has a different interpretation: `extern "C"` lets code be
> called as if it were written in C, regardless of what it's actually
> written in. Further, by Scott's reckoning, the standard intentionally
> allows such C++ code to be callable from C. (He enshrines this in Item
> 34 of More Effective C++.)
>
> To support his argument, Scott draws connections between subclauses 3.5
> and 7.5 that make me a bit nervous. Nonetheless, I'm now thinking that
> he's right and my CUJ item is wrong, or at least misleading/incomplete
> -- that `extern "C"` is an editorial on the code's apparent semantics,
> and not on the actual/intended language of the caller or callee.
>
> So I'm appealing for wisdom here: what *exactly* is the Committee's
> intent for `extern "C"`? And what of that intent is guaranteed by the
> standard vs. simply tolerated?

Keep in mind that the C++ standard cannot constrain a C implementation,
and doesn't even try. The only thing that the standard gurantees is the
behavior when a name or a function type with C language linkage is both
defined and used in C++. Almost everything important about language
linkage is implementation-defined. Therefore, most of what I say below
about C code is purely a matter of intent. Here's my understanding:

First of all, be sure to distinguish the language linkage of names from
the language linkage of function types. A function's type and a
function's name can have different language linkages (see 7.5p4 for an
example).

An expression with function type that has C language linkage is intended
to refer to a function that uses a calling convention that is compatible
with C. It therefore can be evaluated from within C++, even if the
function that it calls as a result was defined in code that was compiled
in C. An expression of that type can be assigned to a function pointer
that is shared with C code; such a function pointer can be dereferenced
inside C code, even if the function it pointed at was defined in C++.

A name with C language linkage is a name that is handled in such a way
that it is compatible with C code. In particular, if the name is the
name of a function, there's none of the name mangling that is used by a
typical C++ implementation to allow overloading. Therefore, the name of
a function or object defined in C can be used unchanged in C++, if that
name is declared with C language linkage. It works the other way too; a
name of a function or object defined in C++ can be used from C code, if
the C++ definition declares it with C language linkage.

The effect is broader than it seems - if any other language provides C
interface support, it should also be possible to link from that language
to C++ through 'extern C' declarations, without any actual C code at
all.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <090820010209154805%BobbySchmidt@mac.com>, Bobby Schmidt
<BobbySchmidt@mac.com> wrote:
>Scott Meyers has a different interpretation: `extern "C"` lets code be
>called as if it were written in C, regardless of what it's actually
>written in. Further, by Scott's reckoning, the standard intentionally
>allows such C++ code to be callable from C. (He enshrines this in Item
>34 of More Effective C++.)

According to verses 7.5:2-3, one can apply the extern "C" linkage clause
to declarations, and C++ function definitions are declarations (see the
grammar summary A.6). Thus the following is possible:
  extern "C" A f(B x) {
    // C++ definition
  }
Here, A and B must be C types, but the body of the function is defined
using C++ objects.

>So I'm appealing for wisdom here: what *exactly* is the Committee's
>intent for `extern "C"`?

So the first intent I think is merely that the C++ compiler produces to
the linker functions that can be linked together with other C functions.
If the extern "C" functions are called in C++ code, the compiler should
know how to link them with C++ code.

> And what of that intent is guaranteed by the
>standard vs. simply tolerated?

Now, there is another snag, namely that C++ objects may depend on
initialization/termination. Then I think the note in verse 3.6.1:1 about
"freestanding environments" applies, which says it is implementation
defined. Clearly, if "main" is in C, the C compiler must know how to make
the initialization and termination of the C++ global objects for the
program to work. The same applies to DLL's.

So for this to work in practise, the C compiler must be tuned together
with the C++ compiler, but it is not required by the C++ standard. I think
that early C/C++ compilers may not have allowed it, but more recent
compilers do. (My compiler, which is not the latest model, does not accept
C linkage definitions with C++ in the body, but I think that GCC might.)

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1008011309410001@du132-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>Here, A and B must be C types

What are those, and how do you come by that requirement? I am not aware
that the Standard imposes any such restriction (though to use an extern
"C" function defined in C++ you need compatible parameters, C++ does
not, AFAIK, define such (well it does define PODs).


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3B733FA0.EFE7F4D5@wizard.net>, James Russell Kuyper Jr.
<kuyper@wizard.net> writes
>It works the other way too; a
>name of a function or object defined in C++ can be used from C code, if
>the C++ definition declares it with C language linkage.

And (and this is very important) the C compiler has a compaitble calling
sequence (most C compilers use the same one, but I do know ones that do
not, for example TopSpeed C - one of the very first compilers to get
full validation in the UK as ISO compliant) used name mangling to ensure
type safe linkage (and I believe this is allowed, just not required in
C). There is also the requirement for compatible types. A C++ compiler
that uses a 32-bit int will not work correctly with a C compiler that
happens to use a 16-bit int. (and, of course the same problem exists
between C compilers)

Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <rjRvUrB1oAd7Ew7$@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>>Here, A and B must be C types
>
>What are those, and how do you come by that requirement? I am not aware
>that the Standard imposes any such restriction (though to use an extern
>"C" function defined in C++ you need compatible parameters, C++ does
>not, AFAIK, define such (well it does define PODs).

Well, I don't see in
  extern "C" A f(B x) {
    // C++ definition
  }
if A and B are not C types, how f could be viewed as a C function from the
linking point of view. If they are something else, one must still be able
to convert them to objects that the linker can view as binary C objects
before handing them over to the linker.

Or so was my impression. If you know how it works, perhaps you should
describe it.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1008011309410001@du132-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>In article <090820010209154805%BobbySchmidt@mac.com>, Bobby Schmidt
><BobbySchmidt@mac.com> wrote:
>...
>  extern "C" A f(B x) {
>    // C++ definition
>  }
>Here, A and B must be C types, but the body of the function is defined
>using C++ objects.

Must be C types?   No, extern "C" does not mean the compiler
needs to enter a C mode or anything.   It is normal C++ code.

>>So I'm appealing for wisdom here: what *exactly* is the Committee's
>>intent for `extern "C"`?
>
>So the first intent I think is merely that the C++ compiler produces to
>the linker functions that can be linked together with other C functions.
>If the extern "C" functions are called in C++ code, the compiler should
>know how to link them with C++ code.

Your first sentence is only an intent (since Standard C++ doesn't
control Standard C).  But your second sentence is a requirement
(at least upon a sole C++ implementation).

>> And what of that intent is guaranteed by the
>>standard vs. simply tolerated?
>
>Now, there is another snag, namely that C++ objects may depend on
>initialization/termination. Then I think the note in verse 3.6.1:1 about
>"freestanding environments" applies, which says it is implementation
>defined. Clearly, if "main" is in C, the C compiler must know how to make
>the initialization and termination of the C++ global objects for the
>program to work. The same applies to DLL's.

It must know as a practical consideration, otherwise, right, what
you're trying to do won't work, but neither standard requires it to work.

>So for this to work in practise, the C compiler must be tuned together
>with the C++ compiler,

Right.

>but it is not required by the C++ standard

Or the C standard :)

>I think that early C/C++ compilers may not have allowed it, but more recent
>compilers do.

Some did, some didn't, some do, some don't. :)

> (My compiler, which is not the latest model, does not accept
>C linkage definitions with C++ in the body, but I think that GCC might.)

If I understand you correctly, I've never heard that before.
Can you give an example of what you mean?
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout

Tasty C99/C++ Combo: Dinkumware libs + Comeau Compilers == WOW!!!

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <tz7uwdBcjAd7Ewb7@ntlworld.com>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <3B733FA0.EFE7F4D5@wizard.net>, James Russell Kuyper Jr.
><kuyper@wizard.net> writes
>>It works the other way too; a
>>name of a function or object defined in C++ can be used from C code, if
>>the C++ definition declares it with C language linkage.
>
>And (and this is very important) the C compiler has a compaitble calling
>sequence (most C compilers use the same one, but I do know ones that do
>not, for example TopSpeed C - one of the very first compilers to get
>full validation in the UK as ISO compliant) used name mangling to ensure
>type safe linkage (and I believe this is allowed, just not required in
>C)

I think there's two statements being made there.  The first is
whether name mangling is required in C.  I think that the answer,
clearly, is no (although it's allowed, it's not a requirement).
The other is whether type safe linkage is required in C.
Certainly some form is.
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout

Tasty C99/C++ Combo: Dinkumware libs + Comeau Compilers == WOW!!!

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1008012124210001@du136-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>Well, I don't see in
>  extern "C" A f(B x) {
>    // C++ definition
>  }
>if A and B are not C types, how f could be viewed as a C function from the
>linking point of view. If they are something else, one must still be able
>to convert them to objects that the linker can view as binary C objects
>before handing them over to the linker.

It's just that the implementation, or the user, has that flexibility.
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout

Tasty C99/C++ Combo: Dinkumware libs + Comeau Compilers == WOW!!!

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hans Aberg wrote:
>
> In article <rjRvUrB1oAd7Ew7$@ntlworld.com>, Francis Glassborow
> <francisG@robinton.demon.co.uk> wrote:
> >>Here, A and B must be C types
> >
> >What are those, and how do you come by that requirement? I am not aware
> >that the Standard imposes any such restriction (though to use an extern
> >"C" function defined in C++ you need compatible parameters, C++ does
> >not, AFAIK, define such (well it does define PODs).
>
> Well, I don't see in
>   extern "C" A f(B x) {
>     // C++ definition
>   }
> if A and B are not C types, how f could be viewed as a C function from the
> linking point of view. If they are something else, one must still be able
> to convert them to objects that the linker can view as binary C objects
> before handing them over to the linker.
>
> Or so was my impression. If you know how it works, perhaps you should
> describe it.

A and B don't have to be C types. However, if they are not C types, then
the way in which they can be used is implementation defined. An
implementation is free to define it's C++ interfaces in such a way that
the following header file, if included in both C and C++ code, would
allow a definition of f() in one language to be called from within the
other:

connector.h:
#ifdef __cplusplus

typedef int &A;
class MyClass{
 int i;
 int j;
};
typedef int MyClass::*B;
extern "C" A f(B);

#else

typedef int *A;
typedef long int B;
extern A f(B);

#endif

Of course, an implementation is also free to make such a program blow
up; it's implemenation-defined.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1008012124210001@du136-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>Well, I don't see in
>  extern "C" A f(B x) {
>    // C++ definition
>  }
>if A and B are not C types, how f could be viewed as a C function from the
>linking point of view. If they are something else, one must still be able
>to convert them to objects that the linker can view as binary C objects
>before handing them over to the linker.
>
>Or so was my impression. If you know how it works, perhaps you should
>describe it.

extern "C" is about C++.

extern "C" void foo(mytype);

How does it matter what type mytype is? Unlike function, we do not
overload types so as long as mytype has a unique ID, that is the end of
the story. Of course a C program cannot pass arguments to foo unless it
has a compatible type but that is quite different and not the concern of
the linker. The linker only has to find object code from compiling a
function definition for foo. If the argument does not match, it is the
compilers job to call it out.

Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9l1los$281$1@panix3.panix.com>, comeau@comeaucomputing.com wrote:
>>  extern "C" A f(B x) {
>>    // C++ definition
>>  }
...
>> (My compiler, which is not the latest model, does not accept
>>C linkage definitions with C++ in the body, but I think that GCC might.)
>
>If I understand you correctly, I've never heard that before.
>Can you give an example of what you mean?

Plugging in some values in the example above, I arrive at say
  extern "C" int f(int) { return 1; }
My out-of-date compiler (compiling under C++) then says
  Error   : illegal function definition

But according to 7.5:2-3, 7.1:1 (A.6) and 8.4, this should be legal.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Thu,  9 Aug 2001 18:26:15 GMT, Bobby Schmidt wrote:
> To support his argument, Scott draws connections between subclauses 3.5
> and 7.5 that make me a bit nervous.

Well duh.  He's the MSDN columnist in charge of C# and he's nervous about
the C++ Standard?  :-) :-) :-)

Anyway, here's the argument I sent to Bobby in response to his current CUJ
column:

  I don't think your discussion of the semantics of extern "C" holds water.
  Let me explain why I care.  This is from Item 34 of More Effective C++:

    The best way to view extern "C" is not as an assertion that the
    associated function is written in C, but as a statement that the function
    should be called as if it were written in C. (Technically, extern "C"
    means the function has C linkage, but what that means is far from
    clear. One thing it always means, however, is that name mangling is
    suppressed.)

    ...

    You can even declare C++ functions extern "C". This can be useful if
    you're writing a library in C++ that you'd like to provide to clients
    using other programming languages.

  As you can see, I have a vested interest in this issue.

  Linkage is defined in 3.5, where it's clear that linkage is a property of a
  name.  In particular, there is nothing said about it being a relationship
  between two entities (except for 3.5/11, which I'll get to in a minute).
  Hence it makes no sense to say that X links to Y or Y links to X.  Rather,
  X may have linkage and Y may have linkage.  Linkage matters only for name
  lookup; whether a name is found during linking depends in part on the
  linkage of that name.

  3.5/11 brings up the notion of linking "to" declarations for entities
  written in other languages.  But what does this mean?  Given the rest of
  3.5, it can mean only one thing: when name lookups occur during linking,
  the names found may correspond to entities implemented by other languages.
  That is, 3.5/11 does nothing more than suggest that a C++ program may
  include entities implemented in languages other than C++.

  Let us thus trot off to 7.5.  7.5/2 introduces the notion of linkage
  "between" code fragments.  Note that according to the usual rules of
  English, "between" is commutative: if X is between a and b, X is also
  between b and a.  Hence, 7.5/2 could just as easily have been started this
  way: "Linkage between non-C++ and C++ code fragments..."

  (As an aside, my favorite part of 7.5/2 is "The semantics of a language
  linkage other than C++ or C are implementation-defined."  Where does the
  Standard define the semantics of C++ and C linkage, especially given 7.5/9?
  On this matter, I stand by my statement in MEC++ above.)

  Of course, 7.5/3 is key.  It requires support for "linkage to functions
  written in the C programming language."  But 3.5 makes clear that linkage
  affects only the ability to perform name lookup during linking.  I thus
  read 7.5/3 this way:

    If you assign "C" linkage to an entity written in C++, that entity can be
    found (via name lookup) during linking to functions written in the C
    programming language.

  Thus, declaring a C++ function extern "C" is a way of making it callable
  from C, as far as the Standard is concerned.  As you point out in your
  column (and I point out at the beginning of MEC++ Item 34), there's a lot
  of stuff the Standard is NOT concerned with, but I think it's clear that
  extern "C" is indended to allow exactly the kind of thing that Phil Brooks
  and Jon Young said it was (provided the underlying C and C++ object models
  are compatible).

Scott

PS - Given what I think is less than crystal-clear wording in the Standard
on this topic, it was my suggestion that Bobby attempt to discern the
*intent* of the people who wrote the Standard.  His posting is presumably
at attempt to divine that intent.
--
Check out "THE C++ Seminar," http://www.gotw.ca/cpp_seminar/
Also check out "Effective STL," http://www.aw.com/estl/

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <v0ceBIAA0Hd7EwKT@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>extern "C" void foo(mytype);
>
>How does it matter what type mytype is? Unlike function, we do not
>overload types so as long as mytype has a unique ID, that is the end of
>the story. Of course a C program cannot pass arguments to foo unless it
>has a compatible type but that is quite different and not the concern of
>the linker. The linker only has to find object code from compiling a
>function definition for foo. If the argument does not match, it is the
>compilers job to call it out.

I got the impression that having extern "C" linkage meant that C code
could link to it. But here you seem to say that is not really the case;
instead having linkage to the C language may just as well mean that one
can link to it.

I am well aware of that one can mix types in a compiler if relies on the
underlying binary structure. For example, my C compiler can link to
Pascal. It uses the convention that Pascal strings correspond to C
unsigned char[256]. But the question is whether
  extern "Pascal" void f(unsigned char*);
is really linkage to the (standard) Pascal language, as a Pascal compiler
not really can link to it: One needs a special Pascal compiler aware of
these conventions.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1108011937150001@du131-226.ppp.su-
anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
>I got the impression that having extern "C" linkage meant that C code
>could link to it. But here you seem to say that is not really the case;
>instead having linkage to the C language may just as well mean that one
>can link to it.
That maybe an expression of intent, but the C++ compiler has no idea
what will link to C. That is an issue for the programmer, knowing what
the compilers require. There is no reason that even this will link to C
object code:

extern "C" int foo(int, int);

nor, if foo is defined and compiled with a C compiler, that your C++
code can call it successfully. However, it is just about certain that
the code will not link successfully if the declaration does not have
extern "C" linkage.

Many people expect too much from linkage specifications. They are
necessary but not sufficient.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <remove.haberg-1108011937150001@du131-226.ppp.su-anst.tninet.se>,
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>In article <v0ceBIAA0Hd7EwKT@ntlworld.com>, Francis Glassborow
><francisG@robinton.demon.co.uk> wrote:
>>extern "C" void foo(mytype);
>>
>>How does it matter what type mytype is? Unlike function, we do not
>>overload types so as long as mytype has a unique ID, that is the end of
>>the story. Of course a C program cannot pass arguments to foo unless it
>>has a compatible type but that is quite different and not the concern of
>>the linker. The linker only has to find object code from compiling a
>>function definition for foo. If the argument does not match, it is the
>>compilers job to call it out.
>
>I got the impression that having extern "C" linkage meant that C code
>could link to it. But here you seem to say that is not really the case;
>instead having linkage to the C language may just as well mean that one
>can link to it.

I think that Francis may have delineated compiler and linker
too strongly.  Anyway, I think the operative words are "could"
and "can" rather than "should" or "must".

>I am well aware of that one can mix types in a compiler if relies on the
>underlying binary structure. For example, my C compiler can link to
>Pascal. It uses the convention that Pascal strings correspond to C
>unsigned char[256]. But the question is whether
>  extern "Pascal" void f(unsigned char*);
>is really linkage to the (standard) Pascal language, as a Pascal compiler
>not really can link to it: One needs a special Pascal compiler aware of
>these conventions.

IMO, it gets fuzzy, but the thing is that the liberty for
it to "do the right thing" does exist.  I'm not sure what you
mean by "special Pascal compiler" since usually so-called
"LanguageX calling convention" is a slippery beast in itself,
and so one usually is talking about calling conventions
for a specific release of a specific compiler (though clearly
some convention are popular).
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout

Tasty C99/C++ Combo: Dinkumware libs + Comeau Compilers == WOW!!!

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9l62tf$c2g$1@panix3.panix.com>, comeau@comeaucomputing.com wrote:
>IMO, it gets fuzzy, but the thing is that the liberty for
>it to "do the right thing" does exist.  I'm not sure what you
>mean by "special Pascal compiler" since usually so-called
>"LanguageX calling convention" is a slippery beast in itself,
>and so one usually is talking about calling conventions
>for a specific release of a specific compiler (though clearly
>some convention are popular).

I am disregarding the fact that the compilers always must somehow be tuned
together.

Then there is the question how much the linker should check for the
accuracy of the linking. In the example I gave, I figure that as Pascal
does not have name overloading, perhaps the linker would just be handed
down a function name, assuming that the binary argument is correct. Then
there would be no problems with
  extern "Pascal" void f(unsigned char*);
as the argument is untyped by the time the linker sees the function a
Pascal type.

In article <KZEHKGBgCqd7EwcR@ntlworld.com>, Francis Glassborow
<francisG@robinton.demon.co.uk> wrote:
>... the C++ compiler has no idea
>what will link to C. That is an issue for the programmer, knowing what
>the compilers require. There is no reason that even this will link to C
>object code:
>
>extern "C" int foo(int, int);

It seems me that the standard is flawed, as what is called "linkage to the
language X" does not mean that one can actually link to code written in
the language X. There are two ways around this: One is to change the name
to say "pseudo-linkage", so that it becomes explicitly clear that it is
merely a way for the C++ compiler can attach language labels onto the code
so that the linker might use it for linking.

Another way would be to strengthen the requirement so that linkage to the
language X actually means that one can link code to that language (even
though, clearly, it still depends on the two compiler being tuned
together). Then
  extern "C" short foo(int);
is not legal unless one has specified conversion operators
  extern "C++" int -> extern "C" int
  extern "C" short -> extern "C++" short

The spin off if forcing such conversion operators to be explicit in the
language is that the types of the different languages need not be tuned
together: In the example, it does not matter anymore that the integral
types of the two different languages are the same. One could also go a
step further, and use it to tune together different compilers of the same
language, that is, if it is somehow possible to indicate in the "extern"
declaration the name of the compiler.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow <francis.glassborow@ntlworld.com> writes:

> In article <remove.haberg-1008012124210001@du136-226.ppp.su-
> anst.tninet.se>, Hans Aberg <remove.haberg@matematik.su.se> writes
> >Well, I don't see in
> >  extern "C" A f(B x) {
> >    // C++ definition
> >  }
> >if A and B are not C types, how f could be viewed as a C function from the
> >linking point of view. If they are something else, one must still be able
> >to convert them to objects that the linker can view as binary C objects
> >before handing them over to the linker.
> >
> >Or so was my impression. If you know how it works, perhaps you should
> >describe it.
>
> extern "C" is about C++.
>
> extern "C" void foo(mytype);
>
> How does it matter what type mytype is? Unlike function, we do not
> overload types so as long as mytype has a unique ID, that is the end of
> the story.

No, that's the beginning of the story.

If it were the end of the story, you could pass the foo you defined
above to

  void bar(void(*)(mytype))

but you can't because foo has the type "C function taking mytype and
returning void" and bar expects the type "C++ function taking mytype
and returning void". Indeed, you can overload on C and C++ function
types!

One problem IMHO is that the two aspects are combined into one feature
(extern "C"), so you don't always have the possibility to get one
(especially the type) without getting the other (the non-overloading
"trans-namespace" feature caused by the turned off name mangling).

Some things you might want to do, but cannot:

extern "C"
{
  template<class T> void foo(T);
     // to be passed per pointer to C functions
     // name mangling wouldn't hurt
}

class X
{
  // ...
private:
  extern "C" static void baz(void*);
    // to be passed to C functions per pointer
};

namespace
{
  extern "C" void bar() {}
    // despite being in an unnamed namespace, this has not the effect
    // of making it local to the translation unit. Every declaration
    // of an extern "C" void bar() anywhere in the program refers to
    // this function. So you have to use static again.
}

The template has no real workaround at all. The class member AFAIK has
as only workaround to hve a global function instead (possibly just
calling the member function). Bad. The unnamed namespace function
problem is easily worked around with static, so it's a minor point
here, but it's still a nuissance.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In my Sep 2001 column for CUJ, I conjecture that the C++ standard's
authors explicitly intend `extern "C"` to let C++ code call C code, but
do not explicitly intend it to allow C code to call C++. The standard
may tolerate C calling C++ -- and indeed, many C++ implementations
allows such calls -- but the standard does not explicitly guarantee or
even endorse this behavior.

Scott Meyers has a different interpretation: `extern "C"` lets code be
called as if it were written in C, regardless of what it's actually
written in. Further, by Scott's reckoning, the standard intentionally
allows such C++ code to be callable from C. (He enshrines this in Item
34 of More Effective C++.)

To support his argument, Scott draws connections between subclauses 3.5
and 7.5 that make me a bit nervous. Nonetheless, I'm now thinking that
he's right and my CUJ item is wrong, or at least misleading/incomplete
-- that `extern "C"` is an editorial on the code's apparent semantics,
and not on the actual/intended language of the caller or callee.

So I'm appealing for wisdom here: what *exactly* is the Committee's
intent for `extern "C"`? And what of that intent is guaranteed by the
standard vs. simply tolerated?

--
Bobby Schmidt, Redmond WA USA               <BobbySchmidt@mac.com>
  Contributing Editor, C/C++ Users Journal  <www.cuj.com/current/>

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <090820010209154805%BobbySchmidt@mac.com>, Bobby Schmidt
<BobbySchmidt@mac.com> writes
>So I'm appealing for wisdom here: what *exactly* is the Committee's
>intent for `extern "C"`? And what of that intent is guaranteed by the
>standard vs. simply tolerated?


As the C++ Committee is not responsible for C it is not able to impose
requirements on how a C compiler should handle extern "C" functions in
C++. As there is no requirement even in C that code generated by one C
compiler can be linked to code generated by another C compiler I cannot
see how, even if it wanted to and with the full co-operation of the C
Standards Committees such a requirement could be made.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <090820010209154805%BobbySchmidt@mac.com>,
Bobby Schmidt  <BobbySchmidt@mac.com> wrote:
>In my Sep 2001 column for CUJ, I conjecture that the C++ standard's
>authors explicitly intend `extern "C"` to let C++ code call C code, but
>do not explicitly intend it to allow C code to call C++. The standard
>may tolerate C calling C++ -- and indeed, many C++ implementations
>allows such calls -- but the standard does not explicitly guarantee or
>even endorse this behavior.

IMO, it allows both directions, but guarantees neither direction.

>Scott Meyers has a different interpretation: `extern "C"` lets code be
>called as if it were written in C, regardless of what it's actually
>written in. Further, by Scott's reckoning, the standard intentionally
>allows such C++ code to be callable from C. (He enshrines this in Item
>34 of More Effective C++.)

I wouldn't use those words, but otherwise agree with the gist.

>To support his argument, Scott draws connections between subclauses 3.5
>and 7.5 that make me a bit nervous. Nonetheless, I'm now thinking that
>he's right and my CUJ item is wrong, or at least misleading/incomplete
>-- that `extern "C"` is an editorial on the code's apparent semantics,
>and not on the actual/intended language of the caller or callee.

Unless this says what you just said above, it might be best for
you to elaborate upon what you just said.

>So I'm appealing for wisdom here: what *exactly* is the Committee's
>intent for `extern "C"`? And what of that intent is guaranteed by the
>standard vs. simply tolerated?

I don't think anything is guaranteed here, but I do think a lot
of flexibility and intent is granted.
--
Greg Comeau                 Countdown to "export": December 1, 2001
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout

Tasty C99/C++ Combo: Dinkumware libs + Comeau Compilers == WOW!!!

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]