Boost logo

Boost :

Subject: Re: [boost] review request: addition to type_traits library of has_operator_xxx
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-11-17 15:44:50

On 11/17/2010 12:26 PM, Stewart, Robert wrote:
> Jeffrey Lee Hellrung, Jr. wrote:
>> On 11/17/2010 6:58 AM, Stewart, Robert wrote:
>>> Jeffrey Lee Hellrung, Jr. wrote:
>>>> One thing that I've either found useful is to have an additional
>>>> template parameter in addition to the parameter types and
>>>> the return
>>>> type, which is a Boost.MPL metapredicate intended to be
>>>> applied to the actual result of the operation. The trait then
>>>> evaluates to true only if the actual result type satisfies
>>>> the given Boost.MPL metapredicate.
>>> Perhaps checking for convertible-to-return-type could be
>>> the default predicate rather than adding another template parameter?
>> How do you envision the interface then? Are you suggesting that the
>> convertible-to-return-type type and the Boost.MPL metapredicate occupy
>> the same template parameter?
> Yes
>> To be clear, I'm suggesting something like
>> template< class T0, class T1 = T0, class Result = void,
>> class ResultCond = boost::mpl::always< boost::true_type> >
>> struct is_less_than_comparable;
> I'm thinking something like this:
> template
> <
> class T
> , class U = T
> , class Pred = boost::type_traits::result_converts_to<void>
> struct is_less_than_comparable;
> boost::type_traits::result_converts_to<void> should inherit from boost::true_type, of course.
>> It seems to me that, by far, the common case is checking
>> convertibility to some given type, so I think it makes sense to make
>> the common case syntactically simple.
> is_less_than_comparable<int, int, bool> would become is_less_than_comparable<int, int, result_converts_to<bool> > which is more verbose but also more obvious and indicative of the additional power.

Okay. I don't like the verbosity but it's a minor issue.

>> If you want to avoid the extra template parameter, maybe you can wrap
>> the predicate in something which could be detected in the Result
>> template parameter, e.g.,
> That would be ideal, but I'm not sure there's a satisfying means to do so without imposing too much on the acceptable predicates.

The mechanism I gave doesn't impose anything on the predicate (as far as
I can see). It does exclude return types that are instances of the
wrapper, but I think that is acceptable.

- Jeff

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