Re: [Boost-users] [program options] new feature

From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2008-04-02 14:49:54

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.get<section::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.get<section::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()->get<Section::Option1>()
...

With Kind Regards,
Ovanes

On Wed, Apr 2, 2008 at 8:11 PM, Vladimir Prus <ghost_at_[hidden]> 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<option_group>();
> > 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>