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?
So far we were mostly discussing the interface.
Sorry, if I didn't make myself clear. I was referring to the interface as well. IMHO, any simplified interface for conversion operations should be compatible with the full blown Spirit API to allow for easy migration in case things get more complicated. It wouldn't be good to have yet another DSEL just for the conversion ops.
As for the implementation, I have nothing against using Spirit as a working horse for string-related conversions between the types it supports. However, I have expressed two requests that don't fit well (as far as I know) with Spirit: 1. Employ operator<< and operator>> for user-defined types.
Spirit supports that out of the box in two ways. a) it has the 'stream' primitive utilizing the user type supplied operator>>() and operator<<() for parsing/generating. I.e. user_type u; spirit::qi::parse(str, spirit::stream, u); spirit::karma::generate(std::back_inserter(str), spirit::stream, u); use the user supplied streaming operators for user_type. b) it exposes manipulator objects allowing to integrate parsing and generation with std io streams. I.e. int i; std::cin >> spirit::qi::match(spirit::int_, i); std::cout << spirit::karma::format(spirit::int_, i);
2. Allow extension for non-string-related conversions as well.
Spirit parsing and generation API's are based on iterators, not strings. So this request is already implemented as well.
I believe that support for these requests can live side-by-side with the "powered by Spirit" part that handles ints, floats, etc.
Again, I'm talking about the interface here, not the implementation (which is superior, BTW - Spirits numeric primitives are faster and more accurate than most std library primitives supplied by the existing compilers). Regards Hartmut