"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:00b601c6258d$bb5f76d0$a9051c52@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