Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron

Subject: Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-03-14 13:45:23

Hi,

Thanks Frédéric for proposing this waited for long time extension.

if I have understood there is no mean to check if an operator or a function
returns void. void has been used as default value for the RET type to don't
check the return type, isn't it? If this is the case, this should be
included in the limitations, as others could think that we can check for
this, as other post let think.

There is a declval function on Boost.Utility that creates a rvalue reference
that could be used instead of the make() function. Please could you check if
this function is adapted to your needs?

The limitation related to the implicit conversion could maybe reduced if the
traits take care of a special trait giving the list of classes that a class
is implicitly convertible to 

  implicitly_convertible_seq::type

With this trait the has_operator_name traits could try to check before in
this type sequence to avoid the ambiguity. The main problem is that this
trait needs to be specialized for each class only once in a centralized way,
which is quite restrictive. Of course this can be defined on top of the
existing traits, so it is not a blocking issue for me, but I would like to
know what other think of the approach.

Just a last comment on the name of the structures used in the detail and
specific namespace. Instead of repeating the name you could just use shorter
names, e.g.

namespace detail {
namespace has_operator_unary_minus_impl {

// ...
// defines some typedef for convenience
template < typename RHS, typename RET >
struct has_operator_unary_minus_impl {
   typedef typename ::boost::remove_reference::type rhs_noref;
   typedef typename ::boost::remove_cv::type rhs_nocv;
   static const bool value=(has_operator_unary_minus_impl1 < rhs_noref, RET,
::boost::is_pointer< rhs_noref >::value >::value);
};
} // namespace has_operator_unary_minus_impl
} // namespace detail

could be replaced by

namespace detail {
namespace has_operator_unary_minus_impl {

// ...
// defines some typedef for convenience
template < typename RHS, typename RET >
struct helper_0 {
   typedef typename remove_reference::type rhs_noref;
   typedef typename remove_cv::type rhs_nocv;
   static const bool value=(helper_1< rhs_noref, RET, is_pointer< rhs_noref
>::value >::value);
};
} // namespace has_operator_unary_minus_impl
} // namespace detail

Last I agree that the use of equal should be replaced by assign when
assignment is intended

+= has_operator_plus_equal -> has_operator_plus_assign

-= has_operator_minus_equal -> has_operator_minus_assign
 
Best,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/Review-Boost-Type-Traits-Extension-by-Frederic-Bron-tp3353283p3354511.html
Sent from the Boost - Dev mailing list archive at Nabble.com.