I made a few changes to my project and it now has two "bass class undefined" errors (for the same class, in the attached picture). I believe, from researching this online, that the problem is that I have circular references. However, I don't know how to remove it. To start, I would need to know what order my project is compiled in. Is there a file list that Visual Studio provides? I'm pretty sure it all starts at App.cpp, then App.h but then what's the next file? How does VS choose which CPP file comes next? Is it alphabetical? If there are 3 header files in a file, will it immediately do all of those headers next? I only have one header in each CPP file (the H file by the same name) but the headers may have 2 or 3.

Here's a screenshot of my project with the problematic class showing.

[attachment=23507:screen.gif]

Thank you for any help!

(By the way, I read that in other situations forward declaration is the way to go but that it doesn't work with base classes.)

How does VS choose which CPP file comes next? Is it alphabetical?

When you build your project there will usually be a window with the compiler output in the bottom. If you want to, you can read the sequence things happen out of there. However, that is not going to be relevant for your problem.

It would really help to post the relevant code (for example where is characterclass actually defined) instead of screenshots as well as complete error messages.

If there are 3 header files in a file, will it immediately do all of those headers next? I only have one header in each CPP file (the H file by the same name) but the headers may have 2 or 3.

Headers are irrelevant. The compiler only deals with .cpp files and an #include directive is just a convenient automatic way to paste the complete content of whatever file is referenced there. That happens during preprocessing before the compiler even sees it.

The most likely issues are that you did not include the header which declares characterclass or your inclusion guard did not use a unique enough define. Note that using '#pragma once' instead of manual inclusion guards would solve this problem immediately and is available on all three compilers an average person is likely to encounter (MSVC, gcc and clang).

On a more serious note, avoid 'using namespace' directives in headers. If you really need to, do that in implementation files or at function scope.

Changing all the headers to #pragma once did not change the result.

And as I mentioned in my original post, from what I'm reading online, forward declarations don't work for base classes.

"Derived classes definitely need to know the structure of their parent, not just that the parent exists, so a forward declaration would be insufficient." from here.

But here's my entire set of code files, should you want to take a look: [attachment=23508:Source.rar]

Oh, and excuse all the globals. ;)

A source file that includes character.h alone, such as character.cpp, will end up in a translation units that is built like this:

1. The file character.cpp, which is being compiled, includes character.h to the translation unit.
2. The file character.h includes world.h.
3. The file world.h includes character.h and player.h.
4. The file character.h is blocked by the include guard to prevent it from being included multiple times, but the file player.h is included.
5. The file player.h includes character.h, which is blocked again by the include guards.
6. The stack of includes falls back to character.h from step 2, and then to character.cpp from step 1.
7. ... and so on.

Pay attention to the order in which the files are included in the final translation unit. The class player ends up in step 4, but the character class it derives from is not included in the translation unit until step 5. Thus, the base class is actually defined after the derived class despite your attempt to include the base class before defining the derived class.

The solution is very simple in this case. What is the purpose of including character.h and player.h in world.h? There's nothing in world.h that depends on the contents of neither of the two files, and those unnecessary and seemingly harmless includes cause circular includes and symbols to not be defined in the correct places within a translation unit.

The solution is very simple in this case. What is the purpose of including character.h and player.h in world.h? There's nothing in world.h that depends on the contents of neither of the two files, and those unnecessary and seemingly harmless includes cause circular includes and symbols to not be defined in the correct places within a translation unit.

Thank you. world.cpp uses the player class. And I was under the impression from somewhere that you should only put one header include in cpp files whenever possible. So I put player.h in world.h instead. But when issues started happening, I added character.h as well to make sure it's included first as I thought: what's the harm? Better to make sure it's included as it can't be included twice anyway, right? And yet there are these circular references which, in my less-than-knowledgable mind, shouldn't even be possible (but I'm starting to understand a bit that the system doesn't work the way I thought it did, thanks to people's help here). I'll see what happens if I put player.h into world.cpp instead but it seems like that would do the same thing...

Thank you. world.cpp uses the player class. And I was under the impression from somewhere that you should only put one header include in cpp files whenever possible.

That is completely untrue. The aim in general is to limit the number of includes in headers files (don't include what you do not need, use forward declarations where possible). Implementation files will often need the complete definition of things they use and then you need to include all relevant headers there.

And yet there are these circular references which, in my less-than-knowledgable mind, shouldn't even be possible (but I'm starting to understand a bit that the system doesn't work the way I thought it did, thanks to people's help here).

Both the manual #ifdef/#define inclusion guards and #pragma once are not magic. They avoid repeated declaration errors but you still cannot have two headers depending on declarations in the other.

Thank you everyone. I'm going to reread the posts here to get a better grasp (lot of the terminology is new to me) and rework my includes where possible.