changing the parent of a KConfigGroup

kde.braxton at gmail.com kde.braxton at gmail.com
Fri Jan 4 07:00:11 GMT 2008


On 1/3/08, Oswald Buddenhagen <ossi at kde.org> wrote:
> On Thu, Jan 03, 2008 at 02:04:11PM -0600, Thomas Braxton wrote:
> > On 1/3/08, Oswald Buddenhagen <ossi at kde.org> wrote:
> > > > +    if (destination == source) {
> > > > +         // simple optimization for when copying a group to a
> different
> > > > +         // parent without changing the name
> > > >
> > > i tend to think that this optimization is pretty pointless in practice,
> > > and as it adds complexity ...
> >
> > it's for the case of copying a group to another config file but still
> > using the same name, it avoids replacing the name with itself that it
> > would do in the other loop.
> >
> i know. ;)
> my point was that it doesn't happen particularly often, so the added
> complexity might not be worth it. anyway, see below.
>
> > > it would make sense to consider a truly hierarchical entry map at
> > > this point. i have some ideas if you want to start on that.
> >
> > sure, send your ideas and we'll see what we can make of them :)
> >
> ok. i think i'll simply extend the todo file. have to handle the mail
> backlog first, though.
>
> > Index: config/kconfig.cpp
> > ===================================================================
> > --- config/kconfig.cpp	(revision 755974)
> > +++ config/kconfig.cpp	(working copy)
> > @@ -113,6 +113,51 @@
> >      return true;
> >  }
> >
> > +void KConfigPrivate::copyGroup(const QByteArray& source, const
> QByteArray& destination,
> > +                                KConfigGroup *otherGroup) const
> > +{
> > + [...]
> > +    if (destination == source) {
> > + [...]
> > +    } else {
> > + [...]
> > +            qDebug() << __PRETTY_FUNCTION__  << "copying...\n\told key =
> [" << group << ',' << key.mKey << ']';
> > +            KEntryKey newKey = key;
> > +            newKey.mGroup.replace(0, len, destination);
> > +            qDebug() << "\tnew key = [" << newKey.mGroup << ',' <<
> key.mKey << ']';
> > + [...]
> > +    }
> > +}
> > +
> ok, assuming that the optimization *is* worth it: the two loops are
> different only by the (non-) execution of the replacement. so put
> the dest == src result into a bool and use it in an if in the loop -
> branch prediction will do the rest. less code to read, maintain, etc.

that's a good idea :)

> > +++ config/kconfiggroup.cpp	(working copy)
> > @@ -1270,3 +1270,30 @@
> >
> > +void KConfigGroup::reparent(KConfigBase* parent)
> > +    d = KConfigGroupPrivate::create(parent, d->mName,
> parent->isGroupImmutable(d->mName), false);
> > +    oldGroup.copyTo(this);
> >
> reparenting an immutable group sort of makes no sense, so this needs
> *some* special handling. i *guess* it would not really work as is now
> anyway.
>
damn, I totally missed that, read-only groups too :(
so, should they be asserts or just ignored?

> --
> Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
> --
> Confusion, chaos, panic - my work here is done.
>




More information about the kde-core-devel mailing list