>> What advantage do I gain by using them?
Lots. Especially in terms of array growth and no remembering to delete.
Plus strings.
More lots.
>> 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 leaksWhat advantage do I gain by using them?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
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?
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 might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
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?
Also, look up the discussion I had with Bubba a few months ago about linked lists vs vectors.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I looked it up (again) and while carfully reading it, I run into two questions. Maybe you want to answer them.
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?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?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.
Last edited by CornedBee; 01-31-2008 at 06:33 AM.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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).