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

How to write a C++ header file that can be #included in a C source file when inheritance is used?
I inherited a piece of software which uses both C and C++.
A C++ header file "netlib_implementation.h" has:
(s_libReceiveSocket and s_libSendSocket are "subclasses" of s_libSocket.)

Code:

---

typedef struct s_libSocket t_libSocket;
struct s_libSocket {
  struct sockaddr sockAddr;
  int IP;
  int socketDescriptor;
}
typedef struct s_libReceiveSocket t_libReceiveSocket;
struct s_libReceiveSocket : s_libSocket {
  pthread_mutex_t threadMutex;
  .... ;
}
typedef struct s_libSendSocket t_libSendSocket;
struct s_libReceiveSocket : s_libSocket {
  pthread_cond_t cond;
  .... ;
}

---

A C++ program file "netlib.cc" has:

Code:

---

#include "netlib_implementation.h"
typedef t_libSocket * netHandle;
typedef t_libReceiveSocket * netRHandle;
typedef t_libSendSocket * netSHandle;
extern "C" netSHandle netOpenSendSocket( ... )
{
  t_libSendSocket *s = malloc(...);
  ...
  return s;
}
extern "C" netRHandle netOpenSReceiveSocket( ... )
{
  t_libReceiveSocket *s = malloc(...);
  ...
  return s;
}

---

A C program file "comm.c" calls the C++ functions:

Code:

---

#include "netlib.h"
netHandle comm_handle;
if (...)
  comm_handle = netOpenReceiveSocket( ... );
else
  comm_handle = netOpenSendSocket( ... );

---

Now the question is: How to write "netlib.h"?
(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.)
Currently "netlib.h" is written as:

Code:

---

typedef void * netHandle;
netHandle netOpenReceiveSocket( ... );
netHandle netOpenSendSocket( ... );

---

Note that the return type of the two function prototypes is netHandle, not netRHandle and netShandle as in the function definition. Also, there would be two different declarations of netHandle, one as void * in "netlib.h", another as t_libSocket * in "netlib.cc". That would be quite confusing.
Is there a better way to handle this?

Quote:

---

Originally Posted by hzmonte

How to write a C++ header file that can be #included in a C source file when inheritance is used?
I inherited a piece of software which uses both C and C++.

---

You don't. The second you add some C++ code, you're no longer programming in C, and you need a C++ compiler.


Quzah.

C++ provides the 'extern "C"' facility so that a C++ function can be used by a C program. So there does not seem to be anything wrong calling C++ code in a C program. I am not talking about mixing C and C++ in one source file; I am talking about calling a C++ function (defined in a C++ source file) in a C source file.

And how about this for "netlib.h":

Code:

---

#ifdef __cplusplus /* included in a C++ program */
typedef t_libSocket * netHandle; /* function as forward decl */
typedef t_libReceiveSocket * netRHandle; /* forward decl */
typedef t_libSendSocket * netSHandle; /* forward decl */
netRHandle netOpenReceiveSocket( ... );
netSHandle netOpenSendSocket( ... );
#else /* included in a C program */
typedef t_libSocket * netHandle; /* function as forward decl */
netHandle netOpenReceiveSocket( ... );
netHandle netOpenSendSocket( ... );
#endif

---

And "netlib.cc" would become:

Code:

---

#include "netlib.h"
#include "netlib_implementation.h"
extern "C" netSHandle netOpenSendSocket( ... )
{
  t_libSendSocket *s = malloc(...);
  ...
  return s;
}
extern "C" netRHandle netOpenSReceiveSocket( ... )
{
  t_libReceiveSocket *s = malloc(...);
  ...
  return s;
}

---

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 would appreciate it if someone could explain.

Quote:

---

Originally Posted by hzmonte

C++ provides the 'extern "C"' facility so that a C++ function can be used by a C program. So there does not seem to be anything wrong calling C++ code in a C program. I am not talking about mixing C and C++ in one source file; I am talking about calling a C++ function (defined in a C++ source file) in a C source file.

---

Actually it's the other way. Extern "C" tells a C++ compiler to compile that bit of code as C code.

At least that's what my books sais.

