Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk