|
Boost Users : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-03-02 02:37:29
Hi Liam,
> 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?
The command line parser in 1.32 version of the library has a mechanism to
accept unregistered options. Unfortunately, due to oversight, that
mechanism is not available via any public interface. At the moment, I'm
cleaning up the command line parser implementation and hope to fix the
above problem, too.
But I also think you should be able to combine options_description and parse
both wrapper and core options at the same time. Something like that:
options_description desc;
options_description wrapper_options;
// .. fill wrapper options
desc.add(wrapper_options);
desc.add(core::options_description());
variables_map vm;
// parse options
core::set_options(vm);
Any reason this is not OK?
- Volodya
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net