[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    RE: QMap bug ? (Re: kioslaves don't die?)
From:       David Faure <David.Faure () cramersystems ! com>
Date:       1999-11-11 12:03:57
[Download RAW message or body]

> At Don, 11 Nov 1999 David Faure wrote:
> > > Hi
> > > 
> > > ok, now we know we have to fix it - if QMultiMap is not here in the
near
> > > future. But we better don't count on that. Should we do the change to
> > > QMap/QList?
> > 
> > Yes, looks like.
> > Can you have a go at it ?
> > 
> 
> Hmm. Only if it doesn't really hurry. I cannot promise whether I can do it
this
> evening. And from Friday until Monday I'm not at home - I would have the
time
> but I don't have a laptop :(
> 
> Two issues:
> 
> - kdelibs is feature-frozen - isn't it? Does it matter that the change
would
> affect binary compatibility of KIOSlavePool? Looks like a rather internal
> class. Does it affect binary compatibility at all if we change/add static
class
> members?

Feature frozen means : don't break it and don't add new features.
No problem for applying (tested) bug fixes.
Binary compatibility is not an issue at all (although a bit inconvenient).

BTW static members don't affect the object size so they don't break 
binary compatibility.

> - we need a "total slave count" to delete the oldest slaves if the number
of
> slaves becomes to large. Any "smarter" but also efficient solutions than
> keeping a static int as counter? Also I cannot see how the slaves are
actually
> terminated by calling remove() on the QMap object.. Is this another bug?

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems

[prev in list] [next in list] [prev in thread] [next in thread]