Boost C++ Libraries: Ticket #6991: Provide a way to disable interspersed arguments

attachment set

driscoll@… — Fri, 15 Jun 2012 22:24:27 GMT

attachment → po.patch

driscoll@… — Fri, 15 Jun 2012 22:25:09 GMT

Okay, there's the patch, relative to the current svn trunk (rev78961). I didn't put a ton of effort into figuring out the best way to do it, but it seems to work and be relatively elegant. I also had trouble compiling the example program example/options_description.cpp so it's untested as-is, but it does build for me and basically the same patched seemed to work with 1.49.

What I'm not sure about is the best way to add the option to the library instead of hard-coding it. I haven't taken a good enough look to figure out where that should be added. (Maybe the style flags?)

I'm willing to help out a little on this, e.g. writing documentation, if it would help get it into a release. :-)

cc set

Mateusz Loskot — Fri, 15 Jun 2012 22:54:59 GMT

cc mateusz@… added

I asked it on boost-users, but perhaps it's missed. Is this ticket also related this issue #5201 ?

driscoll@… — Mon, 18 Jun 2012 17:24:43 GMT

Replying to mloskot:

I asked it on boost-users, but perhaps it's missed. Is this ticket also related this issue #5201 ?

I responded by email (assuming I got the address right) but it occurred to me it might be worth posting back here.

I thank the answer is "no". Though of course I'm not particularly well-versed in the library implementation.

From what I can see, the negative number problem seems to concern when multitoken cuts off its search. I know the code little enough that I'm confused how this happens, but if I use the following option description:

  desc.add_options()
    ("help", "produce help message")
    ("compression", value<string>(), "compression level")
    ("verbose", value<string>()->zero_tokens(), "verbosity level")
    ("email", value<vector<string> >()->multitoken(), "email")
    ;

and run

  ./example --email a b c --compression d

then it gives me a vector of ["a", "b", "c"] for email and a compression of "d". So obviously it's cutting off reading in --email arguments early.

My reading of issue 5201 is that something like --foo 1.0 -1.0 will cause reading of --foo's arguments to end when it sees the next "-".

(Incidentally this example is modified from the one at http://www.boost.org/doc/libs/1_49_0/doc/html/program_options/overview.html#id2500805 which has email as a value<string>. That seems wrong though... are the docs wrong there?)

(However, my analysis here could be wrong.)

My issue is just that when the parser hits the first argument that none of the "style_parsers" recognize, it should stop parsing and treat everything that follows as a positional argument. (This is the same thing that parse_terminator does when it sees a '--' argument on its own, except that the -- gets thrown away. That's why I added the desired behavior at that point in the code.)

attachment set

driscoll@… — Fri, 06 Jul 2012 00:21:00 GMT

attachment → po-allow_interspersed.patch

attachment set

anonymous — Fri, 06 Jul 2012 00:21:21 GMT

attachment → po-disallow_interspersed.patch

driscoll@… — Fri, 06 Jul 2012 00:23:37 GMT

Added two possibilities for a patch that allow the user to choose this behavior it via the style parameter of the basic_command_line_parser. The version with allow_interspersed is more consistent with the library now, but breaks backwards compatibility (see http://lists.boost.org/boost-users/2012/07/75101.php). The version with disallow_interspersed should not affect current programs.

driscoll@… — Fri, 06 Jul 2012 00:26:42 GMT

(Patches include a test case. They are relative to svn trunk @ rev 79301.)

anonymous — Wed, 17 Oct 2012 09:09:02 GMT

I'm sad to see that this patch did not make it into 1.52.0.beta1. Is there any chance of seeing it in 1.52.1?