Boost logo

Boost :

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-01-08 12:46:59


"Stjepan Rajko" <stipe_at_[hidden]> wrote:
>> In case of the former it's a minor concern to just pass in that type.
>> I'm pretty sure the resulting client code will read clearer (that is
>> without having to dig up the docs).

IMO, the whole thing is a minor concern. I don't expect people to use
general purpose function objects with switch_. (It has to take MPL integral
constant wrappers and sort out what to do using some kind of
Thus, it's just a matter of specifying the return type inside the
function object or
specifying it at the call site. The use of result_type is not exactly
unprecedented... The name
result_type seems more self explanatory to me than a bare template

>> The latter seems to me as a misguided approach that encourages users
>> to mess up the result type computation of their function objects.
I beg your pardon? I don't understand.

>> I disagree. Good code is self-explanatory. Good libraries encourage good
>> style. Weird stuff stays weird and documenting it doesn't change it ;-).
>> Maybe I'm just blind - but I see absolutely no benefit from attempting
>> to deduce the result type over having the result type specified by the
>> user.

I think you're overstating your case. Requiring a function object to
have a unique
return type specified by the nested typedef result_type is hardly weird.

> I don't think you're blind - for the most part, I'm just throwing out
> possible viewpoints to see if anyone else sees any validity behind
> them, and to know what to recommend at the end of the review. Thank
> you for providing great arguments for your view - unless the author or
> other reviewers feel strongly otherwise it seems like the most
> reasonable way to go (and thanks to Joel for joining the discussion!).

Agreed. I don't have a strong opinion on this point.

In Christ,
Steven Watanabe

Boost list run by bdawes at, gregod at, cpdaniel at, john at