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