review request: addition to type_traits library of has_operator_xxx

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

review request: addition to type_traits library of has_operator_xxx

Frédéric Bron
I would like to propose to your review the following addition to the
type_traits library, available at the following addresses:
    https://svn.boost.org/trac/boost/browser/sandbox/type_traits
    http://dl.free.fr/lRm4VL6WP/type_traits.tar.bz2

The purpose of the addition is to add type traits to detect if unary
and binary operators can be applied to given types.
For example, is "x<y" or "!x" or "x+y" meaningful?
If required, the return type of such an expression is checked to know
if it is convertible to a given type.
Default behaviour is to not check the return type.

The following traits are added:

// binary operators:
template < typename LHS, typename RHS=LHS, typename RET=void >
    == has_operator_equal_to
    != has_operator_not_equal_to
    >  has_operator_greater
    >= has_operator_greater_equal
    <  has_operator_less
    <= has_operator_less_equal
    +  has_operator_plus
    -  has_operator_minus
    *  has_operator_multiplies
    /  has_operator_divides
    %  has_operator_modulus
    && has_operator_logical_and
    || has_operator_logical_or
    &  has_operator_bit_and
    |  has_operator_bit_or
    ^  has_operator_bit_xor

// unary operators:
template < typename RHS, typename RET=void >
    +  has_operator_unary_plus
    -  has_operator_unary_minus
    !  has_operator_logical_not

This new version reflects the discussions we had on the list:
http://thread.gmane.org/gmane.comp.lib.boost.devel/194625
In particular about the check or not of the return type.
All operators are now included and not only comparison binary operators.

Example:

    has_operator_less<LHS, RHS, RET>::value_type is the type bool.
    has_operator_less<int> inherits from true_type.
    has_operator_less<int, int, std::string> inherits from false_type.
    has_operator_unary_minus<int, long> inherits from true_type.
    has_operator_unary_minus<double, int> inherits from true_type.
    has_operator_unary_minus<int, std::string> inherits from false_type.

Documentation is accessible at libs/type_traits/doc/html/index.html in
the archive.

Regards,

Frédéric

PS: tested with g++ 4.4.5 on i686-linux.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Jeffrey Lee Hellrung, Jr.
On 11/16/2010 03:49 PM, Frédéric Bron wrote:

> I would like to propose to your review the following addition to the
> type_traits library, available at the following addresses:
>      https://svn.boost.org/trac/boost/browser/sandbox/type_traits
>      http://dl.free.fr/lRm4VL6WP/type_traits.tar.bz2
>
> The purpose of the addition is to add type traits to detect if unary
> and binary operators can be applied to given types.
> For example, is "x<y" or "!x" or "x+y" meaningful?
> If required, the return type of such an expression is checked to know
> if it is convertible to a given type.
> Default behaviour is to not check the return type.
[...]

I think several people who follow this list (myself included) have
implementations of such traits lying around, so it makes sense to union
the best parts of each one.  I will take a look at your implementation
and see if I have any suggestions.

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.
This covers the cases where you may want to know more about the result
type than whether it is convertible to some given type.  For example,
for the comparison operators, you may want to check if the result type
of a particular comparison is *precisely* bool, rather than just
convertible bool (that might be a rather contrived example, and if you
don't believe this has a real use, I can (probably) come up with more
real-world examples).  It should be easy to support, it won't complicate
existing use, and I believe it does provide some additional desirable
flexibility.

- Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Edward Diener-3
In reply to this post by Frédéric Bron
On 11/16/2010 6:49 PM, Frédéric Bron wrote:

> I would like to propose to your review the following addition to the
> type_traits library, available at the following addresses:
>      https://svn.boost.org/trac/boost/browser/sandbox/type_traits
>      http://dl.free.fr/lRm4VL6WP/type_traits.tar.bz2
>
> The purpose of the addition is to add type traits to detect if unary
> and binary operators can be applied to given types.
> For example, is "x<y" or "!x" or "x+y" meaningful?
> If required, the return type of such an expression is checked to know
> if it is convertible to a given type.
> Default behaviour is to not check the return type.
>
> The following traits are added:
>
> // binary operators:
> template<  typename LHS, typename RHS=LHS, typename RET=void>
>      == has_operator_equal_to
>      != has_operator_not_equal_to
>      >   has_operator_greater
>      >= has_operator_greater_equal
>      <   has_operator_less
>      <= has_operator_less_equal
>      +  has_operator_plus
>      -  has_operator_minus
>      *  has_operator_multiplies
>      /  has_operator_divides
>      %  has_operator_modulus
>      &&  has_operator_logical_and
>      || has_operator_logical_or
>      &   has_operator_bit_and
>      |  has_operator_bit_or
>      ^  has_operator_bit_xor
>
> // unary operators:
> template<  typename RHS, typename RET=void>
>      +  has_operator_unary_plus
>      -  has_operator_unary_minus
>      !  has_operator_logical_not
>
> This new version reflects the discussions we had on the list:
> http://thread.gmane.org/gmane.comp.lib.boost.devel/194625
> In particular about the check or not of the return type.
> All operators are now included and not only comparison binary operators.
>
> Example:
>
>      has_operator_less<LHS, RHS, RET>::value_type is the type bool.
>      has_operator_less<int>  inherits from true_type.
>      has_operator_less<int, int, std::string>  inherits from false_type.
>      has_operator_unary_minus<int, long>  inherits from true_type.
>      has_operator_unary_minus<double, int>  inherits from true_type.
>      has_operator_unary_minus<int, std::string>  inherits from false_type.
>
> Documentation is accessible at libs/type_traits/doc/html/index.html in
> the archive.

Bravo !

I would very much like to see this happen also, as I can use this
functionality in another library I would like to put in the sandbox.

Without trying to make more work along your lines, would it be easy
enough for you to add the left shift ( << ) and right shift ( >> )
binary operators, and/or the incrementable ( ++x and x++ ) and
decrementable ( --x and x-- ) unary operators, or are any of these
especially different or much more difficult cases ?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Alexander Fokin
Nice work!

As far as I can see, your implementation suffers the same problem as
all other techniques for detection of operator / member function
presence. It causes compilation error in case the operator in question
is private. I believe this should be pointed out in the docs.

And another question. Why are you using your own implementation of
is_convertible instead of the one supplied by boost?

--
Best regards,
  Alaxander Fokin, [hidden email].
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Stewart, Robert
In reply to this post by Jeffrey Lee Hellrung, Jr.
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?

_____
Rob Stewart                           [hidden email]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Jeffrey Lee Hellrung, Jr.
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?

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;

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.

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

template< class P > struct operator_predicate;

and then specialize is_less_than_comparable for that wrapper, so that
the whole thing is

template< class T0, class T1 = T0, class Result = void >
struct is_less_than_comparable { ... };

template< class T0, class T1, class P >
struct is_less_than_comparable< T0, T1, operator_predicate<P> > { ... };

Is this kind of what you had in mind?  I personally prefer adding an
extra template parameter.

- Jeff
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library ofhas_operator_xxx

Vicente Botet
In reply to this post by Edward Diener-3
----- Original Message -----
From: "Edward Diener" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, November 17, 2010 1:29 AM
Subject: Re: [boost] review request: addition to type_traits library ofhas_operator_xxx


On 11/16/2010 6:49 PM, Frédéric Bron wrote:

> I would like to propose to your review the following addition to the
> type_traits library, available at the following addresses:
>      https://svn.boost.org/trac/boost/browser/sandbox/type_traits
>      http://dl.free.fr/lRm4VL6WP/type_traits.tar.bz2
>
> The purpose of the addition is to add type traits to detect if unary
> and binary operators can be applied to given types.
> For example, is "x<y" or "!x" or "x+y" meaningful?
> If required, the return type of such an expression is checked to know
> if it is convertible to a given type.
> Default behaviour is to not check the return type.
>
> The following traits are added:
>
> // binary operators:
> template<  typename LHS, typename RHS=LHS, typename RET=void>
>      == has_operator_equal_to
>      != has_operator_not_equal_to
>      >   has_operator_greater
>      >= has_operator_greater_equal
>      <   has_operator_less
>      <= has_operator_less_equal
>      +  has_operator_plus
>      -  has_operator_minus
>      *  has_operator_multiplies
>      /  has_operator_divides
>      %  has_operator_modulus
>      &&  has_operator_logical_and
>      || has_operator_logical_or
>      &   has_operator_bit_and
>      |  has_operator_bit_or
>      ^  has_operator_bit_xor
>
> // unary operators:
> template<  typename RHS, typename RET=void>
>      +  has_operator_unary_plus
>      -  has_operator_unary_minus
>      !  has_operator_logical_not
>
> This new version reflects the discussions we had on the list:
> http://thread.gmane.org/gmane.comp.lib.boost.devel/194625
> In particular about the check or not of the return type.
> All operators are now included and not only comparison binary operators.
>
> Example:
>
>      has_operator_less<LHS, RHS, RET>::value_type is the type bool.
>      has_operator_less<int>  inherits from true_type.
>      has_operator_less<int, int, std::string>  inherits from false_type.
>      has_operator_unary_minus<int, long>  inherits from true_type.
>      has_operator_unary_minus<double, int>  inherits from true_type.
>      has_operator_unary_minus<int, std::string>  inherits from false_type.
>
> Documentation is accessible at libs/type_traits/doc/html/index.html in
> the archive.

