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 09:57:03

Thorsten Ottosen wrote:

> Vladimir Prus skrev:
>> Thorsten Ottosen wrote:
> 
>>>>> 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?
> 
> I specified vector<unsigned>, so it can't be a value in the list.

Yes, but the parsing level does not know about that, and making decisions
about possible syntax of values based on their type seems tricky at best.
If you know no ambiguity is possible, you can explicitly mark the option
as multitoken.

- Volodya