Subject: Re: [boost] [program_options] Proposed feature to provide option namespace prefixing
From: Chard (boost_at_[hidden])
Date: 2010-06-14 06:36:59
Monty Taylor <mordred <at> inaugust.com> writes:
> On 06/12/2010 01:20 AM, Vladimir Prus wrote:
> > Monty Taylor wrote:
> >> It seems like a possibly nicer or more integrated approach would be
> >> something that would look like this:
> >> module.register_options(commandline_options.add_options(module.get_name
> >> Is anybody interested in me reworking what we end up with to be usable
> >> or applicable back to the Boost core?
This sounds similar to something we're doing, where the first argument on the
command-line decides the mode of the program.
We wanted the convenience of being able to use a single configuration file,
but also the convenience of not having "section." prefixes on the command-
theProgram mode_1 config.ini
theProgram mode_1 opt1=value
theProgram mode_1 config.ini opt2=override
theProgram mode_2 optFoo=value // error: option not available for mode_2
At the moment we have a (simple, but a bit hacky) solution of prepending the
mode onto the command arguments, so +1 for anything that moves code out of our
base into the library ;-)
> > The only concern is that you simplify definition of options, however, it
> > seems that access to options still have to use fully qualified names.
> > Or do you have solution for that as well?
> I don't have a solution to that, but you're right, I should really come
> up with one. I guess my first concern was simply to prevent module
> authors from accidentally breaking namespace rules - but their code will
> certainly make more internal sense if they can access options using the
> same short names.
Is this a case of being able to 'bind' the variables_map to a domain, too?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk