erm, so what would be the best way to get a large array? which is also fast.
>>> You can have a dynamic array that _points_ to the stack, but there is >>> no general mechanism for allocating a dynamic array directly on the >>> stack. You might be able to do something with alloca, but stack space >>> is usually limited and you wouldn't be able to have very large arrays. >>> >>> Performance of dynamic arrays is the same no matter where their data >>> is. Fixed-size 2D arrays are not faster _because_ they are on the >>> stack, they just happen to be allocated on the stack. They are faster >>> (usually) because they don't need two pointer dereferences. You can >>> allocated a fixed-size 2D array on the heap (well.. inside a struct or >>> class anyway) and it will be just as fast. >> >> Ok, so when I want a multimillion array with speed I should use a static >> array on the heap. That would be using new, right :) > > You.. can't actually allocate a static array on the heap using new. > At least not directly. It's kind of an embarrassing hole in the > syntax. In fact, I'm not sure if you can even get a static array to > point onto the heap, since a static array "reference" is treated like > a value type when assigned to, so if you do something like: > > int[3][4] b = (new int[3][4][](1))[0]; > > The weirdness on the right-hand-side is needed to get around the > compiler "helpfully" rewriting "new int[3][4]" as "new int[][](3, 4)". > But this code will simply allocate a static array on the heap, and > then copy its contents onto the stack. Dumb. > > Other than using a struct/class that contains a static array and > allocating _that_ on the heap, I don't know of any way of getting it > on the heap. But then you'd be double-dereferencing anyway since > you'd have to go through the struct pointer or class reference! Sigh.
