StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Yes, one is on the stack, the other on the heap. There are two important differences:</p> <ul> <li>First, the obvious, and less important one: Heap allocations are slow. Stack allocations are fast. </li> <li>Second, and much more important is <a href="http://en.wikipedia.org/wiki/RAII" rel="noreferrer">RAII</a>. Because the stack-allocated version is automatically cleaned up, it is <em>useful</em>. Its destructor is automatically called, which allows you to guarantee that any resources allocated by the class get cleaned up. This is essentialy how you avoid memory leaks in C++. You avoid them by never calling <code>delete</code> yourself, instead wrapping it in stack-allocated objects which call <code>delete</code> internally, typicaly in their destructor. If you attempt to manually keep track of all allocations, and call <code>delete</code> at the right times, I guarantee you that you'll have at least a memory leak per 100 lines of code.</li> </ul> <p>As a small example, consider this code:</p> <pre><code>class Pixel { public: Pixel(){ x=0; y=0;}; int x; int y; }; void foo() { Pixel* p = new Pixel(); p->x = 2; p->y = 5; bar(); delete p; } </code></pre> <p>Pretty innocent code, right? We create a pixel, then we call some unrelated function, and then we delete the pixel. Is there a memory leak?</p> <p>And the answer is "possibly". What happens if <code>bar</code> throws an exception? <code>delete</code> never gets called, the pixel is never deleted, and we leak memory. Now consider this:</p> <pre><code>void foo() { Pixel p; p.x = 2; p.y = 5; bar(); } </code></pre> <p>This won't leak memory. Of course in this simple case, everything is on the stack, so it gets cleaned up automatically, but even if the <code>Pixel</code> class had made a dynamic allocation internally, that wouldn't leak either. The <code>Pixel</code> class would simply be given a destructor that deletes it, and this destructor would be called no matter how we leave the <code>foo</code> function. Even if we leave it because <code>bar</code> threw an exception. The following, slightly contrived example shows this:</p> <pre><code>class Pixel { public: Pixel(){ x=new int(0); y=new int(0);}; int* x; int* y; ~Pixel() { delete x; delete y; } }; void foo() { Pixel p; *p.x = 2; *p.y = 5; bar(); } </code></pre> <p>The Pixel class now internally allocates some heap memory, but its destructor takes care of cleaning it up, so when <em>using</em> the class, we don't have to worry about it. (I should probably mention that the last example here is simplified a lot, in order to show the general principle. If we were to actually use this class, it contains several possible errors too. If the allocation of y fails, x never gets freed, and if the Pixel gets copied, we end up with both instances trying to delete the same data. So take the final example here with a grain of salt. Real-world code is a bit trickier, but it shows the general idea)</p> <p>Of course the same technique can be extended to other resources than memory allocations. For example it can be used to guarantee that files or database connections are closed after use, or that synchronization locks for your threading code are released.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload