finalizing the Iterator API

Casper Boemann cbr at
Wed Jul 7 07:49:16 CEST 2004

> oh I forget, I dislike friendly in c++, and I think we just have to make
> KisTileMgr a private field in KisPaintDevice, and it will do the work.

Huh, what do you mean ?
If you mean a field in iterator, and that tilemgr provides appropiate access
methods, then yes it can be done like that. But it also allows everybody
else to use those access methods breaking encapsulation more than need be.
Friend is not the thing I like the most about c++ either but it has its good
points and this is one of them.

> > 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
> > pixels.
> What do you mean by configuration data ?

The number of channels, types of the individual channels and/or the image

> > 2) it should allow any combination of int8, int12, int32, float,double,
> > bits 3) copyable without knowing interpretation
> I think that in a given color strategy the type of the pixel is fixed.

Yes indeed that is the intend., but if you are going to store it in a class,
that definition has to be repeated there
Note: 3 should more precisely be that it should be runtime polymorph. ie all
code outside colorstrategy should be able to treat it in a uniform way

> > 4) it should either be
> >    a) truly universal, but that requires configuration info clashing
> > 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.
> why not a template ?

That could be listed as option d yes, but not good because it would break 3,
requiring as many different versions of paintdevice as there are imagetypes.

Note however that when it comes down to making the colorstrategies (and
corresponding specific Pixel classes) templates could indeed be used for
variations like channel size.

btw note that the difference between b)dynamic and c)static casting is only
typechecking which for the sake of 1 we have to foresake. Not a problem
because of our design with a single colorstrategy per paintdevice.

best regards
Casper Boemann

More information about the kimageshop mailing list