Const iterators, what's next ?

[Cyrille Berger]

On Thursday 19 October 2006 00:43, Bart Coppens wrote:
> On Thursday 19 October 2006 00:25, Cyrille Berger wrote:
> > I have completed the first step of const iterators, at least the exposed
> > iterators are clean, the internal is a little bit hacky as it is
> > constructed on top of what we had before which wasn't designed with const
> > in mind. But I will leave to someone who know best to transform the
> > tilemanager to be cleaner.
>
> Pffff, as if I don't have enough stuff to do yet ;-) I'm wondering about
> anything specific hack you have in mind here?
Something to avoid the const_casting of the DataManager when creating 
iterators in the KisPaintDevice.

> (...)
> Wha? I think you were sleeping a bit when you wrote that part, or I am
> sleeping when reading. But I'm pretty sure it's you ;-) So could you try
> making this a bit clearer?
you have all allready answer the question :) so there is no point ;) (the 
idea, is that with the same function name, when creating a const iterator 
with a non const paintdevice, you first create a writeable tile iterator)

> > The next logical step is to transform it to:
> > virtual void process(const KisPaintDeviceSP src, KisPaintDeviceSP dst,
> > KisFilterConfiguration*, const QRect&) = 0;
>
> Cool, I hadn't actually ever considered using const together with a Shared
> Pointer, but this really makes sense, especially with const iterators that
> keep the paintdev const as well. If not here, we really should add this
> stuff more throughout the codebase where appropriate.
well a big part of this will come with 

> > The question we need to settle is "do we keep src" ? Or do we choose to
> > have this function in KisFilter : virtual void process(KisPaintDeviceSP
> > dev, KisFilterConfiguration*, const QRect&) = 0;
>
> Hrrrrrrrrm hrrrrrrm. This is a subtle issue. There is somebody who
> sometimes visits the #koffice channel and keeps saying that he wants to use
> the GPU for filtering images. The impression that I got is that it is
> already quite not-good with the tile border getting in the way, but that it
> is worsened by the fact that Rect Iterators for src and dst don't have the
> same
> nConseqPixels (ever noticed how that actually is a misspelling? It's
> consecutive, not consequtive ;-) Looks nicer with the q, though, I guess it
> adds a distinctiveness to it). So that might be an argument in favor of
> ditching src. But it might be easier to port code foreign to Krita with a
> separate src and dst. Plus, it is more intuitive. So I'm not convinced to
> chose any of the two options at the moment, maybe somebody else can answer
> this question better.
We have been pushing to answer this question for a long time now. The truth is 
that with constness of src, I am more confortable with having src and dst, 
but as constify it will ask some work that I am not willing to do if we think 
that we will change the signature of the function.

-- 
--- Cyrille Berger ---