Extern c ошибка

Hello,

I’m a a pretty new programmer just beginning to play around with C and C++. I use Linux and am compiling with gcc/g++ 4.3.2 however I’m coming across a strange problem that I just can’t resolve.

I’m trying to write a simple program to just see the possibilities of calling C++ code from C. The main() function is in C :

1
2
3
4
5
6
7
8
9
10
11
12

#include <stdio.h>
#include <stdlib.h>
#include "cpp_main.h"

/*
 * 
 */
int main(int argc, char** argv) {
    int return_value;
    return_value = cpp_main(argc,argv);
    return (return_value);
}

The function cpp_main() is written in C++, and is in file cpp_main.cpp :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#include "cpp_main.h"
//#include "testclass.h"

//int cpp_main(int argc, char** argv);
/*extern "C" {
    int cpp_main(int argc, char** argv);
}*/

int cpp_main(int argc, char** argv){
    char *testtext = "Some Test Text to display.\n";
    //TestClass::WriteMessage(testtext);
    
    return(0);
}

And cpp_main.h is :

1
2
3
4
5
6
7
8
9
10

//#ifndef _CPP_MAIN_H
//#define _CPP_MAIN_H

// Declare cpp_main() function
//int cpp_main(int argc, char** argv);
extern "C" {
   void cpp_main(int argc, char** argv);
};

//#endif	/* _CPP_MAIN_H */ 

However when I try to build the executable I receive this error :

cpp_main.h:6: error: expected identifier or ‘(’ before string constant

gcc is telling me there is something wrong with extern «C»… ?!?!!?

If I take the line from the header file and paste it directly into cpp_main.cpp everything compiles and links ok… but why won’t it work with the header file ?

Any help is much appreciated

Steve

I’ll try to guess the problem.

The block
extern «C»
{
…
}
need not a final semicolon.

You also may use the difinition of the form
extern «C» void cpp_main(int argc, char** argv);
if you declare the only function.

But worse thing is that the definition in the cpp_main.h differs from that in the cpp_main.cpp in the returned type (void vs int).

Firedraco :

OK, well as in my original post, can you explain why this compiles :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

//#include "cpp_main.h"
//#include "testclass.h"
//=========================================
// Include the header in cpp_main.cpp
//=========================================
//int cpp_main(int argc, char** argv);
extern "C" {
    int cpp_main(int argc, char** argv);
}

int cpp_main(int argc, char** argv){
    char *testtext = "Some Test Text to display.\n";
    //TestClass::WriteMessage(testtext);
    
    return(0);
}

Yet if I separate decelerations into a header file, this does NOT compile, giving the error I originally stated :

cpp_main.h

1
2
3
4
5
6

// Declare cpp_main() function
//int cpp_main(int argc, char** argv);
extern "C" {
   int cpp_main(int argc, char** argv);
};

cpp_main.cpp

1
2
3
4
5
6
7
8
9

#include "cpp_main.h"


int cpp_main(int argc, char** argv){
    char *testtext = "Some Test Text to display.\n";
    //TestClass::WriteMessage(testtext);
    
    return(0);
}

I’m using gcc and it has the capability to determine the source type (C or C++) from the file extension and passes it to the appropriate compiler in the toolchain, therefore I do not believe it’s a problem due to trying to compile C++ with a C compiler.

melkiy:

I was playing round with the return type and forgot to put it back before quoting the code here in the forum. Also it’s not because I didn’t have a semi-colon after the ‘extern’ decleration.

i succeeded in compiling your code with *.h and *.cpp files
with gcc version 3.4.6 20060404 (Red Hat 3.4.6-10)

Are you sure the problem is in compiling (gcc -c cpp_main.cpp), not in linking? Otherwise it’s another problem.

melkiy:

I managed to solve the problem — I had included a C++ header in the C file which contains main() (as you’ll see from my original post)

I had a misunderstanding of the use of headers — I thought they were there to enable the linker to resolve references to functions in other files. I was therefore skeptical at first removing the C++ #include expecting an ‘unresolved function’ error — but no gcc doesn’t necessarily use headers to resolve

Thanks for your help though.. tis much appreciated by a newbie !

My C++ program needs to use an external C library.
Therefore, I’m using the

extern "C"
{
   #include <library_header.h>
}

syntax for every module I need to use.

It worked fine until now.
A module is using the this name for some variables in one of its header file.
The C library itself is compiling fine because, from what I know, this has never been a keyword in C.

But despite my usage of the extern «C» syntax,
I’m getting errors from my C++ program when I include that header file.

If I rename every this in that C library header file with something like _this,
everything seems to work fine.

The question is:

Shouldn’t the extern «C» syntax be enough for backward compatibility,
at least at syntax level, for an header file?
Is this an issue with the compiler?

asked Sep 3, 2014 at 14:10

If extern "C" allowed you to use C++ keywords as symbols, the compiler would have to resolve them somehow outside of the extern "C" sections. For example:

extern "C" {
    int * this;  //global variable
    typedef int class;
}


int MyClass::MyFunction() { return *this; }  //what does this mean?
                                             //MyClass could have a cast operator
class MyOtherClass;  //forward declaration or a typedef'ed int?

answered Sep 3, 2014 at 14:36

Could you be more explicit about «using the this name for some variables in one of its header files»?

Is it really a variable or is it a parameter in a function prototype?

If it is the latter, you don’t have a real problem because C (and C++) prototypes identify parameters by position (and type) and the names are optional. You could have a different version of the prototype, eg:

#ifdef __cplusplus
  extern "C" {
   void aFunc(int);
  }
#else
 void aFunc(int this);
#endif

Remember there is nothing magic about header files — they just provide code which is lexically included in at the point of #include — as if you copied and pasted them in.

So you can have your own copy of a library header which does tricks like the above, just becoming a maintenance issue to ensure you track what happens in the original header. If this was likely to become an issue, add a script as a build step which runs a diff against the original and ensures the only point of difference is your workaround code.

answered Sep 3, 2014 at 17:57