And It explains why all my compilers C headers are sorounded by extern "C"{}.

Quote:

---

Originally Posted by hzmonte

C++ provides the 'extern "C"' facility so that a C++ function can be used by a C program.

---

Quote:

---

Originally Posted by King Mir

Actually it's the other way. Extern "C" tells a C++ compiler to compile that bit of code as C code.

---

I think we are saying the same thing:
1. C++ provides the 'extern "C" ' facility
2. 'extern "C" ' tells the C++ compiler to compile that bit of code as C code
3. Then that code, which is a C++ function itself, can be used by a C program
The only thing I have some doubt is that, strictly speaking, the C++ compiler might not compile that piece of code as C code; it may compile it as some C++ code that is understandable by a C program. I am not sure about this. I know it has to do with some name mangling issue. But this is not important for my purpose.

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

Quote:

---

Originally Posted by hzmonte

I think we are saying the same thing:
1. C++ provides the 'extern "C" ' facility
2. 'extern "C" ' tells the C++ compiler to compile that bit of code as C code
3. Then that code, which is a C++ function itself, can be used by a C program

---

1 - Yes.
2 - Yes.
3 - No. What do you think we're telling you here? NO YOU CANNOT USE C++ CODE IN A C PROGRAM ON A C COMPILER. You can use C code on a C++ compiler. You cannot use C++ code on a C compiler. For that matter, some C code will not compile on a C++ compiler without changes. In short, NO. You're wrong. It is a wrapper for your C code to work on a C++ compiler, not a wrapper so C++ code works on a C compiler.

You have it backwards.

Just because you look into a mirror and see your reflection, doesn't mean the people on the other side of the mirror see their reflection. They're really staring at you. Think about that.


Quzah.

Going back to my question s to 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 did some more experiment and discovered that g++ would issue an error if I change the prototype for C++ as
baseType func(baseType);
That is, it is OK to say in a header file:

Code:

---

#ifdef __cplusplus /* for the use of a C program */
extern "C"
derivedType func(derivedType);
#else  /* for the use of a C program */
baseType func(baseType);
#endif

---

but not OK to say

Code:

---

#ifdef __cplusplus /* for the use of a C program */
extern "C"
baseType func(baseType);
#else  /* for the use of a C program */
baseType func(baseType);
#endif

---

It is interesting that gcc would correctly (at least I did not see any run-time error) link to that C++ function even though the prototype it (i.e. the C compiler) sees does not exactly match to the function definition in the C++ program file.

Read my text: Compiler specific. Not ANSI C. C does not support C++ code. Your compiler might, but that doesn't make it C.


Quzah.

Quote:

---

Originally Posted by quzah

NO YOU CANNOT USE C++ CODE IN A C PROGRAM ON A C COMPILER. You can use C code on a C++ compiler. You cannot use C++ code on a C compiler. For that matter, some C code will not compile on a C++ compiler without changes. In short, NO. You're wrong. It is a wrapper for your C code to work on a C++ compiler, not a wrapper so C++ code works on a C compiler.

You have it backwards.

---

Section 9.2.4 "Linkage to Non-C++ Code" of Stroustrup's "The C++ Programming Language, special edition" (2000) reads:

Quote:

---

Typically, a C++ program contains parts written in other languages. Similarly, it is common for C++ code fragments to be used as parts of programs written mainly in some other langauge.

---

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.
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.
My understanding of what you mean is 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.
What I am saying, and 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.
Unfortunately, the examples in the rest of Sec 9.2.4 can be interpreted either way. Maybe Stroustrup means that it can be done either way, as I suggest.
I have not seen anything in Stroustrap's book or other books that says C cannot call an extern-C-wrapped C++ function. On the other hand, Stroustrap does say "it is common for C++ code fragments to be used as parts of programs written mainly in some other langauge" (such as C). Can anyone show me where in the C++ Standard or any other books that say this is not allowed or this is not what it means?

Quote:

---

Originally Posted by King Mir

Extern "C" tells a C++ compiler to compile that bit of code as C code.

---

To be exact, Stroustrap does not say the exern-C-wrapped C function (or an extern-C-wrapped C++ function, if that is allowed) is to be compiled as C code. He says the function "should be linked according to the C linkage convention." I am not familiar with compilation and linking, but I think there is a difference between teh two. He does not say how the code is compiled, he just say how it is linked.

I find it funny that you choose to believe your interpretation of a somewhat vague quotation from Bjarne Stroustrup over a direct statement that any C programmer would tell you, including Bjarne Stroustrup if you asked him directly.

We are telling you this because we know it for a fact. YOU CAN NOT USE C++ CODE IN A STANDARD C PROGRAM.

The way I take that quote is saying that in some large systems, it's not uncommon to see small bits of the application written in C++ because of it's speed advantages while the rest of the system is developed in another language. In fact, if you look in a lot of banking systems, you find most of the code is still in COBOL while some of the modern processes are passed to things written in C or C++. It's not compiled or linked together in anyway, they just simply interact with each other. Just as a system's kernel will interact with other applications. I don't know if this is what he meant either, but one could interpret that is what he meant.

Well I suppose it might be possible to compile main() as a C function, while other functions would use C++. You would still need a C++ compiler to compile C++ regardless. And extern "C" would still mark the functions that are compiled as C code, not C++ code.

Furthermore you could compile a C++ library into assembly code and include that in your C code.

The convention is to use C code inside C++, not the other way around. After all, what's the point?

Quote:

---

Originally Posted by King Mir

Well I suppose it might be possible to compile main() as a C function, while other functions would use C++. You would still need a C++ compiler to compile C++ regardless. And extern "C" would still mark the functions that are compiled as C code, not C++ code.

---

http://www.parashift.com/c++-faq-lit....html#faq-32.1

Quote:

---

You must use your C++ compiler when compiling main() (e.g., for static initialization)

---

Quote:

---

Originally Posted by Dave_Sinkula

http://www.parashift.com/c++-faq-lit....html#faq-32.1

---

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?

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.

That makes sence, thanks.

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.

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.

Quote:

---

Originally Posted by Dave_Sinkula

http://www.parashift.com/c++-faq-lit....html#faq-32.1

---

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.

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.

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.

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.

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

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.

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.

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.

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 http://cboard.cprogramming.com/showt...5&page=1&pp=15
Could you clarify what you mean and whether the above-mentioned second approach is acceptable in C++? Thank you very much.

:rolleyes: 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:

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.

Quote:

---

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.

Quote:

---

Originally Posted by anonytmouse

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

---

---

That statement was first stated by King Mir. It was refuted by me before anyone else. (Actually quzah agreed to it in his/her June 16 3:17PM post.)

Quote:

---

Originally Posted by citizen

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?

---

Maybe someone tried to explain that a C compiler will not compile C++ code, though I already said that I understood it. But I think some people also tried to tell me that a C program (to be compiled by a C compiler) cannot call a C++ function compiled by a C++ compiler. And I think this is not just "my problem"; obviously this is the problem of some other C++ programmers. I would like to set the record straight here so that others can benefit. It is not that I would not be satisfied until somebody told me that I am totally right; it does not matter whether I am right or wrong. It matters what is right or wrong and why.
To me, the big question is never whether I would argue with someone; it is what the truth is. If the pursuit of knowledge requires me to argue with Stroustrup, I will.

Quote:

---

Originally Posted by anonytmouse

I think you know that what you have stated in your email is correct.

---

Well, I think my interpretation is correct; but someone disagreed. Therefore, for the benefit or myself, those who disagree, and whoever in the future who want to learn in this topic, why not ask Stroustrup and document it here?

Quote:

---

Originally Posted by anonytmouse

All of this is explaned quite well in the FAQ link that Dave posted.

---

If you read all my posts, you should have read my response to it.

Here is Stroustrup's reply:

From : Bjarne Stroustrup <bs at cs . tamu . edu>
Sent : Sunday, June 18, 2006 2:56 AM
Subject : Re: Correct intepretation of your comments on C++

Maybe this clarifies things?:

http://www.research.att.com/~bs/bs_faq2.html#callC
http://www.research.att.com/~bs/bs_faq2.html#callCpp

Note that ``extern "C"'' can appear only in a C++ program. C doesn't have a corresponding ``extern "C++"''