extern "C"

On Sep 5, 4:52 am, "northern_RATT" <n...@none.net> wrote:
> <snip>> I need to be able to mix C and C++.
> > The main program is written in C and needs to access C++
> > code. To be more specific it's a user defined function in
> > fluent, but this should not be relevant.

> > I've allready read that i need to use the extern "C"
> > construction but i don't seem to be doing it right.

> </snip>

> OK. Pardon a rank amature who only lurks here, BUT....
> This looks like backwards logic to me. I thought that
> 'extern C' is a way for C++ code to call undecorated C code(?)

No. 'extern "C"' tells the compiler to use C linkage, period.
A C++ function can be declared 'extern "C"', in which case, it
uses C linkage (but is C++ in every other way), and can be
called from a C program.

The classical example is the function passed to things like
pthread_create (Unix) or CreateThread (Windows); since this
function is called from C code, it must be 'extern "C"'.

> Not the otherway around!
> Not that I have ever needed to face this, but I thought that C
> calling C++ code needs some type of wrapper?

And how would you implement the wrapper? If you can't call C++
from C, you can't implement it in C, and if you implement it in
C++, you couldn't call it from C.

Typically, C++ code does require a wrapper, because it is using
argument types which C can't handle; the wrapper takes care of
any necessary type conversions. But thw wrapper itself is also
C++.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 4 Sep., 21:10, Ian Collins <ian-n...@hotmail.com> wrote:
> Uwe Schmitt wrote:
>
> > Which compilers do you use and how do you use them ?
>
> > If you use the gnu compiliers, you should use
>
> > * * *g++ -c cpplib.cpp
>
> > and then
>
> > * * *gcc cprogram.c cpplib.o
>
> > Greetings, Uwe
>
> That's very unlikely to work. *The main program must be compiled and
> linked as C++.

But all names cpplib.o are plain, because we used 'extern "C"' in
'function()'s declaration. So the linker will see no C++ mangled
symbolnames during linking.
Did I miss something ? Why should I use C++ compiler for compiling and
linking
a C program with some object file which looks like a C-object file ?

Greetings, Uwe

Uwe Schmitt <rocksportrocker@googlemail.com> writes:

> On 4 Sep., 21:10, Ian Collins <ian-n...@hotmail.com> wrote:
>> Uwe Schmitt wrote:
>>
>> > Which compilers do you use and how do you use them ?
>>
>> > If you use the gnu compiliers, you should use
>>
>> > * * *g++ -c cpplib.cpp
>>
>> > and then
>>
>> > * * *gcc cprogram.c cpplib.o
>>
>> > Greetings, Uwe
>>
>> That's very unlikely to work. *The main program must be compiled and
>> linked as C++.
>
> But all names cpplib.o are plain, because we used 'extern "C"' in
> 'function()'s declaration. So the linker will see no C++ mangled
> symbolnames during linking.
> Did I miss something ?

The public symbols exported by cpplib.o and used in cprogram aren't
the problem. The problem is that cpplib.o probably needs to link to
libstdc++. That happens by default when you use g++, but not with
gcc.

sherm--

--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net

On Sep 5, 7:29 pm, Uwe Schmitt <rocksportroc...@googlemail.com> wrote:
> On 4 Sep., 21:10, Ian Collins <ian-n...@hotmail.com> wrote:
> > Uwe Schmitt wrote:

> > > Which compilers do you use and how do you use them ?
> > > If you use the gnu compiliers, you should use

> > > g++ -c cpplib.cpp

> > > and then

> > > gcc cprogram.c cpplib.o

> > That's very unlikely to work. The main program must be compiled and
> > linked as C++.

> But all names cpplib.o are plain, because we used 'extern "C"' in
> 'function()'s declaration. So the linker will see no C++ mangled
> symbolnames during linking.

So?

> Did I miss something ? Why should I use C++ compiler for
> compiling and linking a C program with some object file which
> looks like a C-object file ?

