[Patch] KDirModel fix for non-standard hierarchies
faure at kde.org
Wed Dec 3 16:42:51 GMT 2008
On Wednesday 03 December 2008, Olivier Goffart wrote:
> Le mardi 2 décembre 2008, David Faure a écrit :
> > On Tuesday 02 December 2008, Thiago Macieira wrote:
> > > On Tuesday 02 December 2008 11:46:44 David Faure wrote:
> > > > I rewrote qHash(KUrl) and now it's 60 times
> > > > faster than before...
> > >
> > > Do you mean commit 891419?
> > >
> > > Unfortunately, that change has to wait for KDE 5. That's a behaviour-
> > > incompatible change. Since qHash(KUrl) is inlined all over the place,
> > > code using the old hash will fail to find data inside QHash structures
> > > that were created with the new hashing.
> > Let's be pragmatic. On one hand there's a potential BC breakage for the
> > hypothetical case of two different modules passing each other a hash of
> > urls (I now grepped and I couldn't find that anywhere in trunk/KDE nor
> > extragear), [...]
> Also note that:
> - It is BC to make an inline function non inline (AFAIK) so the //KDE5
> comment can be removed.
True, I uninlined it now.
Technically only "uninlining and NOT changing the implementation" is BC.
Otherwise old code and new code running in the same process would still
use a different definition of the method, which for qHash can create trouble
like Thiago pointed out (if a hash created from old code is used in new code,
or vice versa). But since we agreed that the behavior change was ok for this
time, I might as well uninline and make future changes safe.
> Due to the fact that this might fail anyway and probably be useless, i suggest
> we just don't care :)
Agreed (useless, because there is no hash of urls exported by kdelibs itself).
David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel