Boost Users :
From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-03 12:28:20
dan marsden wrote:
> Why is the fall through behaviour to throw an exception?
I too tripped over this one, yesterday.
I think it shouldn't throw. If we want it to, we can use an approporiate
The 'throw' statement (even if unreachable) can influence other
optimizations. Further, without throwing the semantics remain the same
if exceptions are disabled.
> I'm not too clear with the documentation what the parameter 'n' can be?
"MPL sequence of integer constants" and "equal to" are sorta fuzzy in
this context, too.
Maybe stating that the "[...] the public static member constants 'value'
[...] are used for the 'case' conditions" and that "'n' is used as the
argument to the 'switch' statement" (or so) works to improve the
> The parameter section does not specify the arities of the 2 function
> object parameters, I had to deduce them from the example. Why do these
> have to be function objects, and not just any callable type, including
> ordinary functions (using the Boost.ResultOf mechanism to sort out the
> return type)? I'm not sure how useful that would be for 'f', but for
> 'default_' a full blow function object seems a bit much typing, can't
> I just use a function.
I think "function object" is still the correct term even if you /can/
use a function pointer for the default: A pointer is an object and a
function pointer is a function object. A pointer to member function is
also Callable -- and we probably wouldn't want to support this case...
Of course there are no pointers to templates, so using a function
pointer for anything but the default is pretty pointless. So is trying
to handle varying result types -- maybe the result type should be passed
in with another template parameter?
> Also, why is 'default_' unary, the default in a standard switch
> statement does not access the switch parameter, and the example does
> not exploit this feature either. Why not just a nullary function?
I really like this feature a lot:
If you can't react to some case at compile time doesn't mean you can't
> Again some motivation might be nice.
> And finally, as the introduction mentions the efficiency of the
> standard switch statement, could the docs show some performance
> stats for the library code for comparison?
Couldn't resist to throw some more Euro cents into the pot...
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