RE: [boost] Re: Command line syntaxes

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-24 10:01:05

From:	Schoenborn, Oliver [SMTP:oliver.schoenborn_at_[hidden]]
> 
> From: Stewart, Robert [mailto:stewart_at_[hidden]]
> > 
> > One thing that I've found necessary recently, that hasn't been addressed
> in
> > these discussions, is the ability to split the command line. We have a
> > scenario in which two parts of the application, one of which we have no
> > control over, require command line arguments. We have adopted "@" as the
> > separator between the command line arguments for the parts. Thus, what
> > precedes "@" is given to one part, and what follows "@" is given to the
> > other part.
> 
> Couldn't this just be implemented with a special long argument?  This is a
> preprocessor type of problem, ie you really just need to look at the
string
> before giving it to the parser, to split the string in two (or more).  Is
> this problem general enough to become part of the parser's capabilities?

That won't work if the CLL is populating variables and otherwise providing
semantic reactions to command line arguments.  If it was just parsing the
command line and providing a collection of parsed arguments in the form of
simple values or tuples of delimiter, name, and value, then what you suggest
might work.

However, thinking further, my need to split the command line isn't going to
fit well with the CLL anyway, since I need to create a new argc/argv from
the real ones and some delimiter.  In my (admittedly unique) situation, the
part of the app that requires the beginning of the command line can just be
given a smaller count than argc, since it requires an argc/argv-like pair of
arguments (some other tool might ignore argc and look for the null pointer
at the end of argv, which would break this simple scheme).  Thus, I would
only be able to use the CLL to process from the delimiter argument to the
end of argv, so having it do the splitting -- except into a new argc/argv
pair -- is not something even I could use.  Consequently, I'm arguing
against my own suggestion; this functionality should not be built into the
CLL.

Rob
Susquehanna International Group, LLP
http://www.sig.com