// THE MEMBER VAR. m_vObjs[] IS DEFINED LIKE THIS...
Obj* m_vObjs[ _GEN_MAX_OBJECTS ];
// ...AND THE ACCESSOR METHOD IS DEFINED LIKE THIS.
Obj** Objects() { return m_vObjs; }
Accessing an Array of Pointers
Author
Hi! I'm busy reworking classes that are part of my SDL game engine. These classes work together in a modular fashion, with one class containing the other managing classes as members.
Anyway, the main class, GEngine, maintains an array of pointers to all instances of game objects. I need to be able to sort this array of objects from within GraphicsManager, the class that handles drawing to the screen as well as handling SDL surfaces allocated in memory. Originally, GEngine contained a private helper method for sorting this list of objects, but I decided (after seeking some advice) that this sorting method really belongs in GraphicsManager because GEngine has no use for it; the array only needs to be sorted so that objects are drawn correctly, and only GraphicsManager actually makes use of it.
Anyway... how can I create an accessor method in GEngine to pass a reference to its array of objects? Right now, I have an accessor declared as follows.
I'm not sure if this works correctly though. It's alright if this produces a copy of the array because it only contains pointers to objects and I could always create and use a local array; it would point to the same objects on the heap. Still, I think I'd prefer to work with the actual array from outside of the GEngine class. By the way, this sort of functionality would not be available to the user of the engine, so futzing with the array directly would still be impossible. :-)
Anyway, even if I don't really need to work with the actual array, I'd like to know how anyway. I think I may need to be able to do this in other parts of the engine and it'd be nice to know. Thanks for any help!
(For now, I'll create a local copy of the array.)
You return a pointer to the begginning of the array, thus, there is no copying (well, except for the array address). You are working with the original.
Minor nitpick: Returning an array by copy is not "ok" when you can return only a pointer to it. Depending on the size of the array, copying an array of pointers can be a somewhat expensive operation. Of course, if you DO need a copy, go ahead. But avoiding the copy when it isn't needed it a good idea.
Minor nitpick: Returning an array by copy is not "ok" when you can return only a pointer to it. Depending on the size of the array, copying an array of pointers can be a somewhat expensive operation. Of course, if you DO need a copy, go ahead. But avoiding the copy when it isn't needed it a good idea.
Author
Quote:Original post by RDragon1
I would much rather see you use a standard container to manage your objects.
Good point. The STL would add a great deal of flexibility. In fact, I've used STL vectors everywhere else in my code where I needed to maintain a list. I'm not too sure why I chose a good old array for keeping track of objects... although I wanted to limit the number of objects that can be added to the fray. Still, there's no reason why that can't be done with STL vectors either. :-P
For now, I'll just use this array. I have two alogrithms for adding and removing objects from the list that handle memory without any problems (that I know of yet). Most likely, I'll use a STL vector here too once I get a bit further along. :-)
Quote:Original post by jfclavette
You return a pointer to the begginning of the array, thus, there is no copying (well, except for the array address).
Ah, it's so easy to lose sight of the fact that arrays really are just pointers. I see what you're saying. Thanks for the help. :-)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
