4

I've got a game server. It creates number of instances of Game and adds them (Or a pointer to them? What's better? It has 10 ints and 5 other pointers, 10 member functions) to the vector. After that some events happen inside of the game e. g. game_ends. At this very moment the game should be deleted from the vector... What is the best way to achieve it?

The two ways we've come to are:

  1. create an observer pattern. server will be an observer and game will dispatch an event to delete it.

  2. set the game to ended state while server constantly scans the vector and deletes that games which are in ended state.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Kolyunya
  • 5,973
  • 7
  • 46
  • 81

4 Answers4

2

The nature of your application aside, if you add objects to your vector by value rather than pointer, once they are deleted from the vector, you will not have to worry about deleting them yourself. If you have to create the objects dynamically and add them to your vector as pointers you will be responsible for their deletion.

mathematician1975
  • 21,161
  • 6
  • 59
  • 101
2

An object shouldn't really determine its own lifetime. You should probably have some sort of managing context which owns the container and which can decide when an object needs to go. The actual Game elements may somehow notify the manager that they're done, but they shouldn't delete themselves, or remove themselves from a collection.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • I would disagree on objects managing their own lifetime. For some tasks (async dispatch, spawning another program) it's completely acceptable for an object to destroy itself when it is done. – Richard J. Ross III Aug 23 '12 at 22:54
2

Pointers or instances

If you create a pointer using new you have to remember to delete it. If you are using a real instance, make sure you define a copy constructor, because std::vector copies your objects often.

You can use boost::sharedPointer<Game>. Do not use std::auto_ptr<Game> with std::vector

From the implementation options I would consider the following :

The observer pattern is elegant, but how many times will it be called? Deletion from the vector will be O(n) because you will have to find it and then erase it.

If you know the maximum games you will have in, say a minute, and that fits into memory, you can just have a thread which iterates through the vector every minute and deletes any ended games.

If memory is critical, you have to use the observer pattern. If you have lots of games, and an unique identifier for each game, you can consider std::map instead of vector, and then use the observer pattern to delete from the map which will be O(log(n))

Chip
  • 3,226
  • 23
  • 31
1

Create an object or a pointer to object game?

Is the game object large? Does it contain other pointers or pointers to files, sockets or other such things?

If the answer to either of those is yes, then you should new the game object, and store a pointer to it.

Should you use observer or constantly scan?

To answer this better I would need to know more about your program. Currently it seems like a design decision you are better fit to make. If you scan constantly you will need to spin a thread. This might not be what you want.

I personally would use an observer pattern.

anio
  • 8,903
  • 7
  • 35
  • 53
  • It has 10 ints and 5 other pointers, 10 member functions and stores a 2 socket descriptors – Kolyunya Aug 23 '12 at 22:27
  • @Kolyunya If your object owns sockets, then I don't think you can safely copy it into a another object in side a vector. New it and store a pointer. See this about copying sockets: http://stackoverflow.com/questions/5425666/passing-around-boostasioiptcpsocket – anio Aug 23 '12 at 22:35
  • But socket file descriptor is just an integer. Smth like `5` or `10`. What's the problem, if I store this integer into the instance and push the instance to the vector? It's just an integer. – Kolyunya Aug 23 '12 at 22:37
  • @Kolyunya: if the object owns the socket descriptor it will want to close it when it's destroyed, so, if you make copies, you'll try to close twice the same sockets. – Matteo Italia Aug 23 '12 at 22:51
  • No, no, no... Sockets are managed by the other class... `game` stores socket descriptor only to send data to them – Kolyunya Aug 24 '12 at 06:20