Boost logo

Boost :

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:

http://www.nabble.com/Status-of-the-Boost.Property_tree-library-td15977780.html

> > 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.

Bruno


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk