|
 |
Darren New <dne### [at] san rrcom> wrote:
> Actually, one place I think C++ style templates beat out generics is in this:
Who are you and what have you done to our friend Darren?
(I know, I know, very old joke. But I just *had* to.)
> In MS's simple game libraries, there's a class called GameComponent.
> It inherits from IUpdatable, IDrawable, and IMumble, each of which provides
> the declaration of one of the main routines in a game (update, draw, and
> initialize, respectively).
> Now, if I wanted (and I do) to make a collection of things that act like
> GameComponent objects but aren't necessarily game components, I don't think
> I can do that in C#. I would have to have a collection parameterized on all
> three of those interfaces. GameComponent supports a bunch of things that i
> might not want to have to support, but I can't make a collection that'll let
> me add "anything with those three routines, including GameComponent."
> I think this is something that Google's Go did better, if I understand it.
> C++ templates don't have that problem, but that's because you don't compile
> them separately, so what would normally have to be a runtime check gets done
> at compile time.
I wouldn't say it's that simple with C++ templates either.
You can write a template function which takes an object which "behaves like
a GameComponent" and does things to it ok. However, making a collection (data
container) is a slightly different issue.
If all the objects in the container are of the exact same type, then it's
possible and trivial. Problems start if, in the situation you describe, you
would want to store objects of different types in the container (even if they
all behave like a GameComponent).
You could store *pointers* to the objects in your container, but then you
would end up with the same problem as in C# (if I understood correctly): You
would have to decide the type of the pointer (which has to be the same for
all the container elements).
--
- Warp
Post a reply to this message
|
|
