Re: [boost] Interest in color library.

From: Adam Badura (abadura_at_[hidden])
Date: 2005-09-27 18:05:37

> 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.

    Yes. Indeed.
    I heard of looping over RGB components but never heared of RGB
representations with different types (even size is usually the same). So I
thought to disallow different types for RGB (and CMYK probably also) and to
allow this where it is realy suitable.
    Its no problem to wrtie classes thet serv "red", "green" and "blue"
instead of "component". But giving both solutions for RGB for example would
require (in my opinion) ~double code. I think that large parts of code would
have to be writen once for "generic" (component()) and once for "not
generic". This would probably be realized by a specialization of color_rgb
(model) class for components that suport component and those which do not.
But because I dont wand to use any inhertiance to be maxiamly sure about
memory representation and speed I would have to write to separate (but
giving athe same functions) implementations.
    So I'm not quite sure if its worth in case of RGB. Or do you have any
proposal of easy solution?

    Adam Badura