2014-05-22 1:22 GMT+02:00 Vladimir Batov <Vladimir.Batov@constrainttec.com>:
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<int, 4> integers = {{ 15, 16, 17, 18 }}; std::vector<std::string> strings; boost::cstringstream_converter cnv;
cnv(std::hex)(std::uppercase)(std::showbase);
std::transform( integers.begin(), integers.end(), std::back_inserter(strings), *boost::convert<std::string>(cnv));*
For now it has been moved to the post_review branch though.
So far I only found
boost::convert<std::string>(cnv));
has one limitation over
boost::convert<std::string, int>(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?
I had a short look at post_review branch and it looks we are thinking about the same thing. My apologies for using posh names, I guess I am becoming a snob. Regarding the comparison between the two interfaces, I guess you could provide both (it is not a problem, is it?). First is good for a start. You do not have to think too much or type too much. Then if someone is interested in limiting the function overloads, she can learn how to use the second parameter. Regards, &rzej