Re: [boost] Preprocessor: Nested loops
From: Paul Mensonides
All of this is the status quo of the library. There are two other models that are superior in terms of ease of use and avoidance of these types of issues.
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. 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. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894
-----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
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Paul Mensonides
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.
This reminds me, BTW, of the "intentional programming" paradigm. The really powerful part of that paradigm is that you can do anything--i.e. even with the syntax itself. The really problematic part of that paradigm is that you can do anything--i.e. even with the syntax itself. IOW, it becomes a collection of anything and everything all thrown together--there is no coherent language, just a language system. One of the benefits of a more finite language is that the set of semantics is also finite--and that really is a good thing overall (despite how often we may beat are heads against it). Regards, Paul Mensonides
"Martin Bonner" <martin.bonner@pitechnology.com> writes:
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.
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.
Some of use started out using that option and after finding it to be inferior in a number of ways, switched to using the preprocessor library. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
Martin Bonner -
Paul Mensonides