This is a discussion on Use of C++ header file in C program file calling C++ function declared in that header within the C Programming forums, part of the General Programming Boards category; Originally Posted by King Mir Here's a question then: If since a call to main() is valid in C, but ...
Let me speculate.Originally Posted by King Mir
If main has to be C++, and C++ does not allow calling main, then it would certainly be against the spirit of things to call main from some C code in a C++ program -- which leads me to err on the side of any behavior being undefined.
Last edited by Dave_Sinkula; 06-16-2006 at 08:08 PM. Reason: Poor typing again: ~unddefined/undefined
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
That makes sence, thanks.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Guess what? You're wrong. "Some other language" doesn't mean C. It doesn't say C, you assumed it. Everyone here is telling you otherwise, but because you just decided to interpret it your own way, you ignore us. "Some other language" in this case isn't C.
Guess what? "Some other language" isn't BASIC either. WHY!? OH MY GOD! IT SAYS SOME OTHER LANGUAGE THAT MUST MEAN BASIC! I will NOT believe you liars on the C board! LIES LIES! IT MEANS BASIC!"
No jackass, it doesn't mean BASIC either. It means SOME OTHER LANGUAGES support this. Not all. It never says ALL LANGUAGES MUST ALLOW C++ CODE TO RUN!!!!!!!111OMG111!!1!. It says some language.
Well you're wrong. We've told you that. Pull your head out of your ass and listen.
No. That's not what he means. He means some languages. C is not one of them. Frankly at this point I don't give a ........ if you ever learn anything. You've proven you won't listen to what multiple people tell you when you set your mind to believing something your way. So go stuff yourself.
Quzah.
Hope is the first step on the road to disappointment.
SlyMaelstrom and quzah, can you take a deep breath and allow the possibility that you and a handful of other C/C++ programmers are wrong on this? As a scientist, I do not just take other people's words for it. Besides, you are not Stroustrup, no offense. I have taken the time to search the literature and test the code, why don't you do the same and prove me wrong? You guys keep saying "YOU CAN NOT USE C++ CODE IN A STANDARD C PROGRAM." Basically what you are saying is just "Trust me, it cannot be done, it is wrong." It is not that I do not want to trust you, it is just that it is not a very scientiific way of seeking knowledge.
I did not assume it. I said "such as C". It surely does not say C; but it can be C, can't it? And the entire section 9.2.4 talks about the interaction between C and C++. I believe that C is a very reasonable candidate for such a "some other langauage". Why don't you tell me what this "some other langauge" refers to if you think C is not such one? And what makes you think C is not such one? Getting emotional and citing what "everybody else is telling [me] otherwise" is not the way to convince people.
That kind of attitude only makes me place less trust and attention on what you say. But I do hope that you will learn how to engage in a civilized and productive discussion. The entire section 9.2.4 talks about the interaction of C and C++ but all you keep saying is simply "it isn't C" without explaining why you think it cannot be C, and then you expect others to just trust you because you say so.
Actually I read that and it seems to me that it implies that the way I interpret Stroustrap's words makes sense. In [32.1] it says "you'll need to read the rest of this section to find out how to make your C functions callable by C++ and/or your C++ functions callable by C. " So, it is both ways. And in [32.6] it explains "How can I create a C++ function f(int,char,float) that is callable by my C code?" However, the explanation there is too basic in the sense that it does not address my question, which is "Why would C accept a prototype BaseType func(BaseType) whereas the C++ definition is DerivedType func(DerivedType)?" I think that part of the FAQ does not talk about issues involving inheritance.
For those who are interested in gaining a deeper insight into this issue, rather than in "educating" me by saying "it is so because we say so" or "because we have xx years of experience" or anything like that, I would also point to Section 11.3 of Stroustrup's book "The Design and Evolution of C++" (1994). There he explains this C/C++ linkage problem. If my understanding is correct, C linkage does not require the name of a function, as appeared in the object code, include any info on its argument types. So, the source function open() would appear in the object code as open or _open. On the other hand, "every C++ function name is encoded by appending its argument types." So, the linker would encode the function f(int) as f__Fi, f(int, char*) as f__FiPc, and so on. What the 'extern "C"' facility does is to encode a C++ function in the C way.
The way I read these 2 sentences is that if I bracket my C++ function declaration with this extern "C", then the C++ compiler/linker would encode this C++ function in the C way, so that in the object code, this function is named sqrt or _sqrt rather than sqrt__Fd for example. And this way a C program can call this function, i.e. link its object code, because the C compiler now recognize its name sqrt or _sqrt. If it is named sqrt__Fd, then the C compiler wil not be able to recognize it.
1)Perhalps you should read the section of the book that talks about lining with C then.
2)An example of a language that can be used in combination with C++ is Java.
3)The link Dave provided seems at least as credible as your book. Read it if you want to use C and C++ code together.
Last edited by King Mir; 06-16-2006 at 10:00 PM.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
I guess so, but maybe calling a C++ function from a C program is easier than calling an assembly function from a C program.
I did not write that softwrae; I inherited it. And it was written by two (actually more than 2) people at different times. Perhaps the one who wrote the C++ code wanted to benefit from the inheritance capability. And the one who wrote the C code thought that C runs faster than C++. And neither wanted to use the other's favorite language. I am just guessing.
One final comment:
Apparently it's ok for you to just take someone's word for it if they've put the words into a book. Be sure you say to Herbert Schildt, and Mister C when you see them.
Scientist my ass.
[edit]
Oh, and by 'ass', I mean donkey. My donkey is as much a scientist as you are.
[/edit]
Quzah.
Last edited by quzah; 06-17-2006 at 04:49 AM.
Hope is the first step on the road to disappointment.
>I am talking about calling a C++ function (defined in a C++ source file) in a C source file.
If you're talking about using a C compiler to build those two source files, you're wrong. It can't be done without a C++ compiler because a C compiler doesn't recognize the syntax you want to use. Now, if you're talking about a C++ function with C linkage (extern "C") in an object file that was compiled with a C++ compiler, then it's a different story. It seems that quzah thinks you're talking about the former. So be specific about what you're doing if you don't want people to misunderstand and jump on you.
>specifically why C (specifically gcc 3.4.4 on Solaris 9) would accept
That's simple. gcc is actually calling g++ to compile your C++ code. Unless you use a switch to explicitly select the language being compiled, gcc will choose the compiler used based on the file type. In other words, .cc gets compiled as C++.
My best code is written with the delete key.
It is not just "someone"'s book; it is Stroustrup's book. It is the words of C++'s creator. No offense, but I think Stroustrap's words carry more weight than yours. And humility and open-mindedness may well be important ingrenients of his success.
It's not Stroustrup words, it's your interpretation of his words. Words that we gave different interpretations for. So if you're asking does the words of multiple employed C programmers hold more weight than your interpretation, then yes it does.
Stroustrup has an email address that he answers questions on. Why don't you email him and ask him directly if you're so sure he's on your side.
Sent from my iPadŽ
That's not what I meant. I meant compiling the two C++ functions using a C++ compiler. And linking that object file to a C program which calls these two functions and when compiling this C file with a C compiler. In my initial post, I had this: "Note that I cannot #include "netlib_implementation.h" in comm.c because "netlib_implementation.h" has some inheritance stuff in it and a C compiler does not recognize such." I did recognize a C compiler does not recognize C++ syntax.
I apologize if my not making it explicit at the beginning is the cause of misunderstanding. In my fourth post, I said "the C++ compiler might not compile that piece of code [i.e. the code bracketed by extern "C" {}]as C code. It may compile it as some C++ code that is understandable by a C program. I am not sure about this." Before quzah got impatient with his "ass" comment, I already patiently and explicitly explained what I meant in my sixth post: "What I am saying, and [I think] you disagree, is that one can also wrap a extern "C" around the declaration of a C++ function (which is compiled by a C++ compiler) and #include this declaration in a C program file and then compile this C program (with linkage to the C++ function) with a C compiler."
That may be/is true if I was talking about compiling my C++ functions with gcc. But what I am reallly talking about is compiling my C++ functions with g++ and then compiling a C program that calls these C++ functions using a C compiler.
Last edited by hzmonte; 06-17-2006 at 04:35 PM.
OK, I just sent an e mail to Stoustrap. Stay tuned for his response.
Sent : Saturday, June 17, 2006 10:54 PM
To : bs at cs . tamu . edu
Subject : Correct intepretation of your comments on C++
Hi, Dr Stroustrap:
There is a controversy as to how to interpret what you say about mixing C and C++ code in your two books "The C++ Programming Language" and "The Design and Evolution of C++". In summary, there is no dispute as to the fact that one can wrap an extern "C" around the declaration of a C function (which is compiled by a C compiler) and #include this declaration in a C++ program file and then compile this C++ program (with linkage to the C function) with a C++ compiler. But there is no consensus as to whether one can do it the other way around: Can one also wrap a extern "C" around the declaration of a C++ function (which is compiled by a C++ compiler) and #include this declaration in a C program file and then compile this C program (with linkage to the C++ function) with a C compiler.
Your two books seem to touch on this subject but different people interpret it differently. The detailed discussion is at Use of C++ header file in C program file calling C++ function declared in that header
Could you clarify what you mean and whether the above-mentioned second approach is acceptable in C++? Thank you very much.
He'll write you back as soon as he gets done working and as soon as you spell his name correctly.
We tried to explain that a C compiler will not compile C++ code, so if your problem was really just what Stroustrup wrote why did you post here? Reading the thread it is as though as you weren't satisfied with the answer to your question until somebody told you that you were totally right.
So the big question: are you going to argue with Stroustrup too?
hzmonte, I think you are being unfair to Stroustrup in involving him in a trivial argument that is largely over semantics. I think you know that what you have stated in your email is correct. Further more, I don't think anyone has argued with this proposal. What has been refuted is your statement and the assumptions you made based on it:
To your credit, you now realise this statement was incorrect. The extern "C" specifier marks a function as using C compatible linkage (for either import or export). It does not change the language that the code is compiled in.
To sum up the details:
- A translation unit (a source file with all includes) is compiled as either C or C++. There is no standard way to mix up programming languages in the one translation unit.
- Most linkers are able to link object code which is generated by C or C++ compilers or both. For example, a project with one .c file and one .cpp file. The .c file is compiled to object code by a C compiler. The .cpp file is compiled to object code by a C++ compiler. The linker then links the two into the one executable.
- In the above scenario, the C++ code may call a function from the C code. In this case the prototype for the C function in the C++ translation unit must be marked with the extern "C" specifier.
- In the above scenario, the C code may call a function from the C++ code. In this case the C++ function in the C++ translation unit must be marked with the extern "C" specifier.
- Not all C++ functions may be marked with the extern "C" specifier. For example, overoaded functions can not use C compatible linkage. In this case the typical solution is to use C++ stub functions.
I think you have already answered this question yourself. C linkage on most platforms does not include any details of argument type. Therefore, there is no check of compatible arguments at linkage time. The only check is the normal check against prototypes at compile time. If you 'lie' in your prototypes, the compiler/linker is not going to complain. At run-time, the code may run if the types are compatible, otherwise it will probably crash (the behaviour is undefined).I am glad to report that my approach works , though I still do not know exactly why it works - specifically why C (specifically gcc 3.4.4 on Solaris 9) would accept a prototype
baseType func(baseType);
whereas the function definition in C++ is
derivedType func(derivedType);
As a general tip, I would advise against passing pointers to C++ classes between your C and C++ code, especially if the class is non-trivial (uses inheritance). This is a recipe for trouble. Instead store the C++ class in a plain C type structure and pass the pointer to that around as a void pointer.
All of this is explaned quite well in the FAQ link that Dave posted.
Last edited by anonytmouse; 06-18-2006 at 09:59 AM.
LinkBack URL
About LinkBacks
