[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KAboutData(const KAboutData &)
From:       Simon Hausmann <sh () caldera ! de>
Date:       2001-03-25 18:49:09
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]