Iterator requirements

[Boudewijn Rempt]

On Tuesday 06 July 2004 12:18, Casper Boemann wrote:
> > > For reasons I have already stated it is no good to return a pixel
> > > class. Trust me on this one.
> >
> > Well, it does work for Vigra, I guess that it can be done in C++.
>
> well vigra doesn't do it dynamically. It does it through templating which
> means that it has an image class for each pixel type !
>

It's good for performance :-).

> That does NOT mean that we cannot have a pixel class and specific
> subclasses. If (and this is important) we only use them WITHIN the color
> strategies. It may be a help in code reusage among related colorstrategies.
> I may not, but even from a estetically point of view we might do it anyway.
> No extra members or virtual functions though - but nonvirtual functions are
> ok.
>
> Please note that from all other classes it still needs to be QUANTUM *,
> unless we really what to make a total redesign of our code base (which I
> don't advocate).
>
> Even the color strategies public funtions need to take QUANTUM * as input
> and do the cast as their first thing like:
>
> LabColorStrategy::doSomething(QUANTUM *pixeldata)
> {
>    LabPixel *pixel = (LabPixel *)pixeldata;
>
>    //then the rest of the function can forget about pixeldata and only work
> on pixel.
> }
>

Yes, I agree with this design... Now for some code. I've come to a point where 
I need to visualize the selection masks, and I don't want to touch the 
rendering code until we've done this work. 

If you and Cyrille can hammer out a final design for the API, then we can 
start implementing and moving forward.

-- 
Boudewijn Rempt | http://www.valdyas.org/fading/index.cgi