containers, containers, and more containers
Author
So what is everyone''s preferred container for graphics, sound, monsters, and items? Do you prefer an array for one, and a linked list for others? What about the STL list? I would like them to be dynamic, supporting adding and deleting, perhaps even sorting. I''m just trying to get the best mix of speed and flexibility, while still being resource friendly. My current scheme for caching tiles is creating an array of type BITMAP*[256], then allocating each element as needed. Lame to be sure (this is my first forray into game development afterall), but without having some professional (or atleast semi-pro) =) input, it is impossible to know what the best solution is. So, there it is... hopefully we''ll see who has the most efficient caching method for bitmaps and sound, and the best method for dealing with dynamic objects in game like monsters and items
stl. Use the right container for the job. ie. vector where you would normally use an array, deque where you need something array-like but might need to add and remove at both the front and back, list where you need to be adding and removing in the middle, and map where you need quick lookups of an object based on a key field.
Of course, I''m still annoyed about the limitation on STL with pointers (requires an unnecessary definition of the pointer''s type), and should really get around to coding the workaround for my program sometime soon.
Of course, I''m still annoyed about the limitation on STL with pointers (requires an unnecessary definition of the pointer''s type), and should really get around to coding the workaround for my program sometime soon.
quote:
Hey!!! Don''t forget about this thread!! It is actually an interresting one! =P
Well it was pretty much answered with "STL"
Seriously though, I always use STL containers. There''s no point in writing your own and spending all the time debugging it, at the most I might write a container adapter (e.g. std::stack). If it turns out (after profiling!!!) that the container is talking to much time/memory I might write my own, but I''d probably getter better results if I changed the way I was using the containers. As long you use container well, it''s not very likely that you''ll have any problems with it. e.g. if you do something like this:
for(int i=0; i<someNumberl ++i){ vec.push_back(somthing);} you should call "vec.reserve(someNumber)" first so that you wont need to resize it in the loop.
Using STL containers also means you get to use the exiting algorithms so you don''t need to roll your sort function etc. Another good reason to use the STL instead of your own stuff if that everyone has access to it, so if you have a problem you''ll a lot more likely to get an answer than if the problem was with a home made container.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
