.cpp vs .c

I

I V

I would think that one could wrap function calls to C functions so that a
c++ compiler would compile them as C but link as c++. cheers, f

Can you not just compile the C functions with your C compiler, your C++
functions with your C++ compiler, and link the results?
 
I

Ian Collins

Your said:
I would think that one could wrap function calls to C functions so that a
c++ compiler would compile them as C but link as c++. cheers, f
You just use extern "C" to wrap your function prototypes in their header.
 
Y

Your Uncle

Ian Collins said:
You just use extern "C" to wrap your function prototypes in their header.
# ifdef __cplusplus
extern "C" {
# endif
int * get_an_int(void);
# ifdef __cplusplus
}
# endif
That's what I thought! When I renamed the source file from .c to .cpp, my
compiler asked me to recast a malloc in the function, which is trouble. The
opinion at the other end of the hallway is that it's a c++ issue. cheers,
fu
 
I

I V

That's what I thought! When I renamed the source file from .c to .cpp, my
compiler asked me to recast a malloc in the function, which is trouble. The

Why are you renaming the source file from .c to .cpp ?
 
J

Jack Klein

ma740988 said:
Your said:
I have 2 different files that differ only in filetype. One is Text1.c , the
other is Text1.cpp . If therein I have this function:

int * get_an_int(void)
{
int t;
int * pt;
pt = (int *)malloc (sizeof*pt);
t = 41;
pt[0] = t;
return pt;
}
Then one will compile, whereas if I remove the cast, the other one won't.
This statement is somewhat puzzling to me. What's the impetus behind
removing the cast and expecting the 'other' to compile? I could be
mistaken but if memory serves the csat is necessary.

In C++, implicit casts from void pointers are not allowed for type
safety. In C, the implicit cast is allowed.

Time for the terminology police!

There is no such thing as an "implicit cast" in C or C++. Both
languages have conversions. Some conversions are automatic, some will
not be performed automatically. The use of a cast operator performs
an "explicit conversion".
 
Y

Your Uncle

I V said:
Why are you renaming the source file from .c to .cpp ?
That's a little bit of a story. The source contains a simple function that
works wonderfully in C, and as such, would only coincidentally work at all
compiled as c++. The wrapper is intended to test the integrity of the
wrapper, and so far, has fallen short. On my implementation, and it's not
on a backwater OS with a vendor you wouldn't recognize, assumes that a .cpp
file is to be compiled as c++. When the compiler sees the functions
wrapped with extern "C", I want it to treat that enclosed function as C and
link it so that I'm going to be able to have an app with some functions
compiled in C, others, yet unwritten, in c++, and the whole enchilada linked
successfully. I wouldn't have thought it profitable for the languages to
touch below the OS, but then I saw this wrapper on Cbfalconer's famous
ggets(), and thought, maybe I could do something with this. So far I've
only consumed bandwidth. cheers, f
 
I

I V

That's a little bit of a story. The source contains a simple function
that works wonderfully in C, and as such, would only coincidentally work
at all compiled as c++. The wrapper is intended to test the integrity
of the wrapper, and so far, has fallen short. On my implementation, and
it's not on a backwater OS with a vendor you wouldn't recognize, assumes
that a .cpp file is to be compiled as c++. When the compiler sees the
functions wrapped with extern "C", I want it to treat that enclosed
function as C and link it so that I'm going to be able to have an app
with some functions compiled in C, others, yet unwritten, in c++, and
the whole enchilada linked successfully. I wouldn't have thought it
profitable for the languages to touch below the OS, but then I saw this
wrapper on Cbfalconer's famous ggets(), and thought, maybe I could do
something with this. So far I've only consumed bandwidth. cheers, f

Unfortunately, "extern C" doesn't do what you want it to do - it doesn't
compile the functions as C, which I guess you have seen. However, what it
does do is tell the C++ compiler that functions with these names _will
have been compiled by a C compiler_ elsewhere. Then, you should
be able to link the objects produced by the C compiler, with the objects
produced by the C++ compiler. So you shouldn't have to rename your .c
files to .cpp files to use them in your C++ program. There's more about
this in the FAQ:

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

Have you tried compiling your .c files with the .c, and linking them with
your .cpp files? You do something like this:

--- cfunctions.c ---

int my_c_function()
{
/* Do some C stuff here */
}

--- cfunctions.h ---
#ifdef __cplusplus
extern "C" {
#endif

int my_c_function();

#ifdef __cplusplus
}
#endif

--- cppfunction.cpp ---

#include "cfunctions.h"

int my_cpp_function()
{
int i = my_c_function();
// Do some C++ stuff here
}

---

And you would compile them with:

# Compile the C functions with a C compiler
cc -c cfunctions.c -o cfunctions.o

# Compile the C++ functions with a C++ compiler
c++ -c cppfunctions.cpp -o cppfunctions.o

# Use the C++ compiler to link the C and C++ functions together into a
# program
c++ -o program cfunctions.o cppfunctions.o
 
Y

Your Uncle

I V said:
Unfortunately, "extern C" doesn't do what you want it to do - it doesn't
compile the functions as C, which I guess you have seen. However, what it
does do is tell the C++ compiler that functions with these names _will
have been compiled by a C compiler_ elsewhere. Then, you should
be able to link the objects produced by the C compiler, with the objects
produced by the C++ compiler. So you shouldn't have to rename your .c
files to .cpp files to use them in your C++ program. There's more about
this in the FAQ:

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

Have you tried compiling your .c files with the .c, and linking them with
your .cpp files? You do something like this:

--- cfunctions.c ---

int my_c_function()
{
/* Do some C stuff here */
}

--- cfunctions.h ---
#ifdef __cplusplus
extern "C" {
#endif

int my_c_function();

#ifdef __cplusplus
}
#endif

--- cppfunction.cpp ---

#include "cfunctions.h"

int my_cpp_function()
{
int i = my_c_function();
// Do some C++ stuff here
}

---

And you would compile them with:

# Compile the C functions with a C compiler
cc -c cfunctions.c -o cfunctions.o

# Compile the C++ functions with a C++ compiler
c++ -c cppfunctions.cpp -o cppfunctions.o

# Use the C++ compiler to link the C and C++ functions together into a
# program
c++ -o program cfunctions.o cppfunctions.o
You're on the right track, cowboy. Do you know how this information would
look for the Evil Empire version, where, say .o is .obj ? I took a pain
killer and think I'm getting a little loopy because I wanted to tell a total
starnger with a kickstand that I loved him. Yeah, I'm stoned. ciao, f
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,432
Messages
2,571,680
Members
48,796
Latest member
Greg L.

Latest Threads

Top