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.

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 mis-use, not from problems with vectors.

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 in the last slot of your original list, then it overwrites that value with 'object' (leaking the new list)! If you call addToList a 2nd time, then it will write past the end of your original array, corrupting 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 mis-use, not from problems with vectors.