Re: [boost] Interest in color library.

From: Geoffrey Romer (geoff.romer_at_[hidden])
Date: 2005-09-25 23:19:28

I think you're assuming that when I said "polymorphism", I meant
"inheritance and virtual functions", but "polymorphism" just means
having one piece of code operate on different kinds of data. Templates
are a kind of polymorphism, and that's what I'm referring to.

My question, rephrased, is just "why use templates?" What does this
templated structure give you that you wouldn't get from just having a
bunch of unrelated classes (rgb_color, cymk_color, etc.)? How would a
programmer take advantage of your templated structure?

In other words, can you give an example of how you see this library
being used, in a way that wouldn't be possible (or easy) without
templates?

On 9/25/05, Adam Badura <abadura_at_[hidden]> wrote:
>     Polymorphism would clearly make difference beetwean color representation
> and its model. This difference could be nicely checked at complie time
> without genereting "tamplate errors" which are usually hard to understand
> aspecially when nested or when you are not author of the code in which error
> is signaled and would like not even look at this code.
>
>     If I could use polymorphism (I cannot because of code speed) I would
> have somethinkg like this.
>
> class rgb_representation {
> public:
>     /*
>     ...
>     */
>     virtual double red() const = 0;
>     virtual void red(double) = 0;
>     virtual double green() const = 0;
>     virtual void green(double) = 0;
>     virtual double blue() const = 0;
>     virtual void blue(double) = 0;
>     /*
>     ...
>     */
> };
>
> class color_rgb {
> public:
>     color_rgb(rgb_representation& data);
>     /*
>     ...
>     */
> };
>
>     Naturally this sollution still has cons (beside speed). For easing
> dealing with different component types (int, float, ...) templates probably
> would be still needed. And this makes it harder to use "color_rgb" in code
> like this:
>
>     color_rgb image_buffer[width][height];
>
>     But it would be easier to make a "statement" on what does
> "rgb_representation" need and enforce using only right classes in more
> pleasent (error messages...) way.
>
>     And again. Using polymorphism could lead to quite another project. The
> model could be actualy implemented in abstract base class, but only
> functions like "red", "green", "blue" would have to be added by user
> (naturelly common model would be implemented in lib) this would solve the
> "image_buffer" problem and few others in this kind...
>
>     Adam Badura
>
> "Geoffrey Romer" <geoff.romer_at_[hidden]> wrote in message
> news:301730110509250954e16f7d0_at_mail.gmail.com...
> > I have a question about this approach: what is the purpose of using
> > templates? What operations do you see as being performed on colors
> > polymorphically?
> >
> > In other words, the only advantage I see to this templated approach
> > would be to allow clients to write templated functions/classes which
> > could operate on arbitrary color types, but I can't think of any
> > interesting functions that would work with your approach.
> >
> > (P.S. sorry if this has been addressed earlier in the thread; I only
> > just joined the list)
> >
> > On 9/25/05, Adam Badura <abadura_at_[hidden]> wrote:
> > >     Actually, to be mor acurate I do something like this:
> > >
> > > struct rgb_8888 {
> > >     unsigned char _r : 8;
> > >     unsigned char _g : 8;
> > >     unsigned char _b : 8;
> > >     unsigned char : 8;
> > >     unsigned char red() const {/*...*/}
> > >     void red(unsigned char r) {/*...*/}
> > >     unsigned char green() const {/*...*/}
> > >     void green(unsigned char r) {/*...*/}
> > >     unsigned char blue() const {/*...*/}
> > >     void blue(unsigned char r) {/*...*/}
> > >     unsigned char component(unsigned int index) const {{/*...*/}
> > >     unsigned char& component(unsigned int index) {/*...*/}
> > > };
> > >
> > > template<typename Components> class component_traits {
> > > public:
> > >     typedef ? component_type;
> > >     static const int components;
> > >     static const int indexes[components];
> > >     static const component_type min[components];
> > >     static const component_type max[components];
> > > };
> > >
> > > and than specialization could look like this:
> > >
> > >     component_traits<rgb_8888>::component_type === usnigned char
> > >     component_traits<rgb_8888>::min === [0, 0, 0]
> > >     component_traits<rgb_8888>::max === [255, 255, 255]
> > >
> > >     component_traits<rgb_double>::component_type === double
> > >     component_traits<rgb_8888>::min === [0.0, 0.0, 0.0]
> > >     component_traits<rgb_8888>::max === [1.0, 1.0, 1.0]
> > >
> > > and so on...
> > >
> > >     The base concept is that "color" class (like for example
> "color_rgb",
> > > "color_yuv") akes car of color model or color space things, and
> therefore
> > > must be a template (polymorphism could be used as well, but code speed
> is
> > > here very important [graphic manipulation!] so I decidet: templates)
> > > parametrized with "components type". This "component type" takes care
> for
> > > serving color data lika values of channels. "components type" knows
> exact
> > > types and palcement in memory.
> > >     So if you want to use your own format in wich all channels have 10
> bits
> > > size and all is stored in double word you just write simple components
> type:
> > >
> > > struct your_rgb {
> > >     unsigned int _r : 10;
> > >     unsigned int _g : 10;
> > >     unsigned int _b : 10;
> > >     unsigned int : 2;
> > >     unsigned int red() const { return _r;}
> > >     void red(unsigned int r) {_r = r;}
> > >     unsigned int green() const {return _g;}
> > >     void green(unsigned int r) {_g = g;}
> > >     unsigned int blue() const {return _b;}
> > >     void blue(unsigned int r) {_b = b;}
> > >     unsigned int component(unsigned int index) const {/*...*/}
> > >     unsigned int& component(unsigned int index) {/*...*/}
> > > };
> > >
> > >     component_traits<your_rgb>::component_type === usnigned int
> > >     component_traits<your_rgb>::indexes === [0, 1, 2]
> > >     component_traits<your_rgb>::min === [0, 0, 0]
> > >     component_traits<your_rgb>::max === [2^10, 2^10, 2^10]
> > >
> > > in this case writing "component" could be a little difficult however
> youy
> > > can be sure taht "color class" will not call your functions with
> improper
> > > arguments by it self (actually to speed up code control can be turned of
> and
> > > the user may give wrong arguments, but if someone wants to spoild
> program he
> > > will do it anyway). Also you dont have to actualy retrun type
> > > "component_traits<your_rgb>::component_type" but type that behaves like
> it
> > > were this type.
> > >     (component_traits::indexes is to allow another order of data not
> only
> > > RGB but for example also BGR, "color class" always [to ease using] uses
> > > index 0 for R, 1 for G and 3 for B, this is problem for "compoinent"
> > > function, to avoid using "swich" in this function, what would make its
> > > execution longer, indexes are staticly mapped, so for BGR this array
> would
> > > look like:
> > >
> > >     component_traits<bgr>::indexes === [2, 1, 0]
> > >
> > > and "color class" still uses its indexes, but in calls to components
> > > "component" maps them (staticly) to right indexes.
> > >     Hope everything is understandable... :)
> > >
> > >     But now I encountered another problem, which I post in differen
> message.
> > >
> > >     Adam Badura
> > >
> > > "Rob Stewart" <stewart_at_[hidden]> wrote in message
> > > news:200509201642.j8KGgYci010670_at_shannonhoon.balstatdev.susq.com...
> > > > From: "Adam Badura" <abadura_at_[hidden]>
> > > > >
> > > > >     For now I think taht template representation would be best. What
> i
> > > mean
> > > > > is for example
> > > > >
> > > > >     struct rgb_8888 {
> > > > >         unsigned char r : 8;
> > > > >         unsigned char g : 8;
> > > > >         unsigned char b : 8;
> > > > >         unsigned char : 8;
> > > > >     };
> > > > >
> > > > >     struct yuv_422 {
> > > > >         unsigned char y : 4;
> > > > >         unsigned char u : 2;
> > > > >         unsigned char v : 2;
> > > > >     };
> > > > >
> > > > >     template<typename Components> class color {
> > > > >     private:
> > > > >         Components mComponents;
> > > > >     };
> > > >
> > > > I haven't been following your discussion but this looks suspect.
> > > >
> > > > First, you'd need to specialize color for each color structure
> > > > type so the color member functions know how to do the right
> > > > thing.  That obviates what I think you're trying to do with the
> > > > template.
> > > >
> > > > Second, all code using colors must be either templated on color
> > > > type or will only work with one type.  That is, including the
> > > > representation in the type (color<yuv_422>) means that functions
> > > > must be written in terms of color<something> and can't work with
> > > > color<something_else_entirely>.
> > > >
> > > > To fix the former problem, you might consider that the color
> > > > template can provide higher level functionality from primitives
> > > > supplied by a policy type.  Thus, your Components type would have
> > > > to provide represention plus primitives.
> > > >
> > > > To fix the latter problem, you would need an ABC from which
> > > > color<T> derives.
> > > >
> > > > HTH
> > > >
> > > > --
> > > > Rob Stewart                           stewart_at_[hidden]
> > > > Software Engineer                     http://www.sig.com
> > > > Susquehanna International Group, LLP  using std::disclaimer;
> > > > _______________________________________________
> > > > Unsubscribe & other changes:
> > > http://lists.boost.org/mailman/listinfo.cgi/boost
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> > >
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>