RE: [boost] Re: Command line syntaxes

From: Schoenborn, Oliver (oliver.schoenborn_at_[hidden])
Date: 2002-01-24 09:47:14

> -----Original Message-----
> From: Stewart, Robert [mailto:stewart_at_[hidden]]
> Sent: Thursday, January 24, 2002 8:06 AM
> To: 'boost_at_[hidden]'
> Subject: RE: [boost] Re: Command line syntaxes
> 
> 
> From:	bill_kempf [SMTP:williamkempf_at_[hidden]]
> > 
> > --- In boost_at_y..., "Schoenborn, Oliver" <oliver.schoenborn_at_n...> 
> > wrote:
> > > > Schoenborn, Oliver wrote:
> > > > >
> > > > > Sorry if this has already been explicitly ruled out, but is there
a
> > > > > reason for not distinguishing between long and short arguments by 
> > > > > using - for short and -- for long?  
> > > > 
> > > > I find it the best syntax. In fact, this is what you get with the
> > > > predefined "unix" style. However, people was asking for long options

> > > > names with a single dash/slash. 
> > > 
> > > Yes, but just because users ask for it doesn't mean it is a good 
> > feature to
> 
> This is important to any design.
> 
> <snip>...</snip>
>
> Why must the CLL force one or the other?  An option could be specified as
> long or short, the library user could specify the delimiters to use for
long
> and short options, and the rest would "just work." 
> 
> <snip>...</snip>
>
> Clearly, for that to work, the CLL would need to indicate which delimiter
> was found together with the option name and value, if any. That allows the
> client to decide how to do the assignment. ... In general, however, there
> should be a policy class function that determines how to assign values
based
> upon the delimiter. Thus, the CLL defers to the policy class to do the
> assignments, which can, in turn, take advantage of standard mechanisms
> supplied with the CLL.

I like that idea a lot.

> 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?

Oliver