From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-24 08:32:28
>> ptree pt;
>> write_registry(..., pt.get_child("whatever.child.you.want"));
> That's not an interface *I* want to use for any configuration storage. I
> want this:
> whatever_class settings;
> settings["whatever.you.name.it"] = QPoint(10, 10);
> and then I don't want to invoke 'write_registry' or 'write_ldap' or
> 'write_ini' depending on configuration method that some other kind of
> program has choosen. I want setting to be saved behing the back.
In ptree, instead of
settings["whatever.you.name.it"] = QPoint(10, 10);
settings.put("whatever.you.name.it", QPoint(10, 10));
I believe the only difference is in syntax. The first one is marginally
simpler, but it does not allow you to distinguish between get and put
operations, and also does not scale well towards default value and
To automatically save settings behind your back, you need a wrapper over
ptree, that will among other things, decide when to save.
> Speaking again about program_options and property_tree interaction: if
> is ever to work, I want property_tree to expose some "changed" events,
> W3W DOM has, that I can catch to sync data back to storage. Without that,
> smooth configuration saving will be impossible.
I used ptree for saving configuration numerous times. I don't quite
understand what you mean by "smooth", but for me it was adequate without
notifications. In my case, saving was usually done in a destructor of some
high-level class, something along these lines:
If you need notifications - and I'm sure there are cases where you must have
them - this is the wrong library. Use program_options instead (when it adds
support for saving).