C++Talk.NET

kk_oop@yahoo.com · Guest

Hi. In our domain, we have to vary a lot of code based on a radar type
(of which there are 3--for now). The legacy code acheives this by
heavy use of #ifdef macros sprinkled throughout the code. We now have
an opportunity to redesign a lot of this code. I am recommending that
instead of the macro approach, we use polymorphism-based design
options, such as the strategy, template method and abstract factory
patterns. To me, this just seems intuitively like a better approach.
However, I want to be able to articulate why this a better approach, so
I am prepared to respond to those who will recommend continuing with
the macro approach.

Could someone articulate some reasons that support the
polymorphism/pattern approach?

Thanks in advance!

Ken

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Lorenzo Bettini · Guest

[email]kk_oop (AT) yahoo (DOT) com[/email] wrote:

sid · Guest

Besides using polymorphism you will also have to come with a strategy
to decide which type or radar - is the software going to auto detect it
by some interaction with the radar or is it going to get this from a
configuration. (If it auto detects it's a win-win.)
Also you might need to confirm on a strategy for testing.

So Let me give it a try:

1. Single build step creates the software for all 'radar' types
2. single deliverable to all sites (assuming no configuration needed or
is a one time start up step).
3. Easier code browsing/support.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Rob · Guest

Lorenzo Bettini wrote:

Ivan Vecerina · Guest

<kk_oop (AT) yahoo (DOT) com> wrote

: Hi. In our domain, we have to vary a lot of code based on a radar type
: (of which there are 3--for now). The legacy code acheives this by
: heavy use of #ifdef macros sprinkled throughout the code. We now have
: an opportunity to redesign a lot of this code. I am recommending that
: instead of the macro approach, we use polymorphism-based design
: options, such as the strategy, template method and abstract factory
: patterns. To me, this just seems intuitively like a better approach.
: However, I want to be able to articulate why this a better approach, so
: I am prepared to respond to those who will recommend continuing with
: the macro approach.
:
: Could someone articulate some reasons that support the
: polymorphism/pattern approach?

Be careful that, when you mention "polymorphism", people will think
in terms of base classes and run-time dispatching. People will
think runtime overhead, and you might face an uphill battle.
Obviously in your case you want compile-time polymorphism,
or parameterized polymorphism.
The good news is that C++ is the right language to support this.

A recommended reading to delve into this is James Coplien's
"Multi-Paradigm Design for C++":
http://www.accu.org/bookreviews/public/reviews/m/m001789.htm

I think that the right way to put it is not #ifdef vs. polymorphism,
but #ifdef versus an encapsulated interface.

What your code is currently trying to do with #ifdef-s is to
encapsulate the interface of a 'radar' object. The problem is
that this is a very weak way to provide encapsulation: knowledge
about the internal behavior/specifics of a radar is probably
dispersed throughout your code.

What you want instead is to use object-orientation: to provide
a clean, delimited interface to a radar object, which encapsulates
all radar-specific knowledge/behaviors.
This is what object-oriented design had been invented to solve,
and it has clear benefits (measured by the success of the OO
programming paradigm).
And again, the benefit of C++ is that encapsulation and object
orientation are well supported by the language, and can be
leveraged without incurring any runtime overhead.

This would be the foundation on which I would base
an argumentation. Of course choosing the right
kind of compile-time polymorphism will then
be the next key question to address (e.g. just use an
independent class for each radar? or a template class?
or use a set of strategy/traits classes? etc).

I hope this helps,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Viktor Prehnal · Guest

{In general this post would be rejected for lack of context, however in
this case it could have been posted as a distinct thread without prior
context -mod}

I can't really figure out how to maintain and extend code full of #ifdef
stuff. It must be disgusting.
If OO overhead is problem, I would rather use some C pure solution with
configuration radar choice.
I do not really have a clue why #ifdef solution was even chosen. For
smaller code????????

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

fazl.rahman@VolcanoMail.c · Guest

As soon as you partition your app with #ifdefs you no longer have a
single source base. Each set of #defines presents only one subset of
your source to the compiler. This leads to a combinatoric nightmare
when adding functionality. Withouth the #ifdefs, you can look forward
to fixing problems in one place instead of in three.

Another major problem with #ifdefs: Presumably you have to do three
separate builds in order to run all the regression tests you need to
confirm that any code change hasn't broken anything. If you get rid of
the #ifdefs, you will have a single code base, and you can (maintain
and) run a single regression test suite. That in itself will be a
major productivity boost.

