[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