From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-05-12 19:02:27
Joel de Guzman wrote:
> Tobias Schwinger wrote:
>>Joel de Guzman wrote:
>>>>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).
>>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:
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)
/ | \
/ | \
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:
- the Fusion-based tree dispatcher
- linear Fusion iteration with if/else
> ... More comments on your post later.
Wow! These were a lot of posts...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk