Const iterators, what's next ?

[Bart Coppens]

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?

> 1) right now const and non const iterators share the same function
> signature, I mean we have (for instance):
Personally I have no objection against the sharing, but I agree that making it 
explicit makes for easier understanding of the code afterwards.

> Because in the current situation, if we have:
> KisPaintDeviceSP device = smthg;
> KisHLineConstIteratorPixel  it = smthg->createHLineConstIterator(smthg);
> Then it's the non const function that is called, and the iterator is
> converted to KisHLineConstIteratorPixel, and I am not sure that first
> creating a non const iterator is really a good idea ? Any thought ? (maybe
> bart or casper will know best)
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?

> 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.

> 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.

Bart