D pointers

Frans Englich frans.englich at telia.com
Sat Oct 1 18:40:34 BST 2005

On Saturday 01 October 2005 17:13, George Staikos wrote:
> On Saturday 01 October 2005 12:38, Stephan Kulow wrote:
> > > > > The optimising compiler will very likely elect this->d to be cached
> > > > > in a register, just like this itself is.
> > > >
> > > > Yeah, right. Glad we have soo many registers on i386.
> > >
> > >   I'm glad someone else pointed this out.  I was trying to get out of
> > > this conversation altogether (and I will just revert changes to my own
> > > classes that I don't like), but this is a very valid point.
> >
> > Your classes? That are? I think it's fair to say I will revert your
> > account if you stay out of a discussion to come up with a policy and then
> > revert changes because you don't like the policy. This is not about
> > personal taste, this is about a consistent API.
>   Sure I could not maintain my code too.  Then we could be closer to 100%
> unmaintained kdelibs.  Cool.

No no. The point is missed. From my understanding Coolo is referring to the 
scenario where maintainance is done in a way which conflicts with a general 
consensus and therefore is generally considered wrong. So, to follow up the 
comment; yes, it would make sense to revoke access and therefore maintainance 
since the maintainance was done wrong.

I think there's no one who tries to propose changes which increases 
flexibility on the cost of significant speed reduction -- because no such 
case have yet been posed. Well, it's under ongoing discussion.

However, I wouldn't be surprised if there are exceptions to that it is in 
general good to use d-pointers, since KDE have a lot of special cases(think 
compilers, engines, rendering). If someone said "In this particular app, in 
this special case, a d-pointerification leads to this speed penalty, just 
look at /these/ numbers," then the case is different, and an exception to the 
rule would make sense.

But, the common case is that d-pointers are an overall win. I think the best 
result would be achieved that everything was d-pointerified, and that if 
someone wanted to fold back with a performance motivation, they /have/ to 
back it up with profiling numbers.



More information about the kde-core-devel mailing list