Boost logo

Boost :

From: Geoffrey Romer (geoff.romer_at_[hidden])
Date: 2005-09-27 16:28:32


On 9/27/05, Adam Badura <abadura_at_[hidden]> wrote:
> But this in deed does have some disadvantages. Previous I had functions
> like
>
> component_type component(const int index) const;
> component_type& component(const int index);
>
> or simple [] operator for getting components. This allows to easy write code
> which preforms the same operation on each color component (for example
> interpolates color by interpolating R than G than B...). Now (when
> components could have different types) writing such a function is almost
> impossible because you must return one specific type (inheritance is
> imposibble due to speed overhead and use of basic types).

I don't see this as a big loss. It's still easy to write code which
does the same thing to each component, you just have to do it
explicitly with three separate calls instead of a loop. I don't think
you should be restricting the functionality of the library this much
(since it sounds like components with different types will be a
relatively common case) just to avoid the minor inconvenience of not
being able to be generic over components.

In any event, the color models in which it makes sense to have
different types for the different components are probably models in
which it doesn't make sense to perform the same operation on all three
components. Performing the exact same operation on all three
components only really makes sense in RGB, CYM, and their close
relatives, which model colors as mixtures of semi-arbitrary primaries;
it's not something you're likely to want to do in HSV, LAB, etc, where
the different components are conceptually distinct concepts.

So, it seems like an ideal design would be to allow color classes to
specialize depending on whether their components are in some sense
equivalent. Those that are could offer a component() method, and would
require the same type for all 3 components. Those that aren't would
not offer a component() method, and consequently would have the
freedom to use different types for the different components.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk