[Boost-users] [program_options] parsing multiple times for different sets of opts

From: Liam Routt (caligari_at_[hidden])
Date: 2005-03-01 20:57:38

I'm very hopeful that program_options will simplify the mess that is the 
options parsing in our application, especially as it should allow us to 
handle command-line, config-fle, and environment-variable options in one 
logical step. This is all good.

My initial tests have run into a small hitch, and I'm wondering whether 
there is a way to do what I have been trying to do:

We have a core engine which has the largest options requirements.

For testing, mainly, we wrap that core engine and provide a user 
utility.

I'd like the core engine to be able to handle a broad set of options 
from all three directions (config, command line, environment). Easy.

I'd also like the wrapping utility to have its own (smaller) set of 
options that control what it does. Ideally this should be as logically 
seperate from the engine as possible.

At present we do this by simply not using command-line options for the 
core engine, and only using command-line options for the wrapping 
utility, but that is the fucntionality I most want to add at the
moment - the use of multiple methods of setting (most) options at both 
levels (wrapper and core engine).

What I would most like to be able to do is process the command line (for 
example) twice - once in the outer wrapping context, looking for the 
options that are relvant there, and once in the core engine, looking for 
the options there. When I try a test app with this structure, though, I 
get exceptions thrown when any options are encountered that are not 
included in both the options_descriptions used, which sort of defeats 
what I'm trying to do - I want to have two distinct sets of options: 
one for the wrapper, and one for the core, with (little or) no overlap.

I would be happy if I could disable the exception behaviour, allowing 
the processing to complete and report to me that it encountered some 
unknown options along the way. This would mean that I would risk 
ignoring some unknown options in both passes, but I could live with 
that, I think.

I can see a possible alternative, which requires me to pass the 
wrapper's options_description to the core engine, get it all parsed 
there, and pass back the map for examination by the wrapper. This would 
make some additional work for me, but would probably work fine. I guess 
I'd just like to know whether the other way of approaching things is 
going to be supported, or whether there is yet another approach I should 
consider?

Take care,

Liam
--
Liam Routt                                          Ph: [phone]
Research Programmer                               caligari_at_[hidden]
Computer Science, Melbourne University              (or liam_at_[hidden])