conflicting headers

[Alexander Gorshenev]

I am looking for an elegant solution for the following problem:

I have two projects for which I have to create a kind of bridge
or translator between. For each of the projects there exist a set of headers
included by practicaly all of the member .c files.
For my bridge I would be using all those "main" headers from
both of the projects included together.

But unfortunately, due to historical reasons, those headers
conflict in many points. The conflicts are as:

project A: enum {Monday, Friday, Sunday};
project B: enum {Friday, Sunday, Sausidge, HotDog };

I have no rights to modify the headers because those
constitute the public interfaces.
And it is required for me to make minimal changes to existing code.

So what would smart guys advise?

 

[Malcolm]

I have two projects for which I have to create a kind of bridge
or translator between. For each of the projects there exist a set of
headers included by practicaly all of the member .c files.
For my bridge I would be using all those "main" headers from
both of the projects included together.

But unfortunately, due to historical reasons, those headers
conflict in many points. The conflicts are as:

project A: enum {Monday, Friday, Sunday};
project B: enum {Friday, Sunday, Sausidge, HotDog };

I have no rights to modify the headers because those
constitute the public interfaces.
And it is required for me to make minimal changes to existing code.

You've hit the typedef BOOL problem. Inexperienced programmers often define
identifiers like BOOL to make their code more readable, which it does, until
someone wants to include a function from another source that typedefs
"Bool".

What you want to do is create two "interface" files that sit on top of your
two chunks of legacy C code. Don't allow the legacy code to be called except
through the interfaces. In some cases the interface can be simply a call to
a legacy function. In other cases, for instance with the enumerated types,
you will have to translate the interface you provide into a legacy enum. You
can also probably neaten up the interface a little bit, to make the exercise
more worthwhile.

 

[SM Ryan]

(e-mail address removed) (Alexander Gorshenev) wrote:
# I am looking for an elegant solution for the following problem:
#
# I have two projects for which I have to create a kind of bridge
# or translator between. For each of the projects there exist a set of headers
# included by practicaly all of the member .c files.
# For my bridge I would be using all those "main" headers from
# both of the projects included together.
#
# But unfortunately, due to historical reasons, those headers
# conflict in many points. The conflicts are as:
#
# project A: enum {Monday, Friday, Sunday};
# project B: enum {Friday, Sunday, Sausidge, HotDog };

#define Monday A_Monday
#define Friday A_Friday
#define Sunday A_Sunday
#include "project A.h"
#undef Monday
#undef Friday
#undef Sunday

#define Friday B_Friday
#define Sunday B_Sunday
#define Sausidge B_Sausidge
#define HotDog B_HotDog
#include "project B.h"
#undef Friday
#undef Sunday
#undef Sausidge
#undef HotDog

 

[Robert Wessel]

I am looking for an elegant solution for the following problem:

I have two projects for which I have to create a kind of bridge
or translator between. For each of the projects there exist a set of headers
included by practicaly all of the member .c files.
For my bridge I would be using all those "main" headers from
both of the projects included together.

But unfortunately, due to historical reasons, those headers
conflict in many points. The conflicts are as:

project A: enum {Monday, Friday, Sunday};
project B: enum {Friday, Sunday, Sausidge, HotDog };

I have no rights to modify the headers because those
constitute the public interfaces.
And it is required for me to make minimal changes to existing code.

So what would smart guys advise?

I may be excoriated for making a C++ suggestion in c.l.c, but what the
heck. *If* C++ is an option for your bridge program (and given your
description of the system, it may well be), the use of namespaces can
separate the (non-preprocessing) names in the two headers fairly well.
And just use C++ as a "better C" (the "better" part being the
existence of namespaces in this case).

Include the two header files inside namespace declarations:

namespace ProjectA {
#include <headera.h>
}
namespace ProjectB {
#include <headerb.h>
}

Then you can reference things like:

if (a == ProjectA::Monday)
/* do something */

Again, this won't fix any of your #defines. And it may well lead to
linkage problems with function calls or other external (eg. global)
definition in the two headers (but you'd have those anyway). But for
things like structures and types, namespaces can take care of a lot.

 

[Alexander Gorshenev]

# But unfortunately, due to historical reasons, those headers
# conflict in many points. The conflicts are as:
#
# project A: enum {Monday, Friday, Sunday};
# project B: enum {Friday, Sunday, Sausidge, HotDog };

#define Monday A_Monday
#define Friday A_Friday
#define Sunday A_Sunday
#include "project A.h"
#undef Monday
#undef Friday
#undef Sunday

#define Friday B_Friday
#define Sunday B_Sunday
#define Sausidge B_Sausidge
#define HotDog B_HotDog
#include "project B.h"
#undef Friday
#undef Sunday
#undef Sausidge
#undef HotDog

Thanks,

of all three given variants (stub headers, namespaces, re#defines)
this one looks better for me. So I am going with it unless there
will be any more troubles.

horsh