0

I have the following code

#include <bits/stdc++.h>

using namespace std;

int main() {

    int r = 0, c = 0;
    int best = 0;

    cin >> r >> c;
    int myGrid[r + 2][c + 2] = {};

    for (int i = 1; i < r + 1; i++) {
        for (int j = 1; j < c + 1; j++) {
            cin >> myGrid[i][j];
        }
    }

    bool stillIn = false;

    int di[] = {-1,-1, -1, 0, 0, 1, 1, 1};
    int dj[] = {-1,0, 1, -1, 1, -1, 0, 1};

    for (int i = 1; i < r + 1; i++) {
        for (int J = 1; J < c + 1; J++) {
            stillIn = false;
            for (int k = 0; k < 8; k++) {
    //        cout << myGrid[i][J] << " " << endl;
                if (myGrid[i][J] == myGrid[di[k]][dj[k]]) {
                    stillIn = true;
                }
            }
            if (stillIn == true) {
                best = myGrid[i][J];
            }
        }
    }

    cout << best;

    return 0;
}

If I run the code with the following input:

4 3
0 1 0
1 2 0
1 5 1
2 3 4

It prints 4. However, if I uncomment line 28, which is

//        cout << myGrid[i][J] << " " << endl;

Then it gives me 1, which is the correct answer. Why is this happening!? How does using cout change the final answer?

Thanks in advance for any help.

Mike Smith
  • 527
  • 2
  • 6
  • 20
  • 1
    This is not allowed in standard C++ `int myGrid[r + 2][c + 2] = {};` since the size of an array must be know at compile time, not run time. Instead you should prefer `std::vector` for this case. – Cory Kramer Apr 19 '20 at 16:46
  • 2
    A side note: [Don't use `bits/stdc++.h`](https://stackoverflow.com/questions/31816095/why-should-i-not-include-bits-stdc-h), even though lazy teachers may tell you to. – CherryDT Apr 19 '20 at 16:48
  • Ok, there were a couple of other mistakes as well, but my program works now. Thanks everyone! – Mike Smith Apr 19 '20 at 16:58

1 Answers1

3

You have undefined behavior(UB) because you are indexing out of bounds on this line

myGrid[di[k]][dj[k]]

because di and dj contain values of -1.

If you have UB, then anything can happen, such as a cout statement exisiting or not, changing the program in weird ways.

Also variable length arrays are not allowed in standard c++.

cigien
  • 57,834
  • 11
  • 73
  • 112
  • Oh! no wonder. I forgot to put the i - and j - before those. However, I still have this question: how is the cout statement changing the final answer? – Mike Smith Apr 19 '20 at 16:51
  • 2
    Because it's undefined behavior. Undefined behavior is undefined. It can do literally anything, such as delete your harddrive or launch a nuclear attack. (That's very unlikely though, obviously .) And what exactly it does can be influenced by literally anything as well, such as whether you have a `cout` there or not. It's just that the code that ends up being generated looks a bit differently, probably using different registers or memory layout or doing different optimization, and that influences the result you see. – CherryDT Apr 19 '20 at 16:52
  • _Theoretically_ the out-of-bound access may turn the program into a copy of skynet, yes. As in, the C++ specs have nothing that says this can _not_ happen. (Obviously I was just trying to make a point. Although, I was actually unlucky once in such a way that I actually _did_ build code that started deleting all files on my harddisk due to undefined behavior! So it's not purely theoretical. Granted, there already existed a function in my code that was supposed to delete a folder and all its contents recursively, although it was not supposed to do that to `C:\ `) – CherryDT Apr 19 '20 at 17:03
  • What happened was that due to undefined behavior elsewhere, an empty string got passed into that function. And the function would check if the path already ended with `\ `, and if it didn't, add a `\ `. Now we got an empty string plus a backslash, that is _just_ a backslash - which means "root of the current drive", i.e. `C:\ `... Oops! – CherryDT Apr 19 '20 at 17:09
  • @CherryDT, I'm kidding, I do hope Arnold Schwarzenegger doesn't land in my living room and wrecks my furniture :). – anastaciu Apr 19 '20 at 17:09