Hi Konstantin & Gergely,
in principle I understand the concept of modularization.
My problem is that the differences in the code are on multiple
layers that make it very hard to modularize. I'll give some real
examples (bootloader for an embedded device) and detail:
a) Basic Setup: Device should accept firmware updates on pushing a
certain button-combination. Then it should do a memory test. If
there's no firmware update, it should boot the installed firmware.
If the buttons are pressed, it should receive a firmware update
over a usb connection an install it into flash.
b) Customer wants a device without buttons, so it should wait for a
firmware update for 15 seconds and then boot the installed firmware
if no update is received
Currently, most of this is implemented in the main() function. As
far as I know, one concept of C is that some crt0()-function
sets up the environt. When using a "clean" approach, as soon
as main() is called, everything should be set up correctly: Stack
pointer, ram modules, etc.
The ram test routine however destroys the contents of the memory, so
it should happen before calling main(). Currently checking the
button status happens IN main(), but the ram test should happen
Looks like the code needs some refactoring ;-)
Yeah, I see this is getting off topic, so I'll stop here. Just
wanted to let you know what I'm actually talking about.
Thanks for pointing to StackOverflow and the comp.lang.c newsgroup,
might be helpful soon ...
On Wed, 25 Sep 2013 18:07:11 +0400
Konstantin Khomoutov <flatw...@users.sourceforge.net> wrote:
> 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:
> int foo()
> int x;
> x = quux();
> #ifdef SOME
> #endif /* SOME */
> return x;
> turns into
> typedef void (* handle_x_fn) (int *); // see , for instance
> int foo(handle_x_fn fn)
> int x;
> x = quux();
> return x;
> 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.
> 1. http://stackoverflow.com/a/1591492/720999
> 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 to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
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.