call c++ function from c

[falk.von.roetel]

Hello,

I have the problem to call a c++ funtion in a C project. I have a
header file from the cpp file. In the header file the function is
decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
in the c file and call the function GetHostIPAddresses(1);. But the
linker doesn't found the function. Can someone give me a hint what is
wrong.

Best regards

Falk

 

[Jens Thoms Toerring]

I have the problem to call a c++ funtion in a C project. I have a
header file from the cpp file. In the header file the function is
decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
in the c file and call the function GetHostIPAddresses(1);. But the
linker doesn't found the function. Can someone give me a hint what is
wrong.

It probably would be better to ask this in a comp.lang.c++ since
this is more in the territory of expertise of the regulars over
there. See also

http://www.parashift.com/c++-faq/mixing-c-and-cpp.html

I try a short explanation anyway (which might be wrong since I
am not a C++ expert!): In C++ you can have several functons with
the same name that are only distinguished by the number and
types of their arguments. To allow the linker to distinuish be-
tween these functions the compiler renames the functions auto-
matically, typically by appending some text to the names that
indicates the number and types of arguments, like

foo( int ) becomes foo_i
foo( double ) becomes foo_d

(this is an example, not the real thing, different C++ compilers
may do it in different ways). If you know this mangled name then
you can change the call of the function accordingly, i.e. use the
mangled name in the C code. The obvious drawback is that this
only works for the C++ compiler you determined for how it does
the name mangling.

If you can change the C++ source and there's only a single
function with that name then you can declare it in the C++
header file with

extern "C" void f(int i, char c, float x);

to keep the C++ compiler from mangling the function name.

Regards, Jens

 

[CBFalconer]

I have the problem to call a c++ funtion in a C project. I have a
header file from the cpp file. In the header file the function is
decleared "int GetHostIPAddresses(ini i);". I inlcude the header
file in the c file and call the function GetHostIPAddresses(1);.
But the linker doesn't found the function. Can someone give me a
hint what is wrong.

You can't do it. C++ has provisions for calling C functions, but C
doesn't know anything about C++. Even the C++ calling is
restricted to the same compiler.

 

[Malcolm McLean]

Hello,

I have the problem to call a c++ funtion in a C project. I have a
header file from the cpp file. In the header file the function is
decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
in the c file and call the function GetHostIPAddresses(1);. But the
linker doesn't found the function. Can someone give me a hint what is
wrong.

Get the C++ object file and dump it as ascii. You should see all the
functions arrayed, but because it is C++ they have funny characters and
other things associated with them.
Extract the name - which may take two or three attempts - put it in your C
source, and try to link. Eventually you will succeed. Then test the function
carefully to make sure C++ isn't passing it any extra arguments.

 

[Keith Thompson]

Get the C++ object file and dump it as ascii. You should see all the
functions arrayed, but because it is C++ they have funny characters
and other things associated with them.
Extract the name - which may take two or three attempts - put it in
your C source, and try to link. Eventually you will succeed. Then test
the function carefully to make sure C++ isn't passing it any extra
arguments.

In other words, proceed by trial and error to produce code that's
going to be horribly non-portable because it depends intimately on how
the particular C++ compiler performs "name mangling".

A much better idea: read section 32 of the "C++ FAQ Lite" at
<http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html>, and
take any further questions to comp.lang.c++.

 

[Marcin Wolcendorf]

Hello,

I have the problem to call a c++ funtion in a C project. I have a
header file from the cpp file. In the header file the function is
decleared "int GetHostIPAddresses(ini i);". I inlcude the header file
in the c file and call the function GetHostIPAddresses(1);. But the
linker doesn't found the function. Can someone give me a hint what is
wrong.

Well, other explaind why it doesn't work pretty well, so I'll skip this
part.
If you want to use C++ function in C and you don't want to change C++
code, add a wrapper layer. Decalre function in C++ that calls your
intended function- it should look something like this:

foo() - your C++ function.

