Re: [boost] [review] convert library

Subject: Re: [boost] [review] convert library
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-05-25 05:13:39

On May 19, 2014 9:36:40 PM EDT, Vladimir Batov <Vladimir.Batov_at_[hidden]> wrote:
>
>On 05/20/2014 11:02 AM, Julian Gonggrijp wrote:
>> Vladimir Batov wrote:
>>
>> 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.

Your version is better only in the sense that it provides a common interface, of I understand your point correctly. however, the resulting behavior is not clearly implied by those calls because one must know what the converters actually do in each case. (This is exemplified by the rest compilation error you resolved due to not explicitly specifying the locale.)

Now, switch to a free function and compare it to your proposal and we can make some progress. For the case with to_double(), it might look like this:

d1 = to_double(x);

That interface can be as standard as yours, and is perfectly understandable. They are different ways of spelling a conversion operation. That mine is more succinct makes it superior in many ways. As it is, it lacks two things yours offers, however: extensibility and configurability.

Extensibility can be added by making it a function template like so:

d1 = to<double>(x);

Configurability can be added with an overload:

d1 = to<double>(x, cnv);

Did I miss something? At a glance, this offers everything your more verbose syntax offers.

>> I think encryption is more
>> like std::sqrt than like std::stoi in this regard. Your framework
>> seems appropriate for true type conversions only.

+1

>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 same can be said about the encrypting converter one would use with your framework to effect encryption. What you're suggesting is that your spelling somehow clarifies that an encrypting conversion is occurring, and how it happens, and I don't buy it.

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

You merely shifted the knowledge burden to three converter classes from three member functions. I'll grant that once you understand those the converters, you'll understand their application in multiple contexts, so that advantage does partially justify your claim.

___
Rob

(Sent from my portable computation engine)