Subject: Re: [boost] [program_options] Proposed feature to provide option namespace prefixing
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2010-06-12 04:20:07
Monty Taylor wrote:
> Our approach to doing this with Boost.Program_options at the moment is
> to wrap options_description_easy_init in a class. Something like:
> class DRIZZLED_API options_context
> const std::string &module_name;
> po::options_description_easy_init &po_options;
> std::string prepend_name(const char *name);
> options_context(const std::string &module_name_in,
> po::options_description_easy_init &po_options_in);
> options_context& operator()(const char* name,
> const char* description)
> std::string new_name(module_name);
> po_options(new_name.c_str(), description);
> return *this;
> Then in server plugin registration, a context is created around the real
> program_options and is is handed to the plugin module:
> It seems like a possibly nicer or more integrated approach would be
> something that would look like this:
> And given the mapping of config file sections to name-dotted prefixes,
> it seems like it wouldn't be a ridiculous addition.
> Is anybody interested in me reworking what we end up with to be usable
> or applicable back to the Boost core?
it seems that what you propose can be accomplished by adding a new
member to option_description_easy_init, and then doing string
concatenation in the three operator() methods? It seems pretty reasonable
thing to do, and I'll be happy to integrate patches to that effect.
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?
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk