Ticket #5201 (new Bugs)
Negative numbers as options and values not parsed correctly
|Reported by:||mloskot||Owned by:||vladimir_prus|
|Milestone:||To Be Determined||Component:||program_options|
|Version:||Boost Development Trunk||Severity:||Problem|
This issue has been reported initially on StackOverflow? in question Accepting negative doubles with boost::program_options and later reminded on the mailing list in thread program_options negative numbers. Not sure if it is a bug or lack of feature, but seems it would be reasonable to have it solved.
Simply, program_options can not parse negative numbers as values of options. For example:
mycommand --extent -1.0 -2.0 -3.0 1.0 2.0 3.0 --some-other-argument somevalue
I discussed this issue with Volodya on IRC and there seems to be possible and not difficult to implement solution. Here is the chat script:
Nov 10 17:04:17 <mloskot> volodya: I think it's feasible to refactor the loops in the cmdline parser to handle multitoken options with negative numbers as values. I have an idea to add ::multitoken(int exact_tokens_num) and make parser consuming as much values as the exact number of tokens specified, regardless how the options look like Nov 10 17:04:26 <mloskot> volodya: what you think about this idea? Nov 10 17:04:28 <spitzi> The question is - supposed that I want to make some quick-and-dirty struct for the sake of having related, named fields tied together, but without going through writing c'tors and operators. Can a list of such structs be initialized with boost::assign::list_of ? Nov 10 17:05:30 <volodya> mloskot: well, I think that if that translates into min and max number of tokesn of the option being equal to that value, it seems sane Nov 10 17:05:53 <mloskot> volodya: yes, basically that would be the thing Nov 10 17:05:55 <volodya> and of course, when min=max, there's no need to guessing. Nov 10 17:05:59 <volodya> ok, sounds good.