Vladimir Prus wrote:
Hi Jody, Hi Allen,
Allen Bierbaum wrote:
Is there any way to tell the program options parser to ignore options that it does not recognize? If there is no option like this, how can program_options be used with other option parsers?
Jody wrote:
I am not familiar enough with the library to know the "correct" method. The only thing I can think of is that the interface is lacking. I took a few minutes to look at the code in libs/program_options/src/cmdline.cpp and it looks like the only interpretation is empty or a valid option name.
Ok, let me start with a caveat: ignoring unknown options can be ambiguous:
program --something 10 --known_option
Now, is "10" a value of unknown option or positional option? To remove the problems all unknown options must use this form:
--something=10
which may be problem, or may not, depending on your situation. What do you think?
I recognized that this could be a problem and I think I can work around it. One option I had thought of and have seen in other option parsing libraries is to have the parser method modify the arguments passed and remove the arguments it recognizes. This would be able to handle cases like "--something 10" above if the parser for that options was called first, but I don't really like the idea of modifying the argument list. If it was done it should definitely be optional.
So, at this stage, I think it requires an interface change to support this option.
The detail::cmdline constructor actually has 'allow_unregisted' parameter, which is intended to help with this. However, no non-detail interface allows to specify. Frankly, I don't know if I forgot about this or just decided to wait for a user to request this feature explicitly.
I ran across 'allow_unregistered' and wondered if it would do the trick. I just couldn't figure out how to use it since there is no non-detail interface for using it directly. How could I use this ability through the current interfaces (even if I have to poke into the detail interface a bit)? (I am restricted to boost 1.32 for this project) For example what would I change the following code to in order to make it use allow_unregistered? po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("my_opt", po::value<int>(), "set my option") ; po::variables_map vm; po::store(po::parse_command_line(ac, av, desc), vm); po::notify(vm);
Adding a new method to the 'common_command_line_parser' to set 'allow_unregistered' flag and then tweaking common_command_line_parser::run should do the trick? Opinions?
That is where I expected to see it. That doesn't mean it is the right design, but it was the expected design. -Allen
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost