[En-Nut-Discussion] Using boost::preprocessor (preprocessor metaprogramming)
Harald Kipp
harald.kipp at egnite.de
Fri Feb 13 13:31:39 CET 2009
Hi Thiago,
I'm quite busy adding and testing new debug capabilities for Nut/OS. I'm
telling this to explain, that I may not have read this thread with
sufficient thoughtfulness. More infos about the new features will be
published later.
Other topics had been discussed in this thread as well, like repeating
port configurations. I'm responsible for such weirdness and will try to
respond to these topics separately.
The C programming language, including its preprocessor, is a complicated
beast. It typically takes 3-6 months to become familiar with, let's say,
90% of its capabilities. It may take at least another 1-2 years to
develop a low level of virtuosity. I'm mainly using C as a programming
language for more than 10 years and I'm still discovering new and better
ways to get things done.
Eons ago I did a lot of programming with Z80 assembler. Assembly
languages typically provide much more powerful macros than C
preprocessors. I remember, that one of my most advanced constructions
was a single macro, which expands to the complete CP/M BIOS
initialization code. An impressive experience was, that 2 years after
creating it, I was totally unable to add an enhancement to this macro.
It finally took less time to disassemble the macro into "normal" code
than trying to understand how it works.
As I said, this impressed me a lot and I remember several occasions in
later years, where I unassembled similar constructs in other programming
languages just to make them "more readable", in my personal view. I
never felt comfortable with C++ templates, probably because of the same
reason. I'm highly prejudiced in these things.
While C is the daily job for many of us, boost::preprocessor is not. It
will not only add another dependency, as Duane mentioned. It will also
add another level of complexity. I understood the advantages, but do not
think that they outweigh the cons.
About other compilers: ImageCraft moved to a new pre-processor lately,
which may be able to provide sufficient power for boost::preprocessor
and we are thinking about dropping support for ICCv6 and stick with
ICCv7. Btw. egnite has almost no commercial benefit when supporting
ImageCraft compilers. It is often a burden and, after Richard is
developing his own RTOS/TCP, users may prefer to completely switch to
his environment. Beside all the frustration (awful CONST and INLINE
macros), I learned, that it is a good exercise to have a second compiler
and to make sure, that Nut/OS will not become too GCC dependent.
Harald
P.S. Wondering, whether in 10 years I will laugh about the crap I wrote
above.
P.P.S.
http://www.ethernut.de/en/documents/programming-style-guide.html
contains a link to '#ifdef Considered Harmful'.
More information about the En-Nut-Discussion
mailing list