If you decide to go ahead, remember to do it in small increments.

Kind regards, Fazl

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Rob · Guest

Lorenzo Bettini wrote:

Ivan Vecerina · Guest

"Viktor Prehnal" <prehnal (AT) email (DOT) cz> wrote

: {In general this post would be rejected for lack of context, however in
: this case it could have been posted as a distinct thread without prior
: context -mod}
:
: I can't really figure out how to maintain and extend code full of #ifdef
: stuff. It must be disgusting.
Such code is very likely to be painful to maintain and extend.

: If OO overhead is problem, I would rather use some C pure solution with
: configuration radar choice.
: I do not really have a clue why #ifdef solution was even chosen. For
: smaller code????????
For embedded development, smaller code can sometimes be an issue
(although for a high-margin application such as radar control, I do
not think that sparing a few cents on extra Flash/ROM will matter).
Furthermore, a cleaner design does not mean larger compiled code --
actually it is quite often the contrary.

So how do you end up with #ifdef-s spread all over your code base?
It probably starts with having to add a small custom feature for
customer D. The developer is in a rush, so he quickly adds a few
#ifdef-s to implement the few required changes. Then come customers
E, F, G, and the guys just keep following the same coding pattern.

It takes little experience to recognize the trend towards an
expensive anti-pattern. But it takes someone with a more solid
experience and some clout to make sure that the team dedicates
part of its resources to refactoring and cleaning-up the code.
[ Unless you have some brilliant team member(s) who perform the
repair in the background, without being noticed. But then,
you probably wouldn't have gotten there in the first place. ]

By the time the development gets bogged down, and management
finally recognizes that something has to be done about code
structure, it is often late already...
That is, if the code base is large, going for an extensive
redesign is expensive and risky (= prone to failure).
See http://www.joelonsoftware.com/articles/fog0000000069.html

Hopefully for the OP, the code base is not too complex yet,
and the redesign can be completed without too much hassle.
If not, having a skilled coder who progressively refactors
the code might be a safer/better option than the large
redesign/rewrite mentioned in the original post.

Kind regards,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kk_oop@yahoo.com · Guest

Ivan Vecerina wrote:

Ivan Vecerina · Guest

<kk_oop (AT) yahoo (DOT) com> wrote

: Ivan Vecerina wrote:
: > <kk_oop (AT) yahoo (DOT) com> wrote in message
: > news:1134737410.800827.162550 (AT) z14g2000cwz (DOT) googlegroups.com...
:
: <snip>
:
: > And again, the benefit of C++ is that encapsulation and object
: > orientation are well supported by the language, and can be
: > leveraged without incurring any runtime overhead.
: >
: >
: > This would be the foundation on which I would base
: > an argumentation. Of course choosing the right
: > kind of compile-time polymorphism will then
: > be the next key question to address (e.g. just use an
: > independent class for each radar? or a template class?
: > or use a set of strategy/traits classes? etc).
:
: I'm aware of template classes, but not the other compile-
: time options you mention. Could you expand a bit?

Just like there is a number of ways to leverage virtual
functions calls in object-oriented programming, as codified
in the GoF's Object-Oriented Design Patters, there are
several idioms for taking advantage of template classes
and template parameters.

Traits classes are used in the STL already (see
char_traits, iterator_traits).
Andrei Alexandrescu has written a lot about policy classes
(see Chapter 1 avail at [url]http://erdani.org/book/main.html)[/url],
which are closely related to the Strategy OODP.
Note that the nomenclature is not as clearly standardized
yet, see maybe for a set of examples:
http://www.boost.org/more/generic_programming.html

Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Marcelo Pinto · Guest

[email]kk_oop (AT) yahoo (DOT) com[/email] escreveu:

kanze · Guest

[email]kk_oop (AT) yahoo (DOT) com[/email] wrote: