From kde-core-devel  Tue Jul 13 12:35:19 2004
From: Frans Englich <frans.englich () telia ! com>
Date: Tue, 13 Jul 2004 12:35:19 +0000
To: kde-core-devel
Subject: Re: Kcontrol memory leak
Message-Id: <200407131235.19841.frans.englich () telia ! com>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=108972186207905

On Monday 12 July 2004 16:27, Albert Astals Cid wrote:
> Hi, don't know if you remember that thread
> http://lists.kde.org/?t=107463750200003&r=1&w=2 where it told that each
> time const KAboutData* AccessibilityConfig::aboutData() const was called
> over a kcontrol module it leaked the KAboutData as most of the modules did
> a new KAboutData on each call, i presented a patch that took care of that
> in the kcontrol level, but it was rejected as there where some kcontrol
> modules that returned a static or class member so deleting it was wrong.
>
> Today i have looked at the problem and it is still there so i have spent
> the morning going though all the kcontrol modules in the cvs and ensuring
> they return a class member in that call so there is no memory leaked.
>
> I do not attach the patch as it is quite big and it basically adds a
> private KAboutData *mAbout; that is initialized in the constructor and
> deleted in the destructor and returned in the said call.

Wouldn't it be better with adding set/get members to KCModule instead?
For example:

public
	KAboutData* aboutData() const
	{ return d->aboutData; }
protected:
	void setAboutData( const& KAboutData about )
	{ d->aboutData = about; }
// and separate implementation/declaration, and initialize d->aboutData to 0

It should be possible without breaking compatibility in any way.

Then a simple call to setAboutData( new KAboutData(...) ); in the constructor 
of a module would be enough. It saves code and promotes a proper way to avoid 
that memory leak. No?

Cheers,

		Frans