Boost logo

Boost :

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

>> Right before the test failed, it must have printed with
>> 310: printf("eng locale=%s, presentation=%s.\n",, 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.

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