Use of C++ header file in C program file calling C++ function declared in that header

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

  1. #16
    Just Lurking Dave_Sinkula's Avatar
    Join Date
    Oct 2002
    Posts
    5,006
    Quote Originally Posted by King Mir
    Here's a question then: If since a call to main() is valid in C, but not C++, would it be possible to call main() from a C function included in a C++ project?
    Let me speculate.

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

  2. #17
    Registered User
    Join Date
    Apr 2006
    Posts
    2,021
    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.

  3. #18
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by hzmonte
    The way I read the second sentence is : "C++ code can be used as parts of a program written in some other langauge such as C. In other words, C++ code can be called from a C program." And of course, the implicit assumption is that this C program is to be compiled by a C compiler.
    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.


    Quote Originally Posted by hzmonte
    My understanding of this paragraph, therefore, is that it is a two-way street. C++ program can call C code, and C program can call C++ code.
    Well you're wrong. We've told you that. Pull your head out of your ass and listen.

    Quote Originally Posted by hzmonte
    Maybe Stroustrup means that it can be done either way, as I suggest.
    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.

  4. #19
    Registered User
    Join Date
    Jul 2005
    Posts
    98
    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.
    Quote Originally Posted by quzah
    "Some other language" doesn't mean C. It doesn't say C, you assumed it.
    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.
    Quote Originally Posted by quzah
    Pull your head out of your ass and listen. ... Frankly at this point I don't give a ........ if you ever learn anything.
    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.

  5. #20
    Registered User
    Join Date
    Jul 2005
    Posts
    98
    Quote Originally Posted by Dave_Sinkula
    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.
    Quote Originally Posted by Stroustrup
    an extension of the linkage-specification was introduced into C++:
    Code:
      extern "C" {
          double sqrt(double);
      }
    The linkage specification ... simply tells the compiler to use the C naming conventions for the name used for sqrt() in the object code. This means that the linkage name of this sqrt() is sqrt or _sqrt or whatever is required by the C linkage conventions in agiven system.
    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.

  6. #21
    Registered User
    Join Date
    Apr 2006
    Posts
    2,021
    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.

  7. #22
    Registered User
    Join Date
    Jul 2005
    Posts
    98
    Quote Originally Posted by King Mir
    Furthermore you could compile a C++ library into assembly code and include that in your C code.
    I guess so, but maybe calling a C++ function from a C program is easier than calling an assembly function from a C program.
    Quote Originally Posted by King Mir
    The convention is to use C code inside C++, not the other way around. After all, what's the point?
    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.

  8. #23
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    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.

  9. #24
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >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.

  10. #25
    Registered User
    Join Date
    Jul 2005
    Posts
    98
    Quote Originally Posted by quzah
    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.
    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.

  11. #26
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,066
    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Ž

  12. #27
    Registered User
    Join Date
    Jul 2005
    Posts
    98
    Quote Originally Posted by Prelude
    >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.
    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.
    Quote Originally Posted by Prelude
    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.
    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."
    Quote Originally Posted by Prelude
    >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++.
    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.

  13. #28
    Registered User
    Join Date
    Jul 2005
    Posts
    98
    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.

  14. #29
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,627
    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?

  15. #30
    Yes, my avatar is stolen anonytmouse's Avatar
    Join Date
    Dec 2002
    Posts
    2,544
    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:
    Quote Originally Posted by hzmonte
    2. 'extern "C" ' tells the C++ compiler to compile that bit of code as C code
    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 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);
    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).

    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.

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Need help understanding Header Files
    By Kaidao in forum C++ Programming
    Replies: 11
    Last Post: 03-25-2008, 10:02 AM
  2. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 04:45 PM
  3. Calling a Thread with a Function Pointer.
    By ScrollMaster in forum Windows Programming
    Replies: 6
    Last Post: 06-10-2006, 08:56 AM
  4. <Gulp>
    By kryptkat in forum Windows Programming
    Replies: 7
    Last Post: 01-14-2006, 12:03 PM
  5. Possible circular definition with singleton objects
    By techrolla in forum C++ Programming
    Replies: 3
    Last Post: 12-26-2004, 09:46 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21