From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-16 14:14:19
Hi,
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
programmers.
>
>
> 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
important
> 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
to
> 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
is
> 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
command
> line parser is a bad idea, because people should parse their own
command
> lines using spirit. While this is certainly possible, it makes
more
> sense (to me anyway) to use spirit internally for the command line
> parser implementation. But, that still restricts the user to
whatever
> 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
super
> > advanced grammar (like building a compiler), Spirit would be
worth the
> > effort for me to learn. But frankly, a simple line parser based
on
> > 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
or
> 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
form:
> real, (real), or (real,imaginary) and store the real and imaginary
parts
> in 2 doubles:
>
> bool parse_complex(char const* str, double& real, double&
imaginary);
>
> Writing this by hand would probably take 20 lines of code or so.
With
> 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
that's
> 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
Gennagiy.