The issue is that
is overloaded to select on the type. That is, there is one for
, and another for
, and for
is is confusing the compiler.
is probably relying on some tricky (and therefore fragile
) type promotion behavior the compiler is letting pass, and should not be trusted.
Crank your compiler warnings up to see if it complains.
If you want to see the actual type of
, you can use a couple of tricks to compile a small file that will tell you.
• method one: https://stackoverflow.com/a/56766138/2706707
• method two: https://stackoverflow.com/a/14617848/2706707
Regardless of whether your
array has a constants size, using magic numbers is code smell. Follow the ODR rule and declare it correctly. This will save you headache later:
constexpr std::size_t UO_SLOPE_MAX_SIZE = 4096;
int UO_Slope [UO_SLOPE_MAX_SIZE];
std::size_t UO_Slope_Size = 0; // number of items in actual use in the array, in [0,4096).
Then wherever you access the elements of
you know how many elements are in actual use:
for (std::size_t n = 0; n < UO_Slope_Size; n += 1)
do_something_with( UO_Slope[n] );
I notice that you have defined an array with a subdimension of length one
. That is very odd, and is equivalent to declaring the array without the subdimension size.
What happens, then, is when you have code to access the second
element of the subarray
second element of zero-based array!
the compiler assumes that you the programmer knows what you are doing and does not check that you are making a fencepost error. The consequence is that you actually access the next
item in the array:
The fencepost error causes:
• the first element of the array (
) to never be accessed, and
• a buffer overflow attempt to access one more element than the array possesses.
That second bullet is significant, because it is undefined behavior
. You just haven’t been bitten hard enough to see your program crash. Yet. But you are certainly being bitten somewhere. You just haven’t noticed yet. (Probably.)
So, yeah, in C++ arrays index from zero.