Boost logo

Boost :

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-16 14:14:19


First of all I would like to say that IMO it is odd even to discuss
an ability to use Spirit for generic command line parser. It's like
use a canon to kill a fly. For one It is very expensive and heavy and
also I should drag it all over the place.

--- In boost_at_y..., Dan Nuffer <dnuffer_at_c...> wrote:
> Schoenborn, Oliver wrote:
> >>-----Original Message-----
> >>From: David Abrahams [mailto:david.abrahams_at_r...]
> >>Sent: Tuesday, January 15, 2002 11:54 AM
> >>To: boost_at_y...
> >>Subject: Re: [boost] Any interest for a parser class?
> >>
> >>
> >>Will you submit spirit to boost? I want to see it here; I
> >>strongly believe everyone will benefit.
> >>
> >
> > Seems to me Spirit is targetted at a very special group of
> Nope. Spirit is targetted at any C++ programmer who needs to do
> parsing, which is most of them. Even more so now in the age of the
> internet and all it's protocols which need to be parsed.
So now iin any place where we were using tokenizer or regular
expression I should pile up Spirit.

> > Spirit is an impressive piece of work.

I completly agree with that.

> So impressive, actually, that I
> > don't want to use it because:
> >
> > - I need to know EBNF notation (or an approximation of it, if
only to
> > understand the concepts); do I really want to learn a new
notation just for
> > command line parsing, or even file parsing?
> If a programmer doesn't know EBNF, then they are missing an
> piece of knowledge, since it's the standard for computer langauge
> definition.

Are you so sure? How is it in reallity?

> > - All I need is a toaster to *toast my bread*; not to also make
it, tag it,
> > bag it and deliver it in my plate and gauge the toasting level to
the bread
> > ingredients for the particular slice in the toaster.
> >
> Spirit is aimed to be a general parsing framework. It is not aimed
> be a simple command line parser.

That's the point.

> A command line parser would only
> require a small portion of spirit's capabilities. And, the library
> structured in such a way, that you only pay for what you use.

How much line of includes it will add to use a Spirit to parse a more
or less complex command line?

> I don't think that anyone is saying that having a simple to use
> line parser is a bad idea, because people should parse their own
> lines using spirit. While this is certainly possible, it makes
> sense (to me anyway) to use spirit internally for the command line
> parser implementation. But, that still restricts the user to
> option format(s) the command line parser supports.

Why would I want to use the Spirit in the implementation? Rather than
regexp or tokenizer? Is it that flexible that I can implement
arbitrary parsing with it?

> > In other words, perhaps for really special applications that need
> > advanced grammar (like building a compiler), Spirit would be
worth the
> > effort for me to learn. But frankly, a simple line parser based
> > token-parameters with error reporting is sufficient in 99% of
cases, fast to
> > build, extendable, robust, easy for everyone on the team to
understand, even
> > someone who knows little about parsing. It can't deal with
grammar as
> > complex what Spirit can, but so can't the average programmer.
> >
> Learning how to use spirit is no different than learning a new API
> library.

I would assume that command-line parser still will have MUCH more
simpler interface.

> Spirit makes parsing incredibly easy. Say, for instance you
> had to write a function that would parse a complex number of the
> real, (real), or (real,imaginary) and store the real and imaginary
> in 2 doubles:
> bool parse_complex(char const* str, double& real, double&
> Writing this by hand would probably take 20 lines of code or so.
> spirit, it's a one liner:
> return (
> real_p[ref(real)]
> | '('
> >> real_p[ref(real)]
> >> !(',' >> real_p[ref(imaginary)])
> >> ')'
> ).parse(str, str+strlen(str));
> Well, maybe more than one line if you want it too look nice, but
> one statement :-)

I would say that it will take at least 10 min for maintanance
programmer to grasp what is written here (and this is not counting
understanding how its working). I would implement the same logic in 2-
3 lines using tokenizer or regexp. Something like this:
token_iterator it( str, " \t," );

real = lexical_cast<double>( *it++ );
imaginary = lexical_cast<double>( *it );

> --Dan Nuffer


Boost list run by bdawes at, gregod at, cpdaniel at, john at