Deleting new arrays

[eidge]

Here I go again bothering you.

I was wondering if after creating an array with new and assigning it to a pointer if I can change the index of the item pointed to by the pointer and the delete [] pointer function still works properly.

My english isn't very sharp so I'll give you the example that made me think about this, hoping you can understand what I want.

My code:

//Exercise 14.1.1
#include <iostream>

using namespace std;

int main()
{
    int n=0;
    double *p=NULL;
    double sum=0.0;

    cout<<"Number of elements: ";
    cin>>n;

    p=new double[n];
    if(!p) //Dealing with memory allocation problems.
        {
            cout<<"Cannot alocate memory!\nQuiting\n";
            return -1;
        }

    for(register int i=0; i<n; i++)
        {
            cout<<"Index "<<i<<": ";
            cin>>*p;
            sum+=*p++;
        }

    cout<<"Average input: "<<sum/n;

    delete [] p;

    return 0;
}

So p starts by pointing to the first element of the double array. After the for cicle ends, it points to the last element of the array.

So when I use delete[]p; does the entire array that I allocated gets released or the fact that I've changed the adress of p screws up the deleting proccess?

[Athar]

No, you can't use delete[] on that address - this will lead to undefined behavior. It must be the address that was originally returned by new[].
Two more things: new and new[] do not return 0 when they fail to allocate memory, but they throw a std::bad_alloc exception.
And using the register keyword is pointless as modern compilers just ignore it. They know far better than the average programmer which variables should be kept in registers.

[Moschops]

It screws it up. Here's the relevant text from the C++ 03 standard; "In the second alternative (delete array), the value of the operand of delete shall be the pointer value which resulted from a previous array new-expression."

[LB]

new will not return NULL if it couldn't allocate the memory, instead it throws an exception.

And the answer to your question is no. Instead just add i to p and you'll have no problems.

EDIT: wow 3 posts at once >_>

[eidge]

Thanks for the income.

So what do you recommend in the sake of performance. Copying the adress of p to another pointer and use pointer aritmetics to process the array. Or just use normal array indexing?

EDIT: On the matter of new not returning a null pointer on allocation problems, shall I use a catch statement or the program will terminate if such a problem occurs? (exception handling seems overkill in these small exercise programs..)

NOTE to beginners like me: "C++ without fear", although a good book seems to be outdated in some matters,

found so far:

new does not return a null pointer on allocation problems.
stdlib.h and string.h libraries must be replaced with cstdlib and cstring.

[Athar]

Normal indexing (for clarity, not because of performance).
And I recommend reading this:
http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf
or maybe this thread as it's somewhat similar to your question:
http://www.cplusplus.com/forum/general/28019/

Edit:

On the matter of new not returning a null pointer on allocation problems, shall I use a catch statement or the program will terminate if such a problem occurs? (exception handling seems overkill in these small exercise programs..)

Yes, it is overkill. Your application will just terminate if the exception is not caught.

[zb0S216C]

I back those who say that new[ ]/new throws a std::bad_alloc exception on a allocation failure. However, to force new[ ]/new to return NULL on a failed allocation, you would write this:

double *p( new( std::nothrow ) double[ n ] );

_Wazzak

[eidge]

Thank's, Athar I'll make that pdf the next in the reading schedule. Only 2 chapters to get ride of C++ without fear :)

It's really easy for a perfectionist beginner like me to get obcessed with optimized code..

[Athar]

It's really easy for a perfectionist beginner like me to get obcessed with optimized code..

That's not a bad thing, as long as you keep some things in mind:
1. Only bother about performance in parts of the program that are called very, very often (in complex programs a profiler will help you to identify these parts).
2. Know what optimizations your compiler can do and cannot do. And it can always optimize better than you thought it could, no matter what you thought.
3. And of course:

If you do an optimization, test it on real world data.
If it’s not drastically faster but makes the code less readable: undo it.

[eidge]

Thanks for the tips, I'll try to keep them in mind.