Re: [Boost-users] upcoming Switch library review Jan 5th - Jan 9th
Stjepan Rajko wrote:
If you are interested, please consider submitting a review of this library. I will send more detailed instructions on what to include in the review on the 5th.
Can I jump the gun with with a few questions please? Why is the fall through behaviour to throw an exception? This is not consistent with standard switch, possibly a motivation section is needed in the docs to explain this type of decision? I'm not too clear with the documentation what the parameter 'n' can be? It is of type 'Int' which is described as being an Integer in the parameters section of the documentation. What does this mean, any built in integral type, can I switch on a std::string? What are the limitations? I got a bit lost here in the docs here, after admittedly only a quick read. Maybe just some clarification is required? 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. 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? 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? Cheers Dan ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/
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
AMDG Tobias Schwinger <tschwinger <at> isonews2.com> writes:
dan marsden wrote:
Why is the fall through behaviour to throw an exception?
I too tripped over this one, yesterday.
<snip>
The other option is an assertion. Is that any better? Or should a void return type be a special case?
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.
<snip>
OK. I'll tighten this up.
The parameter section does not specify the arities of the 2 function object parameters, I had to deduce them from the example.
I'll be more precise.
Why do these have to be function objects, and not just any callable type, including ordinary functions <snip>
You can use a plain function for default_.
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...
Even if it's specified as Callable, it's ok because void int::*() e.g. is illegal anyway.
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?
I'd rather leave it as result_of<F()>::type.
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...
Exactly.
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!
Will do. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Tobias Schwinger <tschwinger <at> isonews2.com> writes:
dan marsden wrote:
Why is the fall through behaviour to throw an exception? I too tripped over this one, yesterday.
<snip>
The other option is an assertion. Is that any better?
I think the "default default behavior" should be to use the default constructor. This approach works nice with Any, Variant and Optional.
Or should a void return type be a special case?
If 'Default's result type is 'void' although something else is expected, we should assert it never actually returns at runtime (note that it is possible to detect the result type with an overloaded comma operator and without requiring 'Default' to work with 'result_of' -- might also be faster). If assertions are disabled the behavior should be unspecified in that case. <snip>
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?
I'd rather leave it as result_of<F()>::type.
Actually 'result_of<F()>::type' determines the result of the nullary call to F. I don't think I like this sort of "result_of abuse"... The correct usage would be 'result_of<F(MPLConstant)>::type' but it's pointless since 'MPLConstant' varies and so may the whole type expression. So, if you insist on deducing the result type from the function object (instead of having it specified explicitly) my vote is 'F::result_type', however, I still find another template parameter more appropriate for the following good reasons: o The function object can work fine with result_of in a non-'switch_' context. The cases can return different things as long as they are convertible to the result of 'switch_', and o there is no way to determine this type with 'result_of. Regards, Tobias
On Jan 2, 2008 2:36 PM, dan marsden <danmarsden@yahoo.co.uk> wrote:
Stjepan Rajko wrote:
If you are interested, please consider submitting a review of this library. I will send more detailed instructions on what to include in the review on the 5th.
Can I jump the gun with with a few questions please?
Of course - thanks for opening up the discussion! I'm just not sure whether Steven will be able to respond until the review officially starts.
Why is the fall through behaviour to throw an exception? This is not consistent with standard switch, possibly a motivation section is needed in the docs to explain this type of decision?
I'm not too clear with the documentation what the parameter 'n' can be? It is of type 'Int' which is described as being an Integer in the parameters section of the documentation. What does this mean, any built in integral type, can I switch on a std::string? What are the limitations? I got a bit lost here in the docs here, after admittedly only a quick read. Maybe just some clarification is required?
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.
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? 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?
Cheers
Dan
Stjepan
participants (1)
-
dan marsden -
Steven Watanabe -
Stjepan Rajko -
Tobias Schwinger