[concept] EqualityComparable metafunction

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

[concept] EqualityComparable metafunction

lcaminiti
Hello all,

What is the best way to check if a type T is EqualityComparable?

Essentially, I would need a is_equality_comparable<> metafunction:

struct mytype {};

is_equality_comparable<int>::value // true
is_equality_comparable<mytype>::value // false

Can I re-use the boost::EqualityComparable concept to implement
is_equality_comparable<>? Or, shall I just try to use
introspection-SFINAE techniques?

Thanks in advance.
--Lorenzo

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

Re: [concept] EqualityComparable metafunction

Jeffrey Lee Hellrung, Jr.-2
On Mon, Sep 5, 2011 at 3:30 PM, Lorenzo Caminiti <[hidden email]>wrote:

> Hello all,
>
> What is the best way to check if a type T is EqualityComparable?
>
> Essentially, I would need a is_equality_comparable<> metafunction:
>
> struct mytype {};
>
> is_equality_comparable<int>::value // true
> is_equality_comparable<mytype>::value // false
>
> Can I re-use the boost::EqualityComparable concept to implement
> is_equality_comparable<>? Or, shall I just try to use
> introspection-SFINAE techniques?
>
> Thanks in advance.
> --Lorenzo
>

I think the (relatively) recently-reviewed TypeTraits Extension by Frederic
Bron has what you're looking for, although I have no idea what the name of
the particular metafunction is at the moment :)  has_operator_equals?

- Jeff

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

Re: [concept] EqualityComparable metafunction

Allan Johns-2
boost aside, this article is a great working example of a hand-rolled SFINAE
approach

http://www.martinecker.com/wiki/index.php?title=Detecting_the_Existence_of_Operators_at_Compile-Time



On Tue, Sep 6, 2011 at 10:00 AM, Jeffrey Lee Hellrung, Jr. <
[hidden email]> wrote:

> On Mon, Sep 5, 2011 at 3:30 PM, Lorenzo Caminiti <[hidden email]
> >wrote:
>
> > Hello all,
> >
> > What is the best way to check if a type T is EqualityComparable?
> >
> > Essentially, I would need a is_equality_comparable<> metafunction:
> >
> > struct mytype {};
> >
> > is_equality_comparable<int>::value // true
> > is_equality_comparable<mytype>::value // false
> >
> > Can I re-use the boost::EqualityComparable concept to implement
> > is_equality_comparable<>? Or, shall I just try to use
> > introspection-SFINAE techniques?
> >
> > Thanks in advance.
> > --Lorenzo
> >
>
> I think the (relatively) recently-reviewed TypeTraits Extension by Frederic
> Bron has what you're looking for, although I have no idea what the name of
> the particular metafunction is at the moment :)  has_operator_equals?
>
> - Jeff
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

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

Re: [concept] EqualityComparable metafunction

Dave Abrahams
In reply to this post by lcaminiti

on Mon Sep 05 2011, Lorenzo Caminiti <lorcaminiti-AT-gmail.com> wrote:

> Hello all,
>
> What is the best way to check if a type T is EqualityComparable?
>
> Essentially, I would need a is_equality_comparable<> metafunction:
>
> struct mytype {};
>
> is_equality_comparable<int>::value // true
> is_equality_comparable<mytype>::value // false
>
> Can I re-use the boost::EqualityComparable concept

No, that won't get you what you want: concepts eagerly generate hard
errors when not satisfied.  I think we've had at least one proposal of a
library to support this, but if no off-the-shelf solution presents
itself, you could copy the pattern given by
boost/detail/is_incrementable.hpp

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com


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

Re: [concept] EqualityComparable metafunction

Dave Abrahams
In reply to this post by Allan Johns-2

on Mon Sep 05 2011, Allan Johns <allan.johns-AT-drdstudios.com> wrote:

> boost aside, this article is a great working example of a hand-rolled SFINAE
> approach
>
> http://www.martinecker.com/wiki/index.php?title=Detecting_the_Existence_of_Operators_at_Compile-Time

Good article.  That solution breaks if the operator== returns void.  You
can work around that with techniques shown in
boost/detail/is_incrementable.hpp, but even that technique can break
down if there's a user-defined comma operator.  They all break if
operator== is private.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com


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

Re: [concept] EqualityComparable metafunction

lcaminiti
In reply to this post by Jeffrey Lee Hellrung, Jr.-2
Jeffrey Lee Hellrung, Jr.-2 wrote
On Mon, Sep 5, 2011 at 3:30 PM, Lorenzo Caminiti <[hidden email]>wrote:

> Hello all,
>
> What is the best way to check if a type T is EqualityComparable?
>
> Essentially, I would need a is_equality_comparable<> metafunction:
>
> struct mytype {};
>
> is_equality_comparable<int>::value // true
> is_equality_comparable<mytype>::value // false
>
> Can I re-use the boost::EqualityComparable concept to implement
> is_equality_comparable<>? Or, shall I just try to use
> introspection-SFINAE techniques?
>
> Thanks in advance.
> --Lorenzo
>

I think the (relatively) recently-reviewed TypeTraits Extension by Frederic
Bron has what you're looking for, although I have no idea what the name of
the particular metafunction is at the moment :)  has_operator_equals?
can_call_equal from TypeTraits Extension worked.

Thanks to all for your suggestions.
--Lorenzo
Reply | Threaded
Open this post in threaded view
|

