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);
public:
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); new_name.push_back('.'); new_name.append(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:
module.register_options(options_context(module.get_name(), commandline_options.add_options());
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());
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?
Hi Monty, 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? Thanks, Volodya
Thanks! Monty _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost