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

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

Darren New <dne### [at] sanrrcom> 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

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

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

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

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

Warp wrote:
> Darren New <dne### [at] sanrrcom> 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

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

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