Beginner question: how to free space of vector?

[matth.schmitt]

Hi,

I have a problem with using vector to transfer new data into a class.
Running valgrind on the following program gives
lost memory, but I'm not sure why.

Help appreciated,

Matthias

#include <vector>
#include <iostream>

typedef std::vector<int> TInt;
class mem
{
TInt demo;

public:
void set_mem(TInt &line)
{
std::cout << demo.capacity();
// I believe the problem is here: what was contained in
demo is now lost
// but could someone enlighten me pls?
demo = line;
}

mem()
{
for (int j = 0; j < 5; j++)
{

demo.push_back(j);
}
}

~mem()
{
// I already read that clear doesn't force vector to
free its space, how can I achieve
// this? resize() doesn't seem to have any effect
either...
demo.clear();
}
};

int main()
{
mem* test;
TInt d;
for (int i = 0; i < 10; i++)
d.push_back(i);

test = new mem();
test->set_mem(d);

}

 

[Andre Kostur]

(e-mail address removed) wrote in @o11g2000prd.googlegroups.com:

Hi,

I have a problem with using vector to transfer new data into a class.
Running valgrind on the following program gives
lost memory, but I'm not sure why.

Nothing to do with your vector. See below.

Help appreciated,

Matthias

#include <vector>
#include <iostream>

typedef std::vector<int> TInt;
class mem
{
TInt demo;

public:
void set_mem(TInt &line)
{
std::cout << demo.capacity();
// I believe the problem is here: what was contained in
demo is now lost
// but could someone enlighten me pls?
demo = line;

"Lost"? No. The contents of demo has been replaced by copies of the
contents of line. Whatever demo used to contain has been destroyed.

}

mem()
{
for (int j = 0; j < 5; j++)
{

demo.push_back(j);
}
}

~mem()
{
// I already read that clear doesn't force vector to
free its space, how can I achieve
// this? resize() doesn't seem to have any effect
either...
demo.clear();
}
};

int main()
{
mem* test;
TInt d;
for (int i = 0; i < 10; i++)
d.push_back(i);

test = new mem();
test->set_mem(d);

And here's your memory leak. You allocated a mem object, but did not
delete it.

}

Why bother dynamically allocating the mem object?

 

[Gianni Mariani]

Hi,

I have a problem with using vector to transfer new data into a class.
Running valgrind on the following program gives
lost memory, but I'm not sure why.

Many C++ implementations do not use malloc as their primary allocator
and so when memory is deallocated by a vector, it is still stored in the
allocator.

To get around this for debugging, there is usually a flag or an
environment variable to modify the behaviour of the allocator to use
malloc/free so that you can debug it using products like valgrind.

For GCC you should set the environment variable GLIBCXX_FORCE_NEW or
GLIBCPP_FORCE_NEW depending on your version of gcc.

See:
http://gcc.gnu.org/onlinedocs/libstdc++/debug.html#mem

 

[xgngli]

Your code looks a little confusing to me. It seems not demonstrating
how to free space of a vector. I run your code on Visual Studio, it
worked fine. However, it surprised me that the output is 6 instead of
5. Why?

By the way, I'm not sure if clear method frees memory or not. If not,
I'm interested to learn which method does. I am also a beginner on
STL

 

[Marcus Kwok]

By the way, I'm not sure if clear method frees memory or not. If not,
I'm interested to learn which method does. I am also a beginner on
STL

Usually clear() does not free memory, in the sense that the vector's
capacity() is usually the same. In order to truly free memory, the
"swap" idiom is frequently used:


#include <iostream>
using std::cout;

#include <vector>
using std::vector;

int main()
{
vector<int> v1;
cout << "v1.capacity(): " << v1.capacity() << '\n';

v1.reserve(5);
cout << "v1.capacity(): " << v1.capacity() << '\n';

v1.clear();
cout << "v1.capacity(): " << v1.capacity() << '\n';

vector<int>().swap(v1);
cout << "v1.capacity(): " << v1.capacity() << '\n';
}

 

[Victor Bazarov]

Your code looks a little confusing to me.

My code? Have you actually seen my code?...

Now that I think of it, I am not certain WHAT code you're talking about.
No reference in your post, no link, no nuthin'!

It seems not demonstrating
how to free space of a vector. I run your code on Visual Studio, it
worked fine. However, it surprised me that the output is 6 instead of
5. Why?

By the way, I'm not sure if clear method frees memory or not.

It usually does not. There is no requirement either way.

If not,
I'm interested to learn which method does. I am also a beginner on
STL

You seem to need to learn the rules of Usenet as well. Do, please.

V

 

[James Kanze]

(e-mail address removed) wrote:

It usually does not. There is no requirement either way.

No direct requirement, but indirect requirements concerning the
lifetime of iterators mean that it can't.

The "canonical" way of ensuring that the vector is of minimum
size is:

std::vector< MyType >().swap( toBeCleared ) ;

(Not very intuitive, but, hey, this is the STL.)

 

[Jon Harrop]

I have a problem with using vector to transfer new data into a class.
Running valgrind on the following program gives
lost memory, but I'm not sure why.

STL implementations typically do not free memory reliably. ValGrind is
correctly indicating this.

Unfortunately, restrictions of the C++ language make it impossible to do any
better.

 

[Juha Nieminen]

STL implementations typically do not free memory reliably.

What's that supposed to mean? In which cases do STL implementations
not free the memory they have reserved?

If you mean that you can do "new std::vector<whatever>" and then
if you don't do a delete then the memory is not freed, that's hardly
an issue with the STL in particular.

Unfortunately, restrictions of the C++ language make it impossible to do any
better.

STL containers correctly free their memory when they are destroyed.
I don't understand what you are talking about.

 

[red floyd]

What's that supposed to mean? In which cases do STL implementations
not free the memory they have reserved?

If you mean that you can do "new std::vector<whatever>" and then
if you don't do a delete then the memory is not freed, that's hardly
an issue with the STL in particular.


STL containers correctly free their memory when they are destroyed.
I don't understand what you are talking about.

He's a troll. Ignore him.

 

[Jon Harrop]

STL containers correctly free their memory when they are destroyed.
I don't understand what you are talking about.

In the interests of performance, the STL typically implements its own heap
and allocates and deallocates from it. So letting a data structure go out
of scope results in it being deallocated inside the STLs heap but the heap
itself is not deleted and the memory is not freed.

I've had problems with this in the past. I'll try to dig out some specific
examples if you like.

 

[Kai-Uwe Bux]

In the interests of performance, the STL typically implements its own heap
and allocates and deallocates from it. So letting a data structure go out
of scope results in it being deallocated inside the STLs heap but the heap
itself is not deleted and the memory is not freed.

I've had problems with this in the past. I'll try to dig out some specific
examples if you like.

That is correct for some STL implementations that use a pooling allocator by
default. You can write a simple new/delete (or malloc/free) allocator and
use that with the standard containers that will then use new/delete
(malloc/free) instead of their own pool.


Best

Kai-Uwe Bux