linking C++ functions in a C program

[abasili]

Hi everyone, I'm trying to compile a C++ function and then call it from
a C program.
Since Google is my friend I've ended up to this link which seems very clear:

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

Unfortunately it does not work.
Here is what I'm doing:

-----------------------------------------
//main.c

#include "mylib.h"

int main (int argc, char *argv[]){
foo();
return 0;
}
-----------------------------------------
//mylib.h

#indef __cplusplus
extern "C"{
#endif

void foo();

#ifdef __cplusplus
}
#endif
-----------------------------------------
//mylib.cc

#include <iostream>
#include "mylib.h"

using namespace std; // don't know what for!

void foo(){
cout<<"Hello World!\n";
}
-----------------------------------------
Thanks a lot for any suggestion.

Al

[Flash Gordon]

CBFalconer wrote, On 07/11/08 08:32:

Flash Gordon wrote:

>CBFalconer wrote, On 06/11/08 21:54:

<snip>

>>describes the access to the C code required. In general C++ can
access C code, but C cannot access C++ code.

Remember, the languages are different.

Remember, it has been pointed out to you many times and with
references that you are WRONG. C++ defines how C code can call
C++ code and you have been shown how it works. Since the theory
says it should work and practice shows that it works why keep
insisting that it does not? Neither theory nor practice are on
your side.

I sent some answers, but something has fouled, and they are not
here.

The still quoted text by you above was part of one of your answers you
posted which was wrong. It was EXPLICITLY the quoted text I was refering
to where your answer was wrong but a redirection would have been
appropriate. So instead of the above quoted material you should either
have posted nothing or you should have posted a redirection. Any other
answers you might have posted are irrelevant unless they were also
erroneous and should have been redirections.
--
Flash Gordon
If spamming me sent it to sm**@spam.cause way.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[Stephen Sprunk]

Phil Carmody wrote:

Ian Collins <ia******@hotma il.comwrites:

>abasili wrote:

>>Hi everyone, I'm trying to compile a C++ function and then call it from
a C program.
Since Google is my friend I've ended up to this link which seems very
clear:

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

Unfortunate ly it does not work.

It does if you follow all the points. The first two are often overlooked.

Some would say it's impossible. If you are building the final
executable (main and linking) with a C++ compiler, then they
might say that you are building a C++ program that calls C
functions. However, what was required was instead a C program
which calls C++ functions. If you're careful to avoid anything
too C++-like, then C++ can be incorporated into C, but then
you're hamstrung a bit with what you can do in C++, and what's
the point. So I'd say stick C into C++, not the other way round.

Once you have mixed C and C++ source into the same program, it is no
longer a "C program" or a "C++ program", if indeed it ever was.

It is possible to call C functions from C++ functions. It is possible
to call C++ functions from C functions. It is possible to link C and
C++ functions into the same program. All that remains for discussion is
either (a) how to accomplish it, or (b) declaring it off-topic for
comp.lang.c.

S

[dj3vande]

In article <LO************ ****@nwrddc01.g nilink.net>,
James Kuyper <ja*********@ve rizon.netwrote:

>I am the one who was confused, but it's my news server's fault, not
mine. My news server got Flash's message before it got CBFalconer's
message, and my newsreader displayed Flash's message as a response to my
message.

Blame that on the newsreader[1], not the newsswerver. Newsreaders
should be able to tell that there's an article missing, if a followup
to that article appears (and has a correct References header, which it
did on my newsserver).
An example of a sensible way to handle it:
My newsreader (trn) displays a nice ascii-art tree of the thread:
+-(1)--(1)+-(1)+-(1)--(1)+-(1)
| | | \-[1]
| | \-(1)--(1)
| \-(1)
|-(1)+-(1)+-(1)

If there's an article missing but there is a follow-up to it, the
newsreader can tell that there should be something there (from the
references header in the followups), and it will draw a hole in the
tree in the appropriate place:
+-(1)--( )+-(1)+-(1)--(1)+-(1)
^^^
If I try to go from an article to a missing parent it will tell me
"This article is not available" instead of just skipping it and going
to the next available parent.
dave

[1] The software used to read news, not (at least in this case) the
person reading news.

--
Dave Vandervies dj3vande at eskimo dot com
On my machine, the C++ version is very fast, and crashes much quicker than
Scheme.
--William D Clinger in comp.lang.schem e

[Ian Collins]

James Kuyper wrote:

Keith Thompson wrote:

>James Kuyper <ja*********@ve rizon.netwrites :

