On 05/20/2014 11:02 AM, Julian Gonggrijp wrote:
Vladimir Batov wrote:
I also don't think this idiom would be appropriate beyond type conversions, for example in encryption as suggested in the doc. Of course, encryption in a sense is a conversion, but most functions are ultimately conversions and I think people would agree that the idiom proposed here would be needlessly cumbersome for most of such "conversions". I hear you. Although I admit I do not share your view. My example would be lexical_cast. Coding a type to be used with lexical_cast is a pain. However, when I come across lexical_cast call (in an unfamiliar code), I immediately know what's going on and what the behavior and side effects and so on. You do not get that with some "int v = foo.to_int();", do you? I probably wasn't clear about what I meant by "conversions" (quoted): I meant functions in general. 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.
Any idea/proposal taken too far becomes absurd. So, I am not suggesting we replace std::sqrt. On the other hand, I personally like d1 = boost::convert<double>(x, xcnv).value(); d2 = boost::convert<double>(y, ycnv).value(); d2 = boost::convert<double>(z, zcnv).value(); much better than some obscure d1 = x.to_double(); d2 = y.extract_double(param); d2 = z.simplify(); as boost::convert advertizes known/familiar/instantly recognizable behavior when the seemingly innocuous "to_double()" and others are dark horses that I need to spend time getting to know. When one multiplies that effort manifold, the advantages of using familiar interfaces become clear.
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. 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.
... I successfully compiled the test program with Apple Clang 5.1 (based on 3.4). It ran successfully except for one error:
test_convert.cpp(313): test 'double_eng == eng_expected' failed in function 'int main(int, const char **)' I believe that's because different compiles and platforms have different locale representations. Say, Microsoft's "1.235e-002" is "1.235e-02" with gcc. I wonder what was "double_eng" in your test (printed on line 310)? I'll happily run an adjusted test case for you if you provide the code.
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()); To incorporate Clang I need to know what macro it defines (like __GNUC__ for gcc) and what was printed for "double_eng". Thanks, V.