Can I use blocks to manage memory consumption in C++?

Question

I'm trying to gain some memory saving in a C++ program and I want to know if I can use blocks as a scope for variables (as in Perl). Let's say I have a huge object that performs some computations and gives a result, does it makes sense to do:

InputType  input;
ResultType result;

{
    // Block of code
    MyHugeObject mho;
    result = mho.superHeavyProcessing();
}

/*
   My other code ...
*/

Can I expect the object to be destroyed when exiting the block?

Soak

Answer 1

Yes, you can.

The destructor will be called as soon as the variable falls out of scope and it should release the heap-allocated memory.

Anguine

Strictly speaking, calling destructor is not the same as freeing memory used for object storage. – Portsmouth

I think it's safe to assume the huge word in the question means the object has allocated the larger chunk of memory on the heap and wants it to be freed (e.g. a vector). – Anguine

I'm sorry, but I seem to think that MyHugeObject is allocated on stack, and not on heap unless an explicit malloc is done. Please correct me if I'm wrong. – Profane

@user247077 MyHugeObject instance itself definitely lives on stack. That's not I what I'm talking about though. Let me clarify. Considering the fact that stack space is usually limited and you wouldn't allocate a huge memory on stack most of the time, the MyHugeObject class probably allocates a member on the heap as it's initialized. Regardless, the stack allocated memory will be released at the end of function too. – Anguine

Answer 2

Yes absolutely, and in addition to conserving memory, calling the destructor on scope exit is often used where you want the destructor to actually do something when the destructor is called (see RAII). For example, to create a scope based lock and release easily it in an exception safe way, or to let go of access to a shared or precious resource (like a file handle / database connection) deterministically.

-Rick

Tova

+1 for the reference to scope based locking, a very nice concept. – Lippizaner

Answer 3

Just remember that any memory you allocate on the heap using new/malloc that is freed in the destructor probably won't be released back to the OS. Your process may hold onto it and the OS won't get it back until the process terminates.

Trexler

Although in this case the memory is on the stack, which the OS has probably already committed to your program. (Although on Windows this is surprisingly not always the case!) – Pood

True - my assumption was that any object huge object must be allocating memory dynamically internally even if it is on the stack itself. – Trexler

This isn't really accurate. Although the large chunk of memory will still be assigned to the application, If it goes unused, it will be paged out of physical memory and not hinder performance in any way. A few operating systems (windows) manage unused paged out memory somewhat weakly, but this can always be circumvented by using a memory mapped file and unmapping it when done with it, since this in effect creates a separate page-file for that address space. – Gazpacho

Answer 4

Yes. It will be destroyed at the closing curly brace. But beware of allocating very large objects on the stack. This can causes a stack overflow. If you object also allocates large amounts memory, make sure it is heap allocated with new, malloc, or similar.

Essieessinger

The objects actually point to heap-allocated memory, but I want to free it as soon as possible. – Soak