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: (03) 8344-1315 Research Programmer caligari_at_[hidden] Computer Science, Melbourne University (or liam_at_[hidden])