That's the reason I said "best" and not best. I understand that these things should be project specific, but I was asking for a general idea of STL container speeds. Most games aren't really going to have 100,000 textures, so I was looking for a container that may be "better" than a vector. By "better" I mean one that would balance adding and removing from a non-terminal point and being able to quickly find a value. Vectors are very fast at iterating from the start to end, but removing something in the middle can be heavy. Consider adding are removing instances nearly every step. (Obviously, there are very few times when this is even a good idea, but I know a vector is not the best container for this scenario.)
Okay this gives us a bit more to work with.
Unfortunately
this list is missing C++11 containers.
If you want (amortized) constant (O(1)) look up, insertion and deletion then you might want to take a look at
std::unordered_map, although it's not guaranteed by the standard (afaik) it will probably mostly get implemented as actual
hash table.
std::map on the other hand is often implemented as
red-black tree and thus is also quite fast but since things have to get sorted it's 'only' O(log n).
A
std::list won't be such a good choice, since the look up, insertion and deletion are in O(n).
For the O-notation see
here.
TL;DR: Smaller is better: O(1) < O(log n) < O(n)
And if you got too much time on your hand and are interested in data-structures you can take a look at
this.
I'm writing the managers to implement the most balanced solution for any generic scenario.
And there I thought you've understood it.
Stop writing stuff for 'any generic scenario' and start writing code that's needed by your game.
Writing a generic game engine isn't really something you should target and it's something that's very rare in the wild, e.g. first there was Quake then there was the quake engine or first there was Half Life and then there was the source engine, etc.
I don't mind implementing auto pointers, it just doesn't seem necessary. What's wrong with:
Object* Instance = new (std::nothrow) Object;
if (Instance != nullptr) {/*do stuff*/}
else
{/*do error stuff*/}
Smart pointers not auto pointers (std::auto_ptr is depreciated).
I'm sure it doesn't cover all the possible failures. Like I said read the linked post or at least take a look at
this example.
Show Posts
