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

List:       kde-commits
Subject:    Re: kdenonbeta/kopete/libkopete/ui
From:       Martijn Klingens <klingens () kde ! org>
Date:       2003-02-17 18:58:00
[Download RAW message or body]

On Monday 17 February 2003 05:40, Jason Keirstead wrote:
> What exactly is the benefit of using d pointers in this instance? I mean,
> all the objects you moved there are QObjects, and QObjects are always
> deletd when their parent is, so I don't see the benefit

Huh ?

The idea of d pointers is not that they are automatically deleted :)

The basic idea is that d pointers help you maintain binary compatibility 
because you can add data members to the private object at will without making 
the main object's size change. After all, the definition is only in the .cpp 
file, code that does 'foo = new KopeteEmailWindow' just allocates the space 
for a single 4-byte d pointer and doesn't care about the amount of memory 
that the object allocates internally. This also means you can add data 
members to libkopete and recompile without having to recompile the plugins.

However, although getting libkopete BC is IMO very important for the medium 
term (hopefully around KDE 3.2, but I'm afraid we won't have proper BC by 
then), the main reason for this change is that not requiring all those object 
definitions helps to massively cut down on the amount of #includes in .h 
files and thus compile time. This particular file included no less than 9 
files in the .h file, and I got this down to the .h files of the two base 
classes, KopeteView and KMainWindow.

Now this is still not too impressive as the file is hardly included elsewhere, 
but my grep just counted the amount of #includes and I picked the highest 
scoring to do first...

-- 
Martijn

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