On Tue, Oct 14, 2014 at 07:06:30PM +0200, Milian Wolff wrote: > On Tuesday 14 October 2014 13:44:30 Tomaz Canabrava wrote: > > On Tue, Oct 14, 2014 at 1:35 PM, Milian Wolff <[email protected]> wrote: > > > On Tuesday 14 October 2014 13:22:51 Tomaz Canabrava wrote: > > > > it has a QConfigGroup 'global' value that can be acced directly via > > > > .setValue and .value > > > > > > Why the global state? A QConfig should be valid for a single file and > > > constructed on-demand. If you want to share stuff and keep it open, adding > > > something like a KSharedConfig might be a good idea. But again, that is > > > something that could/should be built on-top of QConfig (imo). > > > > so I don't need to open a config file and parse it every time the user > > created a QConfig object. > > Then provide a QSharedConfig or let the user store the QConfig himself, if it > turns out to be a performance-bottleneck for him. > as i previously pointed out, this is one of the things i consider *bad* about kconfig. i wouldn't necessarily make a real cache, but the objects should be automatically shared in the background. that's what happens when you natively use the windows registry anyway.
> If you add global state to QConfig, you'll need synchronization or > otherwise you are doomed in a multithreaded application. > yes. so what? > Furthermore: If you keep the QConfig in memory all the time, you'll probably > end up duplicating the stuff as soon as you add the fancy high-level > interface > on-top. QConfig will operate on JSON after all and you'll incur a conversion > penalty whenever you read a value from it. The high-level interface should > (hopefully) read the values once and store it internally in the proper type. > you are right with that (that's why i don't think using the json classes as anything else than backend storage and having an abstraction layer on top makes sense), but i don't see how that correlates with the config objects being shared+cached. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
