-3

In grid.h, I have

#ifndef __GRID_H__
#define __GRID_H__

#include "block.h"

extern char **theBoard;
extern Block* blocks[40];

#endif

In my "board.h" file, I have (abbreviated)

#include "block.h"
class Board
{
    ....
    char **theBoard;
    Block* blocks[40];
    ....
}

In my "board.cpp" file, I have initialized theBoard and blocks (abbreviated)

#include "board.h"
#include "grid.h"

theBoard = new char*[18];
for(int i=0; i<18; i++){
    theBoard[i] = new char[10];
    for(int j=0; j<10; j++){
        theBoard[i][j] = ' ';
    }
}
for (int i = 0; i < 40; i++)
    blocks[i] = 0;

In my "block.h" file I have (abbreviated)

class Block
{
    ....
    char **theBoard;
    Block* blocks[40];
    ....
}

In my "block.cc" file, I have (abbreviated)

#include "grid.h"
#include "block.h"

//somewhere in the file I try to read theBoard[1][1]

My program crashes when it tries to read theBoard[1][1] in block.cc. Placing a debugger's watch window on theBoard shows that it is pointing to garbage when the program is running instructions in block.cc

The code is like that because I'm trying to follow the instructions given in answers others have given for the same problem in similar questions posted here.

I'm trying to use the global variables declared in grid.h in every file that includes grid.h.

Can anyone tell me where I made a mistake in using global variables?

Thanks

user3240815
  • 21
  • 1
  • 5
  • You're using a [reserved identifier](http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier) and I'm not sure what's up with the `extern` variables. – chris Jul 30 '14 at 03:29
  • 1
    Unless you have a reason not to use the STL classes, I would strongly recommend using `std::vector< std::vector >` over `char**`. – cdhowie Jul 30 '14 at 03:30
  • 1
    You should avoid global variable, make the code hard to handle. – user1436187 Jul 30 '14 at 03:31
  • 1
    Firstly, it is not clear where your code in `board.cpp` resides. What function? Secondly, I hope you do understand that your `extern` variables in `grid.h` have absolutely nothing to do with your in-class variables in `board.h` and have nothing to do with in-class variables in `block.h`. So, what variables are you working with when the crash happens? Global ones? In-class ones? Which class? – AnT stands with Russia Jul 30 '14 at 03:31
  • 4
    Where do you define the global `theBoard` and `blocks`? Note that the similarly named ones in the `Board` and `Block` classes are *different* variables. – Greg Hewgill Jul 30 '14 at 03:32
  • 1
    Even if you didn't use STL, why didn't you just do this: `char theBoard[18][10];`? There is no need to dynamically allocate anything -- you know at compile time what the sizes will be. – PaulMcKenzie Jul 30 '14 at 03:36
  • I should use vectors, and change this. Originally it was char** because I was trying to pass the 2D array as a pointer to another class. I just started with the idea of using global variables because trying to pass it as a pointer to other classes would make my code too messy. I'm trying to use the global variables declared in grid.h in every file that includes grid.h. – user3240815 Jul 30 '14 at 03:50
  • @user3240815 You can pass pointers to vectors as well (references would be even better), or you can pass a reference to the `Board` object itself, or you can templatize the code that uses it, or... There are any number of things you can do easily without managing your own memory. – cdhowie Jul 30 '14 at 04:02

1 Answers1

1

Having a variable declaration at global scope doesn't magically promote all other uses of that identifier to access the global variable. Instead, using the same name for variables in other scopes will hide the global. (It can still be accessed via a qualified name)

In your program you have both declarations of ::theBoard, a global variable, and Block::theBoard, a non-static member variable of class Block. Ditto for ::blocks and Block::blocks.

Inside of class Block and its member functions, unqualified usage theBoard and blocks will refer to the member. Outside, unqualified usage will refer to the global.

A global variable declaration (using extern) also needs a matching definition, which must be at global scope, in exactly one compilation unit (don't put the definition into a header file). That's what causes the linker to allocate memory for the variable.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720