Fix "does not name a type" without forward declaration

Pages: 12
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):
1
2
3
4
5
6
7
8
//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:
1
2
3
4
5
6
7
// 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:
1
2
3
4
5
6
// enemy.h
#include "baseclass.h"
class Enemy: public BaseClass {
    public:
        Enemy(int x, int y);
};

And its implementation:
1
2
3
4
5
6
7
// 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 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
};
Last edited on
Does problem persist in this stripped down programm? Because it won't for me.
VS2012 cl generates object code from this with no errors.
1
2
3
4
5
6
7
8
9
class Character;
class Enemy;

class Window {

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

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.
Last edited on
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!
Last edited on
In C++11 you should use an enum class for proper scoping ;)
I'm not sure what you mean.
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.
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...?
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.
trojansdestroy wrote:
what is useful about a function that only accepts an empty pointer?
If you are overloading functions for many pointer types
1
2
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);
Topic archived. No new replies allowed.
Pages: 12