Re: boost::program_options (was Re: [Monotone-devel] popt buggy)

[Vladimir Prus]

On Sunday 03 April 2005 03:39, Nathaniel Smith wrote:
> On Sat, Apr 02, 2005 at 04:16:51PM +0000, Julio M. Merino Vidal wrote:
> > Couldn't we use Boost::Program_options?
> >
> > http://www.boost.org/doc/html/program_options.html
>
> Fascinating idea.  I hadn't known this was added.
>
> >From a quick skim, it seems like it would work, except that it only
>
> supports doing the equivalent of poptStuffArgs at the end of the
> command line:
>   http://www.boost.org/doc/html/program_options/howto.html#id549275
> So
>   $ monotone -@ options blah
> would actually have to be parsed like current
>   $ monotone blah -@ options
> which I can't quite decide if is a problem or not :-).  Presumably
> it's not a big deal in practice; OTOH, it is certainly
> confusing/surprising, and it would be more elegant for the response
> file to insert its contents where the user said, like popt's model.
> I'm not sure this is fixable; program_options's model is to parse
> everything before giving user code a chance to react.

This is not fixable with the current version (boost 1.32), but it's fixable 
without breaking the design too much. The library allows one to pass 
"additional_parser", that will be called for each argv element. In 1.32, that 
parser could only return a single option, but for 1.33 I'll allow returning a 
vector of options. So the additional parser can recognize whatever response 
file syntax you like and return the vector of options from the file.

Of course, this only matters if the order of options is somehow important.

> It also, unfortunately, declines to provide a way to parse the file,
> which is a bit annoying, because who wants to figure out what the
> "expected" quoting rules etc. are?  Inexplicably, it actually _does_
> provide a function to parse a command line string into a vector, but
> only on Win32; 

That's because Win32 GUI applications don't have argv (at least you can't get 
on it in anyway portable way), so not providing tokenization code for win32 
would be very bad.

> it'd be nice if this function did something sane on 
> POSIX as well, and then could be used for "response files" directly.
> (I guess "something sane" on POSIX ideally involves knowing about both
> " and ' quoting, but even just providing the Win32-style parsing would
> be a perfectly fine first pass.  poptParseArgv appears to only support
> " quoting itself.)

This was requested once, IIRC. I think it's possible to add if needed.

> I can't figure out how things work when there is order dependence
> between options.  For instance, if the user says --debug --quiet, then
> --quiet should win; but if they say --quiet --debug, then --debug
> should win.  But by the time we see the options, all we know is that
> --debug and --quiet were both passed, and we don't know the relative
> order.  Maybe there's some specific support for this kind of thing,
> but if so it seems to be undocumented; if not, then it seems very hard
> to fix, since again, user code doesn't really get a chance to run
> until parsing is complete.  This is a showstopper for us; I don't
> think we can use program_options at all without this feature.

The example above is easy to handle. The parse_command_line function returns 
parsed_options that contain plain old vector<option>. It's easy to write a 
function that walks over this version and looks for options from (--quiet, 
--debug) set. When it sees an option from this set, the previous option from 
this set is erased from the vector. 

Without knowing more about your application, I can't say how this will scale.

Should you have any more questions, please ask!

HTH,
-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2

-- 
Vladimir Prus
http://vladimir_prus.blogspot.com
Boost.Build V2: http://boost.org/boost-build2