$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [review] Convert library
From: Roland Bock (rbock_at_[hidden])
Date: 2014-05-26 00:58:07
On 2014-05-26 01:25, Vladimir Batov wrote:
>
> On 05/26/2014 12:59 AM, Thijs (M.A.) van den Berg wrote:
>> On May 25, 2014, at 2:47 PM, Roland Bock <rbock_at_[hidden]> wrote:
>>
>>> I think it would be relatively simple to get to a much leaner
>>> interface.
>>> For instance,
>>>
>>> * convert could have a converter template parameter, defaulting to
>>> the
>>> stringstream converter
>>> * convert::from() could have an overload that just takes the "from"
>>> parameter and provides the default-constructed converter itself.
>> In C++11 has std::to_string and various flavours of stoul, stoull,
>> stof. To me it makes more sense to use those for conversions between
>> strings and integral types. Not just because of portability, but also
>> because the interface is so simple.
>>
>> The value of convert to me seems to be more in the context of generic
>> programming for a wide range of types with a uniform interface than
>> for a simple interface for specific types for which there are already
>> simple & standard alternatives.
>>
>
> Indeed. Thank you for summing it up. When *I* try answering it turns
> into 4-volume "War and Piece" and by the time I finish one half is
> asleep and the other has left. :-)
If the ability to be used in generic programming is the main value, then
why are almost all the examples in the documentation string->int?
And I was not (knowingly) suggesting API changes that reduce
applicability for generic programming. In fact the ability to provide a
callable to handle the conversion problems is much better suited than
returning a default value and testing for it, IMHO. It is probably also
performing better than throwing and catching exceptions.
Regards,
Roland