Bravo !

I would very much like to see this happen also, as I can use this
functionality in another library I would like to put in the sandbox.

Without trying to make more work along your lines, would it be easy
enough for you to add the left shift ( << ) and right shift ( >> )
binary operators, and/or the incrementable ( ++x and x++ ) and
decrementable ( --x and x-- ) unary operators, or are any of these
especially different or much more difficult cases ?

_______________________________________________


Hi,

Thanks for pushing these long expected traits.

I would expect all the C++ operators to be covered as ConceptTraits/OperatorTrats did. Next follows an extract from the documentation of this library for the missing operators. BTW, where are the new extensions documented, could you give a link?

::boost::has_address_of_op<T>::value
Evaluates to true if the expression &a is valid.

::boost::has_dereference_op<T>::value

Evaluates to true if the expression *a is valid.

::boost::has_member_access_op<T>::value

Evaluates to true if the expression a-><member> is valid.

The member access operator has to be a member function, so it can only be detected for classes and unions by specialising this trait. It gives default true for these.

::boost::has_subscript_op<T1 [,T2]>::value

Evaluates to true if the expression a[b] is valid.

The subscript operator has to be a member function, so it can only be detected for classes and unions by specialising this trait. It gives default true for these.

::boost::has_pointer_to_member_op<T1 [,T2]>::value

Evaluates to true if the expression a->*b is valid.

The pointer to member operator has to be a member function, so it can only be detected for classes and unions by specialising this trait. It gives default true for these.

::boost::has_comma_op<T1 [,T2]>::value

Evaluates to true if the expression a,b is valid.

::boost::has_function_call_op<T,R [,P1, ...]>::value

Evaluates to true if the expression
R r = a(p1 [, ...]) is valid.

The function call operator has to be a member function, so it can only be detected for classes and unions by specialising this trait. It gives default true for these.

Best,

Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Frédéric Bron
In reply to this post by Jeffrey Lee Hellrung, Jr.
> 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.

This would make type_traits library depend on the MPL library. Is it desirable?

Frédéric
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Frédéric Bron
In reply to this post by Edward Diener-3
> Without trying to make more work along your lines, would it be easy enough
> for you to add the left shift ( << ) and right shift ( >> ) binary
> operators, and/or the incrementable ( ++x and x++ ) and decrementable ( --x
> and x-- ) unary operators, or are any of these especially different or much
> more difficult cases ?

Surely << and >> are totally similar and I will add them.
Prefix ++ and -- should work just fine also.
Postfix ++ and -- need special care due to the additionnal int but
this should be rather straitforward.
What about +=, -=, *=, /=?

Frédéric
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library ofhas_operator_xxx

Stewart, Robert
In reply to this post by Vicente Botet
vicente.botet wrote:

> From: "Edward Diener" <[hidden email]>
> On 11/16/2010 6:49 PM, Frédéric Bron wrote:
> >
> > // binary operators:
> > template<  typename LHS, typename RHS=LHS, typename RET=void>
> >      == has_operator_equal_to
> >      != has_operator_not_equal_to
> >      >   has_operator_greater
> >      >= has_operator_greater_equal
> >      <   has_operator_less
> >      <= has_operator_less_equal
> >      +  has_operator_plus
> >      -  has_operator_minus
> >      *  has_operator_multiplies
> >      /  has_operator_divides
> >      %  has_operator_modulus
> >      &&  has_operator_logical_and
> >      || has_operator_logical_or
> >      &   has_operator_bit_and
> >      |  has_operator_bit_or
> >      ^  has_operator_bit_xor
> >
> > // unary operators:
> > template<  typename RHS, typename RET=void>
> >      +  has_operator_unary_plus
> >      -  has_operator_unary_minus
> >      !  has_operator_logical_not

