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

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

> > 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