1

Let's say that I have a lot of memory that will be allocated at certain points in the program. One of the great debates of memory leaks is that hogging a lot of memory is OK if it's going to be reclaimed by the operating system at the end of the process execution. The problem with this is, it's still memory hogging even if the leak is otherwise benign. I want my process to only "hog" large chunks of memory at a time. Here's what I mean:

{ // begin block
    int a[some_large_number];
    do_work_with_a();
} // destruct large allocation

{ // different block
    int a[some_large_number];
    do_work_with_a();
} // destruct large allocation

Does it really make a big difference?

user4132815
  • 11
  • 1
  • Local arrays are not allocated on the heap though, they are allocated on the stack. The only "allocation" you are making here is to reserve some stack space for these arrays. – cdhowie Oct 11 '14 at 17:38
  • I would say that in general, once you are done with memory, release it. – Niall Oct 11 '14 at 17:44
  • So the next generation of c++ programmers think it's debateable weather or not memory leaks are ok? We are all doomed. – John Dibling Oct 11 '14 at 18:07
  • @JohnDibling: Perhaps he means that it's not a memory leak if the allocation does not happen repeatedly, and the object staying alive is actually part of the design, so as to avoid order-of-destruction issues. – Christian Hackl Oct 11 '14 at 18:17
  • @JohnDibling: I already introduced a deliberate memory leak 10 years ago - my program took 4 hours to deallocate memory after running for just two hours. It always was debatable. – MSalters Oct 12 '14 at 13:54

3 Answers3

3

Your exemple is irrelevant, those variables are on the stack and don't need to be freed.

Moreover deallocating memory is also not an optimization but a must. Every call to reserve memory on the heap should be handled carefully and deallocated after use.

You can read more on heap and stack here.

Community
  • 1
  • 1
ForguesR
  • 3,558
  • 1
  • 17
  • 39
  • That's the usual way of handling things, but from a memory management perspective it is equally valid to release an entire pool (heap) of memory at once, instead of freeing allocations individually. Of course, that assumes trivial destructors. – Ben Voigt Oct 11 '14 at 17:47
0

First of all, here a is in stack, so hopefully some_large_number is not too large, since stack size of a thread is typically measured in single-digit megabytes.

Then 2nd thing, since you are worried about doing things right: do not use a C-style array without an actual reason. Instead, use std::vector or std::array or some other container class.

And 3rd thing, you can't really have memory leak with anything in the stack. You may have stack overflow, and you may have dangling pointers to things in stack which have gone out of scope, but memory leak... no.

That out of the way, having the separate blocks is certainly better for stack objects, especially when they would need to be re-initialized anyway, because simple allocation of stack is very simple operation, basically just adjusting stack pointer register. Having these small scopes will allow compiler to use the same stack space for other things between the blocks, if there's any code there. Also important, it will make clear that these are separate arrays, and no data is carried over, which can also enable compiler warnings about uninitialized variables (which you would not get if you re-used variables and forgot to re-initialize).

But, if you had items in heap, such as you actually used std::vector, then things are a bit different. Heap allocations are more expensive, both to make and to release, so if it is a performance-critical part of code, you probably would rather re-use already created std::vector.

hyde
  • 60,639
  • 21
  • 115
  • 176
0

No. Modern compilers will already reuse the memory space, since int does not have a destructor. However, debug builds are an exception, so that you can study the old array contents in the debugger.

MSalters
  • 173,980
  • 10
  • 155
  • 350