In .cpp file:
extern "C" foo_for_C()
{ return foo()}

In .h file:
#ifdef __cplusplus
extern "C" {
#endif
foo_for_c();

#ifdef __cplusplus
}
#endif


M.

 

[Bill Reid]

Well, other explaind why it doesn't work pretty well, so I'll skip this
part.
If you want to use C++ function in C and you don't want to change C++
code, add a wrapper layer. Decalre function in C++ that calls your
intended function- it should look something like this:

foo() - your C++ function.

In .cpp file:
extern "C" foo_for_C()
{ return foo()}

In .h file:
#ifdef __cplusplus
extern "C" {
#endif
foo_for_c();

#ifdef __cplusplus
}
#endif

Well, looky there, an actual correct answer in this newsgroup. This
question has come up several times here, and certain people have once
again chosen to not only be presumably off-topic but just completely
wrong as well. They were affirmatively corrected several times
before, but apparently they are uneducable.

And I'm quite sure, quite worthless as programmers or for any
type of positive contribution to the human race. They are the garbage
that lie to get a job, then dog it for as long as they can with a constant
stream of excuses, lies, abuse, and obnoxious behavior in lieu of
actually ever writing any type of useful software.

In other words, the epitomy of how most employers are forced
to view "software engineers" due to long painful experience...

 

[Chris Torek]

