Re: [boost] [review] convert library

Subject: Re: [boost] [review] convert library
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-05-20 02:59:29

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?

> The problem (as I see it) is that s/w developers often seem to focus on the small picture and lose the big one. It's not an insult but an observation and is the result of daily attention to details. When focus shifts to having to deal with lots and lots of (often unfamiliar) code, say, code reviews, maintenance, then ability to reliably understand the code as in
> 
> d1 = boost::convert<double>(x, xcnv).value();
> d2 = boost::convert<double>(y, ycnv).value();
> d2 = boost::convert<double>(z, zcnv).value();
> 
> rather than *guess* what it might be doing as in
> 
> d1 = x.to_double();
> d2 = y.extract_double(param);
> d2 = z.simplify();
> 
> is important. All IMO of course.

This looks like a convincing case to me (though I have to suppress 
xyz coordinate associations), but this appears to be a type 
conversion again.

> 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.)

Cheers,
Julian