Re: [boost] [program options] why is ->multitoken() not default for vector arguments?

Subject: Re: [boost] [program options] why is ->multitoken() not default for vector arguments?
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-06-09 00:16:05

Thorsten Ottosen wrote:

> Vladimir Prus skrev:
>> Thorsten Ottosen wrote:
>> 
>>> Hi,
>>>
>>> I have code like
>>>
>>>          bpo::options_description desc("Allowed options");
>>>          desc.add_options()
>>>          ("help", "produce help message")
>>>          ("file", bpo::value<std::string>(), ".sug file with graph
>>> description")
>>>          ("new_edge", bpo::value<std::vector<unsigned>>()->multitoken(),
>>>           "two numbers denoting the new edge");
>>>
>>> I had to add the ->multitoken to make a command like
>>>
>>> ./clique_tester.exe --new_edge 1 2 --file bug1.sug
>>>
>>>                               ^^^^^^^^
>>> work.
>>>
>>> This seems wierd. Why would I want a vector of values, yet only parse
>>> one of the trailing argument?
>> 
>> multitoken options are evil, because of parsing ambiguities. The motivating
>> examples for vector<string> option is the -I option of a compiler -- where
>> each instance of -I takes a single path -- and which seem to work just fine.
> 
> I fail to see this evilness. Something like
> 
> foo.exe --new_edge 1 --new_edge 2
> 
> is hardly readable. How can there be difficulties in parsing everything
> until the next --arg is reached?

Given 

        --new_edge 1 -2

Is -2 a short option, or part of --new_edge?

- Volodya