[boost] Re: program_options: configuring array-like objects

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-09-22 10:29:00

Hi Maurizio,

> For instance for a block containing a register file I'd like to be able to
> say things like:
> 
>   [block]
>   regs[10] = 0
....
> Having to modify the library itself, a quick (and obviously dirty)
> change would be to check for [] when parsing the option name and stuffing
> it as prefix to the value so that user defined parsers can take care of
> it. 
....
> With an appropriate type declaration for regs we can cause the appropriate
> user defined parser for doing the validation.
> 
> So I guess I have three questions:
> 
>    - would be an extension to program_options to take care of the
>      initialization of array-like object considered of general enough
>      interest to deserve a place in the library?

I don't know yet, since "general interest" is the number of users which want
this feature. So far, you're the first one. We'll see..

>    - if not, does the quick-and-dirty approach outlines seem viable to
>    people
>      familiar with the program_options library?

Yes, I believe it's viable.

>    - any other suggestions for a cleaner/more general implementation?

Now that you note this, I realize that while command line parser has a hook
for custom option styles, the config file parser does not. For example, it
would be possible to call a boost::function when the comments and section
headers are processed. That way you can write a function which will do
exactly what you propose, and pass that function to program_options. The
advantage is that you don't need to hack the code.

You can find a patch against current CVS which implements this idea at:

   http://zigzag.cs.msu.su/~ghost/custom_cfg_parser.diff

In particular, the change in
libs/program_options/example/multiple_source.cpp defines the extra parser
and the corresponding "cfg" file makes use of the extra syntax supported by
the parser.

This is the first draft, I'll have to polish it before adding, and this
won't be in 1.32 anyway. Comments are welcome.

- Volodya