Boost logo

Boost :

Subject: Re: [boost] Boost.Convert. Take 2.
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-02-16 17:13:24

On 02/16/2014 08:35 AM, Andrzej Krzemienski wrote:
> 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've extended the Introduction section to address your #1&2 comments. As
for #3&4 I suspect I am lacking the ability to express myself succinctly
enough to squeeze those into the Introduction... without turning it into
"War and Peace"... which would work against me with the impatient kind. ;-)

> 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.
I see your point. Unfortunately, I feel somewhat paranoid as
lexical_cast comparisons dogged my V1 proposal all the way through. Back
then people's reactions were quite natural -- we already have a
conversion API which seems to be a potentially suitable foundation; why
not use it? They were at the beginning of the "road" I already went but
I had to answer the same (not always kind and polite) questions about
lexical_cast over and over again. And youngsters are usually "quick
shooters" -- quick and easy with grandiose statements and opinions, slow
and reluctant with their own research beforehand. So, now I put in
(indeed) a lot of stuff related to lexical_cast -- design, performance,
functionality comparisons... just in case... in fact, if we get to the
review/discussion stage, I am sure people will be asking -- why not
lexical_cast, why does not it behave like lexical_cast?
> 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.
I hope I've addressed your #1 in the Introduction section. Please see if
you find it satisfactory. As for #2 I have to admit I reconsidered my
original position. Indeed, I had the converter parameter in
convert<T>::from(value_in, converter) defaulted to sstream_converter in
my own code. Because I was lazy and did not care for its performance (I
have other chunks "eating" so much more).

Now, as I put it up for everyone to see, it's a different story. My
original lazy approach had two drawbacks -- convert/api.hpp had
sstream_converter.hpp included (an unnecessary coupling) and
convert<T>::from was creating a converter every time it was called. As I
described in the Performance section it has quite a detrimental effect
on performance. As I said, *I* am not concerned (for my current
applications)... but I do not want to give that loophole to people to
explore, discover that performance sucks in their settings and come back
swinging... just the same why I took the implicit converter to T from
convert<T>::result as soon as you mentioned it -- I *personally* find it
very convenient (no need for "value") but defending it is a loosing
battle IMO.

> 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.
Hmm, here with all due respect I really have to disagree on various
levels. :-)

In my neck of the woods, string-to-T and T-to-string are represented
quite equally. Say, we consider the management of configuration files.
Reading values (string-to-T) from cfg files is (to me, anyway) on the
same scale as writing updated values back (T-to-string). Same goes for a
component in a processing pipe or a node in a network --
reading/converting a lot of XML, converting/writing a lot of XML.
> And I find
> it hard to imagine that someone would use it as T to U conversions.
Again, I am far from sure about that. I do currently have to have
OS-native MBCS (MSWin and Solaris) to UCS-2 and UCS-4 string
conversions. They are a separate lib. Can't immediately see anything
wrong in incorporating it into the 'convert' framework. Then I remember
Vicente having a 'conversion' proposal to address that T-to-U conversion
in a generic way. So, he must have had a need for it also. I am not
saying you are wrong. I just do not know. Consider the templates
example. Stroustrup purposefully designed them in a generic way. Their
deployment exploded often in surprising ways. I am certainly no
Stroustrup but you get the idea.
> 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.
Uhm, I would not be that quick saying that T-to-string conversion can
never fail. It depends on complexity of the conversion and the used
character set, etc. What if T is a complex class which in its conversion
depends on other classes to behave and they don't? What if the
conversion depends on, say, formatting specification and it is not met
or is invalid?

On top of it, uniformity (and, therefore, predictability) of API and
behavior is quite important IMO. Special (and questionable I might say)
handling of one special case IMO is not worth it (again IMO).


Boost list run by bdawes at, gregod at, cpdaniel at, john at