@JoeJ I've been told that โInsanity is doing the same thing over and over again and expecting different results.โ
So I have to ask, are you certifiable?
@JoeJ I've been told that โInsanity is doing the same thing over and over again and expecting different results.โ
So I have to ask, are you certifiable?
๐๐๐๐๐<โThe tone posse, ready for action.
JoeJ said:
However, using 2D arrays is not recommended for performance reasons. (Although i'm not sure this concern is still upright with modern compilers, i never use 2D arrays at all) So we usually use a 1D array and care about indexing math ourselves:
The CPP book defines this approach as the way to implement 2D arrays, so basically you're doing manually what the compiler would do otherwise.
That also invalidates the argument that doing this yourself has better performance.
Alberth said:
JoeJ said:
However, using 2D arrays is not recommended for performance reasons. (Although i'm not sure this concern is still upright with modern compilers, i never use 2D arrays at all) So we usually use a 1D array and care about indexing math ourselves:The CPP book defines this approach as the way to implement 2D arrays, so basically you're doing manually what the compiler would do otherwise.
That also invalidates the argument that doing this yourself has better performance.
There are still some differences between the two.
In terms of how the array is laid out, both are equivalent. A int[x][y] and an int [y * 8 + x] both occupy one linear piece of memory. However, they access somehow differs. As there is no multi-argument []-operator in c++, technically what the [x] for addressing the 2d-array does, is give you a pointer to a 1d-array, which is then indexed again (instead of calculating the full index/address as you do in the 1d example). This can have different performance characteristics, especially in debug-builds. In release, those differences mostly go away, but can still be present. I made a quick example in godbolt:
https://godbolt.org/z/o6z1PKa8Tโ
Depending on the compiler and optimization-settings, the result is more or less the same between two methods (but even with -O3, some instructions change). Though clang seems to have some strange deviation, causing it to generate a lot more code for filling the 2d-array (which I'm not sure if it's a bug or just better loo-unrolling).
So in practice, one over the other doesn't really matter, though both are not exactly the same. I personally tend to find it easier to use 1d and calculate the index myself (as I then know that I'm doing the cache-efficient addressing correct while iterating). Also it's easier if you need to process the whole linear array at once, or have a precalculated index, etcโฆ . In Addition, once you go with vector<>, now the 2d example (vector<vector<>>) is significantly worse then having a 1d vector with a customized index.
Alberth said:
JoeJ said:
However, using 2D arrays is not recommended for performance reasons. (Although i'm not sure this concern is still upright with modern compilers, i never use 2D arrays at all) So we usually use a 1D array and care about indexing math ourselves:The CPP book defines this approach as the way to implement 2D arrays, so basically you're doing manually what the compiler would do otherwise.
That also invalidates the argument that doing this yourself has better performance.
I remember i have read this advise to avoid 2D arrays really often in the 90's. Maybe even in the Kerninghan Ritchie C book, but could be wrong.
I do not remember the given reasoning, but it was not really convincing. I would have assumed compilers are smart enough to give similar outputs for either method even back then, but maybe in times of Turbo-C and Watcom some compilers had such problem and that's where the advice comes from. It's likely outdated now, and i never did any related profiling.
But you're right. I take back my advise to avoid 2D arrays, and keep upright only to avoid nested vectors if possible.
pbivens67 said:
so should I use vectors or arrays?
You decide. There is no general argument we could give to clearly prefer one over the other.
Personally i would use the std::vector. Because i like how it abstracts away allocation. This way i can't forget to free the memory.
It also has range checks in debug mode, so it can help to detect indexing bugs. Although you can get this for arrays too if you use std::array.
pbivens67 said:
so should I use vectors or arrays?
Why do you keep asking this question year after year? It shows that you don't understand vectors and maybe you don't understand arrays.
๐๐๐๐๐<โThe tone posse, ready for action.
pbivens67 said:
so should I use vectors or arrays?
A C++ std::vector
is a dynamic array. It is an array internally that the system manages for you, and resizes for you when needed.
There is nothing wrong with using arrays yourself and doing the associated management yourself, or with letting the std::vector
class do that management for you. Doing it yourself gives you a little bit of additional control, but you probably don't need it.
Usually you should use C++ std::vector
as a container unless you have specific reasons not to.
It is also extremely important to understand the parts about โinvalidationโ, which should be covered in your book. Any time you add something to a C++ std::vector
it can potentially move everything to a new place in memory, which can break systems if you refer to items the wrong way. Any time you add something to the collection all the old references and pointers to items become invalid. You'll see more in your book about iterators, too.
fleabay said:
It shows that you don't understand vectors and maybe you don't understand arrays.
Agreed, but please be careful about tone. This is For Beginners. We all learn at a different pace, the important thing from my perspective is that he's had slow but continuous advancing, that he keeps working through examples in his books, and he asks progressively more advanced questions. The questions aren't always great, and sometimes not even actual questions, but it is clear that progress is being made. That's an important element of the For Beginners part of the site. Even if you see the progress as painfully slow for you, it is still progress.