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
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