Those names are not consistent with boost::has_new_operator.  That is, you need to rename them like the following for consistency:

   s/has_operator_\(.+\)/has_\1_operator/

The result won't be perfect.  For example, "has_operator_divides" should be renamed "has_division_operator."

Renaming "has_new_operator" seems more appropriate, however.  "has_operator_new" puts "operator" and "new" in the right order as the query is for operator new, not the new operator.

> ::boost::has_address_of_op<T>::value
> Evaluates to true if the expression &a is valid.

"has_operator_address_of" is more consistent with the above list, but "has_address_of_operator" is more consistent with boost::has_new_operator.

The same discussion applies to the other traits.

> ::boost::has_member_access_op<T>::value
>
> Evaluates to true if the expression a-><member> is valid.

That's called the member selection operator, so "has_member_selection_operator."

> The member access operator has to be a member function, so it
> can only be detected for classes and unions by specialising
> this trait. It gives default true for these.

Why would the default be true?  I'd expect the default to be false so only those classes for which a specialization is provided which may evaluate to true.  (The only reason to specialize the trait, then, is for classes that define the operator.)

The same question applies to the other traits that default to true.

_____
Rob Stewart                           [hidden email]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Frédéric Bron
In reply to this post by Alexander Fokin
> It causes compilation error in case the operator in question
> is private. I believe this should be pointed out in the docs.

Good point, this will be added to the doc.

> And another question. Why are you using your own implementation of
> is_convertible instead of the one supplied by boost?

I must try is_convertible. Not sure it handles correctly an operator
that returns void.

Frédéric
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library ofhas_operator_xxx

Frédéric Bron
In reply to this post by Vicente Botet
> I would expect all the C++ operators to be covered as ConceptTraits/OperatorTrats did. Next follows an extract from the documentation of this library for the missing operators.
> ::boost::has_address_of_op<T>::value
> ::boost::has_dereference_op<T>::value
> ::boost::has_member_access_op<T>::value
> ::boost::has_subscript_op<T1 [,T2]>::value
> ::boost::has_pointer_to_member_op<T1 [,T2]>::value
> ::boost::has_comma_op<T1 [,T2]>::value
> ::boost::has_function_call_op<T,R [,P1, ...]>::value

Not sure I am able to add all of them. &, * look rather similar to
unary operator I added.

> BTW, where are the new extensions documented, could you give a link?

Documentation is accessible at libs/type_traits/doc/html/index.html in
the archive or in the sandbox.

Frédéric
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Stewart, Robert
In reply to this post by Jeffrey Lee Hellrung, Jr.
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.

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

_____
Rob Stewart                           [hidden email]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library ofhas_operator_xxx

Frédéric Bron
In reply to this post by Stewart, Robert
> Those names are not consistent with boost::has_new_operator.  That is, you need to rename them like the following for consistency:
>
>   s/has_operator_\(.+\)/has_\1_operator/
>
> The result won't be perfect.  For example, "has_operator_divides" should be renamed "has_division_operator."
>
> Renaming "has_new_operator" seems more appropriate, however.  "has_operator_new" puts "operator" and "new" in the right order as the query is for operator new, not the new operator.
>
> The same discussion applies to the other traits.

The question of naming has already been discussed here :
http://thread.gmane.org/gmane.comp.lib.boost.devel/194625
At that time, we preferred has_operator_xxx to has_xxx_operator.
I agree that the whole type_traits library would need more consistency
but this would break existing code.
If this is not an issue, renaming should be rather straitforward
providing we can all agree on new names.

Frédéric
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library ofhas_operator_xxx

Vicente Botet
In reply to this post by Frédéric Bron
----- Original Message -----
From: "Frédéric Bron" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, November 17, 2010 9:02 PM
Subject: Re: [boost] review request: addition to type_traits library ofhas_operator_xxx


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

This would make type_traits library depend on the MPL library. Is it desirable?

