[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Iterator requirements
From: "Casper Boemann" <cbr () boemann ! dk>
Date: 2004-07-06 10:18:10
Message-ID: 072801c46342$9c511f50$0401a8c0 () IBMfk13045
[Download RAW message or body]
> > 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 !
We could do that, but as we have already decided to use color strategies and
a single paintdevice we need to do it the way I have described.
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.
}
best regards
Casper Boemann
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic