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

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

 > On 02/17/2014 08:10 PM, Andrzej Krzemienski wrote:
 > Now, I can definitely find all my answers in the Introduction.
 > What I would like to suggest ... is to put a very very short code
 > snippet that will show me how I will be using the library.

Done.

 > Comparison with lexical_cast, and (even more importantly)
 > answering the questions "why would I use Boost.Convert library
 > instead of lexical_cast" and "why did you not extend lexical_cast
 > instead" and "why would I need lexical_cast anymore" are very
 > important for your library's documentation -- I agree. It is just
 > that I am not sure these explanations belong to the
 > Introduction page. But I leave it open. I am satisfied with the
 > improved introduction as it is (except for the one tiny suggestion
 > below).

Understood. Given that in the Intro lexical_cast is only mentioned once 
in passing it should not pose a problem, right?

>> 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. 
> So, you say, it could be used to convert between two different string 
> encodings? I didn't think of it but it looks really useful. So useful 
> that it deserves a bullet in the Introduction. Can it be used to 
> convert from string to wstring?

The thing is that the 'convert' API facade (the convert<T>::from) does 
embarrassingly very little. Still, it ensures the uniformity of 
interface and lays out the rules for the converters. So, if one has a 
"callable", say, an old-fashioned function

bool my_converter(std::string const& value_in, std::wstring& result_out);

then it can be plugged into the 'convert' framework and used as

std::wstring res = convert<std::wstring>::from(std_string, 
my_converter).value();

Still, I am far from sure that this particular application of 'convert' 
will take off. I just do not know. The reason is that TypeIn and TypeOut 
are known in advance, i.e. I know that I want std::string converted to 
std::wstring. So, there is seemingly very little gain from calling

std::wstring res = convert<std::wstring>::from(std_string, 
my_converter).value();

instead of direct

std::string value_in = ...;
std::wstring result_out;
bool success = my_converter(value_in, result_out);

When I, myself, look at convert<T>::from in isolation, I think why on 
Earth I need convert<T>::from to begin with? But convert<T>::from 
appears to be quite important (IMO) to build modular extendible system 
as convert<T>::from API allows me to write code without knowing all the 
types/conversions that will be used by that system. More so, from 
maintenance point of view I find it much easier to see (and recognize) a 
familiar API instead of guessing what " bool success = 
my_converter(value_in, result_out)" might *actually* do.

So, the short answer to your "Can it be used to convert from string to 
wstring?" question is "yes". Will it be useful? I am not sure. I've not 
used "convert" it that fashion so I have no strong feelings one way or 
another. So, I added a section about potentially doing that but tucked 
it to the end. :-) I just to not want to get in to trouble bragging 
about it too much. :-)

>> 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? 
> This is an interesting point. If a conversion fails because it 
> required to acquire some resources and it failed to get them, or 
> because the object was in a disallowed state (some assertion-like 
> thing failed), do you want to return an empty result, or just throw? 

I am not sure I can answer that question definitively. I suspect it 
depends on how a particular failure is interpreted/seen. If that's 
something disastrous/exceptional, then throw; otherwise return 
failure... not exactly a precise answer, is it? :-)

When I said "a complex class which in its conversion depends on other 
classes to behave" I had more "modest" conversion failures in mind. For 
example, I write scheduling s/w for airlines and there there is the 
concept of a leg or a sector -- a chunk of uninterrupted flight from A 
to B. Quite often I want a leg/sector's string representation printed 
out. So,

std::string info = convert<string>::from(leg, cnv).value_or("bad");

The problem is that there are many parameters in that leg/sector 
structure. So, the call above can easily fail. Say, I forgot to set the 
destination port! So, in this example conversion to string can fail. If 
I had the "conversion to string can never fail" rule I could return "", 
"invalid", etc. but I think the code above is far better -- I 
immediately see what string represents conversion failure.

V.