Subject: Re: [Boost-bugs] [Boost C++ Libraries] #6991: Provide a way to disable interspersed arguments
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-06-18 17:24:43
#6991: Provide a way to disable interspersed arguments
-----------------------------------+----------------------------------------
Reporter: driscoll@⦠| Owner: vladimir_prus
Type: Feature Requests | Status: new
Milestone: To Be Determined | Component: program_options
Version: Boost 1.49.0 | Severity: Problem
Resolution: | Keywords:
-----------------------------------+----------------------------------------
Comment (by driscoll@â¦):
Replying to [comment:2 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.)
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/6991#comment:3> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:09 UTC