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