Question

In a multi-dimensional array where the second dimension will be of known sizes (albeit different per each first dimension), would it be faster performance-wise for the actual building of these arrays to hardcode:

int* number[1000];

int secondDim[1];
number[0] = secondDim;

int secondDimTwo[2];
number[1] = secondDim;

etc. etc. 1,000 times (I know, I know)

or dynamically allocate each second dimension:

for(int i = 0; i < 1000; i++)
    number[i] = new int[i+1];

Just trying to wrap my head around a concept here.

Answer 1

As a general rule you can assume, that stack allocations will be faster. Just remember that stack has limited capacity, and overuse of large stack-allocated arrays might lead to, wait for it… stack overflow!

Anyways, your question is valid, but the solutions I’ve seen so far are extremely limited. The thing is, you can easily create utility type, that will act as triangular matrix, and then it’s up to specific use case whether you’ll store it on the stack or heap. Observe:

namespace meta
{
    template <size_t N>
    struct sum
    {
        static const int value = (N + 1) * N / 2;
    };
}

template <size_t Size>
struct MultiArray
{
    // actual buffer
    int numbers[ meta::sum<Size>::value ];

    // run-time indexing
    int* getArray(size_t dimensions)
    {
        // get sum of (dimensions-1)
        size_t index = (dimensions * (dimensions-1)) >> 1;
        return &numbers[index];
    }

    // compile-time indexing
    template <size_t dimensions>
    int* getArray()
    {
        size_t index = meta::sum<dimensions - 1>::value ;
        return &numbers[ index ];
    }

    int* operator[](size_t index)
    {
        return getArray(index);
    }
};

Now it’s up to you where to store it.

MultiArray<1000> storedOnStack;
MultiArray<1000>* storedOnHeap = new MultiArray<1000>();

You have to accessors to get to the inner arrays:

int* runTimeResolvedArray = storedOnStack.getArray(10);
int* compileTimeResolvedArray = storedOnStack.getArray<10>();
int* runTimeResolvedArray2 = storedOnStack[10];
storedOnStack[10][0] = 666;

Hope this helps!

EDIT:
I also must say that I don’t like the term “stack allocation”. It’s misleading. Stack allocation is essentially just an increase in stack pointer register. So, if you “allocate” 100 bytes on stack the pointer will be increased by 100 bytes. But if you allocate 100 bytes on heap, then it gets complicated – current allocator has to find suitable empty memory space, update alloc map and so on, so on.

If it’s one time allocation – go ahead and do it on the heap, the overhead of dynamic allocation won’t be noticable. But if do it many times per second, then opt for stack allocation. Also, stack arrays can be potentially faster to access, because stack contents are more likely to be in cache. But obviously really huge arrays won’t fit cache. So, the anwser is: profile.