Greg Comeau <comeau@panix.com> wrote:

> In article <HkOd7.175$D4.84@www.newsranger.com>,
> Michiel Salters <Michiel.Salters@cmg.nl> wrote:
> >I agree with the "not sufficient" part, but is it necessary? I think
> >it is implementation dependent whether C and C++ code links without
> >extern "C", as I don't see a direct reason in C++ which requires
> >C++ compilers to output code unusable to C linkers.
> >
> >Ergo, without extern "C" it is implementation-defined whether C and C+=
+
> >code links, and with it it still is implementation-defined. The
> >optional extern "C" allows but does not require the C++ compiler to
> >support two linkage types.
>=20
> I'd be more comfortable in saying that it's unspecified w/o
> extern "C" rather than implementation-defined, though now that
> you mention it I'm not sure what it says, if anything.
> If it is unspecified, it may not ever(?) work, whereas if it's
> implementation defined at least there is a fighting chance
> via the documentation.

There is only one difference. The C++ standard mentions that extern "C"
linkage is meant to "provide for linkage to functions written in the C
programming language". It doesn't mention anything of that kind for
extern "C++" linkage.

It goes on to specify semantics for extern "C" functions and (of course)
extern "C++" functions, if used *and* defined entirely within a C++
program. Some more of those semantics and all of the semantics for other
language linkages is left "implementation-defined".

Beyond this, the standard cannot require behavior that is related to
code written in a programming language other than C++. Whether linkage
to such code is possible does not depend on the language, but on the
implementation. There may well be coexisting C implementations and/or
additional linkers which aren't even compatible to one another. Thus you
may have (for one C++ implementation) one C implementation that produces
code that can link directly to 'extern "C++"' code, another one that can
link only to 'extern "C"' code and a third one to which no linkage is
possible.

Because of this, I don't think "unspecified" is appropriate here; and it
would be hard to draw any line to "implementation defined" in this
context.=20

"Implementation defined" does only mean that _some_ _intended_ semantics
must be documented. This does not preclude third parties from providing
compilers for any other language that are compatible to any given
language linkage. Nor does it prevent the implementor from documenting
that extern "C++" linkage (plus some conventions about mapping types) is
compatible to some given implementation of C or maybe even Fortran.

OTOH "unspecified" usually applies to cases where the standard requires
some behavior, but neither mandates which one nor that the decision be
documented. But wrt language linkages the standard doesn't require that
there be any implementation of any programming language to which linkage
can be achieved. Thus not documenting any such compatibility would still
be possible under the terms of "implementation-defined". But if such a
compatibility exists and its public use is intented, it is very likely
that will be documented .

So all that remains is, that:

- For extern "C++" linkage it is tacitly assumed that it does not relate
to any implementation of another language, unless there is documentation
to the contrary;

- For extern "C" linkage, if (and only if) there is a C implementation
that is either 'platform standard' or 'obviously related' to the given
C++ implementation, the implementation must probably document whether
'extern "C"' provides for linkage to such implementation.

- For other language linkages nothing is known  in advance. If the
string literal is the official name of a well-known programming language
('extern "Ada"') one would expect that compatibility to an
implementation of the Ada programming language is documented (or else
that there is well-founded reasoning why this is provided without such
compatibility). If the string literal is anything else ('extern
"Stroustrup"','extern "Microsoft"'), there probably are few
expectations.=20

I'm not even sure how much of these expectations the standard actually
requires.

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                ]

Michiel> I agree with the "not sufficient" part, but is it necessary? I think
Michiel> it is implementation dependent whether C and C++ code links without
Michiel> extern "C", as I don't see a direct reason in C++ which requires
Michiel> C++ compilers to output code unusable to C linkers.

The usual reason is that linkers tend not to support overloading.
Therefore, C++ compilers have to encode each function's argument types
in the name for the function that it gives the linker.  It is not
sufficient to reserve that encoding for functions that are actually
overloaded, because two functions with the same name and different
argument types might occur in two different translation units.

Because C does not support overloading, C compilers typically do not
bother encoding argument types in function names.  In that case, C
programs and C++ programs won't be able to link together, even if they
have the same calling sequence, unless the C++ compiler knows to drop
the encoding for C functions -- which requirement implies that the C++
compiler has to know which ones are C functions and which ones are C++
functions.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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                ]

"James Russell Kuyper Jr." <kuyper@wizard.net> writes:

| Michiel Salters wrote:
| ...
| > I agree with the "not sufficient" part, but is it necessary? I think
| > it is implementation dependent whether C and C++ code links without
| > extern "C", as I don't see a direct reason in C++ which requires
| > C++ compilers to output code unusable to C linkers.

C++ standards don't require C++ compilers to output code unusable to C
linkers.  Is there anything in the C standards which disallows name
mangling for C programs?

Actually, there are out there CFront-like compilers which translate
C++ programs to C equivalent and then invoke the host C compiler to
produce the executable or library; such a library can be smoothly
combined with existing C programs.

| Function overloading is one of the key complications.

Templates also come into play.


--
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 <3B77E11F.B83A544C@wizard.net>, James Russell Kuyper Jr.
<kuyper@wizard.net> writes
>Michiel Salters wrote:
>...
>> I agree with the "not sufficient" part, but is it necessary? I think
>> it is implementation dependent whether C and C++ code links without
>> extern "C", as I don't see a direct reason in C++ which requires
>> C++ compilers to output code unusable to C linkers.
>
>Function overloading is one of the key complications.

Added to which, I do not see any requirement that a C++ compiler should
know what is acceptable to a C compiler, particularly when we consider
that the C compiler might have extensions that could handle the types I
choose to use.


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 <fl7kw8560e.fsf@jambon.cmla.ens-cachan.fr>,
Gabriel Dos Reis  <dosreis@cmla.ens-cachan.fr> wrote:
>Is there anything in the C standards which disallows name
>mangling for C programs?

No.  C's view of type-safe linkage seems to require something
be done, though what the something is is an implementation detail.

>Actually, there are out there CFront-like compilers which translate
>C++ programs to C equivalent and then invoke the host C compiler to
>produce the executable or library; such a library can be smoothly
>combined with existing C programs.

Comeau C++ does that.  The thing though is that since it'll be tied
to a particular C compiler anyway, native code compilers should be
able to experience the same capability, and I think they do.
Or did you mean something else?
--
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 <KZEHKGBgCqd7EwcR@ntlworld.com>, Francis Glassborow says...
>
>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

I agree with the "not sufficient" part, but is it necessary? I think
it is implementation dependent whether C and C++ code links without
extern "C", as I don't see a direct reason in C++ which requires
C++ compilers to output code unusable to C linkers.

Ergo, without extern "C" it is implementation-defined whether C and C++
code links, and with it it still is implementation-defined. The
optional extern "C" allows but does not require the C++ compiler to
support two linkage types.

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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                ]

Michiel Salters wrote:
...
> I agree with the "not sufficient" part, but is it necessary? I think
> it is implementation dependent whether C and C++ code links without
> extern "C", as I don't see a direct reason in C++ which requires
> C++ compilers to output code unusable to C linkers.

Function overloading is one of the key complications.

---
[ 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                ]

"Michiel Salters" <Michiel.Salters@cmg.nl> wrote in message
news:HkOd7.175$D4.84@www.newsranger.com...
[SNIP]
> ... I don't see a direct reason in C++ which requires
> C++ compilers to output code unusable to C linkers.
>
> Ergo, without extern "C" it is implementation-defined whether C and C++
> code links, and with it it still is implementation-defined. The
> optional extern "C" allows but does not require the C++ compiler to
> support two linkage types.

But in the cases where the compiler _does_ support two linkage types
(typically mangled names vs unmangled names), it allows the programmer to
select which of the overloads of a function with a given name has the
"alternative" linkage (typically unmangled names).

IIRC, there is also the requirement that all references to an extern "C"
function of the same name refer to the same function, irrespective of their
namespace.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optoelectronics
The opinions expressed in this message are not necessarily those of my
employer



---
[ 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 <HkOd7.175$D4.84@www.newsranger.com>,
Michiel Salters <Michiel.Salters@cmg.nl> wrote:
>In article <KZEHKGBgCqd7EwcR@ntlworld.com>, Francis Glassborow says...
>>Many people expect too much from linkage specifications. They are
>>necessary but not sufficient.
>
>I agree with the "not sufficient" part, but is it necessary? I think
>it is implementation dependent whether C and C++ code links without
>extern "C", as I don't see a direct reason in C++ which requires
>C++ compilers to output code unusable to C linkers.
>
>Ergo, without extern "C" it is implementation-defined whether C and C++
>code links, and with it it still is implementation-defined. The
>optional extern "C" allows but does not require the C++ compiler to
>support two linkage types.

I'd be more comfortable in saying that it's unspecified w/o
extern "C" rather than implementation-defined, though now that
you mention it I'm not sure what it says, if anything.
If it is unspecified, it may not ever(?) work, whereas if it's
implementation defined at least there is a fighting chance
via the documentation.
--
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                ]

