[En-Nut-Discussion] Using boost::preprocessor (preprocessor metaprogramming)

[Thiago A. Corrêa]

On Wed, Feb 11, 2009 at 3:19 AM, Henrik Maier <hmnews at proconx.com> wrote:
> Thank you Thiago!
>
> Well, I certainly can see the benefit. In particular I had it several times
> that I introduced the classic copy and paste error by copying code for
> device1 to device2 and then forgot to renumber some variables or
> definitions. With the boost::preprocessor macros that would be a matter of
> the past. It also follows the DRY principle
> (http://en.wikipedia.org/wiki/Don%27t_repeat_yourself).

It's a bit hard to explain, but once you see the concept, and face a
problem where it is the only solution, it's sort of evident.
I don't expect this to be widely used. At least it should be seen as a
last resort to avoid duplicated code.

Since I found it usefull for my application, and now, quite sometime
later, I'm finding it usefull to supporting avr32, I thought having it
in ethernut could be a good idea.

> The only concern I have is that Nut/OS contributors have to learn
> boost::preprocessor, which could impose a potential hurdle for people
> willing to contribute or change code.

As mentioned, I sure don't expect it to be so widely used inside
ethernut that would be a problem to contributers. At the very least,
ppl would still be able to do write code the old way, with manual copy
and paste.
This is really a solution to a ninche problem.

> The other issue would be debugability.

Yes, most debuggers can't expand the macros. But they can follow the
execution, and when entering a function, most of the time one can see
from the arguments of functions what happened. But then, if not widely
used shouldn't be a problem.
It should not cause mismatching line numbers between the debug and the
source, since compilers add line number information when it expands
macros and includes.

My other main concern is those compilers that only produce embedded
code, such as ICC(AVR | ARM), EIR, etc.
I don't know if they have any quirks with their preprocessors that
could make boost::preprocessor not to work on them.
I can tell it works great on gcc, but I don't have access to those
other compilers to test on them.

Kind Regards,
    Thiago A. Correa