Re: [boost] [review] Convert library

Subject: Re: [boost] [review] Convert library
From: Roland Bock (rbock_at_[hidden])
Date: 2014-05-26 05:54:59

On 2014-05-26 10:45, Vladimir Batov wrote:
> Roland Bock-2 wrote
>> On 2014-05-26 01:25, Vladimir Batov wrote:
>>> On 05/26/2014 12:59 AM, Thijs (M.A.) van den Berg wrote:
>>>>>     ...
>>>> 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.
>> 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?
> Well, clearly there are many reasons the docs are far from satisfactory...
> You are not suggesting I spend weeks and weeks writing a bestseller just to
> see all that rejected during the review and going to the rubbish bin, right?
> So, I had to be mindful of that.
Sorry, if I annoyed you. Documenting is horribly hard since you know
your motivation and library inside out.
On the other hand, you received several pieces of input for
documentation that could be changed quickly. Why not change them during
the review (easy for me to say, I know)?

>
>
>> 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.
> I never thought of that. It sounds potentially interesting. I myself have no
> experience of such deployment... Might be an overkill as so far "optional"
> served my purposes well... It'd be easier to see real compilable code with
> realistic examples... even if it is merely string->int. ;-) 
We're using such an interface for looking up elements in a map. If the
key is invalid, the function is called.

Very nice, for instance, to log and throw.

Regards,

Roland