Frédéric
_______________________________________________

I don't see the problem, as it depends already.

Vicente
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library ofhas_operator_xxx

Vicente Botet
In reply to this post by Frédéric Bron
----- Original Message -----
From: "Frédéric Bron" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, November 17, 2010 9:12 PM
Subject: Re: [boost] review request: addition to type_traits library ofhas_operator_xxx


Surely << and >> are totally similar and I will add them.
Prefix ++ and -- should work just fine also.
Postfix ++ and -- need special care due to the additionnal int but
this should be rather straitforward.
What about +=, -=, *=, /=?

Frédéric
_______________________________________________

Yes, please, add all of them. See my other post.

Vicente
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Jeffrey Lee Hellrung, Jr.
In reply to this post by Stewart, Robert
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits libraryofhas_operator_xxx

Vicente Botet
In reply to this post by Frédéric Bron
----- Original Message -----
From: "Frédéric Bron" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, November 17, 2010 9:23 PM
Subject: Re: [boost] review request: addition to type_traits libraryofhas_operator_xxx



> I would expect all the C++ operators to be covered as ConceptTraits/OperatorTrats did. Next follows an extract from the documentation of this library for the missing operators.
> ::boost::has_address_of_op<T>::value
> ::boost::has_dereference_op<T>::value
> ::boost::has_member_access_op<T>::value
> ::boost::has_subscript_op<T1 [,T2]>::value
> ::boost::has_pointer_to_member_op<T1 [,T2]>::value
> ::boost::has_comma_op<T1 [,T2]>::value
> ::boost::has_function_call_op<T,R [,P1, ...]>::value

Not sure I am able to add all of them. &, * look rather similar to
unary operator I added.

> BTW, where are the new extensions documented, could you give a link?

Documentation is accessible at libs/type_traits/doc/html/index.html in
the archive or in the sandbox.

Frédéric
_______________________________________________

It will be a shame if some operators, for which the trait can be defined, dont have it. Have you take a look to ConceptTraits? Maybe you can adapt the implementation?

Oh I see them now on the reference documentation. I was looking for a section that explains the motivation and the list of new traits that need to be reveiwed.

Vicente
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library ofhas_operator_xxx

Stewart, Robert
In reply to this post by Frédéric Bron
Frédéric Bron wrote:

>
> > Those names are not consistent with
> > boost::has_new_operator.  That is, you need to rename them
> > like the following for consistency:
> >
> >   s/has_operator_\(.+\)/has_\1_operator/
> >
> > The result won't be perfect.  For example,
> > "has_operator_divides" should be renamed "has_division_operator."
> >
> > Renaming "has_new_operator" seems more appropriate,
> > however.  "has_operator_new" puts "operator" and "new" in the
> > right order as the query is for operator new, not the new operator.
> >
> > The same discussion applies to the other traits.
>
> The question of naming has already been discussed here :
> http://thread.gmane.org/gmane.comp.lib.boost.devel/194625

There wasn't much discussion.  You asked about "has_operator_less_than" versus "has_less_than_operator" and I suggested that the former is more consistent with C++ syntax, but that deviates from boost::has_new_operator.

> At that time, we preferred has_operator_xxx to has_xxx_operator.

I still think its better.

> I agree that the whole type_traits library would need more consistency
> but this would break existing code.

We could add has_operator_new as an alias for has_new_operator (or vice versa) and then the new ones would all be has_operator_* and would be consistent with has_operator_new.

_____
Rob Stewart                           [hidden email]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: review request: addition to type_traits library of has_operator_xxx

Edward Diener-3
In reply to this post by Frédéric Bron
On 11/17/2010 3:12 PM, Frédéric Bron wrote:

>> Without trying to make more work along your lines, would it be easy enough
>> for you to add the left shift (<<  ) and right shift (>>  ) binary
>> operators, and/or the incrementable ( ++x and x++ ) and decrementable ( --x
>> and x-- ) unary operators, or are any of these especially different or much
>> more difficult cases ?
>
> Surely<<  and>>  are totally similar and I will add them.
> Prefix ++ and -- should work just fine also.
> Postfix ++ and -- need special care due to the additionnal int but
> this should be rather straitforward.
> What about +=, -=, *=, /=?

Yes the op= set of operators would be very nice to have also.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123