6 replies to this topic

[Captacha]

I'm using a dynamiclly allocated array in my code. If I have 4 elements in my array and I put

Array[4] = new Object[5]

will the first four elements remain intact?

[Hodgman]

Yes, that won't modify Array[0/1/2/3]... but...
Can you post some real, compilable C++ code? That code could be doing a lot of different things... it's probably not doing what you think it's doing -- it only makes sense if Array is an "array of arrays of objects", and you're setting the array at index 4 to be a new array of 5 objects.

Edited by Hodgman, 14 July 2012 - 11:22 PM.

[bradbobak]

If you have something like

 Object *Array[4]; 

 Array[4] = new Object[5];

You would be using memory outside of Array (Array[4] is one past the end).

If you have

 std::vector< Object * > Array(4, 0);
 Array[4] = new Object[5];

You would again be using memory outside the array.

Otherwise if you have the first and do assign to a Array[X] where X is in bounds, all the other Array elements remain unchanged.

[Captacha]

Yes, that won't modify Array[0/1/2/3]... but...
Can you post some real, compilable C++ code? That code could be doing a lot of different things... it's probably not doing what you think it's doing -- it only makes sense if Array is an "array of arrays of objects", and you're setting the array at index 4 to be a new array of 5 objects.

I just made the example up off the top of my head, so that's why I wasn't following 0-indexing rules. Here's some code I'm using that was I was thinking about

void Player::addToList(Object* object)
{
colListSize++;
colList[colListSize-1] = new Object[colListSize];
colList[colListSize-1] = object;
}

colList is a Dynamic array of Pointers to class Object. It holds all the data I need for managing collisions. colListSize contains the size of the array. It starts off at 0 and increments every time the function is called. What it's supposed to do is add a pointer to the object to the end of the array. I haven't tested it out yet, so I don't know whether or not it works.

[fastcall22]

Okay, so you'd like to resize the array to make room for a new Object*. In C++, this is done using std::vector instead of raw arrays:

std::vector<Object*> colList;

void Player::addToList( Object* object ) {
    colList.push_back( object );
}

int Player::getColListSize() const {
    return colList.size();
}

Using raw arrays, you need to reallocate enough space to hold N+1 Object*s, and move those Object*s from the old array into the new array, and destroy the old array:

Object* newArr = new Object*[N+1];
for ( int idx = 0; idx < N; ++idx )
    newArr[idx] = colList[idx];
delete[] colList;
colList = newArr;

Most implementations of std::vector do the same as above behind the scenes.

Edited by fastcall22, 15 July 2012 - 11:59 AM.

[Captacha]

Okay, so you'd like to resize the array to make room for a new Object*. In C++, this is done using std::vector instead of raw arrays:

std::vector<Object*> colList;

void Player::addToList( Object* object ) {
	colList.push_back( object );
}

int Player::getColListSize() const {
	return colList.size();
}

Using raw arrays, you need to reallocate enough space to hold N+1 Object*s, and move those Object*s from the old array into the new array, and destroy the old array:

Object* newArr = new Object*[N+1];
for ( int idx = 0; idx < N; ++idx )
	newArr[idx] = colList[idx];
delete[] colList;
colList = newArr;

Most implementations of std::vector do the same as above behind the scenes.

So you're saying I should use a vector instead of manual memory allocation. vectors gave me a bunch of weird errors in my last project with subscript errors or something. I figured this would be easier. Oh Well.

[Hodgman]

Yes, that won't modify Array[0/1/2/3]... but...
Can you post some real, compilable C++ code? That code could be doing a lot of different things... it's probably not doing what you think it's doing -- it only makes sense if Array is an "array of arrays of objects", and you're setting the array at index 4 to be a new array of 5 objects.

I just made the example up off the top of my head, so that's why I wasn't following 0-indexing rules. Here's some code I'm using that was I was thinking about

void Player::addToList(Object* object)
{
colListSize++;
colList[colListSize-1] = new Object[colListSize];
colList[colListSize-1] = object;
}

colList is a Dynamic array of Pointers to class Object. It holds all the data I need for managing collisions. colListSize contains the size of the array. It starts off at 0 and increments every time the function is called. What it's supposed to do is add a pointer to the object to the end of the array. I haven't tested it out yet, so I don't know whether or not it works.

This code shows a fundamental lack of understanding in how pointers and memory work in C++. You should really not be trying to invent your own dynamic list until you grok how pointers work.

In that code, you never actually change the size of your original list. For example, if we create the list with 2 elements, then it will always be 2 elements long. When you call addToList, it creates a new list that is 3 elements long, then it writes the address of this new list past last slot of your original list (writing to memory you don't own, causing corruption), then it overwrites that value with 'object' (leaking the new list, and again causing corruption)! If you call addToList a 2nd time, then it will write even further past the end of your original array, corrupting more memory.


To illustrate, black hexidecimal numbers are memory addresses, with the value at that memory address shown in the cell to the right. Empty cells are un-owned by your program. 0xcdcdcdcd is used to show uninitialised memory.

So you're saying I should use a vector instead of manual memory allocation. vectors gave me a bunch of weird errors in my last project with subscript errors or something. I figured this would be easier. Oh Well.

You need to learn to walk before you run. Errors stem from misuse, not from inherent problems with vectors. Also, if you misuse vectors like this (writing past the end of the array), then the debug runtimes will likely be able to detect it and tell you that you're corrupting memory, whereas your code will just silently corrupt memory.

Edited by Hodgman, 16 July 2012 - 12:49 AM.