Connect 4 Game Design in C++
Naming things
Avoid single-character variable names, unless it's something that is very commonly used, like i for a loop index. Consider r and c, even if you guess it has something to do with coordinates, are those positions or sizes? I would personally use width and height here as unambiguous names for the size of the grid.
Note that in the constructor's initializer list, you can use the same name for the parameter as for the member variable, like so:
int width;
int height;

public:
Connect4(int width, int height): width(width), height(height) {...}

Not everyone likes this style; some people want to disambiguate between parameter and member variable by writing:
Connect4(int width_, int height_): width(width_), height(height_) {...}

And you also see projects where all member variables are prefixed with m_, so it will look like:
int m_width;
int m_height;

public:
Connect4(int width, int height): m_width(width), m_height(height) {...}

Other variable names that could be improved:

cnt -&gt; count
itr -&gt; it (the latter is more idiomatic)
diag -&gt; diagonal
verify -&gt; line

Create an enum class for the possibly contents of a grid cell
An enum, and even better an enum class, allow you to specify the possible values of a grid cell up front, with names instead of integer values. I suggest you write the following:
class Connect4 {
    enum class Cell: char {
       EMPTY,
       PLAYER1,
       PLAYER2,
    };
};

The above also explicitly sets the type to char, so only one byte is necessary to store it.
Storing the grid
There are several things wrong with how you store the grid. The data structure you are using is very inefficient, both for large and small grids, and for checking for a winning condition. The best way is to use a single vector to store all the grid cells:
std::vector&lt;Cell&gt; grid;

This ensures things are laid out very compactly in memory, and to look up an arbitrary grid cell, the CPU only has to do one multiplication and two additions, which is very cheap on contemporary processors, and as Toby Speight already mentioned, to check horizontal, vertical and diagonal lines is very easy as well; just calculate the start point, end point and stride to use, and then every step along the line only a single addition has to be done to find out the grid cell to check.
I would add a function to get a reference to a grid cell given its coordinates, like so:
Cell &amp;at(int row, int col) {
    return grid[row * c + col];
}

Handling huge grids
The first thing to consider when dealing with huge grids/arrays/matrices is whether the data structure is going to be densely or sparsely populated. It's easy to think that it should be sparse, after all you start with the grid being completely empty. But consider that during the end game of connect 4, you will probably have used more than half of the grid cells, so a dense grid is likely the best way to store the state.
With the above Cell type, you use one byte per grid cell. Since a cell only has three possible states, you could pack up to five cells in a byte (since 3⁵ = 243) relatively easily, at the cost of some extra calculations when reading/writing a given cell. With this, a 100,000 by 50,000 grid fits in a little less than a gigabyte.
You might also think about compressing the grid somehow, but again consider what a connect 4 game looks like near the end. For sure there won't be runs of more than 3 cells with the same color in a row, otherwise there would already have been a winner. And you rarely see a repetitive pattern appearing. So it basically looks like noise, which is not compressible. Perhaps predictive coding could be used to compress the sequence of moves made by the players, but the compressed data would most likely not be in a form suitable for displaying the grid and checking winning conditions.
The only option I see for significantly reducing the amount of data is to consider that the bulk of the grid cells where players have already played will never be part of the 4 connected cells of the same color. For example, you could mark all cells that are more than 3 positions away (both horizontally and vertically) from any empty cells as being &quot;dead&quot;. This way, that in principle, instead of having to store \$\mathcal{O}(W \cdot H)\$, you only have to store \$\mathcal{O}(W + H)\$ grid cells. But that would mean that you cannot show exactly all the moves made so far anymore.
Checking for a winning condition
Your idea of keeping a per-line score is unfortunately not really helpful. It is quite easy to create a line where the total score would be four, but there are no 4 consecutive cells with the same player, for example, representing players 1 and 2 with O and X respectively:
X O O X O O X O O X O O

There are 8 pieces of player 1, and 4 of player 2, so your way of counting score would result in 4 or -4, but clearly no player has won yet. However, if player 1 adds two more O's to this line:
X O O X O O X O O X O O O O

Then player 1 has 4 in a row, but the &quot;line score&quot; would be 6 or -6. So the line score is not useful.
The simple solution is to just always check the 9x9 area surrounding the latest move for a horizontal, vertical or diagonal line with 4 in a row. This might seem a bit wasteful in the very early game when only few moves have been made, it doesn't really matter in the long run.