On 3/17/2011 7:17 AM, Joachim Faulhaber wrote:
2011/3/17 Joachim Faulhaber<afojgo@googlemail.com>: [...]
thank you again for implementing this has_operator extension. I've found some problems. In the ICL I have an operator + [...] template<class Type> inline typename enable_if <is_associative_element_container<Type>, Type>::type operator + (Type object, const Type& operand);
and is seems that more overloads are checked valid as actually exist. Is this intentional?
BOOST_AUTO_TEST_CASE(has_op_extension_qualifiers) { typedef int T; typedef interval_set<T> IntervalSetT; typedef IntervalSetT::interval_type IntervalT;
// This is supposed to succeed BOOST_CHECK((has_operator_plus<IntervalSetT, const IntervalSetT&, IntervalSetT>::value));
BOOST_CHECK((!is_convertible<const IntervalSetT&, IntervalSetT&>::value));
// These are supposed to fail, but they succeed BOOST_CHECK((has_operator_plus<IntervalSetT, IntervalSetT&, IntervalSetT>::value)); BOOST_CHECK((has_operator_plus<IntervalSetT, IntervalSetT, IntervalSetT>::value)); BOOST_CHECK((has_operator_plus<IntervalSetT, IntervalSetT, IntervalSetT const&>::value)); }
An operator trait allows implicit conversions in the arguments. In fact, the current implementation strategy *must* allow implicit conversions in the arguments, i.e., I wouldn't know how to detect *exact* signatures. - Jeff