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