Thread: 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?

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;
}

Originally Posted by hzmonte

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

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.

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.

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.

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.

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.