Fix "does not name a type" without forward declaration

[DEUX92yv]

All of my header files have guards, so I won't post those in this case.
An extremely simplified version of my program, with some relevant stuff:

A class used in main (provided for comparison):

//character.h
#include <QGraphicsPixmapItem>
#include <QObject>
class Character: public QObject, public QGraphicsPixmapItem {
    Q_OBJECT
    public:
        Character(int x, int y);  // defined in character.cpp
};

A class inherited by five others to allow for easily keeping track of them:

// baseclass.h
#include <QGraphicsPixmapItem>
class BaseClass: public QGraphicsPixmapItem {
    public:
        BaseClass(int x, int y); // defined in baseclass.cpp;
                                 // is different than that for Character()
};

One of these five classes; the one I'm having trouble with:

// enemy.h
#include "baseclass.h"
class Enemy: public BaseClass {
    public:
        Enemy(int x, int y);
};

And its implementation:

// enemy.cpp
#include "enemy.h"
Enemy::Enemy(int x, int y)
    : BaseClass(x, y)
{
    // other members' initializations
}

The main window class, where the error occurs:

// window.h
#include // Qt headers, from all of which an object is used in Window,
         // or Window inherits from it

// Forward declarations
class Character; // causes no problems
class Enemy; // doesn't work

class Window: public /* relevant Qheader */ {
    Q_OBJECT
    private:
        Character* character; // no problem
        Enemy* enemy; // 'Enemy' does not name a type
};

[MiiNiPaa]

Does problem persist in this stripped down programm? Because it won't for me.

[keskiverto]

VS2012 cl generates object code from this with no errors.

class Character;
class Enemy;

class Window {

    private:
        Character* character;
        Enemy* enemy;
};

[LB]

Copy your project to a new folder and start stripping things out until it compiles. That's the easiest way to figure it out with us being able to see your code.

[DEUX92yv]

I have determined the problem. In my Window class, I have an enum State. One of the elements of State is named Enemy. Poor naming practice on my behalf caused Enemy* to be read as 6*, which as we all know is a pointer to 6.

Credit to VS2012's syntax highlighter not quite highlighting the word Enemy! (As it does with all other classes)

Such a simple problem for many minds much greater than mine to have pondered; I apologize for wasting your time. Thank you very much for your help!

[LB]

In C++11 you should use an enum class for proper scoping ;)

[DEUX92yv]

I'm not sure what you mean.

[MiiNiPaa]

http://www.cprogramming.com/c++11/c++11-nullptr-strongly-typed-enum-class.html

[DEUX92yv]

I see. I didn't realize that enums were now available as a class, but even I in my minute understanding of C++ see the value of that improvement (at least the part that I can understand). Thanks all for your time.

[DEUX92yv]

Something in that article caught my attention. If NULL is 0, why does the keyword NULL exist at all? Is it only for human-readable code?

Also, what is useful about a function that only accepts an empty pointer? The one thing I can think of (which is HUGELY valuable, don't get me wrong) is that you can't overwrite dynamically allocated memory this way. Other than that...?

[MiiNiPaa]

why does the keyword NULL exist at all

For readability and as a backward compatibility with C. Today you should use nullptr.
Actually NULL isn't always 0. In gcc on 64x machines it is 0LL (of long long type, where 0 is int type). 0LL (or NULL as my compiler set to 64bit mode) gives me an ambiguos overload, 0 calls int function and nullptr cals char* function.

what is useful about a function that only accepts an empty pointer

No idea.

[Peter87]

trojansdestroy wrote:

what is useful about a function that only accepts an empty pointer?

If you are overloading functions for many pointer types

void foo(char*);
void foo(int*);

calling foo(nullptr) would be ambiguous. Adding an overload for std::nullptr_t fixes the problem.

void foo(std::nullptr_t);