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

Subject: Re: [boost] Boost.Conversion - pre review request
From: Jeroen Habraken (vexocide_at_[hidden])
Date: 2011-07-09 11:05:32

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.

Jeroen