>>95202004>By runtime overhead, I mean of having a bunch of extra allocations and bookkeeping overhead of extra vectors, which is also worse for memory locality.>The index calculations are unavoidable.as the article linked by
>>95201898 says, VLA are almost always the BAD solution.
subOP has such solutions.
decide on memory allocation: constant or in "rows" (as you said)
1) linear-memory
allocate mx*my*mz*mb*sizeof(elem), and then either:
1a) then write full formula to access it like data[ x + y*mx +z*mx*my + b*mx*my*bz ] in each place. sucks balls.
1b) write a class(C++) or function to access element int & access(x,y,z,b, mx,my,mz,mb)
1c) write a templated class for 4d array with that ::access(x,y,z,b) function . fast (not idiotic) runtime and easy to use
1d) use boost::multi....dimensional..array mentioned above, which is like (1c) but already done by these guys
2) blocks of memory - "malloc"
for each x, allocate array of size [my], and place it (the pointer) into data[x]
then next that 3 (total of 4) times.
so you have
array of pointers to
array of pointers to
array of pointers to
array of pointers to integers
2a) data[x][y][z][b:lit] will work. it does 4 pointer "jumps" (slowly, probably bad for memory locality too). ofc that only matters in some applications.
2b) use C++ vector<vector<vector<vector<int>>>> - it's like (1a) but compiler generates all the code
seeing how annoying this is in C, is really a good reason to use C++ and 1d or 2b solution. in C you will pit fall so many times, also with deleting this array properly and all else. maybe it will even "work" but it still has bugs.
then one day you decide you need 5-d array after all (already you do use both 4d and 3d), or other data type, or something like that, and you will be ENRAGED as all the code already written needs fucking terrible manual rewriting.
while C++ chads just add one more vector< > around it and it werks.
basically that is nice example why C++ was invented.
