0

I am starting a new project, which will take two existing projects, use part of the functionality of each, and will add new functionality.

As usual, both projects don't use standard C types, preferring to typedef their own.

All code is in C, not C++, so obviously, both projects wanted a boolean type, and both have typedef'd Bool, resulting in a compiler error in the new code when it includes both header files (the existing projects know nothing of each other & build just fine).

Obviously, neither team wants to change their code (and potentially destabilize it).

And there is no #if typedef.

Bad ascii art follows:

-------------       ---------------       -------------
| Project X |       | new project |       | Project Y |
-------------       ---------------       -------------
          \           /           \         /
           \         /             \       /
       ----------------           -------------- 
       |    X.h       |           |    Y.h     |
       ----------------           -------------- 

Where both x.h and y.h typedef Bool.

I need to be able to build the existing projects X and Y, plus the new project.

How can I get around the problem of the double definition in the new project (which needs lots of other stuff from x.h and y.h), and still be able to build the existing projects X and Y?

(Note: the problem may be more than just Bool, but that's the first one that crops up, so I use it as an example. I am hoping not to find two functions or enums with the same name).

I am looking for a solution which, preferably, has no impact on existing code, or has minimal impact on existing code. I do have an idea in mind, but would prefer to hear from others, preferably someone who has done this before.

  • 2
    The problem with Bool is that you're trying to use the conflicting definitions in the same compilation unit. You can avoid that by introducing an adapter for each dependency. I.e. the new project would depend on an X-Adapter which defines a clean X_Adapter.h. Then only X_Adapter.c would include the problematic X.h, thus isolating your project. Yes, this does require you to basically repeat all function declarations in the new header. And it doesn't protect you from linker errors, though you can possibly get around that via dynamic linking. – amon May 5 '17 at 7:10
  • You are probably looking for how to simulate namespaces in C. When you google for these keywords, you find some solutions, for example this one: stackoverflow.com/questions/389827/namespaces-in-c. The Bool problem, however, might be solved in a simpler manner, if both typedefs use the same underlying type like int or char. – Doc Brown May 6 '17 at 12:30
1

It seems as if your first problem is name clashes.

If both projects did indeed define the expected types in the expected way, then it might be enough to simply #undef the clashing macro immediately before it is #define'd in both places. If they did subtly different things with it, then this could introduce subtle defects; but I think in that case you won't get away without diving into both code bases anyway.

  • The problem is that these are not #define, but typedef – Mawg May 9 '17 at 10:11
1

You could create an "API" project where you move all the duplicated typedefs to and have project X and project Y using that.

  • I *could", but they are extremely resistant to change, as they don't want their projects destabilized. Nor do they want an expensive full retest – Mawg May 6 '17 at 13:18
0

Have you thought about:

#define Bool X_Bool
#include "X.h"
#undef Bool
#define Bool Y_Bool
#include "Y.h"
#undef Bool

It's not what I would call maintainable or sensible use of the preprocessor, but it works in your case.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.