Re: [boost] [review] convert library

Subject: Re: [boost] [review] convert library
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-05-21 19:34:30

On 05/20/2014 04:59 PM, Julian Gonggrijp wrote:
> Vladimir Batov wrote:
>
>>>   Your framework is general enough to
>>> replace
>>>
>>> x = std::sqrt(y);
>>>
>>> with
>>>
>>> boost::sqrt_convert sqrtcnv;
>>> x = boost::convert<double>::from(y, sqrtcnv).value();
>>>
>>> but nobody would find that a good idea.
>> [...]
>>
>>> I think encryption is more
>>> like std::sqrt than like std::stoi in this regard. Your framework
>>> seems appropriate for true type conversions only.
>> The same advantage here.
>>
>> string encripted = encript(str);
>>
>> The above is better *if* and *after* you spent time getting to know what "encript" actually does, its shortcomings, etc. On large scale all that additional knowledge accumulates and expensive.
> I think I understand what you mean, but I fail to see why `encript`
> is a good example and `sqrt` isn't. Both convert one value into
> another, both have details that you need to know about and both can
> fail, right?

You are correct, technically/mechanically *any* function taking one 
argument and returning one argument could potentially be called a 
"converter" and invoked via boost::convert(). The good thing IMO is that 
"convert" allows that *if* there is a need for that... and I *can* think 
of situations when I might deploy std::sqrt as such a converter. Having 
said that, ultimately, it's all about readability. So, given std::sqrt 
is the standard componet, I expect a s/w developer to be already 
familiar with it and, therefore, in most cases I expect it called 
directly. If "encrypt" is as known on my project (say, it's part of out 
foundation lib. collection) then I'll likely treat as std::sqrt. If that 
is some obscure func. call, I might prefer it called via established 
interface.

>> Right before the test failed, it must have printed with
>>
>> 310:    printf("eng locale=%s, presentation=%s.\n", eng_locale.name().c_str(), double_eng.c_str());
> Oh right, now I see it.
>
> rus locale=ru_RU.UTF-8, presentation=1,235e-02.
> eng locale=, presentation=1,235e-02.
>
> That English locale with the decimal comma appears rather like the
> default locale, which is Dutch in my case.
>
> I can also give you the performance results on my machine, which has
> a mobile 2.5 GHz dual core i5 processor:
>
> str-to-int: strtol/scanf/lcast/sstream=0.73/2.01/1.32/4.58 seconds.
> int-to-str: ltostr/prntf/lcast/sstream=3.19/2.67/2.91/5.49 seconds.
> str-to-user-type: lcast/sstream=3.88/4.10 seconds.
>
> (I compiled it without any compiler flags except for the include
> paths.)
>

Thank you, I corrected the test (in the post_review branch) to 
explicitly specify English locale to avoid the error you mentioned.

Thank you for the performance results. I have a suspicion you did not 
compile optimized and, if so, the results are somewhat 
misleading/skewed. For gcc it'd be -O3.