-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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