Re: [concept] EqualityComparable metafunction

Frédéric Bron
In reply to this post by Jeffrey Lee Hellrung, Jr.-2
> I think the (relatively) recently-reviewed TypeTraits Extension by Frederic
> Bron has what you're looking for, although I have no idea what the name of
> the particular metafunction is at the moment :)  has_operator_equals?

It is on the way and the final name will be: has_equal_to<T1, T2, Ret>
Frédéric

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

Re: [concept] EqualityComparable metafunction

Joachim Faulhaber
2011/9/6 Frédéric Bron <[hidden email]>:
>> I think the (relatively) recently-reviewed TypeTraits Extension by Frederic
>> Bron has what you're looking for, although I have no idea what the name of
>> the particular metafunction is at the moment :)  has_operator_equals?
>
> It is on the way and the final name will be: has_equal_to<T1, T2, Ret>

Hi Frédéric,

are you going to announce the results of the poll
http://groups.google.com/group/boost-list/browse_thread/thread/1ed05da11e2b12b2/e72706c0ce9bdc3b?pli=1
that you have conducted end of August regarding naming of operator traits?

Joachim

--
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de

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

Re: [concept] EqualityComparable metafunction

Frédéric Bron
I am working on it right now and wanted to publish the new names with
a new version in the sandbox, ready to be included. But yes the result
is C plus an additionnal has_unary_minus (see below).
Frédéric

# binary
+       has_plus
-       has_minus
*       has_multiplies
/       has_divides
%       has_modulus
+=      has_plus_assign
-=      has_minus_assign
*=      has_multiplies_assign
/=      has_divides_assign
%=      has_modulus_assign
&       has_bit_and
|       has_bit_or
^       has_bit_xor
&=      has_bit_and_assign
|=      has_bit_or_assign
^=      has_bit_xor_assign
<<      has_left_shift
>>      has_right_shift
<<=     has_left_shift_assign
>>=     has_right_shift_assign
==      has_equal_to
!=      has_not_equal_to
<       has_less
<=      has_less_equal
>       has_greater
>=      has_greater_equal
&&      has_logical_and
||      has_logical_or
# prefix
!       has_logical_not
+       has_unary_plus
-       has_unary_minus
-       has_negate
~       has_complement
*       has_dereference
++      has_pre_increment
--      has_pre_decrement
# postfix
++      has_post_increment
--      has_post_decrement

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

Re: [concept] EqualityComparable metafunction

Joachim Faulhaber
2011/9/14 Frédéric Bron <[hidden email]>:
> I am working on it right now and wanted to publish the new names with
> a new version in the sandbox, ready to be included. But yes the result
> is C plus an additionnal has_unary_minus (see below).

Thanks for the good work. I'm looking forward to the final version :)

Joachim

--
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de

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

Re: [concept] EqualityComparable metafunction

Jeffrey Lee Hellrung, Jr.-2
In reply to this post by Frédéric Bron
2011/9/14 Frédéric Bron <[hidden email]>

> I am working on it right now and wanted to publish the new names with
> a new version in the sandbox, ready to be included. But yes the result
> is C plus an additionnal has_unary_minus (see below).
> Frédéric
>
> # binary
> +       has_plus
> -       has_minus
> *       has_multiplies
> /       has_divides
> %       has_modulus
> +=      has_plus_assign
> -=      has_minus_assign
> *=      has_multiplies_assign
> /=      has_divides_assign
> %=      has_modulus_assign
> &       has_bit_and
> |       has_bit_or
> ^       has_bit_xor
> &=      has_bit_and_assign
> |=      has_bit_or_assign
> ^=      has_bit_xor_assign
> <<      has_left_shift
> >>      has_right_shift
> <<=     has_left_shift_assign
> >>=     has_right_shift_assign
> ==      has_equal_to
> !=      has_not_equal_to
> <       has_less
> <=      has_less_equal
> >       has_greater
> >=      has_greater_equal
> &&      has_logical_and
> ||      has_logical_or
> # prefix
> !       has_logical_not
> +       has_unary_plus
> -       has_unary_minus
> -       has_negate
> ~       has_complement
> *       has_dereference
> ++      has_pre_increment
> --      has_pre_decrement
> # postfix
> ++      has_post_increment
> --      has_post_decrement
>

I notice (just now) that unary & and [] are absent.  Detection of operator[]
needs an entirely different mechanism than the above operators, so I
understand its absence (but maybe it could still be included?).  I'm not
sure detection of unary operator& would be all that useful most of the time,
but I'm just wondering what the reasons were for its exclusion.

FWIW, I couldn't find answers to the above questions from browsing the
(obviously outdated) documentation in sandbox/type_traits.  If there's
updated documentation browsable online that address this, feel free to just
direct me there :)

- Jeff

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

Re: [concept] EqualityComparable metafunction

Frédéric Bron
> I notice (just now) that unary & and [] are absent.  Detection of operator[]
> needs an entirely different mechanism than the above operators, so I
> understand its absence (but maybe it could still be included?).  I'm not
> sure detection of unary operator& would be all that useful most of the time,
> but I'm just wondering what the reasons were for its exclusion.

It needs also a different implementation because & always exists (it
is always possible to get the address of something) , even if not
defined by the user so if you define a less preferred operator (like
in the current implementation), I think it becomes more preferred over
the built-in one. I tried at a time and discovered it was not
possible. I do not remember all details however.

Frédéric

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