2

I had declared a array as

int* arr = new int[10];

Then I filled up the first 10 element and also did

arr[10] = 100;
arr[11] = 200;

When I do 

cout << arr[10] << '\t' << arr[11];

and the output was

100   200

I wonder why the code is working. Is this valid or am I missing some information on this topic. Shouldn't the arr[10] and arr[11] be holding any garbage value.

Sudip Ghimire
  • 677
  • 6
  • 15
  • 7
    You are missing the concept of *undefined behavior*. – PaulMcKenzie Apr 21 '20 at 16:35
  • 2
    The code is "working" because of bad luck. If you were truly lucky it would crash and that would confirm that it's not valid. – Pete Becker Apr 21 '20 at 16:37
  • do mean "why the code is working?" as in "why did you get that result when you used that specific compiler with that compiler options and running it on that particular machine?" or as in "does it really work?", for the first you need to study the assembly, for the latter the answer is "no this is invalid code" – 463035818_is_not_an_ai Apr 21 '20 at 16:41
  • 2
    Undefined does not mean "will crash". It means the C++ standard leaves it up to the compiler to define or not define what happens in these situations. By allowing undefined behavior in the standard, it allows implementations to make optimizations that they otherwise wouldn't be able to. If accessing an array out of bound was defined to throw an out of bounds error, then array access would get quite expensive. By leaving it undefined the compiler is free to ignore that bounds checking. By the way, you're LUCKY if you get a crash, not the other way around. Prefer loud errors over silent errors. – JohnFilleau Apr 21 '20 at 16:43
  • @PaulMcKenzie rather extremely unlucky, this could be a test that passed on debug and go havoc in production – 463035818_is_not_an_ai Apr 21 '20 at 16:43
  • Check out what happens if you create a second array right before printing the values of the first. When I run it, the last two numbers that are out of bounds become garbage – lucidbrot Apr 21 '20 at 16:44
  • The most horrifying thing about undefined behaviour is the visible result can be what you expected. – user4581301 Apr 21 '20 at 16:58
  • I have been referring to a book of c++ and the book was also doing the same. So that made me confused – Sudip Ghimire Apr 22 '20 at 04:23
  • I worked everythime and in different madchine too. Should I avoid it, even the book i am referring to is doing the same – Sudip Ghimire Apr 22 '20 at 04:24

1 Answers1

0

Reading/Writing out-of-bounds on an array is undefined behaviour, so anything can happen. It might work, it might not work, it might work every second full moon, anything goes.

melk
  • 530
  • 3
  • 9
  • I worked everythime and in different madchine too. Should I avoid it, even the book i am referring to is doing the same – Sudip Ghimire Apr 22 '20 at 04:24
  • @SudipGhimire You should definitely avoid it. The reason why undefined behaviour is so bad is exaclty because it might work in a seemingly predictable or "correct" manner. But you can't rely on that. It might work as you expect for 20 years, and then stop working. It might crash only one time in a million tries. Which will give you a real headache when trying to debug it. Is your book actually suggesting you do this in production code? Because if so, I suggeest you find another book. – melk Apr 22 '20 at 05:42