views:

285

answers:

4

Possible Duplicate:
Use the keyword class as a variable name in C++

In a C header file of a library I'm using one of the variables is named 'new'. Unfortunately, I'm using this library in a C++ project and the occurence of 'new' as a variable names freaks out the compiler. I'm already using extern "C" { #include<...> }, but that doesn't seem to help in this respect.

Do I have to aks the library developer to change the name of that variable even though from his perspective, as a C developer, the code is absolutely fine, as 'new' is not a C keyword?

+3  A: 

Is it required that the header contain the name of this variable? If you are using a global variable named "new", then of course that would be a reason it is required that you have a globally visible variable name. On the other hand, if this is something like a function argument named "new", simply delete the name from the declaration of the function. If the name is a member of a structure or union, changing it in the header file will not harm the .C code as long as the .C code sees a "private" definition with the name matching that source code.

Since the .C files should be compiled in C syntax and thus will be able to cope with the variable named "new," fixing the header files ought to be a valid work-around.

For the long-term, yes you should bring this to the attention of the library developer.

As a final, somewhat hacky, solution, you could change the header file from "new" to something, e.g., "was_new." And when compiling the C files of the library use compiler switches to enforce #define new was_new.

Heath Hunnicutt
I know I can simply delete or rename that variable, as it is only used in a function declaration. I was searching for a solution that leaves the C header file of the library untouched. I'm sorry if that wasn't clear enough. Thank you for your answer. In the end I changed the header file, and I will contact the library developers about it.
Florian
A: 

If you are modifying a perfectly fine header file of a 3rd party library, I'd recommend that you'd stop now. You are attempting to add C++ code to a C library if I understood you right, that will not do, C does not recognize the "new" keyword as it's a C++ keyword.

Instead I'd recommend that :

You create a separate C++ project with a source file (*.cpp), add an #include to that 3rd party header file, and link (google "linking libs" etc.) the library's binary file to your project.

I hope that helps a bit, Cheers

Maciek
Actually I don't want to modify the C header file at all, as it is part of a library. I was searching for a solution that only relies on changing my own C++ source code. Not linking the libraries is the problem, but compiling the C++ source code of my own project, as it still includes the C headers from the library, and those -- while being valid C -- are not valid C++.
Florian
+6  A: 

Before including the header file, use the preprocessor to rename new:

#define new mynew
#include <...>
#undef new

That will allow the compilation to proceed.

Do you actually need to access this variable? If not - then you're done. If you do, then you'll need to ensure the .c files for the library are compiled with

-Dnew=mynew
psmears
And then hope that there isn't already an existing variable called `mynew` :)
dreamlax
I don't need to access it, it is just a parameter in a function declaration. I see where your heading at: Because the preprocessor replaces 'new' by 'mynew', the C++ compiler never gets to see the 'new' in the header file, but only the 'mynew', which is not a C++ keyword and therefore fine to use.
Florian
And in answer to dreamlax: That should only cause a problem, if use the "-Dnew=mynew" part. The first part should be perfectly fine and in my case sufficient.
Florian
@Florian: Yes,exactly! @dreamlax: :)
psmears
A: 

You could write your own wrapper functions in C. Everything that you use that will touch the library will be written in C with C++ friendly header files. So, instead of:

other_lib.h:
int foo( int new );

my_app.cxx:
extern "C" {
#include <other_lib.h>
}

which won't compile, you do:

my_wrap.h:
#ifdef __cplusplus
extern "C" {
#endif
int my_foo( int );
#ifdef __cplusplus
}
#endif

my_wrap.c:
#include <other_lib.h>
int my_foo( int x ) { return foo( x ); }

my_app.cxx:
#include "my_wrap.h"

...

Compile my_wrap.c with a C compiler, then compile my_app.cxx with the C++ compiler. This allows you to build while making no changes to the existing library.

William Pursell