Re: [Boost-users] upcoming Switch library review Jan 5th - Jan 9th

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 
  function object.

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

> 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 
at runtime...

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

Yes, please!

Couldn't resist to throw some more Euro cents into the pot...

Regards,
Tobias