0

How is it that this comes back with a value for array[6]?

#include <iostream>
using namespace std;

int main()
{
int z;
char array[5];
array[0] = 28;
array[1] = 14;
array[2] = 68;
array[3] = 100;
array[4] = 225;
array[6] = 30;

cout << array << endl;
cout << array[6]; 

return 0;
}

My understanding of arrays is that they are more like pointers to memory where the memory is set by the initialization in this case 5. However, when I place a value for the 6th element it will compile even though it was not a set element. It does not show as part of the array, but I can print the element by itself. Is this because it is just as I thought merely a pointer? It seems that 6 is not part of the container though because it only prints individually and not part of the array. Am I right in thinking this way or is this just one of those friendly compiler issues that I need to be aware of?

  • 1
    Arrays do not check for boudaries. What you are doing is undefined behavior. – rpsml May 16 '15 at 20:13
  • C++ has no array bounds checking. You want to declare an array of 2 elements, and write to element 10,000, go ahead. The problem is that you don't know what will happen. – PaulMcKenzie May 16 '15 at 20:13
  • print array[7] without define it and it will print that value too . – sparsh610 May 16 '15 at 20:14
  • @SparshKhandelwal Or it may not. Since this is UB, you may get a nasal demon instead :-) – Walter May 16 '15 at 20:15
  • Why stop there? `int array[5]; //... for (int i = 0; i < 10000, ++i) cout << array[ i ];` What will happen? Maybe you will print all 0's? Maybe the program will crash after array[5]? I don't know -- that's what *undefined behavior* is about. – PaulMcKenzie May 16 '15 at 20:16
  • @Walter yeah , it will print some value you can not predict. Am i wrong ? – sparsh610 May 16 '15 at 20:17
  • @SparshKhandelwal yes, you're wrong. *anything* may happen. The compiler is allowed to insert code that crashes your computer (though I'm not aware of such a compiler). See the accepted answer in the question referred to at the top. – Walter May 16 '15 at 20:31
  • @Walter yeah you can not predict, anything can happen .. might print ,may crash something known as UB – sparsh610 May 16 '15 at 20:35
  • wouldn't it only be UB for elements that I do not assign values to? in the case here I had assigned a value to 6. if I hadn't then who knows, but since a value was assigned does this not allow for expansion beyond the container ( obviously this would not be a good idea but this is theoretical ) – David St Pierre May 16 '15 at 20:41
  • @DavidStPierre Assigning or reading beyond the boundaries of your array is UB. There is no "memory expansion" happening. – PaulMcKenzie May 16 '15 at 21:44
  • @PaulMcKenzie I am not saying that the memory allocated to the array is expanded I am merely making a note of how the array is, by adding an element that was not part of the original array, allowing access to memory outside of said restrictions. I understand the logical error in this and would never recommend it. The result of printing that element would still be of a char regardless because it is pointing to a byte. Altering that byte could cause unknown issues, but within the program would still come back with the same result. – David St Pierre May 16 '15 at 22:34
  • @PaulMcKenzie yes it is by definition UB, but in theory we are still able to perform actions with the same results when assigning values to these elements. – David St Pierre May 16 '15 at 22:37
  • @DavidStPierre Attempting to even read the byte back is UB. That behavior may be an immediate crash due to a read access violation. So that byte you're trying to get to just doesn't get to you. – PaulMcKenzie May 16 '15 at 22:42

0 Answers0