Stjepan Rajko wrote:
* Default default behavior
Alexander Nasonov has also indicated that a throwing default case can cause inefficiency, even when it is guaranteed not to be invoked.
Wouldn't an assert be more suited then? If default behaviour is unspecified and yet invoked, terminating sounds like a good thing to do.
There has been a lengthy discussion on the underlying design of the library, what it should offer, and whether the name of the library is appropriate. There are two types of designs that have been put forward as being appropriate and/or necessary for a Boost.Switch library. On one hand, there is the submitted design (labeled "A" in recent postings), which takes the switch cases in an MPL sequence and a single function object containing implementations of all cases. Joel de Guzman has proposed another design (labeled "B"), in which the switch cases are specified separately and allow a different function to be used for each case.
It seems to me that B is convertible to A... There would be no need to duplicate the interface then. An utility which converts B to A would be quite useful though, even outside of boost.switch.