1

Why does this work without any errors?

int array[2];
array[5] = 21;
cout << array[5];

It printed out 21 just fine. But check this out! I changed 5 to 46 and it still worked. But when I put 47, it didn't print anything. And showed no errors anywhere. What's up with that!?!?

nvoigt
  • 75,013
  • 26
  • 93
  • 142
user2477112
  • 63
  • 1
  • 6

3 Answers3

5

Because it's simply undefined behaviour (there is no checks for bounds of arrays in C++). Anything can happen.

Simply array[5] is equivalent to *(&array[0] + 5), you are trying to write/read to memory, that you are not allocate.

ForEveR
  • 55,233
  • 2
  • 119
  • 133
1

The array has 2 elements, but you are assigning array[5] = 21; which means 21 is in memory outside the array. Depends on your system and environment array[46] is a valid memory to hold a number but array[47] isn't.

You should do this

int array[47];
array[47] = 21;
cout << array[47];
Ashwini Chaudhary
  • 244,495
  • 58
  • 464
  • 504
Thanushan
  • 532
  • 2
  • 8
  • I got it thanks a lot! But, off topic... dude... you're a guy? Never would have guessed that ashwini is also a guy's name ;) – user2477112 Jun 17 '13 at 09:06
1

In the C and C++ language there are very few runtime errors.

When you make a mistake what happens instead is that you get "undefined behavior" and that means that anything may happen. You can get a crash (i.e. the OS will stop the process because it's doing something nasty) or you can just corrupt memory in your program and things seems to work anyway until someone needs to use that memory. Unfortunately the second case is by far the most common so when a program writes outside an array normally the program crashes only one million instructions executed later, in a perfectly innocent and correct part.

The main philosophical assumption of C and C++ is that a programmer never makes mistakes like accessing an array with an out-of-bounds index, deallocating twice the same pointer, generating a signed integer overflow during a computation, dereferencing a null pointer and so on.

This is also the reason for which trying to learn C/C++ just using a compiler and experimenting by writing code is a terrible idea because you will not be notified of this pretty common kind of error.

6502
  • 112,025
  • 15
  • 165
  • 265
  • "the programmer makes no mistakes" is not part of the C++ philosophy. The philosophy is rather "Don't pay for what you do not use" (or "didn't ask for"), so it's more like "it's expected that the programmer reads the documentation". So if you want bounds-checking, you would use the `at()` family of function, and so on. – Sebastian Mach Jun 17 '13 at 10:12
  • @phresnel: Of course the reason runtime checks are not performed is not because who designed C and C++ was an idiot, it's instead an explicit (and IMO reasonable) decision to favor efficiency. However the absence of checks is pervasive and for example there's no option that saves you from dereferencing a null pointer, using an invalidated iterator or accessing via a reference to an already destroyed object. Reading the documentation is not enough, you must follow perfectly because the runtime is not in charge to check you make no violation. When you do it's a nasal daemon. – 6502 Jun 17 '13 at 10:27
  • Haha, yes. I have to add though that the option to get an exception upon null-pointer-dereferencation is to use a smart-pointer. – Sebastian Mach Jun 17 '13 at 10:41