Re: [boost] Interest in color library.

From: Geoffrey Romer (geoff.romer_at_[hidden])
Date: 2005-09-26 10:08:50

> > 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.
> >
> In the general C++ community, there is a sharp distinction between
> run-time and compile-time polymorphism, due to the 'zero-overhead'
> philosophy of C++, (ie. you don't pay for what you don't absolutely
> _have_ to pay for).  Therefore, unqualified use of the term
> 'polymorphism' is normally assumed to mean run-time polymophism (simply
> because that was added to C++ first), although you are correct in your
> usage of it otherwise.  The 'safe' term to use in this case is 'generic'
> code.  Just FYI.

I'm fully aware of the distinction between compile-time and run-time
polymorphism, but the notion that 'polymorphism' is assumed to mean
'run-time' is new to me (FWIW, Stroustrup suggests 'polymorphism' as a
general term for both kinds). In what sense is 'generic' a safe term?
I had always thought 'generic' referred specifically to compile-time
polymorphism (Googling for C++ generic programming seems to back this
up), but I was trying to talk about polymorphism as a general concept,
apart from whether it was implemented at compile-time or run-time. If
you're not saying 'generic' fills that need, what word should I have
used?

> > 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?
>
> consider a function that *someone* will need to use, that doesn't depend
> on the representation of the data:
>
> // where GraphContext is a TwoDimContainer with a value_type
> // convertable to PixelRepr
> template <class PixelRepr, class GraphContext>
> void resample(const GraphContext& from, GraphContext& to)
> {       // ...
>                 // Dumb aliasing resampling
>                 to[x][y] = from[x*x_scale][y*y_scale];
>         // ...
> }
>

But this function doesn't really use the proposed library, or need it.
All it requires is that PixelRepr be assignable; it doesn't even have
to be a color, much less a color answering to the proposed interface.