From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-06 09:34:40
Forwarding this post from boost.user...
Steven Watanabe wrote:
> 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.
> 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.
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk