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-15 18:37:50

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&lt;RHS, t&gt;::value 
    then
      typedef true_type type;
      return;
    endif
  typedef has_operator_unary_minus&lt;RHS, RET&gt; 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.

Best,
Vicente

Typo: replace ambigous by ambiguous in the doc.

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