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 10:50:01

Hi,

On 9 July 2011 15:51, Vicente Botet <vicente.botet_at_[hidden]> wrote:
>
> Jeroen Habraken wrote:
>>
>> Hi,
>>
>> On 9 July 2011 04:10, Gordon Woodhull &lt;gordon_at_[hidden]&gt; wrote:
>>> Hi Vicente, all,
>>>
>>>> I've been reworking the Boost.Conversion library
>>>>
>>>> Documentation:
>>>> http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/html/index.html
>>>> Sandbox :http://svn.boost.org/svn/boost/sandbox/conversion/
>>>
>>>
>>>> Description:
>>>> Boost.Conversion manages with generic extrinsic conversion between
>>>> unrelated
>>>> types. These conversion can be seen as implicit or explicit conversions.
>>>
>>> I am excited to manage the Conversion review at the end of August.
>>>
>>> It may be simple enough for us to say "extrinsic type-to-type conversion"
>>> since we both participated in the Boost.Convert review and have all those
>>> distinctions in mind...
>>>
>>> But it might be confusing to potential reviewers and followers of Boost
>>> that in other "little c" conversion news this year:
>>> * lexical_cast has received a new maintainer who is adding optimizations
>>> for type-to-type which overlap with Conversion
>>> * Vladimir Batov's Boost.Convert was withdrawn. Â I think it's fair to Ed
>>> Diener's excellent review report [1] to say that the library was not
>>> acceptable in its current form not because it didn't have the right
>>> features, but mostly because of syntax problems. Â And because of
>>> confusion that its scope overlapped with lexical_cast, which I'm trying
>>> to avoid in the upcoming review!
>>> * Jeroen Habraken is working on a Boost.Coerce library [2] which does
>>> more runtime-efficient string-to-type and type-to-string conversion using
>>> Spirit.
>>>
>>> One clear distinction is that the proposed Boost.Conversion is not
>>> concerned with the special cases of string-to-type and type-to-string.
>>> Â It provides a general framework for type-to-type conversion and will
>>> defer string conversions to lexical_cast or coerce depending how it is
>>> configured.
>>>
>>> IMHO lexical_cast is not the appropriate generic function to use for
>>> type-to-type conversion (when there is no text involved), and I am
>>> managing the review to evaluate whether Boost.Conversion is the right
>>> solution.
>>>
>>> Boost.Conversion learns from the use cases that were presented by
>>> Vladimir Batov in Boost.Convert and its review, and IIUC it now provides
>>> all the behaviors that were not string-specific, without the syntax
>>> problems. Â Obviously, that also means no operator<<, so there's no way to
>>> specify formatting options if text is involved. Â (Jeroen, if you're
>>> reading this, can you convert to/from e.g. hexadecimal with Coerce?)
>>
>> It isn't possible at the moment but it is to be re-added during the
>> Google Summer of Code. The syntax will probably look something like
>> coerce::as<int>("0x17", tag::hex());
>>
>> ...
>>
>> If there are any questions regarding Coerce, please don't hesitate to
>> contact me either on- or off-list.
>>
>>
>
> Hi,
>
> I don't see why we need to specify that the format is hexadecimal. I would
> expect that the spirit grammar associated to the coerce library will take
> care of all the formats without any specific additional tag.
>
> I see only a need for tags/manipulators when you want to convert an int to a
> string as you can have only one default behavior. Do you expect to have best
> performances with coerce than using an string stream for type to string
> conversions?
>
> Best,
> Vicente
>

I believe the API of boost.coerce should not try to outsmart the user.
"0x23" is not a valid integer unless he/she explicitly states to
accept hexadecimal numbers, which can be done via tag::hex() or
something akin to tag::detect_base().

Regards,
Jeroen