Is this good practice? Or should I just replace the code block between {
and }
with a function? It could be reusable (I admit) but my only motivation for doing this is to deallocate colsum
since it's huge and not required so that I can free the allocated memory.
vector<double> C;
{
vector<double> colsum;
A.col_sum(colsum);
C = At*colsum;
}
doSomething(C);
Using brackets to scope automatic variables is fine in my book, but generally if you find yourself doing it a lot, especially multiple times in the same function, your function is probably doing too many different things and should be broken up.
Vector doesn't store memory on the stack. Only the vector object itself is stored there, which is not very large. Scoping it like this does force a destruction which will free the memory it has allocated.
Also, I'm not sure that it's specified in the ISO that an implementation must pop a subscope variable off of the stack.
As other have pointed out, the vector memory is not allocated in the stack. If you want to free that memory early on, the common idiom is:
That will create a temporary vector and swap the contents with your large vector. At the end of the instruction the temporary will be destroyed and the memory released. You will be left with an empty vector.
Note that
colsum.resize(0)
andcolsum.clear()
don't need to free the available memory, and in many cases they won't assuming that if the vector grew to that size before, chances are that it will do it again.If the inner code will be reused elsewhere, separate it into a function. If the inner code is called frequently (like in a loop), then it probably needs to be refactored so that the vector isn't being constantly created and destroyed in a loop. Otherwise, I don't think it is bad practice to do what you've suggested.
The data for vectors is always dynamically allocated. Only the bookkeeping data is stored on the stack. Even if it weren't, stack memory allocation is essentially free. Deallocating from the stack is just changing the value of a register on most architectures.
EDIT
Regarding the dynamic deallocation, it will have to be deallocated at one point or another (particularly the end of the function). You're not actually losing anything by leaving the memory allocated until you want to allocate more and there isn't enough. Is the precise timing of when that deallocation occurs really something to be concerned about before you actually run into some problem?
/EDIT
But what's the point? It really seems like you're prematurely concerning yourself with optimization.
If you want to refactor your code, do it for the sake of clarity, not performance.