.cpp vs .c

[Your Uncle]

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.
It doesn't do any good to include a C module if I'm gonna stomp all over it
with different rules. How can I get around this? furunculus

[Mark P]

Your Uncle wrote:

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.
It doesn't do any good to include a C module if I'm gonna stomp all over it
with different rules. How can I get around this? furunculus

What exactly do you want to get around? The name of the file is
irrelevant-- what matters is which compiler is being invoked (C or C++,
presumably). Most compilers will infer the language from the filename
but will also offer some mechanism to override this. (E.g., with gcc
you can use the -x flag.)

[ma740988]

Your Uncle wrote:

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.

[mlimber]

ma740988 wrote:

Your Uncle wrote:

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.

Cheers! --M

[Thomas J. Gritzan]

Your Uncle schrieb:

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.
It doesn't do any good to include a C module if I'm gonna stomp all over it
with different rules. How can I get around this? furunculus

In C, a void* pointer will implicitly converted to any pointer type, so
you don't have to cast malloc's return value. In C++, you have to cast,
or better use new.

Thomas

[ma740988]

mlimber wrote:
[...]

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

Thanks for the correction.. I tend to forget these distinctions.

[Your Uncle]

"ma740988" <ma******@gmail.com> wrote in message
news:11*********************@u72g2000cwu.googlegro ups.com...

mlimber wrote:
[...]

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

Thanks for the correction.. I tend to forget these distinctions.

And they let you live? The difference in the cast one language to the other
is how I'm going to know whether the compiler thinks __cplusplus is defined.
I was having delusions of grandeur thinking that:
# ifdef __cplusplus
extern "C" {
# endif
int * get_an_int(void);
# ifdef __cplusplus
}
# endif
was going to be my ticket out. fu

[ma740988]

Your Uncle wrote:

Thanks for the correction.. I tend to forget these distinctions. And they let you live?

Well not for long ...

The difference in the cast one language to the other is how I'm going to know whether the compiler thinks __cplusplus is defined.
I was having delusions of grandeur thinking that: Momentary insanity for me..
# ifdef __cplusplus
extern "C" {
# endif
int * get_an_int(void);
# ifdef __cplusplus
}
# endif
was going to be my ticket out. fu

You meant furunculus ?

[Andrew Poelstra]

On 2006-06-22, Your Uncle <in*****@crippled.net> wrote:

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.
It doesn't do any good to include a C module if I'm gonna stomp all over it
with different rules. How can I get around this? furunculus

As annoying as it is not to implicitly cast from void *, why don't you just
use new and delete when compiling C++?

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Your Uncle]

"Andrew Poelstra" <ap*******@localhost.localdomain> wrote in message
news:slrne9jvl8.h2c.ap*******@localhost.localdomai n...

On 2006-06-22, Your Uncle <in*****@crippled.net> wrote:

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.
It doesn't do any good to include a C module if I'm gonna stomp all over
it
with different rules. How can I get around this? furunculus

As annoying as it is not to implicitly cast from void *, why don't you
just
use new and delete when compiling C++?

Because I don't want to shitcan everything I did on the other end of the
hallway. I want c++ to talk to its brother underneath the OS. cheers,
furunculus

[Phlip]

Your Uncle wrote:

Because I don't want to shitcan everything I did on the other end of the
hallway. I want c++ to talk to its brother underneath the OS.

Writing C++-ready C is trivial. Just add extra typecasts, and watch your
types and name mangling. So leave (int*) on the C side.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

[Andrew Poelstra]

On 2006-06-22, Phlip <ph******@yahoo.com> wrote:

Your Uncle wrote:

Because I don't want to shitcan everything I did on the other end of the
hallway. I want c++ to talk to its brother underneath the OS.

Writing C++-ready C is trivial. Just add extra typecasts, and watch your
types and name mangling. So leave (int*) on the C side.

Then that undermines the safety of C. If <stdlib.h> is unincluded, typecasting
will hide that error, because C will assume malloc returns int. This invokes
undefined behavior.

You understand that C and C++ are different languages, right? While in this
case you can hack code that will compile as either, this is basically like
trying to put Javascript through a C# compiler.

--
Andrew Poelstra < http://www.wpsoftware.net/blog >
To email me, use "apoelstra" at the above address.
I know that area of town like the back of my head.

[Your Uncle]

"Phlip" <ph******@yahoo.com> wrote in message
news:qU********************@newssvr29.news.prodigy .net...

Your Uncle wrote:

Because I don't want to shitcan everything I did on the other end of the
hallway. I want c++ to talk to its brother underneath the OS.

Writing C++-ready C is trivial. Just add extra typecasts, and watch your
types and name mangling. So leave (int*) on the C side.

With regard to the malloc, I don't think typecasts is an issue (I'm not
saying that because I actually know). With the return types on the malloc,
I thought we decided that was unwinnable. NameMangling is not a productive
topic:-)

Is your idea here though to use an executable to ultimately convert the
source? ciao, f

