![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Actually, one place I think C++ style templates beat out generics is in this:
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.
In any case, it's rather annoying. :-) I might have to figure out how to
patch up MS's samples to also host a collection of game components as well
as the scene-activation/deactivation they do.
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Actually, one place I think C++ style templates beat out generics is in
> this:
As I've written before, AFAIK these are two entirely unrelated
technologies that do totally different things.
> 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."
Heh, just use a language that has first-class functions, and store a
collection of functions. ;-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Am 13.04.2010 00:41, schrieb Darren New:
> Actually, one place I think C++ style templates beat out generics is in
> this:
>
> 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."
From the little I could find ad-hoc on the internet, there seems to be
an interface IGameComponent, so probably all you have to do is make sure
that all classes you want to store in that thing implement
IGameComponent, and use an IGameComponent container.
That's what interfaces are for, after all.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Darren New wrote:
>> Actually, one place I think C++ style templates beat out generics is
>> in this:
>
> As I've written before, AFAIK these are two entirely unrelated
> technologies that do totally different things.
Yep.
> Heh, just use a language that has first-class functions, and store a
> collection of functions. ;-)
Except I want objects, and not just functions. They all have state, and
(worse) they tend to keep pointers to each other. The gridplane needs to
remember how big you want the grid, and it also needs to know where the
camera is so it can draw itself, for example. The guy in the maze needs to
know where the camera is, needs the maze structure, needs the reference to
the gamepad, etc.
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Heh, just use a language that has first-class functions, and store a
>> collection of functions. ;-)
>
> Except I want objects, and not just functions. They all have state, and
> (worse) they tend to keep pointers to each other. The gridplane needs to
> remember how big you want the grid, and it also needs to know where the
> camera is so it can draw itself, for example. The guy in the maze needs
> to know where the camera is, needs the maze structure, needs the
> reference to the gamepad, etc.
It wasn't an entirely serious suggestion. (Although you could probably
make it work. Just have the functions point to the state you want them
to mutate...)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> From the little I could find ad-hoc on the internet, there seems to be
> an interface IGameComponent, so probably all you have to do is make sure
> that all classes you want to store in that thing implement
> IGameComponent, and use an IGameComponent container.
IGameComponent implements the "Initialize" method.
IDrawable implements the "Draw" method.
IUpdatable implements the "Update" method.
GameComponent inherits IGameComponent, IDrawable, IUpdatable.
There's no way to make a "collection of objects that implement
IGameComponent, IDrawable, and IUpdatable" as far as I know.
> That's what interfaces are for, after all.
Yeah, and it would have been nice if IGameComponent included most or all of
the methods that GameComponent implements.
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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?
Heh.
> 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).
That's a point I hadn't considered, yes.
Actually, I think that clued me in a bit. They *are* all of type "object". ;-)
So I could just have a list of objects, and when I get an update,
(dynamic)-cast each element to a IUpdatable and invoke that if it works;
when I get a draw, cast each to an IDrawable and invoke that if it works, etc.
Ugly, but it'll do the trick, I think.
I still don't want to implement all the other mechanics going on there, and
I *do* want to implement somewhat different mechanics to make things more
self-contained. (As it stands, for example, there's no good place to "add
yourself to the list" during initialization. The object that is creating you
has to add you to the list of objects it knows about, which is inconvenient
in some ways.)
Anyway, maybe I'll grope thru the brand new 4.0 release and see what they
have there. They really changing a bunch of this sort of stuff around each
release, while leaving the basic underlying drawing calls alone, so maybe
they realized people need more support for the kind of problem I'm trying to
solve.
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Actually, I think that clued me in a bit. They *are* all of type
> "object". ;-)
>
> So I could just have a list of objects, and when I get an update,
> (dynamic)-cast each element to a IUpdatable and invoke that if it works;
> when I get a draw, cast each to an IDrawable and invoke that if it
> works, etc.
>
> Ugly, but it'll do the trick, I think.
Ah yes, ye olde "upcast everything to Object" antipattern. :-D
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> It wasn't an entirely serious suggestion. (Although you could probably
> make it work. Just have the functions point to the state you want them
> to mutate...)
We already have that. We call them "objects". ;-)
No, seriously, what do you think a pointer to an array of closures all
referencing the same variable is?
--
Darren New, San Diego CA, USA (PST)
Yes, we're traveling together,
but to different destinations.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |