Re: [boost] Interest in color library.

From: Simon Buchan (simon_at_[hidden])
Date: 2005-09-26 18:45:12

Geoffrey Romer wrote:
>>>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?
> 
Yes, polymorphic is the 'correct' term, but it's (over?) use by the OO 
crowd has 'tainted' it for a lot of developers.  I catch myself out with 
this, even.  'Generic' is 'safe', because although it hides the idea 
that you don't care about implementation, it isn't suspect to the 
'implict cast' to run-time polymorphic.  I agree that it isn't perfect, 
but we don't have a neat term for _just_ run-time polymorphism either. 
("operations performed virtually?"  I could deal with that)
> 
>>>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.

Yes I'm a moron.  Sorry about that.
It's not even a very good generic function, PixelRepr isn't needed as a 
template param, and the two GC's don't need to be the same.
I suppose something more usefull would be a colour gamut conversion or 
something.

template <class Gamut, class Repr>
bool inGamut(Gamut g, rgb_color<Repr> c)?

and inGamut(Gamut g, yuv_color<Repr> c), etc... . Would that work?