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

From: Steven Watanabe (steven_at_[hidden])
Date: 2008-01-09 15:11:34

AMDG

Tobias Schwinger <tschwinger <at> isonews2.com> writes:

> 
> As pointed out in other posts I think the default default case behavior
> should be changed not to throw but to use the default constructor if no
> default case function object is specified.

Will do.

> A default case function object returning 'void' should be assumed (and
> 'assert'ed) not to return in a context where a (non-void) result is
> expected (implementation hint: the built-in comma operator allows void
> arguments and an overloaded comma operator doesn't).

Personally, I'd rather just forbid a default that returns void
when the return type is non-void.  I don't think the comma operator
is a completely fool-proof way to detect void.  It could cause an
ambiguity if the other type also defines an overloaded comma operator.

> As also pointed out and discussed in other posts I'm very much for
> having the result type specified explicitly (as opposed to deducing it
> from the function object).
> 
> >     * What is your evaluation of the implementation?
> 
> Again, I like the simplicity. Keep it this way:
> 
> If "fallthrough cases" are going to be implemented it should be done in
> another template (or should it even be a full-blown Duff loop?).

Fallthrough cases make a lot more sense with a fusion sequence
based interface.

> Another variant of the template taking min/max instead of a sequence
> might be a good idea, as it can make things compile faster in many
> typical use cases (well, that would be half-way a design thing).

I'll consider it.  Provided I can measure a speedup, of course.

> 
> >     * What is your evaluation of the documentation?
> 
> Works for me.
> 
> As mentioned before, the reference could be more detailed at places,
> regarding the equality with MPL constants and the exact types passed to
> the function objects (even if overloading operator() is uncommon - it
> might be occasionally useful to deduce a non-type constant from it).

As Dan Marsden mentioned, I can easily imagine dealing with
special cases such as zero by overloading.

Thanks!

In Christ,
Steven Watanabe