Accessing C++ from C

[Evan Carew]

in the September issue of C/C++ Users Journal, there was a technique
mentioned in "Conversations" which suggested how to provide generic
access to C++ classes from C by wrapping your C++ in C. My problem is
that I can't figure otu how this is done. My gcc linker keeps
complaining that it can't find object code for the STL library members.
Has anyone else tried to do this and gotten it to work? if so, could you
let me know how?

Thanks,
Evan Carew

 

[Rolf Magnus]

in the September issue of C/C++ Users Journal, there was a technique
mentioned in "Conversations" which suggested how to provide generic
access to C++ classes from C by wrapping your C++ in C. My problem is
that I can't figure otu how this is done. My gcc linker keeps
complaining that it can't find object code for the STL library
members.

This is actually off-topic here, and should be asked in gnu.gcc.help or
gnu.g++.help, but anyway, you need to use g++ for linking if your
program contains c++ code.

 

[Martijn Lievaart]

in the September issue of C/C++ Users Journal, there was a technique
mentioned in "Conversations" which suggested how to provide generic
access to C++ classes from C by wrapping your C++ in C. My problem is
that I can't figure otu how this is done. My gcc linker keeps
complaining that it can't find object code for the STL library members.
Has anyone else tried to do this and gotten it to work? if so, could you
let me know how?

Tricky at best. The linking issue can be easily solved, include the right
library path (or use g++, it'll compile C code fine, it differs from gcc
in what include and library paths it adds, not how it looks at source code).

Another issue is the C++ RTL. That probably should be initialised, which
is system dependent and may or may not be necessary. The easiest solution
to this is to rename the C main to C_main, write your main in C++ that
only calls this C_main.

HTH,
M4

 

[Rolf Magnus]

Tricky at best. The linking issue can be easily solved, include the
right library path (or use g++, it'll compile C code fine, it differs
from gcc in what include and library paths it adds, not how it looks
at source code).

That's not quite true. g++ will assume your code is C++, while gcc will
try to auto-detect it from the file name. For _linking_ however, g++
will add anything to the linker command line that is needed for C++
code to work.

Another issue is the C++ RTL.

What is a C++ RTL?

That probably should be initialised, which is system dependent and may
or may not be necessary. The easiest solution to this is to rename the
C main to C_main, write your main in C++ that only calls this C_main.

I don't see why this would be needed.

 

[Martijn Lievaart]

That's not quite true. g++ will assume your code is C++, while gcc will
try to auto-detect it from the file name. For _linking_ however, g++
will add anything to the linker command line that is needed for C++
code to work.

My! Learned something. You're right, although this is pretty stupid.

What is a C++ RTL?

Run time library. More specifically the start-up code. The thing that
calls main and is responsible for initialising all kind of stuff. I'm not
sure about C++ implementations, but all C implementations I've linked from
other languages so far had a RTL that had to be initialised before one
could use non-trivial stuf from the standard library. I've seen this for
file I/O, atexit, floating point calculations and probably some I forgot.

In C++, initialisation of globals is most probably handled from the RTL.

I don't see why this would be needed.

See above. BTW, as C++ includes the C standard library, and implementors
should allow linkage to C code, using the C++ startup code ensures that
the C startup code is executed as well.

HTH,
M4

 

[Evan Carew]

Rolf, (and all others who replied with advice of varying degrees of
usefullness)

Thanks for your replies. While I generally don't like people who answer
their own questions, I have a feeling that this question is important
enough to the C++ and C community that it needs to be answered. I say
this because if C developers (or C++ developers) don't have a way to
gradually migrate their legacy code (C) to C++ then we will continue in
our current state of affairs we are in today where people like the
developers of GNOME continue to develop in C. With this technique,
someone could refactor their libraries in C++ and provide a C wrapper
for those still using legacy techniques, while newer developers could go
on to use C++.

Yesterday, I sent a message to the author of C/C++ Users Journal article
I mentioned in my query & he replied with the answer last night. It
turns out to be rather easy. The deal is that while the C compiler is
more than happy to compile the legacy code, and the C++ compiler
likewise happy to compile the wrapper code, the C linker simply wont
link the program. The strange fix is to compile the legacy code with
the C compiler (without linking), then link with g++. Voila, you have a
C front end to C++ library code.

So now, whenever I talk to some C jock who swears there is no way for C
to converse with C++, I'll simply point them to my interface code.

P.S.
If you are interested in a working swample project, I can send you a
gziped tar file which you can compile yourself.

Evan

 

[Ron Natalie]

That's not quite true. g++ will assume your code is C++, while gcc will
try to auto-detect it from the file name. For _linking_ however, g++
will add anything to the linker command line that is needed for C++
code to work.

Both gcc and g++ recognize from the file names whether to compile
as C or C++ (or Fortran and probably some other languages as well).

The only only different is the inclusion of the C++ libraries with G++.

What is a C++ RTL?

Run time library. All of the stuff in the standard library plus miscellaneous glue
routines that the implementation needs (like the thing that runs around and does the
pre-mail dynamic initializations etc...).

should be initialised, which is system dependent and may

I don't see why this would be needed.

It's not needed in G++/GCC. Even with a C main function, gcc inserts code
that invokes the pre-main startup stuff and if you're linked with G++ libraries
it will work.

However, that's a nice feature of GCC/G++ only. The language doesn't
make any guarantees about C++ programs that don't have a C++ main.

 

[Rolf Magnus]

Both gcc and g++ recognize from the file names whether to compile
as C or C++ (or Fortran and probably some other languages as well).

Well, I don't know which version you have, but 2.95 as well as all 3.x
versions I ever used don't do it like that, and I acually tried it with
my current 3.3.2 version to be sure before posting. I tried the
following program:

#include <stdlib.h>

int main()
{
int* x = malloc(sizeof *x);
}

and gcc said nothing, but g++ said:

c_code.c: In function `int main()':
c_code.c:5: error: invalid conversion from `void*' to `int*'

since in C++, that conversion cannot be done implicitly. Note that the
file name ends in '.c'.

The only only different is the inclusion of the C++ libraries with
G++.

You mean the linking to them when using g++ for linking.

 

[Rolf Magnus]

Rolf, (and all others who replied with advice of varying degrees of
usefullness)

Thanks for your replies. While I generally don't like people who
answer their own questions, I have a feeling that this question is
important enough to the C++ and C community that it needs to be
answered. I say this because if C developers (or C++ developers) don't
have a way to gradually migrate their legacy code (C) to C++ then we
will continue in our current state of affairs we are in today where
people like the developers of GNOME continue to develop in C.

Actually, there are C++ wrappers for the GNOME libs (e.g. gtkmm) and
some gnome programs are actually written in C++. There are also quite
some Un*x libs that are written in C++ and used from C programs, or
even plugin systems where the plugins and the main program are not
written in the same language, so glueing C code and C++ code together
isn't actually that uncommon.

With this technique, someone could refactor their libraries in C++ and
provide a C wrapper for those still using legacy techniques, while
newer developers could go on to use C++.

Some developers want to use C rather than C++.

Yesterday, I sent a message to the author of C/C++ Users Journal
article I mentioned in my query & he replied with the answer last
night. It turns out to be rather easy. The deal is that while the C
compiler is more than happy to compile the legacy code, and the C++
compiler likewise happy to compile the wrapper code, the C linker
simply wont link the program. The strange fix is to compile the legacy
code with the C compiler (without linking), then link with g++. Voila,
you have a C front end to C++ library code.

That's what I told you. Just look yourself at what happens. When trying
to link with gcc and with g++, add the -v command line option, and the
compiler will tell you what it does and what command line it passes to
the linker.

 

[Evan Carew]

Evan Carew wrote:

[snip]


Actually, there are C++ wrappers for the GNOME libs (e.g. gtkmm) and
some gnome programs are actually written in C++. There are also quite
some Un*x libs that are written in C++ and used from C programs, or
even plugin systems where the plugins and the main program are not
written in the same language, so glueing C code and C++ code together
isn't actually that uncommon.

I've seen the fine job the gtkmm folks did with the C++ wrapper, I've
also been stepping through the underlying gtk code as of late & that is
exactly why I am here talking about this technique. In other words, it
sure would be nice to be able to refactor this code in an OO environment.

As for gluing C to C++, yes, it is done, but what I have been seeing up
to now has involved use of knowledge in how C++ mangles its names & then
tying that into the C environment. Not what I would call generic
programming (or version stable for that matter).

I've also been informed recently that there are some projects as you
describe which utilize this technique, however, for some reason its use
hasn't been documented in any texts, or manuals I have seen. Even the
article in C/C++ Users Journal I saw didn't discuss the issues related
to getting your compiler to actually link all the code together. Perhaps
this subject could stand some dissemination.

Some developers want to use C rather than C++.

Yep, especially if they are embedded programmers like myself. There is a
place for C++ and typically, embedded programming isn't it. On the other
hand, GUI programming is perfect for C++ & I can't understand why some
projects persist in having their core development done in C (like
GNOME). KDE for example is done (mostly) in standard C++ & is rather
pleasant to program in. Gnome on the other hand is done entirely in C as
are most of its core components & working with those is ... well... lets
just say that it could be better. While the C++ wrapper libraries for
GNOME are fine, it is a little like kissing through saran wrap. If you
need to change anything, you still need to drop into C.