Vicente J. Botet Escriba wrote:
Le 21/08/11 18:18, Phil Endecott a ?crit :
Dear Vicente & others,
Would anyone like to share any practical or motivating applications for the proposed Boost.Conversion library?
It seems to me that there are practical applications for particular types of conversion, e.g. T-to-string and string-to-T, and numeric casts, and serialisation. Apart from that, I am having trouble seeing practical reasons for generic conversion. A motivating case would be if a generic algorithm required conversion, but in the cases that I can think of either (a) the generic algorithm takes a functor, so the caller can pass the currently-required conversion as part of a lambda expression, or (b) you might need to select one of several possible conversions between a pair of types, which this library can't do, or (c) the algorithms are std:: ones which won't work with this library anyway.
Boost and the standard library defines conversion of containers of types that are explicitly convertible. For example std::pair defines the following
template <class T1, class T2> struct pair { ... template <class U, class V> pair(const pair<U,V>& p); }
template<class U, class V> pair(const pair<U, V>& p); Requires: is_constructible<first_type, const U&>::value is true and is_constructible<second_- type, const V&>::value is true. Effects: Initializes members from the corresponding members of the argument. Remark: This constructor shall not participate in overload resolution unless const U& is implicitly convertible to first_type and const V& is implicitly convertible to second_type.
If we can construct implicitly a pair from another pair of implicitly convertible types, why we couldn't allow the conversion from a pair of type that are extrinsically implicitly convertible to them?
Right. But does your library make this possible? If you could change std::pair, you could change that ctor to call your new conversion function. But you can't change std::pair. Or, have I missed something? (I am looking at the "Motivation" section of your docs, where it shows 'T t = explicit_convert_to<T>(u);' and 'f(implicitly(u));', etc.)
As part of my work, I use to be confronted to these kind of situations quite often, where 3rd party libraries we use convey "the same" kind of information following different and specific formats.
It would be great to see some practical examples. Regards, Phil.