Smart pointers and color strategies

[Boudewijn Rempt]

On Sunday 31 July 2005 19:52, Casper Boemann wrote:
> On Sunday 31 July 2005 19:46, Boudewijn Rempt wrote:
> > Since we basicallly have only one copy of each color strategy, and since
> > we don't want to delete that copy ever -- why do we actually use smart
> > pointers for color strategies? With Krita going to the color strategy for
> > every little pixel computation, wouldn't it be smarter to use plain
> > pointers and not have the overhead of smart pointers?
>
> good point
>
> I'm not sure the overhead is that big, but I'm all for it.

I don't know either, but it's an extra function call, isn't it?

const T* operator->() const { return ptr; }

Maybe the compiler smartly inlines this...

Anyway, would it be as simple as 

perl -p -i -e's/KisStrategyColorSpaceSP/KisStrategyColorSpace\*/g'? It's worth 
a try, but first I'm going to see if I can find out why filling a selection 
hangs on the completely innocent line

 m_writable = writable;

in the tiledhline iterator constructor...

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20050731/f6afe27f/attachment.pgp