Kcontrol memory leak

[Albert Astals Cid]

Looking again at KCModule i see that 

/**
   * This is generally only called for the KBugReport.
   * Override and have it return a pointer to a constant.
   *
   * @note it is mandatory to implement this function.
   *
   * @returns the KAboutData for this module
   */
  virtual const KAboutData *aboutData() const { return 0; }

it says you have to override it.

To make the code you suggest work, the virtual should be removed to ensure 
kcontrol modules make use of the setAboutData and KCModule's aboutData and 
not the redefined aboutData, but the BC will be broken (if i undestand 
http://developer.kde.org/documentation/library/kdeqt/kde3arch/devel-binarycompatibility.html 
correctly) if the virtual is removed.

I think maybe i could commit my patch for now and maybe make a comment for 
KDE4 to change how KAboutData is handled to make what you suggest.

Any more ideas? 

Albert

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