Re: [Boost-users] formal review of Switch library ends tomorrow (Wednesday, January 9th) - reviews needed

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-09 16:39:07

Joel de Guzman wrote:
> Tobias Schwinger wrote:
>> Stjepan Rajko wrote:
>>>     * What is your evaluation of the design?
>> I very much like the simplicity.
>>
>> I'm not sure it really suits the name 'switch_', as I'd expect something
>> syntactically different (something like Joel sketched out in his review,
>> and with some argument forwarding), however, I think it's an important
>> building block that should be kept as simple as possible.
> 
> I can assure you that my suggestion is "as simple as possible, but
> not simpler" ;-) Simpler than that is simply not usable to me.
> I know. I've been there many times. I have real world use cases
> for this thing. Switch is not simple. Let's not pretend it is.

My point is that the utility we have here is in fact too different from 
phoenix::switch_ to compare the two (and that boost::switch_ is not the 
best name):

What would be the point in phoenix::switch_ if it wasn't lazy?

As Steven pointed out, overloading operator() (which is roughly what you 
propose - just using an uglier syntax) is a rare use case. Usually we'll 
want to feed the index to some metaprogramming machinery and instantiate 
several high-speed dispatched control paths.
This utility is about generating the machine code of 'switch'. It does 
not necessarily have to mimic it's syntax!

> Here's an acid test for the API -- try to implement my suggested
> syntax on top of the "simple" API. You'll soon realize that you
> can't 

No?! Here is how it's done:

o  Use fusion::unfused or wire up some operators to build a fusion::map 
of constant / function object pairs, and

o  create a function object from that map that looks up the appropriate 
function object in the map and calls it (if we want it to be non-lazily 
evaluated) or returns it (otherwise) and is fed to 'switch_'.

Please note that the reverse requires indeed to repeat the PP code.
Also note that it would also work to implement the variant visitor.

Also also note that the 'switch_' name is obviously confusing :-).

> It's not a suitable building block, like say, mpl::for_each.

No, but it fits perfectly well into the same category.

Regards,
Tobias