D pointers

Zack Rusin zack at kde.org
Sat Oct 1 10:54:04 BST 2005

On Friday 30 September 2005 18:17, you wrote:
> My argument for flatten-where-possible is based on the need for extra
> allocations and indirections.

Which as people have already told you makes absolutely no difference and 
is pointless.

> I don't know what you mean by loss of flexibility: I never proposed
> getting rid of the d pointer - only not using it when possible.

No, that's not what I meant. Once you have members in the class you 
can't get rid of them, that's a loss of flexibility. And the argument 
that these classes are stable doesn't hold. Stable != won't change 
anymore. In our field saying that some code won't ever be changing is 
almost saying no one will be maintaining it anymore and it's 

> > Also if you want real world example of what kind of effect porting
> > of Qt 3 app to Qt 4 has look at:
> > http://blogs.qtdeveloper.net/archives/2005/08/24/qsa-120/
> Nice anecdote, but beside the point. 

I'm not sure whether you have some identity crisis which I should be 
aware of  but if I wanted to reply to your email only, top of that 
email wouldn't say:
"On Wednesday 28 September 2005 22:31, Stephan Kulow wrote:"
Maybe you're going through one of the "Wanna be like Coolo" phases, but 
trust me I know him and you're not it. So since he was complaining 
about the speed of Qt 4 this part was right on the money.

> Even without a convenient 
> algorithm change, if you start with a non-empty d-pointer structure
> and you flatten it out, you will go faster.

Oh, sure, you'll also go faster if you code it all in one big main 
function or even better write it in assembly. Hell, machine code all 
the way and we'll be flying...
The bottom line is this: people have shown you that the performance 
difference is negligible so flattening d-pointers makes no difference. 
The performance argument is bogus. And unless you can provide 
performance measurements of where it really matters you don't have an 
argument. At all.


Every man for himself, all in favor say "I"

More information about the kde-core-devel mailing list