Hi, Is there a specific yes_type and no_type inside boost that I should be using when writing a SFINAE test? There seem to be quite a few defined already and reinventing the wheel (albeit it being trivial) again doesn't make sense. Regards, Jeroen
On Fri, Apr 15, 2011 at 4:13 PM, Jeroen Habraken <vexocide@gmail.com> wrote:
Hi,
Is there a specific yes_type and no_type inside boost that I should be using when writing a SFINAE test? There seem to be quite a few defined already and reinventing the wheel (albeit it being trivial) again doesn't make sense.
There's true and false types, would that do? Yes/no is generally less clear than true/false as the phrasing of the resulting function identifier tends to be less crisp. if ( doesItWork( )== yes ).... vs if ( itWorks( ) ).... - Rob.
On 16/04/2011 12:11, Robert Jones wrote:
On Fri, Apr 15, 2011 at 4:13 PM, Jeroen Habraken<vexocide@gmail.com> wrote:
Hi,
Is there a specific yes_type and no_type inside boost that I should be using when writing a SFINAE test? There seem to be quite a few defined already and reinventing the wheel (albeit it being trivial) again doesn't make sense.
There's true and false types, would that do? Yes/no is generally less clear than true/false as the phrasing of the resulting function identifier tends to be less crisp.
if ( doesItWork( )== yes )....
vs
if ( itWorks( ) )....
They need to be differently sized types so that you can use sizeof to distinguish which function overloads gets picked up.
On Sat, Apr 16, 2011 at 11:23 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
They need to be differently sized types so that you can use sizeof to distinguish which function overloads gets picked up.
I didn't understand that at all, quite possibly because I misunderstood the OP. What overloads are we seeking to distinguish? (Sorry if I'm being a bit slow here!) - Rob.
On 16/04/2011 12:32, Robert Jones wrote:
On Sat, Apr 16, 2011 at 11:23 AM, Mathias Gaunard< mathias.gaunard@ens-lyon.org> wrote:
They need to be differently sized types so that you can use sizeof to distinguish which function overloads gets picked up.
I didn't understand that at all, quite possibly because I misunderstood the OP. What overloads are we seeking to distinguish? (Sorry if I'm being a bit slow here!)
SFINAE is usually used to define traits like this: template<typename T> struct my_trait { typedef char yes_type; struct no_type { char dummy[2]; }; template<typename X> yes_type test(whatever_you_want_to_test_with_X *); no_type test(...); static const bool value = sizeof(test<T>(0)) == sizeof(yes_type); typedef boost::mpl::bool_<value> type; };
On 16/04/2011 12:45, Mathias Gaunard wrote:
On 16/04/2011 12:32, Robert Jones wrote:
On Sat, Apr 16, 2011 at 11:23 AM, Mathias Gaunard< mathias.gaunard@ens-lyon.org> wrote:
They need to be differently sized types so that you can use sizeof to distinguish which function overloads gets picked up.
I didn't understand that at all, quite possibly because I misunderstood the OP. What overloads are we seeking to distinguish? (Sorry if I'm being a bit slow here!)
SFINAE is usually used to define traits like this:
template<typename T> struct my_trait { typedef char yes_type; struct no_type { char dummy[2]; };
template<typename X> yes_type test(whatever_you_want_to_test_with_X *);
no_type test(...);
sorry, forgot a template<typename X> over the second overload there.
static const bool value = sizeof(test<T>(0)) == sizeof(yes_type); typedef boost::mpl::bool_<value> type; };
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 4/15/2011 11:13 AM, Jeroen Habraken wrote:
Hi,
Is there a specific yes_type and no_type inside boost that I should be using when writing a SFINAE test? There seem to be quite a few defined already and reinventing the wheel (albeit it being trivial) again doesn't make sense.
For the Boost developer there is: #include <boost/type_traits/detail/yes_no_type.hpp> you then have: ::boost::type_traits::yes_type ::boost::type_traits::no_type Of course the intention of 'detail' for a library is that the code should only be used by that library, but I think, in this case, it is allowable for other Boost library developers to use it also. But since this is a part of type traits detail it is not meant to be used outside of a Boost library ( ie. by end-users ). It would perhaps be better if ::boost::type_traits::yes_type and ::boost::type_traits::no_type were put into its own utility classes to make it more apparent that Boost library developers and end-users of Boost could use it. OTOH it might be presumptuous of me to suggest that it be used at all outside of type traits, but I have used it in my own TTI sandbox library anyway since type traits itself is used heavily there.
Message du 16/04/11 15:57 De : "Edward Diener" A : boost@lists.boost.org Copie à : Objet : Re: [boost] SFINAE yes_type and no_type
On 4/15/2011 11:13 AM, Jeroen Habraken wrote:
Hi,
Is there a specific yes_type and no_type inside boost that I should be using when writing a SFINAE test? There seem to be quite a few defined already and reinventing the wheel (albeit it being trivial) again doesn't make sense.
For the Boost developer there is:
#include
you then have:
::boost::type_traits::yes_type ::boost::type_traits::no_type
Of course the intention of 'detail' for a library is that the code should only be used by that library, but I think, in this case, it is allowable for other Boost library developers to use it also.
But since this is a part of type traits detail it is not meant to be used outside of a Boost library ( ie. by end-users ).
It would perhaps be better if ::boost::type_traits::yes_type and ::boost::type_traits::no_type were put into its own utility classes to make it more apparent that Boost library developers and end-users of Boost could use it.
OTOH it might be presumptuous of me to suggest that it be used at all outside of type traits, but I have used it in my own TTI sandbox library anyway since type traits itself is used heavily there.
Hi, even if these two classes don't add too much I don't see any problem if they are moved to Boost.TypeTraits. John? Best, Vicente
Edward Diener wrote:
On 4/15/2011 11:13 AM, Jeroen Habraken wrote:
Hi,
Is there a specific yes_type and no_type inside boost that I should be using when writing a SFINAE test? There seem to be quite a few defined already and reinventing the wheel (albeit it being trivial) again doesn't make sense.
For the Boost developer there is:
#include <boost/type_traits/detail/yes_no_type.hpp>
you then have:
boost::type_traits::yes_type boost::type_traits::no_type
Of course the intention of 'detail' for a library is that the code should only be used by that library, but I think, in this case, it is allowable for other Boost library developers to use it also.
But since this is a part of type traits detail it is not meant to be used outside of a Boost library ( ie. by end-users ).
It would perhaps be better if ::boost::type_traits::yes_type and
boost::type_traits::no_type were put into its own utility classes to make it more apparent that Boost library developers and end-users of Boost could use it.
OTOH it might be presumptuous of me to suggest that it be used at all outside of type traits, but I have used it in my own TTI sandbox library anyway since type traits itself is used heavily there.
I think I'm using the one from MPL. If you use MPL for the compile time boolean operations with enable_if then you might as well use the ones in MPL. Actually, it turns out I'm inheriting from the ones in MPL, but it could have been a typedef. struct gtl_no : mpl::bool_<false> {}; struct gtl_yes : mpl::bool_<true> {}; Regards, Luke
On 16/04/2011 22:24, Simonson, Lucanus J wrote:
I think I'm using the one from MPL. If you use MPL for the compile time boolean operations with enable_if then you might as well use the ones in MPL. Actually, it turns out I'm inheriting from the ones in MPL, but it could have been a typedef.
struct gtl_no : mpl::bool_<false> {}; struct gtl_yes : mpl::bool_<true> {};
Both of these types have the same size.
participants (6)
-
Edward Diener -
Jeroen Habraken -
Mathias Gaunard -
Robert Jones -
Simonson, Lucanus J -
Vicente BOTET