Re: [boost] Convert library -- Andrzej's review

On 05/20/2014 09:58 PM, Andrzej Krzemienski wrote:

2014-05-20 6:34 GMT+02:00 Vladimir Batov :

...

On 05/18/2014 11:45 PM, Vladimir Batov wrote:

...

Vladimir Batov writes:

Andrzej Krzemienski writes:

...

I personally do not like this trick to force me to type this "from" in

...

"convert<int>::from". Given a few people were not happy with boost::convert::from() interface I've added boost::cnv() for now (so that the names do not clash while both exist).

int v = boost::cnv<int>(str, cnv).value(); A bike-shed issue, isn't it? Either choice has its flaws. I guess the best solution is that you make your chocie, and use it, unless someone is able to convince you otherwise.

Well, you felt strongly enough to mention that you did "not like this trick to force me to type this "from"", right? :-) Other people also mentioned it. So, I tried to adapt less objectionable interface.

One question though, regarding your last example:

convert<int>::from<string>(cnv).value_or(-1);

this renders a "converter object" with the following signature:

int operator()(std::string const&); // right?

That must be convert::from call with algorithms. With algorithms convert::from returns an "algorithm_helped" object which then calls the provided callable with the signature mentioned in the documentation.

It is an equivalent of a "monomorphic" lambda. I guess you could invent another syntax, that does not require to specify this InType:

convert<int>(cnv).value_or(-1);

which would render a converter object with parametrized signature:

template <typename InType> int operator()(const InType&);

I admit I have no slightest idea what "monomorphic lamda" is :-) but that is *exactly* what I've done while moving from convert::from() to simply convert(). For example, boost::array integers = {{ 15, 16, 17, 18 }}; std::vectorstd::string strings; boost::cstringstream_converter cnv; cnv(std::hex)(std::uppercase)(std::showbase); std::transform( integers.begin(), integers.end(), std::back_inserter(strings), *boost::convertstd::string(cnv));* For now it has been moved to the post_review branch though. So far I only found boost::convertstd::string(cnv)); has one limitation over boost::convert(cnv)); Namely, the latter can do implicit conversions when the former does not. That is, for the former to work correctly I have to have a container of elements the *correct* type. With the latter I can feed to an algorithm a container of elements *convertible* to the explicitly specified TypeIn.

This would be an equivalent of a polymorphic lambda. This appears more useful, at the first sight. Any reason why you choose not to do so?

Do you think we could have a quick look at the post_review branch and let me know if that's what you had in mind?