finalizing the Iterator API

Casper Boemann cbr at
Wed Jul 7 00:15:08 CEST 2004

> > >From you experience with the other iterators, are there anything you
> >
> > like to change navigationvise - now that we have the chance..
> >
> > GOF uses done() to check for reaching the end. You use another iterator
> > compare with. GOF also lists your method as an alternative (also lists
> > alternative of advance() returning a status) so I'm not saying there is
> > anything wrong. It's just a matter of taste, and now that you have had
> > experience with use, you might have som wishes.
> Unfortunatelly my experience has been "polluted" by the STL, which use
> and end(), and Qt et kdelibs use also begin() / end(), so I think we
> keep them.

Ok fine, I kind of prefer those as well for the very same reason. Just
wanted to be sure, that you or anyone else wouldn't argue for changes. If we
are going to do a rewrite we might as well harvest any experience. It's
settled then.

> As for the ".h", here is my opinion :
> * I don't see the difference between KisPixelIterator and
> KisPixelRectIterator.

Well KisPixelIterator is just a super class (oh I forgot that in the class
definition didn't I)
Other subclasses besides Rect could be Path or Line, or Extent
They only visits some pixels. The superclass doesn't really do anything - I
think it should be abstract.
And as Boudewijn said up,down.left,right might be nice functions, however
they don't make sense for a PathIterator. I have had this idea myself, but
on reflection: when would they really be used.
Another Iterator I just tought of is an afine transformation, used to scale,
rotate and shear images.

> * the reason why I made two iterrators (one for the line and one for the
> pixel) was that it might be usefull to skip a line or to go back to the
> beginning
> * I think that iterrator should not return a pointer, but they should be
> to give the value of a pixel and to modify it so that why I started to add
> the two following operators :
> operator QUANTUM ();
> operator=(QUANTUM v);
> * I do really think that we need an operator that return a class
> a pixel, a class which look like this :
> class PixelRepresentation {
> public:
> operator[](Q_INT32 a);
> operator=(PixelRepresention a);
> }
> which may be use like this :
> PixelRepresentation a;
> PixelRepresentation b;
> a[RED] = 0.2*b[BLUE] + 0.6*c[RED] + 0.2*c[GREEN]
> a[BLUE] = 0.4*b[BLUE] + 0.3*c[RED] + 0.3*c[GREEN]
> a[GREEN]= 0.6*b[BLUE] + 0.1*c[RED] + 0.3*c[GREEN]
> b = a;

I think Boudewijn said it best. Also it doesn't allow int and float mixed og
even double and float. or 8 and 16 bit int.

Also it means that every pixel needs to be copied several times.

The prime requirements when defining our pixel representation are:
1) it should store only the actual channel data. No configuration data -
since that would cost too much memory when storing several millions of
2) it should allow any combination of int8, int12, int32, float,double, bits
3) copyable without knowing interpretation
4) it should either be
   a) truly universal, but that requires configuration info clashing with
requirement 1
   b) dynamic down-castable to specific imagetypes but that also clashes
with 1
   c) static down-castable which is what my proposal does.

Anyway , the GOF (p 91 bottom paragraph) discusses a similar problem, and
doesn't refer to a usable pattern. It actually alludes that there are none
except the same solution I propose. Note our problem is even worse because
we have even more requirements.

We could change my proposal to a pointer to an entirely empty class, but
that is only name calling, and we would still have to static downcast to
specific subclasses in the colorstrategies.

The problem with an empty class is that calling sizeof() would be wrong (can
sizeof be overloaded to give a compile error?). Also an empty class that
actually contains something seems wrong to me conceptually. For example you
cannot have an array of these empty classes. The byte array seems more

The benefit of an empty class is that the iterators return a pointer to a
Pixel class, which may seem more descriptive to the programmer.

Anyway I'm willing to use an empty class, if the rest of you insists. I do
however think it gives more complicated and errorprone code, but it is
definitely doable.

> as for accessing to the tilenumber by (col,row), i don't understand why it
> usefull ?

yes it is because of the dynamic layersize I'm working on. It may be
possible to encode the row,col as a single number but that would just be yet
another calculation to do for no real benefit. Row and col of a tile remain
the same when the size of the device changes. tilenum does not as it depends
on the number of columns (which obviously will  no longer be constant)

best regards
Casper Boemann

More information about the kimageshop mailing list