[Frederick Gotham]

Your Uncle posted:

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. It doesn't do any good to include a C module if I'm gonna stomp
all over it with different rules. How can I get around this?
furunculus

Three scenarios.

Scenario 1:
You're writing C++ code. Name the file "code.cpp" and put the
following in it:

pt = static_cast<int*>( malloc(sizeof *pt) );

(Also consider using "new")
Scenario 2:
You're writing C code. Name the file "code.c" and put the following
in it:

pt = malloc( sizeof *pt );
Scenario 3:
You're writing code which you wish to compile successfully as either
C or C++ (not a good idea in my opinion). This is where you'd use:

pt = (int*)malloc( sizeof *pt );

[Your Uncle]

"Frederick Gotham" <fg*******@SPAM.com> wrote in message
news:Xn***************************@195.188.240.200 ...

Your Uncle posted:

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. It doesn't do any good to include a C module if I'm gonna stomp
all over it with different rules. How can I get around this?
furunculus

Three scenarios.

Scenario 1:
You're writing C++ code. Name the file "code.cpp" and put the
following in it:

pt = static_cast<int*>( malloc(sizeof *pt) );

(Also consider using "new")
Scenario 2:
You're writing C code. Name the file "code.c" and put the following
in it:

pt = malloc( sizeof *pt );
Scenario 3:
You're writing code which you wish to compile successfully as either
C or C++ (not a good idea in my opinion). This is where you'd use:

pt = (int*)malloc( sizeof *pt );

If those are my only scenarios, then I think to misunderstand the nature of
a "module." Clearly, anyone who wants to keep from turning cross-eyed keeps
the two separate. Oh well. Thanks for your reply. fu

[mlimber]

Frederick Gotham wrote:

Three scenarios.

Scenario 1:
You're writing C++ code. Name the file "code.cpp" and put the
following in it:

pt = static_cast<int*>( malloc(sizeof *pt) );

(Also consider using "new")

[snip]

Yes, if you're writing C++, you generally should use new rather than
malloc (see
http://www.parashift.com/c++-faq-lit....html#faq-16.4 for
reasons why), but more to the point, you should avoid using new when
possible because it is error prone. If you do need to use it (e.g. for
creating an object that will be used polymorphically), always attach
the result of "new" to a smart pointer that will automatically release
it (you can also use some smart pointers with malloc/free), and prefer
std::vector over of dynamically allocated arrays of objects (see
http://www.parashift.com/c++-faq-lit...html#faq-34.1).

C++ allows several programming paradigms (old-style C being one of
them), but the advice above represents the generally accepted "best
practice" for C++.

Cheers! --M

[Marcus Kwok]

Frederick Gotham <fg*******@spam.com> wrote:

Your Uncle posted:

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. It doesn't do any good to include a C module if I'm gonna stomp
all over it with different rules. How can I get around this?
furunculus

Three scenarios.

Scenario 1:
You're writing C++ code. Name the file "code.cpp" and put the
following in it:

pt = static_cast<int*>( malloc(sizeof *pt) );

(Also consider using "new")
Scenario 2:
You're writing C code. Name the file "code.c" and put the following
in it:

pt = malloc( sizeof *pt );
Scenario 3:
You're writing code which you wish to compile successfully as either
C or C++ (not a good idea in my opinion). This is where you'd use:

pt = (int*)malloc( sizeof *pt );

In that case, would this work?

#ifdef __cplusplus
pt = static_cast<int*>(malloc(sizeof *pt));
#else
pt = malloc(sizeof *pt);
#endif

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Your Uncle]

"Marcus Kwok" <ri******@gehennom.invalid> wrote in message
news:e7**********@news-int2.gatech.edu...

Frederick Gotham <fg*******@spam.com> wrote:

Your Uncle posted:

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. It doesn't do any good to include a C module if I'm gonna stomp
all over it with different rules. How can I get around this?
furunculus

Three scenarios.

Scenario 1:
You're writing C++ code. Name the file "code.cpp" and put the
following in it:

pt = static_cast<int*>( malloc(sizeof *pt) );

(Also consider using "new")
Scenario 2:
You're writing C code. Name the file "code.c" and put the following
in it:

pt = malloc( sizeof *pt );
Scenario 3:
You're writing code which you wish to compile successfully as either
C or C++ (not a good idea in my opinion). This is where you'd use:

pt = (int*)malloc( sizeof *pt );

In that case, would this work?

#ifdef __cplusplus
pt = static_cast<int*>(malloc(sizeof *pt));
#else
pt = malloc(sizeof *pt);
#endif

You can ifdef around the differences, when you've identified them and lost a
day in development doing so. Mixing the two is simply a recipe for a flat
tire. cheers, f

[Jim Langston]

"Your Uncle" <in*****@crippled.net> wrote in message
news:44***********************@news.usenetmonster. com...

"Marcus Kwok" <ri******@gehennom.invalid> wrote in message
news:e7**********@news-int2.gatech.edu...

Frederick Gotham <fg*******@spam.com> wrote:

Your Uncle posted:
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. It doesn't do any good to include a C module if I'm gonna stomp
all over it with different rules. How can I get around this?
furunculus

Three scenarios.

Scenario 1:
You're writing C++ code. Name the file "code.cpp" and put the
following in it:

pt = static_cast<int*>( malloc(sizeof *pt) );

(Also consider using "new")
Scenario 2:
You're writing C code. Name the file "code.c" and put the following
in it:

pt = malloc( sizeof *pt );
Scenario 3:
You're writing code which you wish to compile successfully as either
C or C++ (not a good idea in my opinion). This is where you'd use:

pt = (int*)malloc( sizeof *pt );

In that case, would this work?

#ifdef __cplusplus
pt = static_cast<int*>(malloc(sizeof *pt));
#else
pt = malloc(sizeof *pt);
#endif

You can ifdef around the differences, when you've identified them and lost
a day in development doing so. Mixing the two is simply a recipe for a
flat tire. cheers, f

You're screwed then. Better switch to Basic.

Seriously, if you want to be able to compile C code in a C++ compiler, you
are going to have to work around these things. Your other option is not to
compile C code as C++ code then you don't have to worry about it.

Yes, it is going to take you time to find the problems and fix them. It
would be better, IMO, to just convert it to C++ code and don't try to
compile it as C code anymore then you won't have to do these types of
things. You get what you pay for, in other words.

[Your Uncle]

"Jim Langston" <ta*******@rocketmail.com> wrote in message
news:jC*****************@fe05.lga...

"Your Uncle" <in*****@crippled.net> wrote in message
news:44***********************@news.usenetmonster. com...

"Marcus Kwok" <ri******@gehennom.invalid> wrote in message
news:e7**********@news-int2.gatech.edu...

Frederick Gotham <fg*******@spam.com> wrote:
Your Uncle posted:
> 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. It doesn't do any good to include a C module if I'm gonna stomp
> all over it with different rules. How can I get around this?
> furunculus

Three scenarios.

Scenario 1:
You're writing C++ code. Name the file "code.cpp" and put the
following in it:

pt = static_cast<int*>( malloc(sizeof *pt) );

(Also consider using "new")
Scenario 2:
You're writing C code. Name the file "code.c" and put the following
in it:

pt = malloc( sizeof *pt );
Scenario 3:
You're writing code which you wish to compile successfully as either
C or C++ (not a good idea in my opinion). This is where you'd use:

pt = (int*)malloc( sizeof *pt );

In that case, would this work?

#ifdef __cplusplus
pt = static_cast<int*>(malloc(sizeof *pt));
#else
pt = malloc(sizeof *pt);
#endif You can ifdef around the differences, when you've identified them and
lost a day in development doing so. Mixing the two is simply a recipe
for a flat tire. cheers, f

You're screwed then. Better switch to Basic.

As a twelve year old, I could lprint(something) and have something as a hard
copy. Trying to get information from C to a printer has now become an
odyssey, one that I'm not even going to be able to do without MFC.
Seriously, if you want to be able to compile C code in a C++ compiler, you
are going to have to work around these things. Your other option is not
to compile C code as C++ code then you don't have to worry about it.

Yes, it is going to take you time to find the problems and fix them. It
would be better, IMO, to just convert it to C++ code and don't try to
compile it as C code anymore then you won't have to do these types of
things. You get what you pay for, in other words.

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

[I V]

On Fri, 23 Jun 2006 17:59:00 -0400, Your Uncle wrote:

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?

[Ian Collins]

Your Uncle wrote:

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.

--
Ian Collins.

[Your Uncle]

"Ian Collins" <ia******@hotmail.com> wrote in message
news:4g*************@individual.net...

Your Uncle wrote:

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.

# 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 V]

On Fri, 23 Jun 2006 21:09:44 -0400, Your Uncle wrote:

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 ?

[Jack Klein]

On 21 Jun 2006 18:31:21 -0700, "mlimber" <ml*****@gmail.com> wrote in
comp.lang.c++:

ma740988 wrote:

Your Uncle wrote:

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".

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Your Uncle]

"I V" <wr******@gmail.com> wrote in message
news:pa****************************@gmail.com...

On Fri, 23 Jun 2006 21:09:44 -0400, Your Uncle wrote:

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 ?

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 V]

On Sat, 24 Jun 2006 11:32:43 -0400, Your Uncle wrote:

"I V" <wr******@gmail.com> wrote in message
news:pa****************************@gmail.com...

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

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-lit...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

[Your Uncle]

"I V" <wr******@gmail.com> wrote in message
news:pa***************************@gmail.com...

On Sat, 24 Jun 2006 11:32:43 -0400, Your Uncle wrote:

"I V" <wr******@gmail.com> wrote in message
news:pa****************************@gmail.com...

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

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-lit...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