Boost logo

Boost :

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

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

> and
> will cause a compile time error wherever implicit_cast<t>(S) will succeed
> 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

> 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.


Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at