Re: [Boost-users] Re: Re: Program options: terminating parsing.

From: The Grumpiest Man You Know (mrgrumpyguts_at_[hidden])
Date: 2005-03-04 00:51:41

> > Well it's because there are two separate lists of options.  One to the
> > program that I'm parsing for and one for code that we just perform a
> > pass through to.  I have no control over the options recognized by the
> > other guy I just want to stop parsing when I get to them.  My solution
> > was to create a class that defined operator() and use it as the
> > additional parser.  Then once I spot the change from "my" to "his"
> > part.  I stick all the words n a dummy option.
> 
> The standard approach is the "--" token. Say:

Yes, but I can't change the syntax so can't use that.

> If you tell me the logic you use to detect the change from "your" to "his"
> option, I might suggest another approach.

I'd forget my head if it wasn't attached. :)  I really should have
added this shouldn't I? :)

Ok the image I am in is called "foo", it accepts a set of flags and
options.  Ideally I would be able to use "-option_word" or any
unambiguous substring there of, although I'm hoping to squeeze past
having to use "--option_word". At some point on the command line there
will be the name of command, pretty much the only thing I can say
about this is that it won't start with a "-" following this will be
zero or more arguments to the command, none of which I can parse.  So
the command line looks like:

foo -foo_opt1 value -foo_flag ... command_name -cmd_option cmd_val
-cmd_flag word ...

One of the options to foo is to name a file which consists of lines
that look like command lines each of which I am parsing with the same
code, now I have no zero length regexs :), by having my extra parser
class doohicky, ignoring the first word on the line if it's
instantiated with a bool initialiser.

I really appreciate your help and I'd love to hear the thoughts of
someone, unlike me, who knows what they're doing.  Thank you for your
time.

-- 
Blue Skies