From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-04-05 11:04:42
> >> As long as JSON has a hierarchical structure, wouldn't it be better
> >> for you to use the future property_tree library?
> To which Boost library does property_tree belong? Is it Boost Property
> Map? I found a file propert_tree_rev5.zip in the Vault but it has been
> uploaded two years ago?
It will be a library on its own. I'm not really aware of the whole
story but basically it has been started some time ago and after having
been in standby mode during a while, it has restarted recently:
> > That's a good question. I actually wondered about using hierarchical
> > storage
> > for program_option, possibly based on property_tree. Nothing concrete at
> > this point.
> Yes, that's what I meant. Even if I can create my own parse function it
> won't help me if the file format I parse can't be represented by the
> storage used by Boost.ProgramOptions. But I guess the storage can't be as
> much generalized that someone who wants to use any file format X can
> create a parser for Boost.ProgramOptions, too.
Indeed, a few glue code between program_options and property_tree
library would be a very neat solution, I completely agree with this
idea. Let's keep it in mind until property_tree is released. For the
storage problem, why not merely insert some dots into the variable
names without changing anything to the storage model itself: you would
query variables["object.subobject.field"] to access a nested field.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk