>> What advantage do I gain by using them?
Lots. Especially in terms of array growth and no remembering to delete.
Plus strings.
More lots.
Printable View
>> What advantage do I gain by using them?
Lots. Especially in terms of array growth and no remembering to delete.
Plus strings.
More lots.
Dealing with memory leaksQuote:
What advantage do I gain by using them?
With smart pointers, you can use a reference count to delete memory only when no longer in use. In other words, you'll be guaranteed that you aren't causing memory bugs by freeing memory to be used later and you guarantee there will be no memory leaks.Quote:
Originally Posted by Yarin
By using std::vector.at, you can make sure the code doesn't do any out-of-bounds since it will throw an exception if you try to access out-of-bounds elements.
Oh. Is the advantage really worth revamping my code though?
OF course it is. No major changes needed. For the most, at least :)
You'll be better protected and you'll see if you can get rid of catch some bugs!
While this may prevent going over bounds with this array, it is still a horrible fix. The reader of the code won't either understand it or realize that the original coder was seriously confused about arrays.Code:TORP torp[MAX_TORPS + 2];
The fix for the algorithm was already suggested. If you want to access this and the next item, don't loop up to the very end.
In addition, vector has the erase method, so that you wouldn't even need to write the DestroyTorpedo function yourself. (And thanks to this and other things, such as a vector knowing its own size rather than relying on a global(?) variable, you're code would contain less bugs and be a bit shorter than 1300 lines. :))
I guess I'll do that. Thank you all for the help. :)
Wrong. You can still access members before 0.Quote:
Originally Posted by Yarin
Yarin, I suggest you use linked lists for your game objects.
It's more efficient for removing (or inserting) things from the middle.
They are also efficient when accessed sequentially, which I
assume is another kind of access you need.
So if you don't need so-called "random access", it's might be best.
Anyone else agree?
Yes, but it will also require a rewrite. It would probably be a good idea if speed is a concern.
Also, look up the discussion I had with Bubba a few months ago about linked lists vs vectors.
I looked it up (again) and while carfully reading it, I run into two questions. Maybe you want to answer them.Quote:
Originally Posted by CornedBee
I tried to find out what problem exist with using expensive copy constructor and vector. I found, that the copy constructor is called twice while adding to the end of a vector, if I dont't call reserve() before insertion. Why does it need to be called twice? And why does an explizit call to reserve can do a similar job (reserving memory) without calling the copy constructor?Quote:
Unless copying of the individual elements is expensive (std::string is one case - but not once we get r-value references in C++09), it takes a lot of elements to overcome the consider- ably greater overhead that, say, a list has.
An could you explain please what exactly will change with the r-value-reference thing?
The other question:
Why does the list need more space?Quote:
When you're dealing with primitives,
it's most noticeable. On a 64-bit system, for example, a list<int> needs 5
times as much space to store a single element as a vector.
Thank you in advance!
Basically, the vector has to reallocate every now and then, and for that it needs to copy its elements around. Furthermore, insertion and deletion in the middle of the vector involves moving all elements after this position around - this, too, involves a lot of copying. That's why, if the copy constructor and copy assignment operator are slow, std::vector takes a performance hit.
If, on the other hand, copying is fast - some vector implementations recognize POD types and use straight memmove() then - the overhead is considerably lower.
With r-value references, the vector will be able to use move semantics. Moving is a destructive copy - the target gets the value of the source, but unlike copying, the value of the source after the operation doesn't matter. For classes like std::string, which allocate memory dynamically and keep a pointer to it, this means that the ownership of the memory can simply be passed to the target object, leaving the source object with an empty value. Obviously this is much faster than allocating a new block and copying the contents over.
The list needs more space because every element needs pointers to the next and previous node. There's two pointers overhead for every single element stored. In a vector, there's zero overhead per element, only some constant overhead for managing the memory.
Nice, thank you. Maybe someone should move this together with the post I quoted from to the FAQ board, because this container releated questions are asked very often (directly or indirectly) and few people seems to have such in depth knowledge about it.
It should also be made clear that although with 64-bit words a list<int> may need 5 times the space, a list<sixety_four_byte_object> will only need 1.25 times the space.
You also must consider how much faster the list may (or may not) be for your most common operations. In particular, lots of insertions and deletions might mean a list is faster overall, particularly if they are mostly in the middle (but your case sounds like insertions may all be at the end). The vector may have faste sequential access, and adding to the end _should_ be efficient (if you reserve lots of space beforehand).