Re: [boost] [conversion] implicit_cast undocumented

From: David Abrahams (dave_at_[hidden])
Date: 2006-01-30 10:39:25

"Andy Little" <andy_at_[hidden]> writes:

> "John Maddock" <john_at_[hidden]> wrote in message
> news:00b601c6258d$bb5f76d0$a9051c52_at_fuji...
>>> BTW would there be any point in an is_implicitly_convertible<A,B>
>>> type_trait?
>>
>> That's what is_convertible does now: tests for implicit convertibility.
>> There's no way you can test for other kinds of valid (but explicit)
>> conversions I believe.
>
> Oops sorry for being too lazy to try that out before posting.  Perhaps it would
> be useful to put that in the documentation for implicit_cast e.g
>
> implicit_cast<t>(S)  will succeed wherever
> is_convertible<S,T>::value ==true 

I think that would be a lie for some reasonable definitions of
"succeed":

        struct foo
        {
           operator int() { throw "fooled ya"; }
        };

> and
> will cause a compile time error wherever implicit_cast<t>(S)  will succeed
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
eh?
> wherever is_convertible<S,T>::value ==false. Maybe could even do the reverse too
> if implicit_cast was documented.
>
> BTW Its a real pain that the parameter order for is_convertible isnt the other
> way round IMO. Its confusing and error prone because casts go the other way. Is
> there a reason for it?

"from, to" is the usual convention except for old-style things like
strcpy.

> Getting back to the original topic (or trying to anyway ).. So is the
> documentation I provided for implicit_cast useful?

Haven't had time to dig into them, but they seemed pretty good on the
surface.  I'll try to find time to check them in.

Thanks,

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com