From: Vladimir Prus (ghost_at_[hidden])
Date: 2008-04-05 05:45:50
Bruno Lalande wrote:
>> I'm interested in a more general approach to extend Boost.ProgramOptions
>> with new parsers. Then you could add a CGI query parser while I could add
>> a parser which reads configuration data from JSON files. Then however
>> Boost.ProgramOptions would need to support something more sophisticated
>> than key=value pairs. I'm not sure if this can be easily generalized?
> Maybe an extension facility for ProgramOptions parsers could be made.
> I don't know yet exactly how this part of the library is designed and
> how easy it is to extend it. My approach would thus be to implement
> what I've proposed by first merely making another whole parser. Then
> I'll have a better sight and I can decide if we can go further towards
> genericity and extension features. However, the extension
> possibilities of the library are already at a good level due to its
> separation into 3 parts: descriptions, parsing and storage. not sure
> if the parsing parts really has to be even more generic...
I don't either. A parser is basically a function, which anybody can call.
One does not have to register a parser with the rest of library in any
> As long as JSON has a hierarchical structure, wouldn't it be better
> for you to use the future property_tree library?
That's a good question. I actually wondered about using hierarchical storage
for program_option, possibly based on property_tree. Nothing concrete at
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk