From: Stjepan Rajko (stipe_at_[hidden])
Date: 2008-01-12 13:42:37
On Jan 12, 2008 8:25 AM, Mathias Gaunard <mathias.gaunard_at_[hidden]> wrote:
> 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.
An assert was considered as well - e.g., see:
This behavior is also analogous to the standard switch statement - if
the default label is omitted, and none of the cases is matched, no
> > 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.
Under the right details, yes:
Tobias offered formal transforms between the two:
> An utility which converts B to A would be quite useful though, even
> outside of boost.switch.
Thanks for your comments!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk