Re: [Boost-bugs] [Boost C++ Libraries] #6991: Provide a way to disable interspersed arguments

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