Well, other explaind why it doesn't work pretty well, so I'll skip this
part.
If you want to use C++ function in C and you don't want to change C++
code, add a wrapper [via C++'s extern "C" method]. [example snipped]

Well, looky there, an actual correct answer in this newsgroup.

Yes, except for one problem: the example code (that I snipped,
above) is wrong. The bug is small and simple and easily corrected
(and will be caught by the compiler), but still, the example contains
a bug.

(In fact, the C part of the example is valid C89 but not valid C99.
This is, in effect, what is wrong with the C++ part of the example.)

This question has come up several times here ...

And the answer here is "C++ defines a way to call C but not vice
versa, so you will get a better (peer-reviewed, as it were) answer
in comp.lang.c++, so you would be wiser to go there for advice."

... and certain people have once again chosen to not only be
presumably off-topic but just completely wrong as well.

No, you and Marcin Wolcendorf were only *slightly* wrong.

This sort of subtle error is *why* one should seek answers in a
more-appropriate forum. A newsgroup full of POSIX-specializing
programmers (such as comp.unix.programmer) is more likely to know
all the details of, say, using POSIX AIO -- even from C code --
than is a forum of "strictly ANSI/ISO C programmers" like the
comp.lang.c newsgroup.

 

[Marcin Wolcendorf]

Well, other explaind why it doesn't work pretty well, so I'll skip this
part.
If you want to use C++ function in C and you don't want to change C++
code, add a wrapper [via C++'s extern "C" method]. [example snipped]

Well, looky there, an actual correct answer in this newsgroup.

Yes, except for one problem: the example code (that I snipped,
above) is wrong. The bug is small and simple and easily corrected
(and will be caught by the compiler), but still, the example contains
a bug.

(In fact, the C part of the example is valid C89 but not valid C99.
This is, in effect, what is wrong with the C++ part of the example.)

I should have written 'foo(....)', so you wouldn't be confused. Well, I
assumed, possibly wrongly, that 'looks something like that' is an
example that might not compile, but shows a concept. Perahaps I should
have put it in the footnote...

And the answer here is "C++ defines a way to call C but not vice
versa, so you will get a better (peer-reviewed, as it were) answer
in comp.lang.c++, so you would be wiser to go there for advice."


No, you and Marcin Wolcendorf were only *slightly* wrong.

This sort of subtle error is *why* one should seek answers in a
more-appropriate forum. A newsgroup full of POSIX-specializing
programmers (such as comp.unix.programmer) is more likely to know
all the details of, say, using POSIX AIO -- even from C code --
than is a forum of "strictly ANSI/ISO C programmers" like the
comp.lang.c newsgroup.

Have you actually read the description of this newsgroup? It's nice and
clear, one line only:
'Disscussion about C.'
I can't see here any 'strictly' nor 'ANSI' nor 'ISO'. The 'programmers'
have also been lost somehere in translation... The only match is 'C'.
Where *exactly* have you taken the description of this group from?


Regards,

M.W.

 

[CBFalconer]

.... snip ...

Have you actually read the description of this newsgroup? It's
nice and clear, one line only:
'Disscussion about C.'
I can't see here any 'strictly' nor 'ANSI' nor 'ISO'. The
'programmers' have also been lost somehere in translation...
The only match is 'C'. Where *exactly* have you taken the
description of this group from?

The only factual descriptions of the C language are the ISO
standard(s) and, earlier, K & R.

 

[Sudhanshu]

header.h file
#ifdef__cplusplus
extern "C" {
#endif
int GetHostIPAddresses(ini i);
#ifdef__cplusplus
}
#endif

cpluplus.cpp
#include <header.h>
int GetHostIPAddresses(ini i)
{
......
}

cfile.c
#include <header.h>

 

[CBFalconer]

header.h file
#ifdef__cplusplus
extern "C" {
#endif
int GetHostIPAddresses(ini i);
#ifdef__cplusplus
}
#endif

cpluplus.cpp
#include <header.h>
int GetHostIPAddresses(ini i)
{
.....
}

cfile.c
#include <header.h>

That enables C++ to call C, not the reverse direction.

Include adequate quotation from whatever you are answering, and
indent your code properly. Don't use tabs, use spaces.

 

[Chris Torek]

[Using C++'s extern "C" construct] enables C++ to call C, not
the reverse direction.

Actually, it works both ways, provided some reasonably obvious
and straightforward restrictions are met.

(It is possible to write C++ code that can*not* call C code, nor
vice versa; and mixing one vendor's C compiler with another's C++
compiler can result in various disasters, but this is equally true
for mixing one vendor's C compiler with another vendor's C compiler.
But if the calls can be done at all, the C++ extern "C" method is
almost always the way to go. Further discussion about this really
belongs in comp.lang.c++ and/or vendor-specific newsgroups, of
course.)

 

[Chris Torek]

Background: Marcin Wolcendorf provided a mostly-correct and suitably
worded answer, to which I did not object. Then:

I should have written 'foo(....)', so you wouldn't be confused. Well, I
assumed, possibly wrongly, that 'looks something like that' is an
example that might not compile, but shows a concept.

Yes -- this was, I think, the main reason I did not object at all
to your own posting. I was really responding to Bill Reid:

Have you actually read the description of this newsgroup? It's nice and
clear, one line only:
'Disscussion about C.'
I can't see here any 'strictly' nor 'ANSI' nor 'ISO'.

The lack of anything more specific -- the generality of the phrase
"discussion about C" -- is precisely what creates this constraint!
In a group that addresses generic "C" -- not "C on Tandem Non-Stop",
not "C on VMS", not "the C routines provided by vxWorks" -- what
sort of advice will you get on when to use semBCreate() versus
semMCreate()? Who will tell you, correctly, all the details about
SYS$QIO? Will you get correct information about thread programming
here, or are you more likely to get correct information elsewhere?

Perhaps you think we *should* discuss these here. But then I would
have to wonder why we have comp.os.vms and comp.programming.threads.

(Incidentally, one should use semBCreate if the mutex will be used
for interrupt code. One should use semMCreate if the mutex needs
to do automatic priority elevation to avoid inversions, or to set
various options. Otherwise either one will generally suffice.)

 

[CBFalconer]

[Using C++'s extern "C" construct] enables C++ to call C, not
the reverse direction.

Actually, it works both ways, provided some reasonably obvious
and straightforward restrictions are met.

(It is possible to write C++ code that can*not* call C code, nor
vice versa; and mixing one vendor's C compiler with another's C++
compiler can result in various disasters, but this is equally true
for mixing one vendor's C compiler with another vendor's C compiler.
But if the calls can be done at all, the C++ extern "C" method is
almost always the way to go. Further discussion about this really
belongs in comp.lang.c++ and/or vendor-specific newsgroups, of
course.)

The C++ system attempts to adorn external calls with information
about parameters, etc. in various ways. The C system has no way of
understanding this mess. Thus C can't call C++ bcause the
'adornments' are missing. However, C++ has a provision for
dropping those 'adornments' to call precompiled C code.

Since C provision for linking to C++ only involves a couple of one
line #includes, and no effort at the C++ level, I consider it
discussable here. C99 includes the reserved identifier
__cplusplus__ to guard those #includes.

 

[Ian Collins]

[Using C++'s extern "C" construct] enables C++ to call C, not
the reverse direction.

Actually, it works both ways, provided some reasonably obvious
and straightforward restrictions are met.

(It is possible to write C++ code that can*not* call C code, nor
vice versa; and mixing one vendor's C compiler with another's C++
compiler can result in various disasters, but this is equally true
for mixing one vendor's C compiler with another vendor's C compiler.
But if the calls can be done at all, the C++ extern "C" method is
almost always the way to go. Further discussion about this really
belongs in comp.lang.c++ and/or vendor-specific newsgroups, of
course.)

The C++ system attempts to adorn external calls with information
about parameters, etc. in various ways. The C system has no way of
understanding this mess. Thus C can't call C++ bcause the
'adornments' are missing. However, C++ has a provision for
dropping those 'adornments' to call precompiled C code.

I think you are completely missing the point about it working both ways,
never mind.

 

[SM Ryan]

# understanding this mess. Thus C can't call C++ bcause the
# 'adornments' are missing. However, C++ has a provision for

That comes as a shock and disappointment to all of us who
actually do this.

 

[Richard]

# understanding this mess. Thus C can't call C++ bcause the
# 'adornments' are missing. However, C++ has a provision for

That comes as a shock and disappointment to all of us who
actually do this.

http://developers.sun.com/sunstudio/articles/mixing.html

 

[Marcin Wolcendorf]

Hi Chris,

Background: Marcin Wolcendorf provided a mostly-correct and suitably

...snip..

To make it short:
- Please, if you add some criticism- be specific. I'd be happy if you
pointed out mistakes I made. I guess this is what you object to do for
philosophic reasons. Well, I have no solution to that, then; I need
facts, not foggy clues and riddles anyway.
- I can see your point of limiting the topics to 'C only'; I somewhat
agree. Nevertheless making group too narrow will make it unusable
(IMHO). Some other groups may do the same- then someone looking for
answers will be bounced from every group with 'OT' excuse. IMO- this
is the place to provide answers, not frustration. What's more- if
you'll make it too strict, too narrow, you'll soon find there is
no-one to talk to.


Regards (and EOT),

M.W.

 

[Richard Heathfield]

Marcin Wolcendorf said:

- I can see your point of limiting the topics to 'C only'; I somewhat
agree.
Good.

Nevertheless making group too narrow will make it unusable

So will making it too wide. This newsgroup discusses C. That is a wide
enough topic to ensure that this group has been useful for almost a
quarter of a century.

(IMHO). Some other groups may do the same- then someone looking for
answers will be bounced from every group with 'OT' excuse. IMO- this
is the place to provide answers, not frustration.

Right - and the answer to your question is that C does not provide a
mechanism to interface specifically with C++ functions. If you find the
answer frustrating, that's unfortunate, but it happens to be the
correct answer nonetheless.

What's more- if
you'll make it too strict, too narrow, you'll soon find there is
no-one to talk to.

And if you make it too wide, you'll soon find there's nowhere left to
ask about C, because the S/N ratio will drop through the floor and the
C experts will give up bothering with the group, so the only people
left to answer your questions will be the guessers.