If the files and errors have changed you will need to repost them. Line 21 of main.h is empty space.
Also don’t name things “even”. It is likely to conflict with something.


L. Spiro

You have a circular header dependency, as AverageMidget points out. #include is just dumb text replacement. The preprocessor literally copies and pastes the preprocessed contents of #included files at the point where the include is encountered.

Let us take a simpler example to illustrate. We have the following files:

tile.h

#ifndef TILE_H
#define TILE_H

class Tile
{
public:
enum Type
{
Green,
Black
// More tile types...
};

Tile(int x, int y, Type type)
:
x(x),
y(y),
type(type)
{
}

// Useful member functions...

private:
int x;
int y;
Type type;
};

#endif


tile_load.h

#ifndef TILE_LOAD_H
#define TILE_LOAD_H

#include "tile.h"
#include "main.h"

const int TILE_WIDTH = 32;
const int TOTAL_TILES = 225;
const int TILE_HEIGHT = 32;
const int TILE_SPRITES = 2;

bool set_tiles(Tile *tiles[]);

#endif


main.h

#ifndef MAIN_H
#define MAIN_H

#include "tile_load.h"

const int level_width = 15;
const int level_height = 15;

extern Tile *tiles[TOTAL_TILES];

#endif


Now imagine our main function source file:

#include "main.h"

int main()
{
set_tiles(tiles);
}

Let us look at what the tools do when compiling main.cpp. First, the file must be preprocessed to create a translation unit.

Here is our translation unit, annotated with comments to explain the preprocessor logic:

// Preprocessor begin include main.h
// Preprocessor check if MAIN_H defined: no
// Preprocessor add MAIN_H to list of defines (currently none)
// Preprocessor begin include tile_load.h
// Preprocessor check if TILE_LOAD_H defined: no
// Preprocessor add TILE_LOAD_H to list of defines (currently MAIN_H)
// Preprocessor begin include TILE_H
// Preprocessor check if TILE_H defined: no
// Preprocessor add TILE_H to list of defines (currently MAIN_H, TILE_LOAD_H)

class Tile
{
public:
enum Type
{
Green,
Black
// More tile types...
};

Tile(int x, int y, Type type)
:
x(x),
y(y),
type(type)
{
}

// Useful member functions...

private:
int x;
int y;
Type type;
};

// Preprocessor end include TILE_H
// Preprocessor begin include main.h
// Preprocessor check if MAIN_H defined: yes
// Preprocessor end include main.h

const int TILE_WIDTH = 32;
const int TOTAL_TILES = 225;
const int TILE_HEIGHT = 32;
const int TILE_SPRITES = 2;

bool set_tiles(Tile *tiles[]);

// Preprocessor end include tile_load.h


const int level_width = 15;
const int level_height = 15;

extern Tile *tiles[TOTAL_TILES];

// Preprocessor end include main.h

int main()
{
set_tiles(tiles);
}

This file is what the compiler actually sees. It sees one monolithic file which it compiles on its own. The file is compiled top to bottom (more or less), so if the order of the declarations that end up being included is incorrect then the compiler will issue errors. Your compiler will have a flag somewhere where you can ask it to output the preprocessed file, if you'd like to see for yourself. It will be scary experience though if you ever look at a preprocessed file that includes the standard library, Windows.h, SDL.h or any other large header.

You might already see that we just narrowly avoided trouble. When tile_load.h tried to include main.h, nothing happened because MAIN_H was already defined. Luckily in this simple example nothing in tile_load.h depended on anything that was only visible in main.h.

You're running into trouble because your more complex files do depend on each other's contents.

To catch such problems early, for each header file, have a source file which includes that header as the first line. This ensures that each header works in isolation. Another piece of advice is to avoid "pull everything in" headers like "main.h", "global.h", etc. Each header and source file should include only what it needs.

If you have some common external headers, from the Standard C++ Library, SDL or Boost, having a "common.h" or similar isn't too bad because these headers should never cause circular dependencies. However you will often be pulling in many unnecessary headers, which will affect your build times (note in my example above that "tile.h" doesn't need to include anything).

In a small project your build times will usually be so short that it would be difficult to measurably affect them, I wouldn't worry about them. When it does become an issue, moving these external headers to a precompiled header is one way to solve this.

Where is the declaration of "clips"? Is it properly declared extern in any header files, and defined in exactly one source file?

If you read my post, you might see how the compiler thinks that you have defined this variable in two translation units. If it is defined in a header that is included more than once this will be the case.

The key point is that the compiler doesn't see header files, or source files. These are destroyed by the preprocessing stage. It sees translation units. The linker sees compiled translation units, called object files. The toolchain isn't smart enough to work backwards to tell you where the errant definitions really came from.

This is what happens when a compilation process designed for computers with less than 16K of RAM circa 1970 is still used relatively unchanged today. It ain't your fault it is confusing - in fact it is a little braindead!