Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-01-18 16:39:06


On Friday 18 January 2002 04:19 pm, you wrote:
> Douglas Gregor wrote:
> > On Thursday 17 January 2002 03:19 pm, you wrote:
> >>If I understand you correctly, this model forces the programmer into
> >>writing code like this:
> >>
> >>// Pseudo-code
> >>while ((arg = parser(i, j)) != PARSE_END) {
> >> // Do something with this argument
> >>}
> >>
> >>Other bits of discussion have focused on speparating syntax
> >>analysis and semantic action. This model doesn't allow that
> >>unless "Do something with this argument" builds an AST or
> >>parse tree, which a parser should already do.
> >
> > I depends on how you define the Parser concept, of course. It could
> > return an AST,or perhaps an argument*, where argument is a class that can
> > contain any argument that will be passed to the user. The interface
> > between the CLA parser and other arbitrary parsers need not equal the
> > interface between the user and the CLA parser.
>
> Er...you lost me. :) What "other arbitrary parsers" are there?
> I'm missing something important in your design, I think.

Sorry, I'll try again. Let's assume that CLA is a command-line parser class.
CLA will contain the ability to parse several types of options (e.g., -foo,
--bar=value). However, we know that CLA can't always do everything that the
user needs, so CLA needs to be extensible to be able to meet the needs of
these users.

I'm suggesting that for this extensibility, the CLA class allow the user to
give it a function object that is responsible for parsing part of the command
line. The function object would then be a Parser that can parser some or all
of the remaining command line, and tell the CLA class what it did. This way,
the CLA class is extensible by any option syntax the user can come up with,
as long as they can write a parser to handle it.

If that didn't clarify things, I'll wait until I look at a concrete
implementation of a command line argument parser and describe how it is or
could be extensible by user-defined parsers.

        Doug


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk