When to declare arrays???

[tgreiner]

When reading any beginning manual on C++ an array is introduced as follows:

float A[10];

That format is valid, in that it compiles and seems to work just fine -- for a while.

Later on in the manual we learn to allocate/release memory using the new and delete keywords. So, the same array would be:

float * A = new float[10];
some code;
delete[] A;

Now, the question is: When does it become necessary to allocate memory for an array?

I've seen code snipets of some fairly complicated algorithms, that make use of the simpler version of array declaration. But I wonder. If that algorithm is used as a function and called only once or twice, I guess it's no big deal. But if the same function is called 1000 times or more will the program run out of memory?

If it is always bad practice to not allocate memory, then why does every C++ manual I have ever seen introduce arrays without mentioning memory allocation? I have been criticized to re-read the instructional manuals more carefully whenever I have failed to allocate memory for arrays. But, I have never seen an instructional manual that introduces arrays and memory allocatation at the same time. They are always mentioned in two separate chapters, and memory allocation usually appear towards the end as a "more advanced" coding techinque (usually next to chapters on classes and templates) which implies that allocation is not always necessary. But, reading the advice on this forum I get the impression that it is.

So, when is is absolutely necessary to allocate memory and when is it ok not to do so?

Is there some guideline, or rule, for this?

[ddanbe]

Well, let me say idunno.
But I guess if you use just A[10] a smart compiler, allocates the memory for you. This would be OK for a small array and in teaching textbooks it is easy to explain. If you, as a programmer want to stay in full control, you can override this, by allocating the memory yourself.

[Moschops]

Now, the question is: When does it become necessary to allocate memory for an array?

As programmer, you in effect have two kinds of memory available to you. The stack, and the heap.

Anything you create without using new goes on the stack. All these go on the stack.

int x;
float y;
int z[10];

Anything you create using new goes on the heap, and the function new gives you back a pointer to the object. All these go on the heap.

int* x = new int;
float* y = new float;
int* z = new int[10];

So you would use new when you wanted the object to go on the heap, instead of on the stack.

You put something on the heap in the following situations:

1) The stack is too small (the stack is much, much, much smaller than the heap, and if you put too much on the stack, it fills up and your program crashes)

2) You want to control when the object is destroyed. If you put an object on the stack, it is detroyed when it goes out of scope. If you put it on the heap, it is destroyed when you say so (by using delete).

But if the same function is called 1000 times or more will the program run out of memory?

Now that you have read what I wrote above, you know the answer to this. If that function puts its objects on the stack, then when the function ends and all the objects inside it go out of scope, they are automatically destroyed. So if you call it 1000 times, then 1000 times it creates objects (on the stack), and then uses them, and then destroys them, and the memory is available to be reused. So no, the program will not run out of memory if the objects are on the stack.

So, when should you use new and put objects on the heap? As I said above, in those two cases.

You should find a simple explanation of the stack, and the heap, and read it. You should also learn how all the objects in functions that you call get put on the stack, and used, and if they call functions those go on top, and so on, and then as each function finishes it is tidied away. You can watch the stack grow and shrink as you call functions. Understanding this will make you a far better programmer, and will enable you to debug your own code when it goes wrong.

This being C++, and especially as a beginner, you should think carefully before using new. It's very often not necessary. We have clever containers (such as vector, and in C++11 a std::array container) that will take care of memory allocating and expandnig and so on for you. There's nothing wrong with using new, but in doing so you are taking full responsibility yourself for taking proper care of that memory, and if you don't actually need that full level of control, you're just making things more complicated for yourself, and your brain power is better spent on other things.

[deceptikon]

Agreed with Moschops, but this is still a legitimate question.

When does it become necessary to allocate memory for an array?

Typically when the size of the array is unknown until runtime, or the lifetime of an array would be insufficient for your needs (such as returning a locally generated array from a function). Another reason might be that the array is large enough to risk overflowing the stack, but in that case you probably need to consider other data structures.

[mridul.ahuja]

Memory is assigned in both situations.
In float A[10] , we are declaring a float array.
In float * A = new float[10] , we are declaring a float array with a pointer A pointing to it.

Suppose you use float A[10] in a function

void fun()
{ 
   float A[10];
   ------------
   ------------
}

You won't be able to use A outside this function.This is called automatic storage duration.

However if you use float * A = new float[10] in a function

void fun()
{ 
   float * A = new float[10];
   ------------
   ------------
}

You will be able to use A anywhere (even outside the function) until you explicitly call delete. This is called dynamic storage duration.

[tgreiner]

Thanks, your answers cleared things up for me.

In most of my applications, array lengths are determined at run time. So that is the reason why they sometime work and sometimes don't if I do not declare them using new.

I will lable this question "solved," although I would still be interested in reading any further amplifications or opinions.