views:

73

answers:

3

I am looking after a huge old C program and converting it to C++ (which I'm new to). There are a great many complicated preprocessor hacks going on connected to the fact that the program must run on many different platforms in many different configurations. In one file (call it file1.c) I am calling functionA() and in another file (call it file2.c) I have a definition of functionA(). Unfortunately the exact type of the function is specified by a collection of macros created in a bewildering number of ways. Now the linker is complaining that functionA is an unresolved external symbol. I suspect that the problem is that the prototype as seen in file1.c is slightly different from the true definition of the function as seen in file2.c. There is a lot of scope for subtle differences due to mismatches between _cdecl and fastcall, and between with and without __forceinline. Is thee some way to show exactly what the compiler thinks is the type of functionA() as seen by file1.c as opposed to file2.c?

+1  A: 

You can pass a flag to the compiler (/P, I think) that causes it to output the complete preprocessed output that is passed to the compiler - you can then open this (huge) file, and search through it and the information you need will be in there, somewhere.

1800 INFORMATION
+1. Thanks... that has helped somewhat although it has now revealed a deeper mystery which I have put in a new question.
Mick
+1  A: 

Must you actually convert all the existing C code to C++? This is likely to be a lot of work, especially given what you've described so far.

Instead, you can write new code in C++ and call into the C code using extern "C". For example, in a C++ source file you can:

extern "C" {
#include "old_c_header.h"
}

This changes the linkage so the C++ compiler generates external references to the C code without name mangling, allowing the linker to match everything up.

Greg Hewgill
Unfortunately I must convert it to C++ for many reasons, but thanks for the tip anyway.
Mick
A: 

Normally you should have the expected and the actual signature in the output.

Otherwise you can instruct the compiler to output the results of the preprocessing into a seperate file, cl.exe /p for MSVC and for gcc gcc -E.

Georg Fritzsche
The linker reports the precise declaration of the function it is failing to find, which presumably is the one corresponding to file1.c, but I have no clue about the one corresponding to file2.c.
Mick
Too bad, i hope preprocessor output and grep/search for the function name helps.
Georg Fritzsche