Re: [boost] Boost.Convert+Boost.Parameter

Subject: Re: [boost] Boost.Convert+Boost.Parameter
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2009-02-28 12:17:41

> 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