The C++ standard is quite clear: main() must be compiled as C++.
Depending on the compiler, it might work if this isn't the case,
or it might not, or somethings might work, and others not. In
particular, with some compilers, there's a very good chance that
static variables won't be initialized correctly if main isn't
compiled as C++.

And mangling really has not got much to do with the problem.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Sep 5, 7:35 pm, Sherm Pendley <spamt...@dot-app.org> wrote:
> Uwe Schmitt <rocksportroc...@googlemail.com> writes:
> > On 4 Sep., 21:10, Ian Collins <ian-n...@hotmail.com> wrote:
> >> Uwe Schmitt wrote:
> >> > Which compilers do you use and how do you use them ?

> >> > If you use the gnu compiliers, you should use

> >> > g++ -c cpplib.cpp

> >> > and then

> >> > gcc cprogram.c cpplib.o

> >> That's very unlikely to work. The main program must be
> >> compiled and linked as C++.

> > But all names cpplib.o are plain, because we used 'extern
> > "C"' in 'function()'s declaration. So the linker will see no
> > C++ mangled symbolnames during linking. Did I miss
> > something ?

> The public symbols exported by cpplib.o and used in cprogram
> aren't the problem. The problem is that cpplib.o probably
> needs to link to libstdc++. That happens by default when you
> use g++, but not with gcc.

The problem is also that static variables have to be
initialized; some compilers do this by generating special code
in main. Of course, if main wasn't compiled with a C++
compiler, it won't have that special code.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

In article <48c0dbfe$0$17346$426a74cc@news.free.fr>,
michael.doubez@free.fr says...

[ ... ]

> Most c++ compiler support C99 unless you disable it in the command line.

Really? All the C++ compilers I have handy seem to reject the following
perfectly legal bit of C99 code:

union {
char birthday[9];
int age;
float weight;
} people = { .age = 14 };

Even Comeau (which will accept it as C99 code) rejects it as C++ code
(quite rightly, I might add, since it's ill formed C++ code, and I don't
believe C++ 0x will allow it either).

Every other compiler I have handy (Microsoft, Digital Mars, gnu) rejects
it as either C or C++. gnu has a '-std=c99' flag, but appears to
implement little enough of C99 that it doesn't accept this even with
that flag.

--
Later,
Jerry.

The universe is a figment of its own imagination.

On 5 Sep., 20:25, James Kanze <james.ka...@gmail.com> wrote:
> On Sep 5, 7:35 pm, Sherm Pendley <spamt...@dot-app.org> wrote:
>
>
>
> > Uwe Schmitt <rocksportroc...@googlemail.com> writes:
> > > On 4 Sep., 21:10, Ian Collins <ian-n...@hotmail.com> wrote:
> > >> Uwe Schmitt wrote:
> > >> > Which compilers do you use and how do you use them ?
> > >> > If you use the gnu compiliers, you should use
> > >> > * * *g++ -c cpplib.cpp
> > >> > and then
> > >> > * * *gcc cprogram.c cpplib.o
> > >> That's very unlikely to work. *The main program must be
> > >> compiled and linked as C++.
> > > But all names cpplib.o are plain, because we used 'extern
> > > "C"' in 'function()'s declaration. So the linker will see no
> > > C++ mangled symbolnames during linking. *Did I miss
> > > something ?
> > The public symbols exported by cpplib.o and used in cprogram
> > aren't the problem. The problem is that cpplib.o probably
> > needs to link to libstdc++. That happens by default when you
> > use g++, but not with gcc.
>
> The problem is also that static variables have to be
> initialized; some compilers do this by generating special code
> in main. *Of course, if main wasn't compiled with a C++
> compiler, it won't have that special code.
>
> --
> James Kanze (GABI Software) * * * * * * email:james.ka...@gmail.com
> hing nConseils en informatique orientée objet/
> * * * * * * * * * *Beratung in objektorientierter Datenverarbeitung
> 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

