Idea: SkipDirtyOnIdenticalValues WriteConfigFlag for KConfigBase / KConfig

[Eduardo Robles Elvira]

El Viernes 23 May 2008, Oswald Buddenhagen escribió:
> and why exactly would you want to pollute the api with such nonsense? is
> there any reason *not* to use it everywhere?

I've been convinced by thiago and ereslibre too that this flag really has no 
need to exist and that this should always be done. I attach a patch to 
*always* do the optimization. Now, being a case of a bug being fixed, this 
could actually enter into KDE 4.1, I guess.

> the hard part is finding out whether the entry map was actually modified or
> not - its api does not provide that comfort currently.
> to do it efficiently, the setter function should obtain a non-const
> reference to the entry it writes, check whether it was just created or
> existed before (dunno, maybe a flag in the struct) and set the new value
> and return true if either the old value was unset or differed.
> disclaimer: i haven't looked at that code for months.

The optimization of cheking if the entry already existed is not done by 
KConfigGroup::hasKey() either so I haven't done it, I actually think it's too 
much but if anyone wants, feel free to do it =) Else.. should I commit?

Greetings,
       Eduardo Robles Elvira.
-- 
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man." (George Bernard Shaw)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kconfig-save-power.patch
Type: text/x-diff
Size: 985 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080523/5083ddf2/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080523/5083ddf2/attachment.sig>