Hartmut Kaiser wrote:
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. 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. 2. Allow extension for non-string-related conversions 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.