Boost logo

Boost :

Subject: Re: [boost] [review] convert library
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2014-05-19 21:02:27


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. I think encryption is more
like std::sqrt than like std::stoi in this regard. Your framework
seems appropriate for true type conversions only.

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

Cheers,
Julian


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk