[concept] EqualityComparable metafunction
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
On Mon, Sep 5, 2011 at 3:30 PM, Lorenzo Caminiti <lorcaminiti@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 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
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_O... On Tue, Sep 6, 2011 at 10:00 AM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung@gmail.com> wrote:
On Mon, Sep 5, 2011 at 3:30 PM, Lorenzo Caminiti <lorcaminiti@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 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
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_O...
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
Jeffrey Lee Hellrung, Jr.-2 wrote:
On Mon, Sep 5, 2011 at 3:30 PM, Lorenzo Caminiti <lorcaminiti@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 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 -- View this message in context: http://boost.2283326.n4.nabble.com/concept-EqualityComparable-metafunction-t... Sent from the Boost - Dev mailing list archive at Nabble.com.
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
2011/9/6 Frédéric Bron <frederic.bron@m4x.org>:
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/1ed05da11e2b1... that you have conducted end of August regarding naming of operator traits? Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
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
2011/9/14 Frédéric Bron <frederic.bron@m4x.org>:
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
2011/9/14 Frédéric Bron <frederic.bron@m4x.org> > 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
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
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
participants (7)
-
Allan Johns -
Dave Abrahams -
Frédéric Bron -
Jeffrey Lee Hellrung, Jr. -
Joachim Faulhaber -
lcaminiti -
Lorenzo Caminiti