Helping out with Krita

Clarence Dang dang at kde.org
Fri Mar 12 12:24:12 CET 2004


On Fri, 12 Mar 2004 09:08 pm, Boudewijn Rempt wrote:
> > Is it ok to add d-pointers everywhere - not for binary compatibility but
> > rather for decreasing compile time.  Without a d-pointer for KisView, for
> > instance, I would have to recompile more than just kis_view.cc if I add a
> > single variable to the KisView class.  Every so often, someone with CPU
> > to burn :) could move the d-pointer variables into the class proper.
>
> Well... First you have to tell me what d-pointers are :-). I haven't come
> across the term yet -- which isn't all that significant, having been
> working in C++ only since last October.
A d-pointer is a pointer to a private class containing more data members.  
It's ordinarily used as a binary compatibility workaround:

Normally if you add/remove a new data member to a class, you change the size 
and/or layout of the class creating 1) a need for a complete recompile of all 
code dependent on the header (this is very bad on my slow computer) 2) random 
behaviour/crashes with code that uses that class that hasn't been recompiled 
(won't happen in this case but would happen if KisView became public API).

So you add an extra pointer conventionally called "d" to the main class that 
points to an internal class to hold more data members so that you can add 
variables without increasing the size of the class.

e.g. in kis_view.h:

class KisView
{
public:
	KisView ();
	virtual ~KisView ();

private:
	KAction *ordinaryData, *moreOrdinaryData;
	struct KisViewPrivate *d;
};

in kis_view.c:

struct KisViewPrivate
{
	int clarencesNewVariable;
	int anotherNewVariable;
};

KisView::KisView ()
	: d (new KisViewPrivate)
{
	ordinaryData = KStdAction...
	moreOrdinaryData = new KAction...
}

KisView::~KisView ()
{
	delete d; d = 0;
}

Cheers,
Clarence



More information about the kimageshop mailing list