Doug Judd (djudd@ads.com) wrote:
: tony@online.tmx.com.au (Tony Cook) wrote:
: >
: > Have there been any changes from the ARM regarding 'extern "C"'
: > functions?
: >
: > I see three main problems with the rules in the ARM in relation to
: > the "C" standard library inherited from ANSI C:
: >
: >     a) qsort/bsearch - must the function pointer supplied to this be
: > a "C" or "C++" function.  If the ANSI C library is now a part of the
: > C++ standard library, then having to use 'extern "C"' functions with
: > qsort/bsearch will be inconvenient and not a little ridiculous.  For
: > example using static member functions or template functions as the
: > comparison function.
: >
: >     b) atexit - similarly for this - though the function of this can
: > be replaced by a destructor for a global static object.
: >
: >     c) signal - the handler function may cause problems.
: >
: > I'm sure there's other similar cases.

: I don't see any problem with the three examples you have presented
: above.  Have you tried them?  Supplying C++ functions to signal()
: works fine for me (gcc2.6.3  sparc-sun-sunos4.1.3_U1).

I have tried these and other similar calls - but a compiler (or all
compilers) compiling the code does not mean that the code is portable
ANSI/ISO C++.

: ARM r.7.4:

:  "Linkage from C++ to objects defined in other languages and to
:   objects defined in C++ from other languages is implementation and
:   language dependent."

: The primary reason for the extern "C" linkage specification is for
: resolving external symbols whos names are not mangled.  I suppose
: it is possible for a C++ compiler to not allow substitution of
: C functions with C++ functions, but it seems to me that it would
: be a significant amount of extra work for the compiler writer.

Did you see the annotation towards the end of section 7.4:
 "Since functions with different linkage may have different
  calling conventions, a linkage specification may have a major
  effect on pointers to functions."

None of the compilers I use will prevent passing a C++ function where a
C function is required, but apparently the Symantec C++ compiler for the
Mac does (there was a message a few days ago on comp.lang.c++ about this).

As C is so closely related to C++ we should either:
 a) force C++/C functions to have the same calling convention,
    by standard, or
 b) make the type system use the information in overloading.

See also the article:
 "Looking at the X Window System - Callback functions: The heart
  of every GUI's API", Ronald van Loon, C++ Report Nov/Dec 1994.

and also "Questions and Answers", C/C++ Users Jounal, Oct 1994.

        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com
--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

tony@online.tmx.com.au (Tony Cook) wrote:
>
> Have there been any changes from the ARM regarding 'extern "C"'
> functions?
>
> I see three main problems with the rules in the ARM in relation to
> the "C" standard library inherited from ANSI C:
>
>     a) qsort/bsearch - must the function pointer supplied to this be
> a "C" or "C++" function.  If the ANSI C library is now a part of the
> C++ standard library, then having to use 'extern "C"' functions with
> qsort/bsearch will be inconvenient and not a little ridiculous.  For
> example using static member functions or template functions as the
> comparison function.
>
>     b) atexit - similarly for this - though the function of this can
> be replaced by a destructor for a global static object.
>
>     c) signal - the handler function may cause problems.
>
> I'm sure there's other similar cases.

I don't see any problem with the three examples you have presented
above.  Have you tried them?  Supplying C++ functions to signal()
works fine for me (gcc2.6.3  sparc-sun-sunos4.1.3_U1).

ARM r.7.4:

 "Linkage from C++ to objects defined in other languages and to
  objects defined in C++ from other languages is implementation and
  language dependent."

The primary reason for the extern "C" linkage specification is for
resolving external symbols whos names are not mangled.  I suppose
it is possible for a C++ compiler to not allow substitution of
C functions with C++ functions, but it seems to me that it would
be a significant amount of extra work for the compiler writer.

- Doug

 o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o
 Doug Judd
 Advanced Decision Systems (Booz-Allen & Hamilton, Inc.)
 1500 Plymouth St., Mountain View, CA 94043-1230
 djudd@ads.com, (415) 960-7450