I have read on lots of tutorials that you once an array is set, it stays that size. this is false. today i got bored in school and suddenly realized that the bare base of an array swap function i wrote can resize the array. i havent figured out how to make it smaller yet, but i can make it bigger and it will be the start of my whole array library
Are you actually making it larger, or are you copying it to a larger array? Because the former is going to rather implementation defined. When you create an array, it's either given a set amount of space in the stack, or a set amount of space on the heap. Each of which have to be contiguous. This means you could have an array sitting right next to some other random data, in which case making it larger would be impossible as you would end up intruding into occupied memory (which the OS likely won't allow anyway).
void resize(int* array, int growth)
{
//Mistake #1: sizeof(array) merely returns the size of a pointer, which is usually
// (but not necessarily) equal to sizeof(int).
int size = sizeof(array);
int counter;
for(counter = 0; counter < growth; counter = counter + 1)
//Mistake #2: using size, which is expressed in bytes, as an index, which is
// expressed in elements.
//Mistake #3: no actual resizing is taking place. You're merely overwriting some
// random memory that doesn't belong to array (depending on the exact
// value of growth).
array[counter + size] = array[0];
}
There's no need. It didn't. The fact that the program didn't crash isn't proof of anything.
The semantics of C and C++ don't allow the resizing of arrays. There's nothing you can do to prove that an array has been resized because that's simply impossible.
When you use an array's name, what you get is the memory address of the first element. So array[20] translates to *(array + 20). (Also try 20[array] for fun.)
This is basically, pointer arithmetic. The language expects you to know what you're doing, so if this ever blows up in your face, it'll be at the operating system's discretion (segmentation fault).
Conclusion: your code is bad, even if you're not given an error or warning.
I suggest you head what everyone is saying here, because they are right and you are wrong -- despite the appearance of you being correct. This is undefined behavior as far as the C++ standard goes: rainbow unicorns could should lasers through your windows because of your code and it would still be technically a "correct" program.
Let me ask you, which is more likely: That everyone here who is explaining to you why your code is incorrect, are in fact wrong, despite the fact that they have referenced the C++ standard as well as given you examples showcasing why you are incorrect (this is a textbook Buffer Overflow error, http://en.wikipedia.org/wiki/Buffer_overflow) OR you have discovered the magic secret 4 lines of code of mythic legend that entire libraries have been written for like the STL, Boost and others?
None of us are trying to "shut you down" or kill off any creativity you might have. We're just simply saying that what you claimed to have accomplished is, first of all, impossible in modern computer architecture, and second of all, you just didn't accomplish what you think you did.
@Helios,
That is some interesting results. How did a even get touched in all that? And did you happen to find out why b[12] is 12?