Lex's (actually Flex) output contains this:

The problem is that I am defining yywrap() in C++, not C. And I can't compile Lex's output as C, because YYSTYPE has members which are C++ classes.

Then what exactly is the problem? Compile lex's output in C++ and make sure you declare you yywrap() function extern "C" in C++... or is there some other problem? Do you know what extern "C" means?

1 members found this post helpful.

I always thought that an extern "C" function must be compiled with a C compiler.

No - extern "C" would be invalid C. To a C++ compiler, it directs it to give that function C-style linkage (i.e. no name mangling for namespaces/argument types etc.). You can compile it with C++ by marking it extern "C" in the source file:

Just note that you won't be able to do things like overload yywrap(void), or have it be a member function of any class.

No, I meant that I thought that is the prototype is compiled in C++ and is defined extern "C", then the implementation must be in a separate, C-compiled file.

So you now understand?

Just to be sure:

You can use extern "C" in C++ to declare a C interface function that can be called from C++ and is defined elsewhere (maybe in C, maybe in C++).

You can also use extern "C" in C++ to declare a C interface function that will be defined in the same C++ compilation unit using full C++ features. That C interface function might be called elsewhere from C or C++ code. (Those "full C++ features" are obviously usable only in the body of the function, not in its signature, because the point is to have a C signature).

In concept extern "C" is used either to declare a C function to be called from C++ or a C++ function to be called from C. But it is also useful in some cases for C++ functions called from C++.

I work with a lot of situations in which C++ code in a shared object is called from C++ code in an executable, but the two will be compiled with incompatible C++ compilers and the shared object actually compiled after the executable has been compiled and linked. That is only practical if the entry points in the shared object are all extern "C". So even though the caller and called function are both C++, the called function signature must be C.

If I understand your situation, you have automatically generated C code that (because of some included definitions) must be compiled with a C++ compiler, that calls a function with C signature. Hopefully, you now understand that is no problem. A function defined in C++ can be given a C signature.

So if you're calling a C++ function from C, the C++ function's implementation must be extern "C", right?

Should the implementation be extern "C" even if the prototype is extern "C", even when everything is compiled in C++?

The C++ function's declaration/signature must be extern "C". I'm not sure we mean the same thing by "implementation".

I think if the implementation as the body of the function, which is C++.

When I code extern "C" functions, they are typically very tiny stubs that exist just to call some member function:
1) Often there is a singleton object with a class static method to get a reference to it. An extern "C" function would get the reference to the singleton, then call a member function of that singleton object.
2) Sometimes one of the calling parameters of the extern "C" function is something I call an "opaque" pointer. That is a pointer that was returned by some other function in this .so and points to an object created in this .so. The definition of that object cannot be compatibly understood by the main executable, so code in the main executable only gets the pointer from one .so function and later passes the pointer to other .so functions. The extern "C" function receiving that pointer as a parameter might be implemented by calling a member function of the object pointed to. The main code cannot call that member function for itself, because the definition of the object is opaque to the main code.

IIRC, if you declared the function extern "C" and you included that declaration before the definition, it doesn't matter whether the definition also has the extern "C" syntax. It will be compiled with an extern C signature as a result of being declared that way.

Just wanted to be sure, becasue I didn't put extern "C" before the definition and it worked, but post #4 did, and I was wondering if I did it wrong.