Tobias Schwinger wrote:
Here's another one:
Say we have a bunch of (generic) Strategies and an Algorithm template.
Now we want to choose the an Algorithm instantiation (that is, an Algorithm template specialized with a Strategy) at some entry point.
We don't want dynamic calls and we want everything after the initial dispatch to be inlined.
Does this sound familiar? Right we just have to substitute "Strategies" with "Scanners" and Algorithm with "RD Parser" and "some entry point" with "Rule" and we're talking about Spirit's Multi Scanner Support.
A scalable solution on top of Fusion and Switch will be almost trivial.
That's why I'm very interested with switch_. I'm well aware of the possibilities :) I have a lot more use cases. How about static first-follow prediction :P I don't think we have a disagreement on usefulness.
Also also note that the 'switch_' name is obviously confusing :-).
... (which I think should be called differently) selective cascading.
I disagree. I don't see any reason why we have to invent another mechanism when we can borrow the ideas from a well tested scheme: the native switch, albeit in a more FP flavor. It does not stop there. At the machine level, a switch is properly implemented as a perfect hash of N vs N functions. It is also very possible to have the N functions in a dynamic runtime container and dispatch with the speed of a switch. I did some experiments on this sometime ago and posted to this list along with some timings. We could actually get the speed of switch at runtime by computing, before hand, the perfect hashes. With some compilers, I recall even surpassing the switch speed (yes: http://lists.boost.org/Archives/boost/2004/08/69787.php) A switch_ library is crucial -- one that I would not take lightly with a half-baked solution. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net