the Boost.Range library introduce the concept of adaptor (or view). I'm wondering if this could be also convenient for the Boost.Convert library.
Take the uuid user data type.
uuid u; string res;
u | corverted_to<string> | uppercased > res;
The evaluation should be lazy, only when we assign throwg the > operator we force the evaluation.
or
string str;
int i = str | radix(10) | locale(...) | converted_to<int>;
Could this approach work for the Boost.Convert library?
Well, in this case I really prefer: using namespace spirit::std_locale; spirit::qi::parse(str, spirit::int_, i); or, if you need another radix: typedef spirit::qi::int_parser<int, 16> hex; spirit::qi::parse(str, hex(), i); or, if you need exactly 4 hex digits: typedef spirit::qi::int_parser<int, 16, 4, 4> hex4; spirit::qi::parse(str, hex4(), i); etc. Which is far less convoluted. Same/similar works for converting the other way around: typedef spirit::karma::int_generator<int, 16> hex; spirit::karma::generate(std::back_inserter(str), hex(), i); <rant> I still don't get it. I agree that it might be favorable to have a simple API for type<-->string conversions. But as you can clearly see the requirements are piling up and it's everything else but simple by now. So I ask again: What's the benefit of coming up with just another full blown parser/generator interface in Boost? What's the benefit of discarding/obsoleting lexical_cast<>() as the _really_ minimal, simple interface? Guy's. You're trying to come up with a DSEL (domain specific embedded language) for parsing and generating. What's it exactly you don't like in Spirits DSEL? Just the fact that it wasn't _you_ to come up with this particular syntax? Have you even looked? Wouldn't it be better to use the experience the Spirit developers/users have collected over _years_ (!) and try to find a simpler API on top of Spirit directly extending from the existing one, certainly while limiting the possibilities in favor of a reduced feature set and a simplified usage model? </rant> Regards Hartmut