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
2014-02-14 20:16 GMT+01:00 Vladimir Batov <Vladimir.Batov@constrainttec.com> : 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