"Vesa Karvonen" <[EMAIL PROTECTED]> writes:
> David Abrahams:
>>FWIW, while in my opinion this is theoretically interesting work,
>
> BTW, the same "acceleration" technique can be used with templates to
> overcome template recursion depth limitations. Probably most people
> know about it already, though I haven't explicitly checked.
> (Plain unrolling is not as effective: Theta(k*n) < Theta(pow(k,n)).)
Well, if I understand your suggestion correctly, it's one thing I
thought of. Basically you're doing "tree unrolling" instead of
"linear unrolling", right? In the TMP case you don't have the
advantage of auto-detecting the depth limit, though ;-)
>>I can't imagine a case where the limit might cause a problem for my
>>code. In other words, the PP library works great for me, and nobody
>>should feel pressure to lift its arbitrary limits on my account.
>
> IMO, it is not a very good argument to say that more powerful tools
> are unnecessary
I am not making that argument. I am just trying to say that I think
the library is already serving its users well. One argument I *would*
make is that if anyone is going to invest more time in it, the
introductory overview Edward Diener wants would make more of a
difference than lifting this limitation.
> , because a specific person (or even a set of persons) does not find
> them useful. It must have been said a million times before and
> probably every time it has been shown to be wrong (in time). A much
> better argument would be that the same effect can be had with only
> minimal overhead compared to the proposed tool with existing tools,
> thus making the proposed tool mostly unnecessary.
But I'm not saying that.
> There are a few good practical reasons why a more powerful WHILE may
> not be very useful. One good reason is that most preprocessors are
> rather slow. This means that even if we could theoretically use the
> preprocessor for non-trivial compile time computation, it may be too
> slow to be practical. Another good reason is that preprocessor code
> is not necessarily very readable, so many interesting things may
> require too much programming time. Essentially,
>
> "Why program by hand in 5 days what you can spend 5 years of your life automating?"
>-- Terence Parr
>
> (, but with the opposite conclusion.)
Well, yeah. However, I think for some things the *usage* of that code
can be more readable than TMP. Your state machine below is one
good example.
> However, I think that there are many useful things that could
> potentially be done using the preprocessor if the arbitrary limits
> on iteration would be removed and performance would be
> acceptable. Consider, for example, the state machine example of the
> MPL paper. A state machine generator using template metaprogramming
> techniques is essentially limited to having to specify functions as
> the actions. This can be partially circumvented by using a lambda
> library, but the solution is not perfect.
No, not hardly.
> A distinct possibility would be to use the preprocessor to generate
> the transition function. What makes this interesting is that then we
> could pass in straight C++ blocks as actions.
Ever thought about writing Yacc with just the preprocessor (<wink>, I
think)?
> Consider the following pseudo-code snippet, which is a start of the
<snip>
Nice.
> Similar things can certainly be done with various templates
> techniques. However, when it comes to passing arbitrary C++ code to
> the generator, preprocessor macros have certain advantages.
Lots.
> Now, the above example can probably be done without a more powerful
> WHILE, but many generators / mini compilers may do substantially
> more computation. Theoretically, the preprocessor could be used for
> making a parser generator
I guess you have thought about making Yacc. You're a few steps ahead
of me, friend.
> that could have an advantage compared to Spirit due to syntactical
> issues. The main practical problems would be the difficult of
> implementation and compile-time performance (which is exactly the
> same as with template techniques, but often worse).
Yep.
> Another possible direction for program generators would be to take a
> middle road: use preprocessor to define the input syntax and
> generate code skeleton (switch case statement), then use template
> metaprogramming or even run-time code to compute the transition
> tables. This kind of an approach would make it possible to get a
> very nice syntax for specifying many kinds of program generators
> (and in many cases the overhead of transition table generation is
> not important).
To be sure, the world of C++ metaprogramming is vast and mostly
unexplored.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
