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