What's the difference?
An old maths teacher once said to me "You don't have to understand it, you just have to be able to do it". Which is a surprisingly useful motto and has worked for me even through university ^_^
This question is sort of along those lines; in that I'm not really having any problems in this particular area with regards to my code not compiling/bugs in the program etc, but rather just interested in understanding why it must be done this particular way.
C++ doesn't like stuff like this
because when declaring an array the size must be constant and not a number not known until the program is run. However you can get around this by using something like this
long aFunction(long n)
//some more code
Now I don't really understand what the big difference here is. The line "anArray = new char[n]" is simply requesting a block of n pieces of memory each the size of a char. So why can it do this at runtime and not create an array in the first block of code?
long aFunction(long n)
anArray = new char[n];
//some more code
I'm still new to the language so I'm sure there must be something going over m head here, but if someone could explain it to me I would be most grateful :)
C++ has a MUCH better alternative to arrays -- the std::vector class, which can grow automatically, so you don't even need to know the size at compile time and don't need to worry about allocating & deleting memory...
Because that's just the way the language is designed.
C can have arrays like that, mind you.
But only C99, the newer version. C++ inherited the restriction from C89 and pre-standard C versions.
The reason is that it is far simpler for the compiler to generate code for arrays if their size is always known at compile time. C has quite a number of things that were done mostly to make compilers simpler. Another one among these is that you have to declare all local variables at the start of a block. (Also lifted in C99.)
This creates an array of n elements on the stack.
This creates an array of n elements on the heap.
char* anArray = new char[n];
That's the difference.
Not really, Elysia. The names stack and heap are really academic these days: they date from a decade or two back, when memory was scarce, and when primitive operating systems were designed to support no more than a few hundred kilobytes of total memory (as 1MB was considered to be more memory than any application would EVER need). When memory became a bit cheaper, those operating systems had to be tweaked to support larger amounts of memory (and, in fact, some machines had two distinct physical areas of memory, on physically different chips). On those systems, stack was the name given to the "low end" of memory (the memory the operating systems were designed to access) and the "high end" (memory that the operating systems were not designed to access, but special drivers would allow usage). The "low end" of memory was referred to be various names (eg "system memory", "stack") and the "high end" of memory was referred to by various names (eg "high memory", "extended memory", "special memory", "heap"). After a while, they were most commonly known as stack and heap. In practice, dynamically allocated memory (eg managed with malloc() in C) were able to be allocated from either heap or stack but, after a while it became more common to use the "stack" for program variables and "heap" for dynamically allocated memory.
Modern 32 bit (and 64 bit) operating systems make no distinction between areas of memory, except in terms of what process is allowed to access what memory. So the terms "heap" and "stack" are irrelevant: they are the same physical memory.
In any event, the differences are that the lifetime of dynamically allocated memory (eg char *AnArray = new char[n];) is explicitly managed by the programmer (eg destroyed with operator delete ). The lifetime of variables (eg char AnArray[n];) is managed by the compiler (in C or C++, the array will be destroyed at the end of the enclosing scope) or runtime support of the language, and is not controlled directly by the programmer.
I believe processor's have a stack implementation in hardware.
It's true that both stack and heap are just placed somewhere in virtual memory, but as we know, that doesn't mean it all ends up in physical memory.
But the stack and the heap still have different properties in a modern system where memory is uniform. For example, data stored on the stack gets "lost" when you leave the function where it was instantiated/created.
As a consequence, heap allocated data needs to be freed at some point.
Also, even thought stack and heap use the same type of memory, the stack is much more limited in space (even a 64-bit machine defaults the stack-size to a few megabytes), whilst the heap is normally only limited by the amount of virtual space allowed for the application (and amount of virtual space the OS can deal with), and even in 32-bit OS's this reaches into the gigabytes sizes.
There is also a certain speed difference, as the heap-allocated space is referenced through a pointer, and although an optimizing compiler can reduce the overhead of getting to the data, it will still be some overhead compared to the stack allocated data that is available at a set offset on the stack.
There is some hardware to accellerate stack accesses, particularly a short list of return addresses, but at least for x86 and such like, the stack is implemented simply as a stack-pointer and it refers to virtual memory which has to be backed by physical memory if you ever access it [which you do at some point or another if you write C or C++ code]. (Of course, it's likely that the virtual memory backed by the physical address is actually copied into the cache and thus the accesses to the physical memory does not actually happen very often or at all - but this is no different from any other part of memory being accessed in the system).
Originally Posted by Elysia
Stack and heap are not C++ terms. The terms are "automatic storage" and "dynamic storage" (and "static storage" for globals and statics). Those are clumsy terms, so everyone calls them stack and heap.