Kcontrol memory leak

[Albert Astals Cid]

A Dimarts 13 Juliol 2004 14:35, Frans Englich va escriure:
> 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.

It seems a good idea to me. 

What about library compatibility? Is it possible adding that methods to 
KCModule without breaking stuff? (i do not know but i have seen comments like 
this function should be never called but don't remove before 4.0 so we don't 
loose compatibility)

If everybody thinks it is a good idea adding that methods to KCModule and it 
does not break stuff i'll rewrite my patch.

Albert

>
> 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