hi,
i am trying 2 merge 2 projects into one project.One project is using c
language and the other one is using c++ code.
both are working very fine independently.But now i need to merge both
and my c++ code should call c code.but when i tried to call a function
in c code externing that function in my c++ code, i am getting
unresolved external symbol error. Whatever i try its giving more and
more errrors...so is it possible to merge 2 projects?
if so how can i do that?
please reply....
- Thejaswini
47  4879 
On Dec 5, 9:20 am, teju <tejaswini_ra...@yahoo.co.inwrote:
hi,
i am trying 2 merge 2 projects into one project.One project is using c
language and the other one is using c++ code.
both are working very fine independently.But now i need to merge both
and my c++ code should call c code.but when i tried to call a function
in c code externing that function in my c++ code, i am getting
unresolved external symbol error. Whatever i try its giving more and
more errrors...so is it possible to merge 2 projects?
if so how can i do that?
this is nice article about what you want <mixing of c and c++ code> http://developers.sun.com/solaris/articles/mixing.html
hope it will helpful.
>
please reply....
- Thejaswini
-Raxit Sheth
teju wrote:
>
i am trying 2 merge 2 projects into one project.One project is
using c language and the other one is using c++ code.
both are working very fine independently.But now i need to merge
both and my c++ code should call c code.but when i tried to call
a function in c code externing that function in my c++ code, i am
getting unresolved external symbol error. Whatever i try its
giving more and more errrors...so is it possible to merge 2
projects?
if so how can i do that?
Follow the following organization. The result works for both C and
C++.
----------- note from here on --------------
/* a C header file for linking to C++ */
/* the normal provisions for skipping on a second request */
#ifdef __cplusplus
extern "C"
{
#endif
/* Here is the complete .h file, as used in C */
/* barring the above skip on second request */
#ifdef __cplusplus
}
#endif
--------- end of repaired c header -------
By the way, all this is perfectly standard ISO C.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer <cb********@yahoo.comwrote in message
news:47***************@yahoo.com...
teju wrote:
i am trying 2 merge 2 projects into one project.One project is
using c language and the other one is using c++ code.
both are working very fine independently.But now i need to merge
both and my c++ code should call c code.but when i tried to call
a function in c code externing that function in my c++ code, i am
getting unresolved external symbol error. Whatever i try its
giving more and more errrors...so is it possible to merge 2
projects?
if so how can i do that?
Follow the following organization. The result works for both C and
C++.
We're getting closer here...
----------- note from here on --------------
/* a C header file for linking to C++ */
....or C++ header file for linking to C...
/* the normal provisions for skipping on a second request */
....and here are any normal external data declarations...then for
the external function declarations:
#ifdef __cplusplus
extern "C"
{
#endif
/* Here is the complete .h file, as used in C */
No, just the external function declarations, in the usual form:
extern void my_callable_function(void);
....
If you are calling a C function from C++, that is all you need to do.
However, check your external C++ function declarations carefully
for return values and arguments of types not derived from or of the
fundamental types allowed by the C programming language.
If so, you can't call that function from C. You'll have to write a
C++ "wrapper" function to translate the arguments and/or return
value into allowed C types, or in some other way modify your
include file typedefs or C++ source to account for this discrepancy.
/* barring the above skip on second request */
???
#ifdef __cplusplus
}
#endif
--------- end of repaired c header -------
By the way, all this is perfectly standard ISO C.
Well, yeah, in general...
---
William Ernest Reid
teju wrote:
hi,
i am trying 2 merge 2 projects into one project.One project is using c
language and the other one is using c++ code.
You want the newsgroup comp.lang.c++. First, find their FAQ, which I
believe has a section on this topic.
Brian
Bill Reid wrote:
CBFalconer <cb********@yahoo.comwrote:
>teju wrote:
>>>
i am trying 2 merge 2 projects into one project.One project is
using c language and the other one is using c++ code.
both are working very fine independently.But now i need to merge
both and my c++ code should call c code.but when i tried to call
a function in c code externing that function in my c++ code, i am
getting unresolved external symbol error. Whatever i try its
giving more and more errrors...so is it possible to merge 2
projects?
if so how can i do that?
Follow the following organization. The result works for both C and
C++.
We're getting closer here...
----------- note from here on --------------
/* a C header file for linking to C++ */
...or C++ header file for linking to C...
No, you can't link C++ to C, in general.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer <cb********@yahoo.comwrites:
[...]
No, you can't link C++ to C, in general.
I don't believe that's correct. Further information would be topical
in comp.lang.c++, not in comp.lang.c (since it's C++, not C, that
defines the mechanisms), but see questions 32.5 and 32.6 in the "C++
FAQ Lite" at <http://www.parashift.com/c++-faq-lite/>.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer wrote:
....
No, you can't link C++ to C, in general.
I'm curious in what sense you mean that. C++ provides the concept of C
language linkage, and I believe that most C++ implementations support
that feature. Without getting into the details of how it works, it's
supposed to allow precisely what you've said can't be done. Are you
saying that most C++ implementations don't support this feature? Are
you saying that this feature doesn't work, or that it does work in
some special cases, but that in general it doesn't? Could you expand
upon that? ja*********@verizon.net wrote:
>
CBFalconer wrote:
...
No, you can't link C++ to C, in general.
I'm curious in what sense you mean that. C++ provides the concept of C
language linkage, and I believe that most C++ implementations support
that feature. Without getting into the details of how it works, it's
supposed to allow precisely what you've said can't be done. Are you
saying that most C++ implementations don't support this feature? Are
you saying that this feature doesn't work, or that it does work in
some special cases, but that in general it doesn't? Could you expand
upon that?
See my reply to Keith.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
[...]
>No, you can't link C++ to C, in general.
I don't believe that's correct. Further information would be
topical in comp.lang.c++, not in comp.lang.c (since it's C++, not
C, that defines the mechanisms), but see questions 32.5 and 32.6
in the "C++ FAQ Lite" at <http://www.parashift.com/c++-faq-lite/>.
The point is that C++ function names are modified, to express the
parameter types, in the linkable object code sections. C does not
do this, since it doesn't have shared function names etc. Thus the
C++ code can be told (with the "extern C {...}") that selected C
functions are to be accessed (from C++) with unmodified names. The
reverse is not possible.
Thus I gave the general method for making C object code available
to aa C++ program.
Maybe we are confusing the direction of linking? You can call C
from C++, but not C++ from C (without impossible diddling).
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
>
Maybe we are confusing the direction of linking? You can call C
from C++, but not C++ from C (without impossible diddling).
No, we have been here at least once before.
A C++ function declared as extern "C" may be called from C, that's one
of the reasons C++ has the linkage specifier. It is also used to
identify C function prototypes.
Otherwise C++ would not be able to call C library functions which have a
function pointer as a parameter.
--
Ian Collins.
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
[...]
>>No, you can't link C++ to C, in general.
I don't believe that's correct. Further information would be
topical in comp.lang.c++, not in comp.lang.c (since it's C++, not
C, that defines the mechanisms), but see questions 32.5 and 32.6
in the "C++ FAQ Lite" at <http://www.parashift.com/c++-faq-lite/>.
The point is that C++ function names are modified, to express the
parameter types, in the linkable object code sections. C does not
do this, since it doesn't have shared function names etc. Thus the
C++ code can be told (with the "extern C {...}") that selected C
functions are to be accessed (from C++) with unmodified names. The
reverse is not possible.
Thus I gave the general method for making C object code available
to aa C++ program.
Maybe we are confusing the direction of linking? You can call C
from C++, but not C++ from C (without impossible diddling).
No, I'm asserting that it's possible to call C from C++ *and* to call
C++ from C.
The C++ FAQ agrees, and directly contradicts your claim. Its authors
certainly know C++ better than I do.
Furthermore, I've just done it. Here are my source files:
==func.h <==
#ifdef __cplusplus
extern "C" {
#endif
void func(int i, char c, float x);
#ifdef __cplusplus
}
#endif
==func.C <==
#include "func.h"
#include <iostream>
void func(int i, char c, float x)
{
std::cout << "In func, sizeof 'a' = " << sizeof 'a' << "\n";
std::cout << "i = " << i << ", c = '" << c << "', x = " << x << "\n";
}
==c_main.c <==
#include "func.h"
#include <stdio.h>
int main(void)
{
printf("In C main, sizeof 'a' = %d\n", (int)sizeof 'a');
func(42, '$', 123.456);
return 0;
}
==cpp_main.C <==
#include "func.h"
#include <iostream>
int main()
{
std::cout << "In C++ main, sizeof 'a' = " << sizeof 'a' << "\n";
func(42, '$', 123.456);
return 0;
}
Here's the output of the C main program:
In C main, sizeof 'a' = 4
In func, sizeof 'a' = 1
i = 42, c = '$', x = 123.456
Here's the output of the C++ main program:
In C++ main, sizeof 'a' = 1
In func, sizeof 'a' = 1
i = 42, c = '$', x = 123.456
<OT>Both main programs had to be linked with "g++", because both need
the C++ standard library.</OT>
But as you can see the C program was compiled as C and successfully
called a C++ function.
Obviously this requires some compatibility between the C and C++
implementations.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
>
<OT>Both main programs had to be linked with "g++", because both need
the C++ standard library.</OT>
This is where this 'goes wrong' I think...
But as you can see the C program was compiled as C and successfully
called a C++ function.
I don't think so. The C++ compiler would have turned func into something
like func::func@as:33:22 or some such other decorated nonsense. The C
compiler would have generated a call to _func or whatever. The linker
can't resolve this.
The only way the modules will link is if main.lowercase-c was compiled
as C++ /OR/ if some implementation-specific magic went on to tell the
linker to look for multiple possible versions of the name.
Obviously this requires some compatibility between the C and C++
implementations.
Indeed - so _in general_ this isn't possible, as CBF said in the first
place?
Mark McIntyre said:
Keith Thompson wrote:
>>
<OT>Both main programs had to be linked with "g++", because both need
the C++ standard library.</OT>
This is where this 'goes wrong' I think...
No, not really. That was just a quick way to tell the linker how to do The
Right Thing.
>But as you can see the C program was compiled as C and successfully
called a C++ function.
I don't think so. The C++ compiler would have turned func into something
like func::func@as:33:22 or some such other decorated nonsense.
But wasn't it extern "C" qualified? The whole point of that - or at least
one of the points - is to switch off name-mangling.
The C
compiler would have generated a call to _func or whatever. The linker
can't resolve this.
The only way the modules will link is if main.lowercase-c was compiled
as C++ /OR/ if some implementation-specific magic went on to tell the
linker to look for multiple possible versions of the name.
>Obviously this requires some compatibility between the C and C++
implementations.
Indeed - so _in general_ this isn't possible, as CBF said in the first
place?
To use a C library from a C program requires some compatibility between the
C implementation used for the library and the one used for the program. So
are you saying that, in general, it isn't possible to call C libraries
from C?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Mark McIntyre wrote:
Keith Thompson wrote:
>>
<OT>Both main programs had to be linked with "g++", because both need
the C++ standard library.</OT>
This is where this 'goes wrong' I think...
Nope.
>But as you can see the C program was compiled as C and successfully
called a C++ function.
I don't think so. The C++ compiler would have turned func into something
like func::func@as:33:22 or some such other decorated nonsense. The C
compiler would have generated a call to _func or whatever. The linker
can't resolve this.
No it would not. The function was declared extern "C", so its name and
calling convections will be as they are in C.
The only way the modules will link is if main.lowercase-c was compiled
as C++ /OR/ if some implementation-specific magic went on to tell the
linker to look for multiple possible versions of the name.
Nonsense. If that were the case, no C++ application could call a C
library function.
>Obviously this requires some compatibility between the C and C++
implementations.
Indeed - so _in general_ this isn't possible, as CBF said in the first
place?
Nonsense, the same applies to any two C compilers on the same platform.
--
Ian Collins.
On Dec 5, 12:20 pm, teju <tejaswini_ra...@yahoo.co.inwrote:
hi,
i am trying 2 merge 2 projects into one project.One project is using c
language and the other one is using c++ code.
both are working very fine independently.But now i need to merge both
and my c++ code should call c code.but when i tried to call a function
in c code externing that function in my c++ code, i am getting
unresolved external symbol error. Whatever i try its giving more and
more errrors...so is it possible to merge 2 projects?
if so how can i do that?
please reply....
- Thejaswini
Try
extern "C"
{
extern C_API();
}
in your cpp file , and then call the C_API().
Richard Heathfield wrote:
Mark McIntyre said:
>Keith Thompson wrote:
>><OT>Both main programs had to be linked with "g++", because both need
the C++ standard library.</OT>
This is where this 'goes wrong' I think...
No, not really. That was just a quick way to tell the linker how to do The
Right Thing.
Riight - implementation-specific magic, in other words!
But wasn't it extern "C" qualified?
I don't recall that, but ICBW. If so, the function in question wasn't
actually copmiled as C++ so I'm not sure it was a valid test...
To use a C library from a C program requires some compatibility between the
C implementation used for the library and the one used for the program. So
are you saying that, in general, it isn't possible to call C libraries
from C?
Correct. Try calliing a Turbo C 2 library from Watcom 32-bit C, or an
MSC 5 library from Vax C 5....
gd&r
Ian Collins wrote:
Nonsense. If that were the case, no C++ application could call a C
library function.
Firstly that's true, if the function isn't declared as extern "C".
Secondly we were dicsussing C calling C++, not the other way round.
Lastly compiling the C++ routine as C doesn't count.
>>Obviously this requires some compatibility between the C and C++
implementations.
Indeed - so _in general_ this isn't possible, as CBF said in the first
place?
Nonsense, the same applies to any two C compilers on the same platform.
Indeed, and more so between C and C++. So *in general* it isn't
possible, without invoking implementation-specific features.
You like the word nonsense, don't you? Myself I like the word
Balderdash, its much more evocative.
Mark McIntyre wrote:
Ian Collins wrote:
>Nonsense. If that were the case, no C++ application could call a C
library function.
Firstly that's true, if the function isn't declared as extern "C".
No one disputes that.
Secondly we were dicsussing C calling C++, not the other way round.
A C++ function declared extern "C" can be called from C. Otherwise C++
code could not call C functions that have function pointers as parameters.
Lastly compiling the C++ routine as C doesn't count.
No one said it did.
>>Indeed - so _in general_ this isn't possible, as CBF said in the first
place?
Nonsense, the same applies to any two C compilers on the same platform.
Indeed, and more so between C and C++. So *in general* it isn't
possible, without invoking implementation-specific features.
Not so. Every platform I use (which excludes windows), uses a standard
C calling convention. All the C++ compilers I use use this for extern
"C" functions. Mixing C and C++ code is as trivial as mixing C and C code.
You like the word nonsense, don't you? Myself I like the word
Balderdash, its much more evocative.
Bollocks is more evocative and sums up this thread.
--
Ian Collins.
Mark McIntyre <ma**********@spamcop.netwrites:
Richard Heathfield wrote:
>Mark McIntyre said:
>>Keith Thompson wrote:
<OT>Both main programs had to be linked with "g++", because both need
the C++ standard library.</OT>
This is where this 'goes wrong' I think...
No, not really. That was just a quick way to tell the linker how to
do The Right Thing.
Riight - implementation-specific magic, in other words!
The specific method used to achieve this is implementation-specific.
The specific method used to compile, link, and execute a simple C
"hello, world" program is equally implementation-specific. The
ability to call C++ from C, and to call C from C++, is specified by
the C++ standard (which is, of course, off-topic here).
If you don't believe me, check the C++ FAQ and the C++ standard.
>But wasn't it extern "C" qualified?
I don't recall that, but ICBW. If so, the function in question wasn't
actually copmiled as C++ so I'm not sure it was a valid test...
``extern "C"'' is a C++-specific feature. Try compiling a source file
that contains that construct with a C compiler. You'll get a syntax
error.
The code that I said was compiled as C++ was compiled as C++. Using
``extern "C"'' doesn't make the code C; it's still C++, and in fact it
*cannot* be C unless the ``extern "C"'' is #ifdef'ed out (as it was in
my func.h header).
Go back and take a look at the output. I displayed the value
of sizeof 'a' in each function; that distinguishes (assuming
sizeof(int) 1, which it is for the implementations I used)
between C and C++.
>To use a C library from a C program requires some compatibility
between the C implementation used for the library and the one used
for the program. So are you saying that, in general, it isn't
possible to call C libraries from C?
Correct. Try calliing a Turbo C 2 library from Watcom 32-bit C, or an
MSC 5 library from Vax C 5....
The point is that calling C from C++, or C++ from C, is no more or
less implementation-specific than calling C from C.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[ Used the wrong news server again. Sorry if you see this twice. ]
Mark McIntyre <ma**********@spamcop.netwrites:
Richard Heathfield wrote:
>Mark McIntyre said:
>>Keith Thompson wrote:
<OT>Both main programs had to be linked with "g++", because both need
the C++ standard library.</OT>
This is where this 'goes wrong' I think...
No, not really. That was just a quick way to tell the linker how to
do The Right Thing.
Riight - implementation-specific magic, in other words!
The specific method used to achieve this is implementation-specific.
The specific method used to compile, link, and execute a simple C
"hello, world" program is equally implementation-specific. The
ability to call C++ from C, and to call C from C++, is specified by
the C++ standard (which is, of course, off-topic here).
If you don't believe me, check the C++ FAQ and the C++ standard.
>But wasn't it extern "C" qualified?
I don't recall that, but ICBW. If so, the function in question wasn't
actually copmiled as C++ so I'm not sure it was a valid test...
``extern "C"'' is a C++-specific feature. Try compiling a source file
that contains that construct with a C compiler. You'll get a syntax
error.
The code that I said was compiled as C++ was compiled as C++. Using
``extern "C"'' doesn't make the code C; it's still C++, and in fact it
*cannot* be C unless the ``extern "C"'' is #ifdef'ed out (as it was in
my func.h header).
Go back and take a look at the output. I displayed the value
of sizeof 'a' in each function; that distinguishes (assuming
sizeof(int) 1, which it is for the implementations I used)
between C and C++.
>To use a C library from a C program requires some compatibility
between the C implementation used for the library and the one used
for the program. So are you saying that, in general, it isn't
possible to call C libraries from C?
Correct. Try calliing a Turbo C 2 library from Watcom 32-bit C, or an
MSC 5 library from Vax C 5....
The point is that calling C from C++, or C++ from C, is no more or
less implementation-specific than calling C from C.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mark McIntyre <ma**********@spamcop.netwrites:
Ian Collins wrote:
>Nonsense. If that were the case, no C++ application could call a C
library function.
Firstly that's true, if the function isn't declared as extern
"C". Secondly we were dicsussing C calling C++, not the other way
round.
We were discussing both.
Lastly compiling the C++ routine as C doesn't count.
Nobody implied that it does count. extern "C" can appear only in C++
code. Take a look at my "func.C" file; it writes output to std::cout,
so it *couldn't* be compiled as C (if you're unwilling to accept my
word that I did use a C++ compiler to compile it).
>>>Obviously this requires some compatibility between the C and C++
implementations.
Indeed - so _in general_ this isn't possible, as CBF said in the first
place?
Nonsense, the same applies to any two C compilers on the same platform.
Indeed, and more so between C and C++. So *in general* it isn't
possible, without invoking implementation-specific features.
Since neither language standard specifies how to compile, link, or
execute programs, it's not possible to do *anything* without invoking
implementation-specific features.
I posted valid, portable C and C++ code that demonstrated calling a
C++ function from a C main program. My code used only features
specified by the C and/or C++ standards; the only
implementation-defined output is the result of "sizeof 'a'".
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mark McIntyre wrote, On 06/12/07 18:53:
Ian Collins wrote:
>Nonsense. If that were the case, no C++ application could call a C
library function.
Firstly that's true, if the function isn't declared as extern "C".
Secondly we were dicsussing C calling C++, not the other way round.
Lastly compiling the C++ routine as C doesn't count.
<snip>
Isn't it time for everyone to take this next door to comp.lang.c++ where
they know all about the compatibility between C and C++? Although they
will probably just point you at the FAQ and/or standard which tell you
how to make your C++ callable from C without compiling your C++ as C or
your C as C++.
--
Flash Gordon
Mark McIntyre wrote, On 06/12/07 18:53:
Ian Collins wrote:
>Nonsense. If that were the case, no C++ application could call a C
library function.
Firstly that's true, if the function isn't declared as extern "C".
Secondly we were dicsussing C calling C++, not the other way round.
Lastly compiling the C++ routine as C doesn't count.
<snip>
Isn't it time for everyone to take this next door to comp.lang.c++ where
they know all about the compatibility between C and C++? Although they
will probably just point you at the FAQ and/or standard which tell you
how to make your C++ callable from C without compiling your C++ as C or
your C as C++.
--
Flash Gordon
Mark McIntyre wrote:
Richard Heathfield wrote:
....
But wasn't it extern "C" qualified?
I don't recall that, but ICBW. If so, the function in question wasn't
actually copmiled as C++ so I'm not sure it was a valid test...
When you use a C++ compiler to compile a function declared with extern
"C" language linkage, the body of the function is compiled as C++
code, not as C code. Language linkage only affects the name mangling,
argument passing and how the return value is returned.
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
>Keith Thompson wrote:
>>CBFalconer <cb********@yahoo.comwrites:
[...]
No, you can't link C++ to C, in general.
I don't believe that's correct. Further information would be
topical in comp.lang.c++, not in comp.lang.c (since it's C++, not
C, that defines the mechanisms), but see questions 32.5 and 32.6
in the "C++ FAQ Lite" at <http://www.parashift.com/c++-faq-lite/>.
The point is that C++ function names are modified, to express the
parameter types, in the linkable object code sections. C does not
do this, since it doesn't have shared function names etc. Thus the
C++ code can be told (with the "extern C {...}") that selected C
functions are to be accessed (from C++) with unmodified names. The
reverse is not possible.
Thus I gave the general method for making C object code available
to aa C++ program.
Maybe we are confusing the direction of linking? You can call C
from C++, but not C++ from C (without impossible diddling).
No, I'm asserting that it's possible to call C from C++ *and* to call
C++ from C.
The C++ FAQ agrees, and directly contradicts your claim. Its authors
certainly know C++ better than I do.
Furthermore, I've just done it. Here are my source files:
==func.h <==
#ifdef __cplusplus
extern "C" {
#endif
void func(int i, char c, float x);
#ifdef __cplusplus
}
#endif
==func.C <==
#include "func.h"
#include <iostream>
void func(int i, char c, float x)
{
std::cout << "In func, sizeof 'a' = " << sizeof 'a' << "\n";
std::cout << "i = " << i << ", c = '" << c << "', x = " << x << "\n";
}
Well, once more this is a matter of viewpoint, IMO. I maintain you
have declared, within a C++ program, that func.h is not a C++
routine, but a C routine, and is to be so linked. And you are then
calling C functions from a C++ program.
I believe you will find that all the standard C headers are wrapped
(internally) in the "extern C { /* whatever */ } sequence.
Note that this does NOT affect the object code in any way, only the
headers. You can't invert this and generate normal C++ modules
that can be linked into a C program. Note the "normal".
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
Keith Thompson wrote:
....
No, I'm asserting that it's possible to call C from C++ *and* to call
C++ from C.
The C++ FAQ agrees, and directly contradicts your claim. Its authors
certainly know C++ better than I do.
Furthermore, I've just done it. Here are my source files:
==func.h <==
#ifdef __cplusplus
extern "C" {
#endif
void func(int i, char c, float x);
#ifdef __cplusplus
}
#endif
==func.C <==
#include "func.h"
#include <iostream>
void func(int i, char c, float x)
{
std::cout << "In func, sizeof 'a' = " << sizeof 'a' << "\n";
std::cout << "i = " << i << ", c = '" << c << "', x = " << x << "\n";
}
Well, once more this is a matter of viewpoint, IMO. I maintain you
have declared, within a C++ program, that func.h is not a C++
routine, but a C routine, and is to be so linked. And you are then
calling C functions from a C++ program.
func.h is neither a C++ routine nor a C routine. It's a header. I
presume you're referring to func() itself?
So are you actually saying that a function which can make use of
std::cout to print out the fact that sizeof 'a' == 1, even if
sizeof(int) is greater than 1, is a C function? Any feature that
distinguishes C++ from C can be used with func(). Any code which is
legal C and legal C++, but with different meanings in the two
languages, will have it's C++ meaning if found within the body of
func().
Note, in particular, that func() can call C++ functions that have NOT
been declared with "C" language linkage. Therefore, if you insist on
identifying func() as a C function, then you yourself have identified
a way for a C function to call a C++ function; something you've
claimed is impossible. The only way you can retrieve some semblance of
your original claim is to maintain that func() is neither a C function
nor a C++ function, but some brand new category.
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
>>Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
[...]
No, you can't link C++ to C, in general.
I don't believe that's correct. Further information would be
topical in comp.lang.c++, not in comp.lang.c (since it's C++, not
C, that defines the mechanisms), but see questions 32.5 and 32.6
in the "C++ FAQ Lite" at <http://www.parashift.com/c++-faq-lite/>.
The point is that C++ function names are modified, to express the
parameter types, in the linkable object code sections. C does not
do this, since it doesn't have shared function names etc. Thus the
C++ code can be told (with the "extern C {...}") that selected C
functions are to be accessed (from C++) with unmodified names. The
reverse is not possible.
Thus I gave the general method for making C object code available
to aa C++ program.
Maybe we are confusing the direction of linking? You can call C
from C++, but not C++ from C (without impossible diddling).
No, I'm asserting that it's possible to call C from C++ *and* to call
C++ from C.
The C++ FAQ agrees, and directly contradicts your claim. Its authors
certainly know C++ better than I do.
Furthermore, I've just done it. Here are my source files:
==func.h <==
#ifdef __cplusplus
extern "C" {
#endif
void func(int i, char c, float x);
#ifdef __cplusplus
}
#endif
==func.C <==
#include "func.h"
#include <iostream>
void func(int i, char c, float x)
{
std::cout << "In func, sizeof 'a' = " << sizeof 'a' << "\n";
std::cout << "i = " << i << ", c = '" << c << "', x = " << x << "\n";
}
Well, once more this is a matter of viewpoint, IMO. I maintain you
have declared, within a C++ program, that func.h is not a C++
routine, but a C routine, and is to be so linked. And you are then
calling C functions from a C++ program.
Do you mean func rather than func.h? If you do, how can you call it a
C routine (just look at the code)? What is more, Keith Thompson (who
must be tired by now of defending this clear demonstration) took pains
to include code that shows a C++ routine (printing 1 for sizeof 'a')
being called from C (printing sizeof int for sizeof 'a').
It is C++ called from C.
--
Ben.
Keith Thompson wrote:
Mark McIntyre <ma**********@spamcop.netwrites:
>Richard Heathfield wrote:
>>Mark McIntyre said:
Keith Thompson wrote:
<OT>Both main programs had to be linked with "g++", because both need
the C++ standard library.</OT>
This is where this 'goes wrong' I think...
No, not really. That was just a quick way to tell the linker how to
do The Right Thing.
Riight - implementation-specific magic, in other words!
The
ability to call C++ from C, and to call C from C++, is specified by
the C++ standard (which is, of course, off-topic here).
If you don't believe me, check the C++ FAQ and the C++ standard.
Sure - but you have to tell the compiler to generate a non-C++ style
function. The function call has to be 100% compatible with C, you can't
use any features of C++.
[yes, I'm backtracking on my original over-bold assertion, you're
getting to me...]
>>But wasn't it extern "C" qualified?
I don't recall that, but ICBW. If so, the function in question wasn't
actually copmiled as C++ so I'm not sure it was a valid test...
``extern "C"'' is a C++-specific feature. Try compiling a source file
that contains that construct with a C compiler. You'll get a syntax
error.
You miss my point - you're telling the C++ compiler to generate C
compatible code.
The code that I said was compiled as C++ was compiled as C++. Using
``extern "C"'' doesn't make the code C; it's still C++, and in fact it
*cannot* be C unless the ``extern "C"'' is #ifdef'ed out (as it was in
my func.h header).
Go back and take a look at the output. I displayed the value
of sizeof 'a' in each function;
I understand that and didn't miss it.
The point is that calling C from C++, or C++ from C, is no more or
less implementation-specific than calling C from C.
I disagree to the extent that calling C from C is typically trivial and
doesn't require access to the original source code, whereas calling C++
from C requires the source code and some additional trickery. After all,
with suitable trickery you can call Fortran, Pascal, Python and probably
Ada from C.
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Mark McIntyre wrote:
Keith Thompson wrote:
....
``extern "C"'' is a C++-specific feature. Try compiling a source file
that contains that construct with a C compiler. You'll get a syntax
error.
You miss my point - you're telling the C++ compiler to generate C
compatible code.
That's true, but only in a very limited sense, and your wording does
not clearly convey what the limits on that statement are. The C++
compiler must generate code that allows the function to be called from
C, and in that sense it is compatible. But the way you say it gives
the incorrect impression that the function itself is compiled as if by
a C compiler, and therefore cannot make use of C++ features. If that's
not the impression you intended to make, you should have chosen
different wording.
In article <13*************@corp.supernews.comMark McIntyre <ma**********@spamcop.netwrites:
....
``extern "C"'' is a C++-specific feature. Try compiling a source file
that contains that construct with a C compiler. You'll get a syntax
error.
You miss my point - you're telling the C++ compiler to generate C
compatible code.
For the entry sequence only, in all other aspects it is full-fledged C++.
The point is that calling C from C++, or C++ from C, is no more or
less implementation-specific than calling C from C.
I disagree to the extent that calling C from C is typically trivial and
doesn't require access to the original source code, whereas calling C++
from C requires the source code and some additional trickery. After all,
with suitable trickery you can call Fortran, Pascal, Python and probably
Ada from C.
Depends quite a lot on the compilers. With some it is far from trivial,
and you need specially designed interface routines to put everything in
place. The reason is that neither Fortran, nor Pascal, nor Ada state
anything about how to interface with C. But the C++ standard *does* do
it, both ways. Python states how to interface with C routines, so calling
C from Python is trivial. It is the other way here that is not trivial.
For calling Fortran from C, see for instance:
<http://www.aei.mpg.de/~jthorn/c2f.html>
which works on a limited kind of systems. And also
<http://www.vni.com/tech/imsl/8902.pdf>
which describes it for a larger number of systems, or
<http://www-zeus.desy.de/~burow/cfortran/>
for a still larger set of systems.
There is a good reason there are over 200,000 web pages that describe
how to call Fortran from C. It is far from trivial.
With Pascal the situation is a bit worse. (And there are millions of
web pages to describe it, and what I have seen of it all system
specific.) The problem is that Pascal knows nested procedures, which
C does not know about. This complicates interfacing considerably.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ ja*********@verizon.net wrote:
CBFalconer wrote:
.... snip ...
>>
Well, once more this is a matter of viewpoint, IMO. I maintain
you have declared, within a C++ program, that func.h is not a C++
routine, but a C routine, and is to be so linked. And you are
then calling C functions from a C++ program.
func.h is neither a C++ routine nor a C routine. It's a header.
I presume you're referring to func() itself? So are you actually
saying that a function which can make use of std::cout to print
out the fact that sizeof 'a' == 1, even if sizeof(int) is greater
than 1, is a C function? Any feature that distinguishes C++ from
C can be used with func(). Any code which is legal C and legal
C++, but with different meanings in the two languages, will have
it's C++ meaning if found within the body of func().
Once you have std::cout in func.c it is no longer C source. Now
you are dealing with something else entirely. What we are worrying
about is object modules (compiled code) that can be used in C and
in C++ programs. Valid programs.
I maintain that you can't have such modules written in C++ and
callable from C. Well, maybe I should cavil a bit, and say useful
modules. But you can have useful C modules callable from C++.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
ja*********@verizon.net wrote:
>CBFalconer wrote:
... snip ...
>>Well, once more this is a matter of viewpoint, IMO. I maintain
you have declared, within a C++ program, that func.h is not a C++
routine, but a C routine, and is to be so linked. And you are
then calling C functions from a C++ program.
func.h is neither a C++ routine nor a C routine. It's a header.
I presume you're referring to func() itself? So are you actually
saying that a function which can make use of std::cout to print
out the fact that sizeof 'a' == 1, even if sizeof(int) is greater
than 1, is a C function? Any feature that distinguishes C++ from
C can be used with func(). Any code which is legal C and legal
C++, but with different meanings in the two languages, will have
it's C++ meaning if found within the body of func().
Once you have std::cout in func.c it is no longer C source. Now
you are dealing with something else entirely.
Well, of course. The whole module is C++; extern "C" is a C++ feature,
not a C feature. func.c is C++ source code from beginning to end. It
describes, in C++ code, a function that must be translated in such a way
as to be callable from C, but that doesn't make it C code.
I would prefer not to repeat myself, but you didn't address my previous
comments. When you said that func.h is a C routine, what precisely did
you mean? Were you actually referring to the function func(), or did you
in fact mean the header file func.h? If you were talking about func(),
how do you reconcile that statement with your current recognition that
the body of the definition of func() contains C++ source code?
What we are worrying
about is object modules (compiled code) that can be used in C and
in C++ programs. Valid programs.
I maintain that you can't have such modules written in C++ and
callable from C. Well, maybe I should cavil a bit, and say useful
modules. But you can have useful C modules callable from C++.
A C++ function written to be callable from C, can, when called from C,
do anything that any other C++ function can do. In what way do such
functions fall short of being useful? Or are you denying that this is
the case? Would you care to identify any particular feature of C++ that
you believe can't be used by such a function? Keith has already
demonstrated that there are at least two C++-specific features that can
be used in such a function.
You've talked repeatedly about modules. Neither the C standard nor the
C++ standard uses that term, but the usual meaning as I understand it is
that one object code module is created by the typical compiler as a
result of translating a single translation unit. Therefore, from your
wording I get the impression that you think this is controlled at the
translation unit level. Language linkage is controlled at the function
level, not the translation unit level. A single C++ translation unit can
contain functions with "C" language linkage and functions with "C++"
language linkage (and as many other language linkages as the compiler
cares to support, such as "Fortran" or "Pascal").
CBFalconer <cb********@yahoo.comwrites:
ja*********@verizon.net wrote:
>CBFalconer wrote:
... snip ...
>>>
Well, once more this is a matter of viewpoint, IMO. I maintain
you have declared, within a C++ program, that func.h is not a C++
routine, but a C routine, and is to be so linked. And you are
then calling C functions from a C++ program.
func.h is neither a C++ routine nor a C routine. It's a header.
I presume you're referring to func() itself? So are you actually
saying that a function which can make use of std::cout to print
out the fact that sizeof 'a' == 1, even if sizeof(int) is greater
than 1, is a C function? Any feature that distinguishes C++ from
C can be used with func(). Any code which is legal C and legal
C++, but with different meanings in the two languages, will have
it's C++ meaning if found within the body of func().
Once you have std::cout in func.c it is no longer C source. Now
you are dealing with something else entirely.
It's not "no longer" C source; it never was C source. It's C++
source, plain and simple. I never attempted to compile it with a C
compiler (if I had done so, it would have failed).
What we are worrying
about is object modules (compiled code) that can be used in C and
in C++ programs. Valid programs.
Right. In this case, the object module was generated from C++ source
by a C++ compiler.
I maintain that you can't have such modules written in C++ and
callable from C. Well, maybe I should cavil a bit, and say useful
modules.
I'm having great difficulty understanding how you can continue to make
this claim. I've clearly demonstrated how you can do *exactly* what
you claim is impossible. Perhaps the code I posted isn't useful, but
it could easily do any arbitrary thing that any C++ code could do.
You can call C++ from C.
But you can have useful C modules callable from C++.
Yes, of course.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer <cb********@yahoo.comwrites:
[...]
Well, once more this is a matter of viewpoint, IMO. I maintain you
have declared, within a C++ program, that func.h is not a C++
routine, but a C routine, and is to be so linked. And you are then
calling C functions from a C++ program.
Wrong. extern "C" is a C++ feature; it can't occur in C code.
I believe you will find that all the standard C headers are wrapped
(internally) in the "extern C { /* whatever */ } sequence.
I'm sure they are on some systems. I believe youll find that the
extern "C" {
and
}
lines are enclosed in "#ifdef __cplusplus" .. "#endif" lines.
Note that this does NOT affect the object code in any way, only the
headers. You can't invert this and generate normal C++ modules
that can be linked into a C program. Note the "normal".
What exactly do you mean by "normal"? Does the use of extern "C", a
feature defined by the C++ standard, render code abnormal?
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Dik T. Winter" <Di********@cwi.nlwrites:
[...]
Depends quite a lot on the compilers. With some it is far from trivial,
and you need specially designed interface routines to put everything in
place. The reason is that neither Fortran, nor Pascal, nor Ada state
anything about how to interface with C. But the C++ standard *does* do
it, both ways. Python states how to interface with C routines, so calling
C from Python is trivial. It is the other way here that is not trivial.
[...]
Actually, Ada does specify how to interface with C, in considerable
detail.
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer wrote:
>
I maintain that you can't have such modules written in C++ and
callable from C. Well, maybe I should cavil a bit, and say useful
modules. But you can have useful C modules callable from C++.
Rubbish, you can provide an extern "C" prototype interface to any C++
module. I have written device drivers (which are loadable kernel
modules) in C++.
--
Ian Collins.
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
.... snip ...
>
>Note that this does NOT affect the object code in any way, only
the headers. You can't invert this and generate normal C++
modules that can be linked into a C program. Note the "normal".
What exactly do you mean by "normal"? Does the use of extern "C",
a feature defined by the C++ standard, render code abnormal?
I think we are getting at the heart of the disagreement. To me, a
normal C++ 'module' contains such things as functions with modified
names, reflecting the parameters, and used to separate the various
forms. The code has not been modified by an "extern C" clause. It
is usable without special care in any C++ program. (There is some
speculation here, because I don't really use C++).
To call that system from a C module, something has to supply the
modified function name. There is no such provision in C. It is
hard to add controlled gubris to a function name. Therefore you
can't call the C++ code from C.
However, you can call a C module from C++. All you have to do is
wrap the .h file in the "extern C {}" magic, and the prototype
names will be used unchanged. It is much easier to forbid name
modification than to insist on it, and specify the actual
modifications. Note that the C compilation is not affected because
that magic is guarded by "if __cplusplus", and the C standard
forbids any C implementation from defining __cplusplus.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
>Keith Thompson wrote:
>What exactly do you mean by "normal"? Does the use of extern "C",
a feature defined by the C++ standard, render code abnormal?
In article <47***************@yahoo.com>
CBFalconer <cb********@maineline.netwrote:
>I think we are getting at the heart of the disagreement. To me, a
normal C++ 'module' contains such things as functions with modified
names, reflecting the parameters, and used to separate the various
forms.
The thing is, you can tell *every* [%] C++ compiler *not* to use "mangled
names", simply by writing one special C++ declaration in front of
the function definition.
[% See parenthetical caveat below, also marked with [%].]
Imagine, if you will, that we have -- instead of C and C++ -- the
two languages P and L. In P, we write:
linkage "L":
declare foo as function taking integer and returning nothing.
begin function foo:
input parameter x is integer;
write x;
end function foo.
end linkage "L".
declare bar as function taking Lstring and returning nothing.
begin function bar:
input parameter p is Lstring;
write p;
end function bar.
In L, however, we write:
extern func foo [int];
extern (interface "P") func bar [string];
Now a program in language L can call both foo and bar, even though
both are defined in language P. A program in language P can also
(of course) call both foo and bar. Here, both languages have some
sort of special syntax specifically designed to interface with each
other.
If P and L use header files, then -- since the syntax differs --
we must obviously write two *separate* header files for P and L
to declare foo and bar in each. (The indented text above *is*
the L-language header, in fact. The P-language header simly
omits the source code for foo and bar -- the parts from "begin
function" to "end function".)
In the case of C and C++, however, instead of *both* languages
having some sort of special syntax, only C++ has the special syntax.
Luckily, only one such syntax is required -- normally, to turn off
the "name mangling" you know about. ([%] On some systems it might
do more and/or less than just disable name mangling. In particular,
C compilers are *also* allowed to do name mangling; it is just that
most avoid it, both because of tradition/history, and because extra
work is then required to handle old K&R-style non-prototyped
functions. The key item, in any case, is that the C++ special
syntax, required in every C++ compiler, tells that C++ compiler
that the functions so declared should be compiled such that they
use the C++ implementation's C-language linkage conventions, whatever
those are. That allows any later definition of those functions --
in any language, even if they are written in Pascal or Java -- to
call or be called from anything that is capable of using those
C-language linkage conventions.)
Because only the C++ side has the special syntax, you have to prefix
any C++ function *definition* with the appropriate syntax, so that
the C++ compiler does whatever is required to make that C++ function
callable from C.
At the same time, though, because C and C++ share so much syntax,
we can actually write a single "foo.h" header file, using those
annoying "#ifdef __cplusplus" lines, so that our two logically-separate
headers (for-c-foo.h and for-c++-foo.h) occupy a single source
file. We could do the same with the P and L headers, if there is
some sort of shared preprocessor for each, but there is less reason
to do so, since we would end up with:
#ifdef __P_LANGUAGE__
linkage "L":
declare foo as function taking integer and returning nothing.
end linkage "L".
#else
extern func foo [int];
#endif
If C were to adopt the C++ syntax for "extern", we could even
eliminate the annoying #ifdef from the shared C and C++ headers.
Perhaps we could also add name-mangling to C compilers so that we
could write:
extern "C++" somefunc(const char *);
instead of using:
extern "C" somefunc(const char *p) { ... }
on the C++ side -- but that would just be "completing the symmetry",
not actually adding any new functionality.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
CBFalconer wrote:
....
I think we are getting at the heart of the disagreement. To me, a
normal C++ 'module' contains such things as functions with modified
names, reflecting the parameters, and used to separate the various
forms. The code has not been modified by an "extern C" clause. It
is usable without special care in any C++ program. (There is some
speculation here, because I don't really use C++).
To call that system from a C module, something has to supply the
modified function name. There is no such provision in C. It is
hard to add controlled gubris to a function name. Therefore you
can't call the C++ code from C.
As I've said before, language linkage is controllable at the function
level, not the module level. A C++ translation unit containing the
definition of a function with "C" language linkage can also contain
other functions declared with "C++" language linkage. So - is that a C
module or a C++ module? If it's a C++ module, is it a "normal" one?
The functions with "C" language linkage can be called by name from
both C code and C++ code, without any need to worry about name
mangling. Are those functions C functions or C++ functions? The only
"special care" needed in C++ code is to make sure that the declaration
of a function with "C" language linkage must actually say so. I don't
consider that "special care". It's the same issue as, and no more
difficult than, giving the correct return type in a function
declaration.
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
... snip ...
>>
>>Note that this does NOT affect the object code in any way, only
the headers. You can't invert this and generate normal C++
modules that can be linked into a C program. Note the "normal".
What exactly do you mean by "normal"? Does the use of extern "C",
a feature defined by the C++ standard, render code abnormal?
I think we are getting at the heart of the disagreement. To me, a
normal C++ 'module' contains such things as functions with modified
names, reflecting the parameters, and used to separate the various
forms. The code has not been modified by an "extern C" clause. It
is usable without special care in any C++ program. (There is some
speculation here, because I don't really use C++).
I think the problem is that you're associating "C++" with an object
code module. C++ is a source code language. The contents of an
object module generated by a C++ compiler from a C++ source file are
entirely implementation-specific. The mangled names are not part of
C++; they're something used by the implementation, largely invisible
to portable C++ code.
And once again, extern "C" is a C++ feature. It's specified by the
C++ standard, and there is absolutely nothing "abnormal" or non-C++
about it.
A C++ source file containing an extern "C" directive is 100% pure C++.
To call that system from a C module, something has to supply the
modified function name. There is no such provision in C. It is
hard to add controlled gubris to a function name. Therefore you
can't call the C++ code from C.
Then please explain how I'm able to do exactly that. You can do so
only by assigning nonsensical meanings to the phrases "C code" and
"C++ code".
[...]
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
.... snip ...
>
A C++ source file containing an extern "C" directive is 100% pure C++.
>To call that system from a C module, something has to supply the
modified function name. There is no such provision in C. It is
hard to add controlled gubris to a function name. Therefore you
can't call the C++ code from C.
Then please explain how I'm able to do exactly that. You can do so
only by assigning nonsensical meanings to the phrases "C code" and
"C++ code".
In other words you are wrapping the _entire_ C++ source module with
the 'extern "C" {}' wrapper. That means you need to create a
separate .h header file, with the same wrapper, for use only in the
C linkage (This is hazy). It also means that there is no header
file for C++ use (unless you create another one).
The module that you compiled with the C++ compiler is not usable in
a C++ program without the extra effort of the separate header
file. To me this is not what is desired.
I will retract the 'impossible' claim, and replace it with
'impracticable'.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
... snip ...
>>
A C++ source file containing an extern "C" directive is 100% pure C++.
>>To call that system from a C module, something has to supply the
modified function name. There is no such provision in C. It is
hard to add controlled gubris to a function name. Therefore you
can't call the C++ code from C.
Then please explain how I'm able to do exactly that. You can do so
only by assigning nonsensical meanings to the phrases "C code" and
"C++ code".
In other words you are wrapping the _entire_ C++ source module with
the 'extern "C" {}' wrapper. That means you need to create a
separate .h header file, with the same wrapper, for use only in the
C linkage (This is hazy). It also means that there is no header
file for C++ use (unless you create another one).
No, the 'extern "C" {}' wrapper is *part of* the C++ source module.
I wrote a single header file, func.h, in which the 'extern "C" {' and
'}' lines were wrapped in "ifdef __cplusplus" ... "#endif". This is
*extremely* common practice.
The module that you compiled with the C++ compiler is not usable in
a C++ program without the extra effort of the separate header
file. To me this is not what is desired.
Only a single header file is needed. That single header file need to
be written to be compatible with both C and C++, which is not at all
difficult. Take a look at what I posted.
I will retract the 'impossible' claim, and replace it with
'impracticable'.
And you're still utterly wrong.
I. Showed. You. How. To. Do. It.
But since this is off-topic for comp.lang.c, I'm going to drop this.
If you're curious about this, post to comp.lang.c++ (but first read
the C++ FAQ and/or any decent book on C++).
--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
CBFalconer wrote:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.comwrites:
... snip ...
>A C++ source file containing an extern "C" directive is 100% pure C++.
>>To call that system from a C module, something has to supply the
modified function name. There is no such provision in C. It is
hard to add controlled gubris to a function name. Therefore you
can't call the C++ code from C.
Then please explain how I'm able to do exactly that. You can do so
only by assigning nonsensical meanings to the phrases "C code" and
"C++ code".
In other words you are wrapping the _entire_ C++ source module with
the 'extern "C" {}' wrapper. That means you need to create a
separate .h header file, with the same wrapper, for use only in the
C linkage (This is hazy). It also means that there is no header
file for C++ use (unless you create another one).
The language linkage specification can be used in several different ways:
extern "Pascal" double pfunc(int);
typedef extern "C" char *cstringfunc(char*, const char*);
extern "Fortran" {
// Identifiers between the curly brackets all have "Fortran"
// Language Linkage
}
The last one makes it trivial to mark large blocks of code as having a
particular language linkage. And it's also quite trivial to create a
single same header usable equally well in both C and in C++ to describe
functions with "C" language linkage:
common_header.h:
#ifdef __cplusplus
extern "C" {
#endif
// Normal C header file contents
#ifdef __cplusplus
}
#endif
To summarize: you do not need to wrap an entire C++ source module in
this fashion, unless you want to; it's perfectly feasible to apply it to
only a small portion of the module, or even a single function. You do
not need separate header files for C and C++.
The module that you compiled with the C++ compiler is not usable in
a C++ program without the extra effort of the separate header
file. To me this is not what is desired.
I will retract the 'impossible' claim, and replace it with
'impracticable'.
The apparent impracticality of this is largely due to your own
unfamiliarity with how it's done. It's not very difficult to use; it
requires the addition of only six extra lines to a typical header file.
The trickiest part is figuring out what you want to do once you've
pierced the C/C++ boundary; and that's not tricky because it's hard to
do. It's tricky because there's such a wide variety of options to consider.
Chris Torek wrote:
CBFalconer <cb********@maineline.netwrote:
>Keith Thompson wrote:
>>What exactly do you mean by "normal"? Does the use of extern "C",
a feature defined by the C++ standard, render code abnormal?
I think we are getting at the heart of the disagreement. To me, a
normal C++ 'module' contains such things as functions with modified
names, reflecting the parameters, and used to separate the various
forms.
The thing is, you can tell *every* [%] C++ compiler *not* to use "mangled
names", simply by writing one special C++ declaration in front of
the function definition.
[% See parenthetical caveat below, also marked with [%].]
Imagine, if you will, that we have -- instead of C and C++ -- the
two languages P and L. In P, we write:
.... snip ...
I have put this aside for further study, along with Keiths separate
example. I think we are defining interconnection differently, but
am not sure now.
I am talking about complete modules, taking advantages of all the
abilities of their respective language, being used in object form
in the other language.
--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.
--
Posted via a free Usenet account from http://www.teranews.com
CBFalconer wrote:
Chris Torek wrote:
>CBFalconer <cb********@maineline.netwrote:
>>Keith Thompson wrote:
What exactly do you mean by "normal"? Does the use of extern "C",
a feature defined by the C++ standard, render code abnormal?
I think we are getting at the heart of the disagreement. To me, a
normal C++ 'module' contains such things as functions with modified
names, reflecting the parameters, and used to separate the various
forms.
The thing is, you can tell *every* [%] C++ compiler *not* to use "mangled
names", simply by writing one special C++ declaration in front of
the function definition.
[% See parenthetical caveat below, also marked with [%].]
Imagine, if you will, that we have -- instead of C and C++ -- the
two languages P and L. In P, we write:
.... snip ...
I have put this aside for further study, along with Keiths separate
example. I think we are defining interconnection differently, but
am not sure now.
I am talking about complete modules, taking advantages of all the
abilities of their respective language, being used in object form
in the other language.
So are we. It does work, honest! I produce a lot of mixed C and C++
applications and from a C++ perspective, there are only a couple of
restrictions imposed on functions declared extern "C".
Due to C not having function overloading, extern "C" functions can't be
overloaded by other extern "C" functions.
You can't declare a function template as extern "C".
Other than those, and C++ function with extern "C" linkage is exactly
that, a C++ free function with an alternative linkage specification.
There aren't any restrictions on what the function does, or calls.
--
Ian Collins.
On Dec 6, 2:15 pm, Mark McIntyre <markmcint...@spamcop.netwrote:
Keith Thompson wrote:
<OT>Both main programs had to be linked with "g++", because both need
the C++ standard library.</OT>
This is where this 'goes wrong' I think...
But as you can see theCprogram was compiled asCand successfully
called a C++ function.
I don't think so. The C++ compiler would have turned func into something
like func::func@as:33:22 or some such other decorated nonsense. TheC
compiler would have generated a call to _func or whatever. The linker
can't resolve this.
The only way the modules will link is if main.lowercase-cwas compiled
as C++ /OR/ if some implementation-specific magic went on to tell the
linker to look for multiple possible versions of the name.
Obviously this requires some compatibility between theCand C++
implementations.
Indeed - so _in general_ this isn't possible, as CBF said in the first
place?
with extern "c" much worked and after making some changes now both
projects merged and working fine but now i need to access c++ object
from my c code...
now how can i do this?
teju wrote:
>
with extern "c" much worked and after making some changes now both
projects merged and working fine but now i need to access c++ object
from my c code...
now how can i do this?
Please, don't rake this thread up again, it has just died down. Read
this thread (and the countless others here and down the hall in c.l.c++).
--
Ian Collins. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: pieter.breed |
last post by:
Hi All,
Is it possible to export a c# method into a dll in such a way that your
"normal" C application can then call this method?
To be clear: I am not asking how to use "DllImport" or...
|
by: Ross A. Finlayson |
last post by:
Hi,
I hope you can help me understand the varargs facility.
Say I am programming in ISO C including stdarg.h and I declare a
function as so:
void log_printf(const char* logfilename, const...
|
by: Dave |
last post by:
does calling a regular function cost any cpu time? In other words, is it
faster to write the code of two functions into main(), or is it the exact
same thing as calling two functions. I know its...
|
by: Mark Jerde |
last post by:
Yesterday I posted the message below to microsoft.public.dotnet.languages.vb
and microsoft.public.vc.language. The two replies are also posted.
I need to write some ISO C++ functions, more...
|
by: Jesse McGrew |
last post by:
Hi all,
I'm trying to make a plugin DLL for a third-party application, using
VC++ .NET 2003. This DLL acts as a bridge between the C++ plugin API of
the application, and my actual plugin code...
|
by: H.B. |
last post by:
Hi,
I need to make a function that can display data on my Managed C++ app and be
called by an unmanaged C++ DLL. Something like :
void Form1::Form1_Load(System::Object * sender,...
|
by: Daniel Lidström |
last post by:
I'm using a library called fyba. This library reads and writes files in a
format called sosi. fyba uses the following code to determine if the
calling process has own methods to handle errors,...
|
by: John Friedland |
last post by:
My problem: I need to call (from C code) an arbitrary C library
function, but I don't know until runtime what the function name is,
how many parameters are required, and what the parameters are. I...
|
by: Edwin Gomez |
last post by:
I'm a C# developer and I'm new to Python. I would like to know if the concept of Asynchronous call-backs exists in Python. Basically what I mean is that I dispatch a thread and when the thread...
|
by: sulekhasweety |
last post by:
Hi,
the following is the definition for calling convention ,which I have
seen in a text book, can anyone give a more detailed explanation in
terms of ANSI - C
"the requirements that a...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
