[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-commits
Subject: Re: kdelibs/kdecore
From: Waldo Bastian <bastian () kde ! org>
Date: 2001-12-31 19:16:49
[Download RAW message or body]
On Monday 31 December 2001 08:33 am, Simon Hausmann wrote:
> On Mon, Dec 31, 2001 at 03:30:49AM +0000, Daniel Molkentin wrote:
> > kdelibs/kdecore klibloader.cpp,1.52,1.53 klibloader.h,1.45,1.46
> > Author: danimo
> > Mon Dec 31 03:30:26 UTC 2001
> >
> >
> > Modified Files:
> > klibloader.cpp klibloader.h
> > Log Message:
> > Added new convinience function KLibarary::unload() as discussed with
> > Waldo.
>
> I might be missing something, but I think that's a bad idea. Calling
> this method on a KLibrary object leaves the object in a completely
> unusable state. The factory pointer becomes a dangling pointer (crashes
> ahead) and the handle the library holds becomes invalid. The object pretty
> much becomes unusable, and there's no way to make it usable again. The
> only thing one can do is destructing the object. And surprise, guess
> what destructing a KLibrary object does? It closes the library ;-)
Not only that, It closes the library ignoring any refcounting that is going
on.
/**
* @internal
* Don't destruct KLibrary objects yourself. Instead use
* @ref KLibLoader::unloadLibrary.
*/
~KLibrary();
void KLibrary::unload() const
{
KLibLoader::self()->unloadLibrary(QFile::encodeName(name()));
}
The remaining question is why ~KLibrary is public and not protected.
Cheers,
Waldo
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic