
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? boost::array, std::tuple, and other know classes, define implicit or explicit constructors in a similar way. If you find these kind of conversion useful, maybe you could understand that we could extend it to types that were initialy designed by unrelated teams, but that one day are used by a 3rd needing conversion from one to the other. 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. Of course we can define specific functions to make the conversion between concrete types, but soon we need generic way to access to the conversion from generic Source and Target types. Boost.Conversion can be used to define all these conversions in a way that can be used with a uniform interface. It is not more :( Note that these conversion/transformations will not needed if the 3rd paty libraries provided a concept based interface, but in the real world we need to manage with libraries that have an important added value even if the interface is not of our taste. To resume: my intention with this library is to extend this possibility to conversions of unrelated types, containers of unrelated types, ... in a quasy-recursive way.
Example:
struct person { string firstname; string surname; };
vector<person> people; // sorted by firstname
// Try to find everyone with firstname "John": std::equal_range(people.begin(),people.end(),"John");
That doesn't work. Making it work has always struck me as more difficult than it should be. Can this library make it easier? If not, what similar problems can it help with?
No. The library is not intendeed to help in these cases. What you need is containers views. Thanks for your interest, Vicente