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