tags:

views:

174

answers:

6

I have two large framework libraries, whose header files are included in my project. Either one works flawlessly, but including both causes erratic behaviour (but no error message related to the macro).

I assume that they both #define a macro of the same name. What is the most efficient way to identify the problematic macro?

+1  A: 

grep for #define ?

are you sure the problem isn't something else than a macro (for example pragmas for structur packing, global memory allocators, global namespace for class names, messing with locale ...)

6502
+5  A: 

I assume that they both #define a macro of the same name.

That should generate at least a warning by the compiler (if they are in the same translation unit).

How do I identify redefined macros in C/C++?

As far as I know there is no straight-forward way.

Either one works flawlessly, but including both causes erratic behaviour

Can you please give us some details on the eratic behaviour? What actually happens? What makes you think it's the macro definitions?

utnapistim
+3  A: 

If the header files are badly written and #undef SYMBOL ... #define SYMBOL something-else then you can't trace this. Simply #defining a macro twice should at least issue a warning. You'd have to look more closely at the 'erratic behavior'.

AshleysBrain
Thanks! I hadn't thought of them possibly using undef. That made searching for it a lot easier.
relet
+3  A: 

Try looking at the preprocessed output to determine what's different about it when you #include the header files and when you don't. With gcc and with MSVC, you'd compile with -E to print the preprocessor output to stdout. (It likely will be many thousands of lines, so you'll want to pipe it to a file.)

jamesdlin
This and making sure the "warning: redefinition of something or other" isn't turned off.
rubenvb
+1  A: 
  1. Compile with all warnings on - they should tell you when a macro 'is already defined' (maybe you can modify code in order to fix this)
  2. If (1) doesn't help then you should try to create function wrappers for each library. This way you avoid including the conflicting headers by including the wrapped headers, using the wrapped functions. This is laborious but it's sometimes the only way to make two libraries coexist in an application.

Basically solution (2) would make a separation between libraries. An example of such conflict is ACE with wxWidgets (2.8 version) when forced using precompiled libraries that are compiled with different options (one library Unicode the other ASCII).

Iulian Şerbănoiu
+2  A: 

You should be able to run ctags over your source. ctags can generate a tags file that, amongst other things, contains the names and locations of the macros in your C files.

You can control the types of symbols that ctags will store in your tags file through the use of the --c-kinds option. eg. ctags --c-kinds=+d -f tags --recurse ./your_source_directory/

You can then search for duplicates in the resultant tags file.

Andrew Edgecombe