I wrote a function to help with a C++ challenge where growing/shrinking dynamic array's occurs frequently. So far the function seems to work fine, however, from my tests if someone does this
1 2 3 4
int * ptr = newint[10];
ptr[20]=9;
cout<<ptr[20];
The value of 9 assigned to unallocated memory of index 20 will STILL be returned. I have tested that the copy & shrink works fine, thats easy enough, but how do I test that the array has actually been allocated properly when using a higher value? Here is my function code
From what I can find, you can't really tell if much of a dynamic array, so the only solution is to make SURE your code is correct to prevent memory leaks and what not.
EDIT: Also out of curiousity, at the end of the copy where I do delete[] aTemp, is that line necessary since everything inside this function is destroyed once it exits?
From what I can find, you can't really tell if much of a dynamic array, so the only solution is to make SURE your code is correct to prevent memory leaks and what not.
Or use a type that has checked access, like std::vector and std::vector::at. It should be vanishing rare that you are managing your own dynamic memory.
Even without reading through your function, it is easy to see it is incorrect from the prototype. It receives a copy of a pointer and has no way of modifying the original, so all changes are lost when the function ends.
int * ptr = newint[10];
for (int i = 0; i<10; i++ ) {
ptr[i]=i;
}
cout<<ptr[9]<<endl; // successfully returns 9
if(GrowShrinkDynamicArray(ptr, -1, 10, true)) {
cout<<ptr[8]<<endl; //returns 8 as expected
cout<<ptr[9]<<endl; //returns some random large number, as expected since it no longer exists
}
with the function as-is, it IS modifying ptr...
Edit: Also, the challenge explicitly says use dynamic arrays. It is from an EDU site and it does mention vectors, but says not to use them as the topic hasn't been covered yet.. to stick with the challenge, i use dynamic arrays
> as expected since it no longer exists
wrong, undefined behaviour is undefined. You don't expect `a high value', `zero', `unchanged', `-1' because you can't expect anything.
> with the function as-is, it IS modifying ptr...
It is not. Check the value of `ptr' before and after the function call.
Your function may delete the array, but ptr keep pointing there.
I'll suggest to print from a debugger.
Your function is unnecessarily complicated
Also, don't use exceptions as error codes (there is a nothrow version of new)
I was thinking about your previous comment about the ptr still pointing at the same address regardless of deleting the array.
The point of the function is to re-allocate memory for the array (free memory or take some). You said I >am< successfully deleting the array, therefore, freeing memory, correct? I then copy back over the required data plus or minus some, depending on if im sizing up or downward.
So based on that, shouldn't my function be successfully re-allocating memory?
For example
1 2 3 4 5 6 7 8 9
int * ptr = newint[10];
//some code that sets values for each index here
//now lets re-allocate the array to only hold 9 values instead of 10, copying over the already set 9 values in array.
if(GrowShrinkDynamicArray(ptr, -1, 10, true)) {
cout<<"SUCCESS!"
}
//OR//
1 2 3 4 5 6 7 8 9 10
int * ptr = newint[10];
// some code that sets values for each index here
//grow the array, keeping already set values
if(GrowShrinkDynamicArray(ptr, 5, 10, true)) {
cout<<"SUCCESS";
//memory should now be allocated for indexes 10-14
}
lol... didn't know about the std::copy, so now I see how it is unnecessarily complicated.
if i take lines 11-13 and place them after the try/catch, wouldn't that solve the case of copy throwing an error since everything in a function is tossed once you return from said function?
NO WAY! AN ONLINE C++ COMPILER!!! THANK YOU SO MUCH FOR THAT :D :D :D
Thank you for helping me thus far as well to better understanding managing dynamic arrays. I got over excited when I realized your link was an online C++ compiler.. didn't know anything of the sort existed. :D
if i take lines 11-13 and place them after the try/catch, wouldn't that solve the case of copy throwing an error since everything in a function is tossed once you return from said function?
Unfortunately, no. That wouldn't address the issue. The issue being if an assignment that occurs when std::copy is called throws, the memory pointed to by newMem would not be deallocated.