Re: [boost] [Conversion] Practical applications

Subject: Re: [boost] [Conversion] Practical applications
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-08-21 13:08:49

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