Boost logo

Boost Users :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-09 08:55:46


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 think it should probably be a part of MPL. It would fit perfectly next
to 'mpl::for_each' -- 'mpl::for_petrified_constant' or so :).

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.
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).

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?).

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).

> * 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).

> * What is your evaluation of the potential usefulness of the library?

The implemented functionality is a must-have for metaprogram-driven code
generation.

> * Did you try to use the library?

Not yet.

> * How much effort did you put into your evaluation? A glance? A
> quick reading? In-depth study?

Doc reading & discussion.

> * Are you knowledgeable about the problem domain?

Yes.

>
> * Do you think the library should be accepted as a Boost library?
> Be sure to say this explicitly so that your other comments don't
> obscure your overall opinion.

Yes, given that handling of the default and the result type is changed
as discussed in the design section of this review (or someone makes me
change my mind by bringing up even better approaches :) ).

Regards,
Tobias


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net