Subject: Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-03-15 20:11:21
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.