From kde-core-devel  Sun Mar 25 18:49:09 2001
From: Simon Hausmann <sh () caldera ! de>
Date: Sun, 25 Mar 2001 18:49:09 +0000
To: kde-core-devel
Subject: Re: KAboutData(const KAboutData &)
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=98554631000548

On Sun, Mar 25, 2001 at 10:38:39AM -0800, Charles Samuels wrote:
> On Sunday 25 March 2001 09:58 am, Simon Hausmann wrote:
> > On Sun, Mar 25, 2001 at 09:46:19AM -0800, Charles Samuels wrote:
> > > Are there any arguments against me giving KAboutData a copy constructor?
> >
> > Then you should make all related classes completely value based
> > (KAboutPerson, etc.) and also add an assignment operator, IMHO.
> I disagree, this is relatively simple class, and absolute maximum speed is 
> required, since the hit is startup, and that's where KDE has the most speed 
> problems.

Where's a performance problem with adding a method?
 
> >
> > > Each Noatun plugin will have a function capable of returning KAboutData,
> > > where the framework will create the KAboutDialog from that.
> >
> > Usually there exists only one KAboutData object per instance, so what about
> > retrieving a pointer to the plugin's KAboutData instead? (like it is done
> > for kparts components for example)
> >
> > (of course making clear that the ownership remains with the plugin)
> And the code would be significantly easier to write and maintain.  I don't 
> see how returning a pointer to the plugin's KAboutData is any different than 
> using the copy constructor, other than making the code simpler.

If you add a copy constructor then the semantics should IMHO be made clear that
it is a value based class. Objects of that type can be assigned using the copy
constructor or using the assignment operator. A class that has only a copy
constructor but no assignment operator is broken IMHO (in this context of
kdelibs/qt API)

Bye,
 Simon