Re: [boost] Preprocessor: Nested loops

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2006-02-21 07:41:37

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Martin Bonner

> > The first of these, I use in a different (far more powerful) 
> > preprocessor library.  The problem with this model is that it isn't 
> > portable to broken  preprocessors (which are heavily used 
> by users of 
> > Boost--e.g. VC++).
> > 
> > The second alternative model revolves around automatically deducing 
> > all algorithm states whenever they are needed.
> [snip].
> 
> There is a third model - don't use the C++ preprocessor, but 
> use a more general purpose text transformation tool like M4, 
> or awk/perl/python, or a custom tool written with bison or 
> boost::Spirit.

The first of the alternate models is fine, BTW.  It completely eliminates this
problem.  It is only some popular concrete preprocessors not doing what they
should that prevents it, not the semantics of the abstract preprocessor.

> I'm not knocking the preprocessor library with that 
> suggestion.  An external tool would be no use for a library 
> like boost where it is very difficult to control the 
> compilation system.  Furthermore, the heroics involved in 
> implementing the boost preprocessor library mean that using 
> it is remarkably simple.  
> 
> I just wanted to point out that there is always another option.

Well, it isn't a good option, IMO, even in an in-house project.  A DSEL is
better than a non-embedded DSL (e.g. Spirit compared to YACC) for a variety of
reasons.  It is better to do as much as you can with what you have (i.e. the
language).  External tools for code generation should only be used as a very
last resort.  More important than the introduction of another build step, the
use of external code generators creates a significant barrior to entry and
represents an unbounded number of possible code constructions (that aren't part
of C++) in C++ code.  It comes down to the same reason that a standard
definition of C++ is important--which is not just portability, but portable
understanding.

In any case, the delineated options aren't supposed to a list of all code
generation options--just a list of options for a preprocessor library--and it
isn't even a complete list of those.

Regards,
Paul Mensonides