Joel de Guzman wrote:
Tobias Schwinger wrote:
Joel de Guzman wrote:
<snip>
http://tinyurl.com/l5bxl (source file in the vault)
Very cool! That might be a good example for a tutorial if you are willing to document and share it.
Sure (that is, for the willingness-part).
I'm not sure whether it qualifies for a good tutorial. There might be better ways to do things (I wanted to get my hands on the library quickly, so I didn't put too much time into planning, plus I still have some questions, below).
Right.
Given that my implementation can not be radically simplified, it might also be too much code for a tutorial. Maybe a linear version for a tutorial and the logarithmic version for an inline-documented source code example would work better...
BTW. implementation improvements, anyone? I'm all ear!
I was contemplating on something like the one you are doing. The inputs are:
1) A runtime value (a primitive integer; e.g. char,int) 2) A tuple of functions 3) A tuple of args (usually tiers)
I was thinking of using the boost preprocessor instead to generate actual switch code. Something like:
<snip code> Yeah, sure - that probably works better in practice, but I would've been a pretty bad one for learning/using Fusion ;-). In contrast to switch/case, however, the toy code I posted uses a decision tree. It depends on the optimizer in use whether switch/case ends up like that. Example: n=3 (2 bits are used for each level in the dispatch id) root seq. / | \ / | \ o o f /|\ /|\ f f f f f f Legend: o: node (no data, it's an external tree) f: function object Adding some more MPL code could make it a compile time huffman coder ;-). Not that I'd have any use for it...
++ A little change, we can use an mpl::vector_c to hold the cases. Something like:
case mpl::at_c<cases, 0>::value : return at_c<0>(dispatch)(args); case mpl::at_c<cases, 1>::value : return at_c<1>(dispatch)(args);
where "cases" is an mpl::vector_c. Such a utility will provide the backbone for 1) Phoenix2's switch_ statement 2) Spirit's switch_p 3) Spirit-2's predictive parsing schemes, and all those stuff that intends to optimize spirit's alternative.
++ Some more code to handle defaults; etc... see Phoenix2 switch and Spirit switch_p for reference.
It might be interesting to compare the full optimized disassembly and performance of: - switch/case - the Fusion-based tree dispatcher - linear Fusion iteration with if/else
... More comments on your post later.
Wow! These were a lot of posts... Thanks, Tobias