On Wed, 25 Sep 2013 02:36:39 -0700 (PDT)
Michael Weise <michael.we...@ek-team.de> wrote:
> One problem I'm facing is that we have different customers who get
> different versions of our program (programming language is C).
> Currently these versions are implemented with lots of #ifdefs that
> make the code hard to read.
Not sure if this applicable to your particular situation but one way to
go about solving this is modularising: you extract all the common code
to a library (static or dynamic -- depends on the exact requirements)
and then write a *separate* program for each customer, and each would
use the library by linking with it. Yes, this *is* code duplication
as these separate programs will have much in common and possibly even
some exact parts but it's quite possibly this won't be code you change
A refinement to this approach is to turn functions which have #ifdef-ed
code into several (similar) functions each, or may be a single
-- "framework" -- function which, when called, receives one of more
pointers to other functions which provide bits currently coded inside
#ifdefs, like this:
x = quux();
#endif /* SOME */
typedef void (* handle_x_fn) (int *); // see , for instance
int foo(handle_x_fn fn)
x = quux();
which is then called
y = foo(&blurb);
y = foo(&mumble);
depending on which customer's program this is, with foo() being located
in the library both programs share.
This is called modularisation.
I've consciously diverged from the topic in the hope this would be of
some help, but if it is, you're better off asking about the exact
techniques for modularisation in C using other venues such as Stack
Overflow and comp.lang.c newsgroup available here on Google Groups.
Hope this helps.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.