Re: [boost] Boost.Conversion - pre review request

Subject: Re: [boost] Boost.Conversion - pre review request
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-07-09 11:39:07

Jeroen Habraken wrote:
> 
> Hi,
> 
> On 9 July 2011 16:20, Vicente Botet <vicente.botet_at_[hidden]>
> wrote:
>>
>> Jeroen Habraken wrote:
>>>
>>> Hi,
>>>
>>> Colour me curious, but what's the advantage of wrapping boost.coerce
>>> in boost.conversion? We're trying to create a sensible API for
>>> boost.coerce (which, as we've seen, is quite a challenge for a
>>> conversion library) and I personally do not see the benefit of it
>>> being wrapped with a different API in a different library.
>>>
>>>
>>
>> The scope of Boost.Conversion is not to define specific conversions but
>> allow to put all the basic type-to-type conversion using a generic
>> interface. If Boost.Coerce provide an string to type efficient conversion
>> Boost.Conversion can provide a specialization for string to types
>> conversion
>> that will delegate to Boost.Coerce. At the end std::string is a type as
>> others.
>>
>> Boost.Conversion provides currently and optional (specific file) a
>> specialization for string-to-type and type-to-string that uses
>> lexical_cast.
>> It will try to make this specialization available only if the used
>> expression is valid, but I have no taken the needed time yet.
>>
>> Best,
>> Vicente
> 
> It is important to note there is no generic way of implementing
> type-to-string and string-to-type which is the reason that
> boost::lexical_cast and boost::coerce can co-exist. Whilst there is
> definitely an overlap in the problems both libraries solve the
> approach is significantly different. If one must support locale than
> lexical_cast is the way to go, if one prefers runtime speed than
> coerce is the way to go. Since these libraries obviously aren't
> drop-in replacements of each other the user must make an informed
> decision and pick one based on his/her requirements. This also means,
> in my opinion anyways, that boost.conversion can't generically wrap
> both in a meaningful way since they operate differently and one can't
> switch between them without consequences.
> 
> 

You are right and the same applies to any type-to-type conversion. And maybe
this is the MAJOR flaw of Boost.Conversion: to think that we can define
extrinsically THE conversion between two types. Every body admit that if a
class T defines a constructor from a std::string THE conversion from
std::string to T is the one defined by this constructor. 

Boost.Conversion pretend to provide a specialization point to state what is
THE conversion from one type to another extrinsically. Of course, the fact
that this is done outside both classes allows to have two different points
of view that will be ambiguous if the two view are visible from the same
compilation unit  or will violate the ODR if both views are present on the
same program.

Note that this issue is not only limited to Boost.Conversion but to any
function that could be overloaded by the user or any template class that can
be specialized by the user. Two different parts of a program could make the
same overloading or the same specialization. This doesn't implies that we
should avoid overloading or specializations.

It seems clear to me that if we don't have a consensus on the default
type-to-type conversion extrinsically Boost.Conversion mustn't not provide
it, neither the user. Does it means that Boost.Conversion has no sens? I
don't know. 

Coming back to the string to int conversion, if we can not have a default
string-to-type or type-to-string, Boost.Conversion must remove these
specializations.

Thanks Jeroen and Harmut for raising this issue before the review,
Vicente

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-Conversion-pre-review-request-tp3650286p3656323.html
Sent from the Boost - Dev mailing list archive at Nabble.com.