Re: [boost] [review] convert library

Subject: Re: [boost] [review] convert library
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-05-19 21:36:40

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.