Boost logo

Boost :

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

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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at