472,139 Members | 1,507 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,139 software developers and data experts.

validity of pointers to vectors

Hi all,

I have vectors that holds pointers to other vectors, like so:

vector<whatever> x;
vector<whatever*> z;

z=&x;

Now I add something to x

x.push_back(something);

Will all the pointers in z still be valid? Of course I have problems with
something like this and I think not, but I didn't find anything that says
if, on using push_back, the vector allocates new memory for the whole
vector or if it just allocates new memory for the stuff that is added.
Also, I read that if you have vectors in vectors like so:

class x
{
vector<whatever> z;
}

and then
vector<x> vec;

That this often causes problems with keeping track of memory therewith
causing memory leaks? If so, is there a better way to do it?

Any help is greatly appreciated,

Jens
Jul 23 '05 #1
4 1865
Dr. J.K. Becker wrote:
Hi all,

I have vectors that holds pointers to other vectors, like so:

vector<whatever> x;
vector<whatever*> z;
Do you mean 'whatever' is a vector type?
z=&x;
That doesn't make sense.
z is a vector of pointers, not a pointer-to-vector.
Now I add something to x

x.push_back(something);

Will all the pointers in z still be valid?
That depends. If the push_back operation causes x to resize (and
reallocate storage), then probably no.

Of course I have problems with something like this and I think not, but I didn't find anything that says
if, on using push_back, the vector allocates new memory for the whole
vector or if it just allocates new memory for the stuff that is added.
It allocates new memory as soon as its initial capacity is too small to
hold the new object.
Also, I read that if you have vectors in vectors like so:

class x
{
vector<whatever> z;
}

and then
vector<x> vec;

This is not a vector of vector but a vector of x, which has has a vector
field. That's quite a difference.
That this often causes problems with keeping track of memory therewith
causing memory leaks? If so, is there a better way to do it?
Since no pointers and dynamic resource allocation are used in your
example, the memory won't leak.
Any help is greatly appreciated,

Jens

--
Matthias Kaeppler
Jul 23 '05 #2

"Dr. J.K. Becker" <be****@jkbecker.de> wrote in message
news:d0*************@news.t-online.com...
Hi all,

I have vectors that holds pointers to other vectors, like so:

vector<whatever> x;
vector<whatever*> z;

z=&x;
I think you are confusing a pointer and a vector containing pointers.

what would make sense is something like this...
x.push_back(something);
and for z it would be..

int *p = new int(10);
z.push_back(p);
or even
z.push_back(&x[0]); or something like that.

Now I add something to x

x.push_back(something);

Will all the pointers in z still be valid? Of course I have problems with
something like this and I think not, but I didn't find anything that says
if, on using push_back, the vector allocates new memory for the whole
vector or if it just allocates new memory for the stuff that is added.
Also, I read that if you have vectors in vectors like so:
Adding anything to X, might not be related to anything in Z.
if you want something in Z, you need to add the pointer to the appropriate
vector element in X.
class x
{
vector<whatever> z;
}

and then
vector<x> vec;

That this often causes problems with keeping track of memory therewith
causing memory leaks? If so, is there a better way to do it?

Any help is greatly appreciated,

Jens

Jul 23 '05 #3
On 3/4/2005 12:20 PM, Dr. J.K. Becker wrote:
Hi all,

I have vectors that holds pointers to other vectors, like so:

vector<whatever> x;
vector<whatever*> z;

z=&x;
I think you might have made a typo in there. I'm going to assume that z
is of type vector<whatever> *.
Now I add something to x

x.push_back(something);

Will all the pointers in z still be valid? Of course I have problems with
something like this and I think not, but I didn't find anything that says
if, on using push_back, the vector allocates new memory for the whole
vector or if it just allocates new memory for the stuff that is added.
If x was resized as a result of the insertion, then z is now invalid. I
don't think the standard specifies exactly how the reallocation takes
place, and frankly I don't think it matters. To be safe, assume that
every insertion invalidates iterators, pointers, etc.
Also, I read that if you have vectors in vectors like so:

class x
{
vector<whatever> z;
}

and then
vector<x> vec;

That this often causes problems with keeping track of memory therewith
causing memory leaks? If so, is there a better way to do it?


This is only a problem if whatever is a pointer type. The default
destructor for class x will destruct z, which will in turn destruct each
of its elements. If whatever is a pointer, the pointer will be
destructed but the object it points to will not, thereby leaking
resources. To get around this, write your own destructor for class x to
explicitly destruct each element of z. You could also look into
boost::shared_ptr if you're able to use the Boost library.

Of course, this whole discussion is moot if whatever is not a pointer
type. STL objects clean up after themselves just fine. You can safely
create vectors of vectors of vectors ad nauseam.

Kristo
Jul 23 '05 #4
"Dr. J.K. Becker" <be****@jkbecker.de> writes:
Hi all,

I have vectors that holds pointers to other vectors, like so:

vector<whatever> x;
vector<whatever*> z;

z=&x;
This is a compiler error.

Now I add something to x

x.push_back(something);

Will all the pointers in z still be valid?
Iff push_back() causes a reallocation then all pointers, references,
and iterators which refer to an element of the container are
invalidated. A reallocation occurs if size() == capacity() at the
time of the push_back(). You can use reserve() reserve enough
capacity to do a number of push_pack()s.

Example:

#include<vector>

int main()
{
std::vector<int> v;
//reserve(2) guarantees at least enough space for 2 elements to be
//added to v before reallocation.
v.reserve(2);
v.push_back(1);
int* foo= &v[0];
v.push_back(2);
//at this point, foo is still valid.

if (v.capacity() == v.size())
{
v.push_back(3);
//The 3rd push_back exceeded capacity, so
//it invalidated foo.
*foo; //undefined behavior.
}
else
{
v.push_back(3);
//In this case, v.capacity() is at least 3, so push_back does
//not force a reallocation, and foo is still valid.
*foo; //defined behavior.
}
}

Note that reserve() itself will trigger a reallocation iff the
requested size is greater than the current capacity.

My example uses pointers, but for vector, the same rules apply to
iterators and references as well.

Of course I have problems with
something like this and I think not, but I didn't find anything that says
if, on using push_back, the vector allocates new memory for the whole
vector or if it just allocates new memory for the stuff that is added.
Also, I read that if you have vectors in vectors like so:

class x
{
vector<whatever> z;
}

and then
vector<x> vec;
If this (common) usage results in memory leaks, you have a badly
broken implementation. Where I work, we use 3 different versions
of gcc, MSVC++ 2003, and hp aCC, and none of them have trouble
with constructs like this.
That this often causes problems with keeping track of memory therewith
causing memory leaks? If so, is there a better way to do it?

[snip]

Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Rex_chaos | last post: by
18 posts views Thread by Matthias Kaeppler | last post: by
16 posts views Thread by jacob navia | last post: by
8 posts views Thread by jagguy | last post: by
33 posts views Thread by a | last post: by
6 posts views Thread by blux | last post: by
160 posts views Thread by raphfrk | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.