thanks, I learned something new :-)

Greetings, Uwe

Jerry Coffin <jcoffin@taeus.com> writes:

> In article <48c0dbfe$0$17346$426a74cc@news.free.fr>,
> michael.doubez@free.fr says...
>
> [ ... ]
>
>> Most c++ compiler support C99 unless you disable it in the command line.
>
> Really? All the C++ compilers I have handy seem to reject the following
> perfectly legal bit of C99 code:
>
> union {
> char birthday[9];
> int age;
> float weight;
> } people = { .age = 14 };
>
> Even Comeau (which will accept it as C99 code) rejects it as C++ code
> (quite rightly, I might add, since it's ill formed C++ code, and I don't
> believe C++ 0x will allow it either).
>
> Every other compiler I have handy (Microsoft, Digital Mars, gnu) rejects
> it as either C or C++. gnu has a '-std=c99' flag, but appears to
> implement little enough of C99 that it doesn't accept this even with
> that flag.

Recent versions of gcc accept it.

--
Ben.

Ben Bacarisse wrote:
> Jerry Coffin <jcoffin@taeus.com> writes:
>
>> In article <48c0dbfe$0$17346$426a74cc@news.free.fr>,
>> michael.doubez@free.fr says...
>>
>> [ ... ]
>>
>>> Most c++ compiler support C99 unless you disable it in the command line.
>> Really? All the C++ compilers I have handy seem to reject the following
>> perfectly legal bit of C99 code:
>>
>> union {
>> char birthday[9];
>> int age;
>> float weight;
>> } people = { .age = 14 };
>>
>> Even Comeau (which will accept it as C99 code) rejects it as C++ code
>> (quite rightly, I might add, since it's ill formed C++ code, and I don't
>> believe C++ 0x will allow it either).
>>
>> Every other compiler I have handy (Microsoft, Digital Mars, gnu) rejects
>> it as either C or C++. gnu has a '-std=c99' flag, but appears to
>> implement little enough of C99 that it doesn't accept this even with
>> that flag.
>
> Recent versions of gcc accept it.
>
gcc also accepts VLAs, but I doubt any other C++ compiler would.

--
Ian Collins.

Ian Collins <ian-news@hotmail.com> writes:

> Ben Bacarisse wrote:
>> Jerry Coffin <jcoffin@taeus.com> writes:
>>
>>> In article <48c0dbfe$0$17346$426a74cc@news.free.fr>,
>>> michael.doubez@free.fr says...
>>>
>>> [ ... ]
>>>
>>>> Most c++ compiler support C99 unless you disable it in the command line.
>>> Really? All the C++ compilers I have handy seem to reject the following
>>> perfectly legal bit of C99 code:
>>>
>>> union {
>>> char birthday[9];
>>> int age;
>>> float weight;
>>> } people = { .age = 14 };
>>>
>>> Even Comeau (which will accept it as C99 code) rejects it as C++ code
>>> (quite rightly, I might add, since it's ill formed C++ code, and I don't
>>> believe C++ 0x will allow it either).
>>>
>>> Every other compiler I have handy (Microsoft, Digital Mars, gnu) rejects
>>> it as either C or C++. gnu has a '-std=c99' flag, but appears to
>>> implement little enough of C99 that it doesn't accept this even with
>>> that flag.
>>
>> Recent versions of gcc accept it.
>>
> gcc also accepts VLAs, but I doubt any other C++ compiler would.

I mean gcc accepts it when invoked with '-std=c99'. Jerry Coffin said
it did not. I am reporting that at least some recent versions do (as
they must if they want to compile C99).

For the record, the same gcc correctly rejects (or at least diagnoses)
VLAs when invoked as a conforming C++ compiler. The presence of a
default mixed mode where a compiler accept some odd half-language plus
extensions is unfortunate but common.

--
Ben.