On 3/15/2011 6:37 PM, Vicente Botet wrote:
Vicente Botet wrote:
Frédéric Bron wrote:
The limitation related to the implicit conversion could maybe be 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.
I cannot comment on that as I do not see exactly how this would be implemented. Sorry.
I will develop it later.
From the documentation " * There is an issue if the operator exists only for type A and B is convertible to A. In this case, the compiler will report an ambigous overload because both the existing operator and the one we provide (with argument of type any) need type conversion, so that none is preferred. "
Given the trait
template struct implicitly_convertible_seq { typedef mpl::vector0<> type; };
which must be specialized explicitly for each type having implicit conversions. We can define on to of the existing interface a trait that takes care of implicit conversions
template struct has_operator_unary_minus_ext { // in pseudo imperative code
FOREACH t in implicitly_convertible_seq::type if has_operator_unary_minus<RHS, t>::value then typedef true_type type; return; endif typedef has_operator_unary_minus<RHS, RET> type; };
To take care of the examples in the doc we will do
struct A { }; void operator-(const A&); struct B { operator A(); }; template<> struct implicitly_convertible_seq { typedef mpl::vector type; }; boost::has_operator_unary_minus ::value; // this is fine boost::has_operator_unary_minus::value; // No error: as class A is in the list of conversion from B, so boost::has_operator_unary_minus ::value is tested before
Let me know if you need some explanations.
This idea looks promising but it would be even more so if your '<' was not showing as '<' and you '>' was not showing as '>' everywhere in your messages so I could follow it more easily. I do understand what you are saying, and it offers a decent workaround even at the price og an end-user of a type doing a little more work. I too am very interested if the "Known Issues" which can cause compiler errors when using type traits operators can be solved. or worked around, without causing compiler errors.