Re: [boost] Boost.Convert. Take 2.

Subject: Re: [boost] Boost.Convert. Take 2.
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-02-15 16:35:12

2014-02-14 20:16 GMT+01:00 Vladimir Batov <Vladimir.Batov_at_[hidden]>
:

> On 02/15/2014 01:46 AM, Edward Diener wrote:
>
>> On 2/13/2014 11:01 PM, Vladimir Batov wrote:
>>
>>> ...
>>>
>>> Finished the docs. The whole thing is at
>>> https://github.com/yet-another-user/boost.xtra.
>>>
>>
>>
I have a suggestion regarding the documentation. It is abut the first page.
I am expressing my preference, but I am pretty sure I am not the only
person here with this expectation. I am a very impatient man and I expect
of the first page a number of answers quickly, or otherwise I will be not
interested. When I see "Conversion" in the name of the library, I will need
the following questions answered quickly (I guess I am not more arrogant
than an average stressed programmer):

1. Is it only string to T and T to string conversions, or arbitrary T to U
conversion?
2. Will it consider locale?
3. Will it return optional<T> (or some such) so that I can decide myself
how to deal with conversion failure?
4. How will I use it. Give me a minimum example.

In other words, I need to see from the first page what this library will
and will not give me.
I would also suggest not to start with the comparison with lexical_cast.
Your users may not even know lexical_cast. Also, there is something
discouraging when I read how your library differs from some other library
rather than learning what your library is.

Two other suggestions for the initial page. 1. Mention that it works with
non-DefaultConstructibel types. It is unusual (in the positive sense) for a
conversion library. 2. Since you mentioned that convert can be used without
specifying the second (streamer) argument, show this in the initial
example: let it be really simple.

And one other thought (it is not really a suggestion for Boost.Convert, but
a general observation regarding string conversions). Your library is mainly
about converting string to T. T to string will be less common. And I find
it hard to imagine that someone would use it as T to U conversions. When
converting from T to string, you do not really need to return optional<T>,
because it is not possible that this conversion can fail. Any T always has
a string representation, doesn't it? I wonder (but I do not have a good
answer) if conversion in this direction should have the same interface.

Regards,
&rzej