So this may seem like a widely-answered question, but I'm interested more in the internals of what exactly happens differently between the two.
Other than the fact that the second example creates not only the memory, but a pointer to the memory, what happens in memory when the following happens:
char a[5];
char b* = new char[5];
And more directly related to why I asked this question, how come I can do
const int len = 5;
char* c = new char[len];
but not
const int len = 5;
char d[len]; // Compiler error
EDIT Should have mentioned I'm getting this compiler error on VC++ (go figure...)
1>.\input.cpp(138) : error C2057: expected constant expression
1>.\input.cpp(138) : error C2466: cannot allocate an array of constant size 0
1>.\input.cpp(138) : error C2133: 'd' : unknown size
EDIT 2: Should have posted the exact code I was working with. This error is produced when the constant length for the dynamically allocated array is calculated with run-time values.
Assuming random(a,b)
returns an int
between a
and b
,
const int len1 = random(1,5);
char a[len1]; // Errors, since the value
// is not known at compile time (thanks to answers)
whereas
const int len2 = 5;
char b[len2]; // Compiles just fine
When you're using new, you are allocating memory from the free-store/heap and you need to take care of releasing it yourself. Also, locating the free memory might actually take some time, as will freeing it.
When you are not using new, your memory gets reserved on the stack and is implicitly allocated and freed. I.e. when you enter a function, the call stack will just expand by the size of all your local variables (at least conceptually - for example, some variables can exist entirely in registers) and it will just be decremented when you leave the function.
When you allocate a variable with dynamic size on the stack as in your last example, it means that you need some additional information when entering the function scope. Specifically, the amount of space that needs to be reserved varies depending on the function inputs. Now if the context can be determined at the beginning of the function, everything is well - which is presumably why this is allowed in C99 - but if you have a variable for the size who's value you only know mid-function, you end up adding "fake" function calls. Together with C++'s scoping rules, this can get quite hairy, so it's conceptually a lot easier to just let C++ scoping take care of this via std::vector.
The third pair of lines should work, that should not be a compiler error. There must be something else going on there.
The difference between the first two examples is that the memory for
char a[5];
will automatically be freed, whilechar* b = new char[5];
allocates memory on that will not be freed until you expressly free it. An array that you allocate the first way can not be used once that particular variable goes out of scope because its destructor is automatically called and the memory is free to be overwritten. For an array created usingnew
, you may pass the pointer around and use it freely outside the scope of the original variable, and even outside of the function in which it was created until youdelete
it.Something that you cannot do is:
For dynamic memory allocation, the size must be known at compile time.
Your a array is allocated on the stack ; that means, once the program is compiled, it knows it will have to reserve 5 bytes to stores the chars of a. On the opposite, b is just declared as a pointer, and its content will be allocated at runtime on the heap, and that can fail if memory is too scarce. Finally, as be has been newed, it must be deleted at some point, or you will be leaking memory.
Assuming a typical but somewhat simplified C++ implementation, and that the above code appears in a function:
The stack pointer is moved by 5 bytes, to make a 5-byte space. The name
a
now refers to that block of 5 bytes of memory.The stack pointer is moved by
sizeof(char*)
, to make space forb
. A function is called, that goes away and allocates 5 bytes from a thing called the "free store", basically it carves 5 or more bytes off a big block of memory obtained from the OS, and does some book-keeping to ensure that when you free those bytes withdelete[]
, they will be made available for future allocations to re-use. It returns the address of that allocated block of 5 bytes, which is stored into the the space on the stack forb
.The reason that the second is more work than the first is that objects allocated with
new
can be deleted in any order. Local variables (aka "objects on the stack") are always destroyed in reverse order of being created, so less book-keeping is needed. In the case of trivially-destructible types, the implementation can just move the stack pointer by the same distance in the opposite direction.To remove some of the simplifications I made: the stack pointer isn't really moved once for each variable, possibly it's only moved once on function entry for all variables in the function, in this case the space required is at least
sizeof(char*) + 5
. There may be alignment requirements on the stack pointer or the individual variables which mean it's not moved by the size required, but rather by some rounded-up amount. The implementation (usually the optimizer) can eliminate unused variables, or use registers for them instead of stack space. Probably some other things I haven't thought of.The language rule is reasonably simple: the size of an array must be a constant expression. If a
const int
variable has an initializer in the same TU, and the initializer is a constant expression, then the variable name can be used in constant expressions.random(1,5)
is not a constant expression, hencelen1
cannot be used in constant expressions.5
is a constant expression, solen2
is fine.What the language rule is there for, is to ensure that array sizes are known at compile time. So to move the stack, the compiler can emit an instruction equivalent to
stack_pointer -= 5
(wherestack_pointer
will beesp
, orr13
, or whatever). After doing that, it still "knows" exactly what offsets every variable has from the new value of the stack pointer -- 5 different from the old stack pointer. Variable stack allocations create a greater burden on the implementation.char a[5]
allocates 5sizeof(char)
bytes to stack memory, whennew char[5]
allocates those bytes to heap memory. Bytes allocated to stack memory is also guaranteed to be freed when scope ends, unlike heap memory where you should free the memory explicitly.char d[len]
should be allowed since the variable is declared const and thus the compiler can easily make the code to allocate those bytes to stack memory.char a[5]
allocates 5 chars on the stack memory.new char[5]
allocates 5 chars on the heap memory.Both are compiled successfully for me.