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