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.