>>Flash Gordon wrote:
CBFalconer wrote, On 06/11/08 21:54:
If you're responding to what he wrote at that time, why don't you post
it as a response to the message in which he actually wrote it, on the
thread in which he wrote it? It's a little confusing to post it as a
response to a message I wrote, in a thread where he's said some
incorrect things about C/C++ linking, but he hasn't actually said
these particular incorrect things (at least, not yet):

describes the access to the C code required. In general C++ can
access C code, but C cannot access C++ code.

James, either I'm confused or you are.

I am the one who was confused, but it's my news server's fault, not
mine. My news server got Flash's message before it got CBFalconer's
message, and my newsreader displayed Flash's message as a response to my
message.

You weren't the only one. Something went wrong somewhere yesterday.

--
Ian Collins

[CBFalconer]

James Kuyper wrote:

CBFalconer wrote: Various incorrect things.

.... snip ...

>
Rather than repeat my previous failed attempts to get a straight
answer out of you about that question, I've written a program that
contains one function named foo() which is compiled in C, and is
therefore unambiguously a C function. It contains another function
named baz() compiled in C++ that has "C++" language linkage, so it
is unambiguously a C++ function. foo() calls bar() which calls
baz(). Therefore, no matter how you classify bar(), this program
contains a C function calling a C++ function.

foobar.h:
=============== =========
#ifndef FOOBAR_H
#define FOOBAR_H

#ifdef __cplusplus
extern "C" {
#endif

void foo(int);
void bar(int);

#ifdef __cplusplus
}
#endif
#endif

foo.c:
=============== =============== =====
#include <stdio.h>
#include "foobar.h"

void foo(int i) {
puts("About to call bar()");
bar(i);
puts("Finished calling bar()");
}

main.C
=============== =============== =============== =====
#include <iostream>
#include "foobar.h"

int main() {
foo(42);
}

static void baz(int i) {
std::cout << "the number is:" << i << std::endl;
}

void bar(int i) {
baz(i);
}

I concede my posts have not been accurate. I still don't think C
calling C++ is convenient, accurate, and really useful, although
possible. In the above:

foobar.h sets up definitions of foo and bar that requires them to
be called without name adornment The actual code is implemented in
the C++ file (.cpp would be more descriptive than .C, IMO). I
guess the compiler can generate two references to foo, one adorned,
and one not adorned, although that is an unnecessary complication.

Some confusion: Note that the code for bar is compiled with a C++
compiler. Thus it must follow C++ rules, for such things as
reserved names, size of char constants, etc. It can thus make a
great difference if bar is moved to a .c file, #includes
"foobar.h", and totally removed from main.C. To me, this is a
cleaner organization, and ensures that C code is compiled as C, and
C++ code is compiled as C++. Conceded, it will prevent using
std::cout etc.

I think I have avoided confusing my biases with facts here :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[jameskuyper]

CBFalconer wrote:
....

I concede my posts have not been accurate. I still don't think C
calling C++ is convenient, accurate, and really useful, although
possible. In the above:

foobar.h sets up definitions of foo and bar that requires them to
be called without name adornment The actual code is implemented in
the C++ file (.cpp would be more descriptive than .C, IMO). ...

? - The actual code for foo() is in the C file.

... I
guess the compiler can generate two references to foo, one adorned,
and one not adorned, although that is an unnecessary complication.

I know of no way to tell the either compiler to do so, nor any reason
to want to. Both functions are callable without adornment from
anywhere that their declarations from foobar.h are in scope.

Some confusion: Note that the code for bar is compiled with a C++
compiler. Thus it must follow C++ rules, for such things as
reserved names, size of char constants, etc. It can thus make a
great difference if bar is moved to a .c file, #includes
"foobar.h", and totally removed from main.C.

Well, the whole purpose of bar() is to be callable from C code, while
having access to C++ functionality. It would lose that access if were
moved to the .c file. It's sort of like saying: that bridge would be
much less likely to fall in the river if you moved it over onto the
west bank. The point of the bridge is to cross that river, and the
point of bar() is to enable communication between the C and C++ parts
of the program.

... To me, this is a
cleaner organization, and ensures that C code is compiled as C, and
C++ code is compiled as C++. Conceded, it will prevent using
std::cout etc.

Yes, thereby defeating the whole purpose of the code. This is just a
simplified example, a more realistic example would involve linking
together two different libraries, one written in C, one written in C+
+, and making use of both libraries from within a single program.
Clearly, either library could be rewritten in the other language;
neither language has unique capabilities, just some things that it
does better than the other - but why re-write when C++ provides the
tools needed to link them together without a rewrite?

I think I have avoided confusing my biases with facts here :-)

[Ian Collins]

CBFalconer wrote:

>
I concede my posts have not been accurate. I still don't think C
calling C++ is convenient, accurate, and really useful, although
possible. In the above:

Accurate?

My most common use for C calling C++ is C++ device drivers. The
interface between the operating system and drivers is a often a struct
of function pointers. I use extern "C" linkage functions as the public
interface for my drivers to populate these tables.

Calls between languages don't have to be direct. For a driver writer,
calling through function pointers is both convenient and really useful.

--
Ian Collins

[Stephen Sprunk]

CBFalconer wrote:

James Kuyper wrote:

>CBFalconer wrote: Various incorrect things.

... snip ...

>Rather than repeat my previous failed attempts to get a straight
answer out of you about that question, I've written a program that
contains one function named foo() which is compiled in C, and is
therefore unambiguously a C function. It contains another function
named baz() compiled in C++ that has "C++" language linkage, so it
is unambiguously a C++ function. foo() calls bar() which calls
baz(). Therefore, no matter how you classify bar(), this program
contains a C function calling a C++ function.

foobar.h:
============== ==========
#ifndef FOOBAR_H
#define FOOBAR_H

#ifdef __cplusplus
extern "C" {
#endif

void foo(int);
void bar(int);

#ifdef __cplusplus
}
#endif
#endif

foo.c:
============== =============== ======
#include <stdio.h>
#include "foobar.h"

void foo(int i) {
puts("About to call bar()");
bar(i);
puts("Finished calling bar()");
}

main.C
============== =============== =============== ======
#include <iostream>
#include "foobar.h"

int main() {
foo(42);
}

static void baz(int i) {
std::cout << "the number is:" << i << std::endl;
}

void bar(int i) {
baz(i);
}

I concede my posts have not been accurate. I still don't think C
calling C++ is convenient, accurate, and really useful, although
possible. In the above:

It's sometimes inconvenient, since you lose certain benefits of C++ and
have to add some extra syntactic sugar when you make a function callable
from C. However, it is quite certainly "accurate" and "useful".

I've worked with several libraries that used C++ internally and provided
both a C interface and a C++ interface; the C interface was simply a
bunch of wrapper functions that manipulated the C++ interface, which a C
program couldn't see (because it used classes).

foobar.h sets up definitions of foo and bar that requires them to
be called without name adornment The actual code is implemented in
the C++ file (.cpp would be more descriptive than .C, IMO).

..cpp or .cc is the usual convention when there's any possibility of
confusion. The .C convention doesn't work on systems that aren't
case-sensitive (e.g. Windows).

I guess the compiler can generate two references to foo, one adorned,
and one not adorned, although that is an unnecessary complication.

That's not required.

The C compiler processing foo.c will see a normal C function named
foo(), and it will generate the object code as it always does.

The C++ compiler processing main.C will see an extern "C" function named
foo(), and any time that C++ code calls it, it will call the unmangled C
name instead of the default mangled C++ name.

Since the C++ code is calling the unmangled name foo(), and the C
compiler produced a function named foo(), everything works.

Some confusion: Note that the code for bar is compiled with a C++
compiler. Thus it must follow C++ rules, for such things as
reserved names, size of char constants, etc. It can thus make a
great difference if bar is moved to a .c file, #includes
"foobar.h", and totally removed from main.C. To me, this is a
cleaner organization, and ensures that C code is compiled as C, and
C++ code is compiled as C++. Conceded, it will prevent using
std::cout etc.

bar() and baz() are both C++ functions, and are properly compiled with a
C++ compiler. bar() is callable from C, due to the way it's declared,
but baz() is not. However, bar() can call baz(), which makes bar() a
"wrapper" function for baz().

The wrapper is unnecessary in this case (baz() could have been extern
"C" and called directly from foo(), since its declaration doesn't
require any special C++ features), but it's a useful technique at times.

S

[James Kuyper]

Stephen Sprunk wrote:
....

bar() and baz() are both C++ functions, and are properly compiled with a
C++ compiler. bar() is callable from C, due to the way it's declared,
but baz() is not. However, bar() can call baz(), which makes bar() a
"wrapper" function for baz().

The wrapper is unnecessary in this case (baz() could have been extern
"C" and called directly from foo(), since its declaration doesn't
require any special C++ features), but it's a useful technique at times.

In a more complicated version I've been thinking of, just to demonstrate
what's possible using this approach, the equivalent of baz() would be a
C++ function that uses many C++-specific features as part of the
function interface (it's a templated operator() overload with a default
argument that is a class member function), making it impossible to
declare it as extern "C".

The point is that the function interface (return type and parameter
list) of bar() can only use features that are shared between C and C++,
but the body of bar() has no such restrictions, and can include calls to
functions that are not subject to that same restriction.