Ok, if you need some help I would be interested in helping you. I also found some approach how to make static options. I am going to apply at Dr.Dobbs for an article. The idea behind static options is the following: 1. Any program knows which options it needs. Otherwise these are unknown options and the program would be unable to access them at all. 2. The approach of accessing options via strings (const or nonconst) is error prone. Since the user can change the option name, but that is not automatically propagated though all places in code. Let's say it would be possible to write instead of: options_instance["section.optionA"] options_instance.getsection::optionA(); Where section is the C++ namespace and optionA is a type. So if I rename my type from optionA to optionABC compiler will immediately blame that there is no type optionA in namespace section. Further optionA is a specialization of a template class which can also receive trait class template parameter. Therefore this trait will determine what is the result type of optionA and that can be propagated to the get<Type>() member. This will prevent users from using any_cast, since get-member function will do it internally and on the other hand compiler will check assignment on user side. So if optionA has a result_type vector<string> (std namespace assumed) it will disallow do the following code at compile time: int i = options.getsection::optionA(); since vector can not be casted to int. And on the other hand it will in most known cases prevent from any_cast exceptions. What do you think about this idea? I have implemented this at work it works really great and I have the permission to write an article for Dr.Dobbs. If this is interesting for boost it could be reimplemented from scratch based on ideas from article. On the other hand I could ask the company if they agree to make a donation to boost as base version for development start. To implement the template classes is not so difficult, difficult was to make some automated way of option generation. Here I used preprocessor meta-programming the symantic is like: //option tree (sequence of sequences) #define PP_MY_OPTIONS \ ((Section)(Option1)(TypeA)(TraitType)) \ ((Section)(Option2)(TypeB)(TraitType)) \ ((Section)(Option3)(TypeC)(TraitType)) \ ((Section)(Option4)(TypeD)(TraitType)) \ ((Section)(Option5)(TypeE)(TraitType)) PP_GENERATE_OPTIONS(SomeOptionsNameSpace, PP_MY_OPTIONS) so that later I could access: SomeOptionsNameSpace::singleton::instance()->getSection::Option1() ... With Kind Regards, Ovanes On Wed, Apr 2, 2008 at 8:11 PM, Vladimir Prus wrote:

Ovanes Markarian wrote:

...

Hello *!

I would like to know if there is any interest to support hierarchical configuraitons in boost program options library.

The idea is mainly:

[Level1] Option1 Option2 Option3

[[Level2]] Option1 Option2 Option3

I think this syntax may be helpful, and should not harm anybody, so patches to support will be welcome.

...

Access rules would be: Level1.Option1 or Level1.Level2.Option1

Sometimes it is very useful to introduce an additional level instead of putting a prefix to each option. On the other hand it might be beneficial during access.

PSEUDOCODE: option_group g = parsed_options["Level1.Level2"].as(); do_smth(g["Option1"]);

I've though about providing access to a specific set of options, probably on the level of variables_map, and probably making use of the property_tree library, but no concrete design yet.

- Volodya

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users