3

I have a C++ project in VS with more or less 100 files (each file is a class). I modified one a couple of days ago, adding some declarations, and now I can't compile and it gives a lot of errors and this one lastly:

error count exceeds 100; stopping compilation

Posting the errors seems useless, but here are some (the are all pretty much the same):

error C2275: 'btTransform' : illegal use of this type as an expression  
error C2275: 'btVector3' : illegal use of this type as an expression
error C2275: 'btVector3' : illegal use of this type as an expression    
error C2275: 'btVector3' : illegal use of this type as an expression    
error C2504: 'Platform' : base class undefined
error C2535: 'btAlignedObjectArray<T>

Note than most of the mentioned errors shouldn't be errors, and IntelliSense shows no error in the error list output. And I am completely sure I forgot a ; or something similar.

What should I do? Also I am working with a lot of stuff, and I forgot which file I modified. I browsed through most of them and couldn't find anything.

Here is the complete list: http://pastebin.com/1CD9fGgn (it is so long that it doesn't fit here)

As requested:

Player.h

#pragma once
#include <Ogre.h>
#include "BtOgreGP.h"
#include "BtOgrePG.h"
#include <OISKeyboard.h>
#include <OISJoyStick.h>
#include "BulletCollision\CollisionDispatch\btGhostObject.h"
#include "balance.h"
#include "WorldGenerator.h"
#include "Keys.h"
#include "PlayerController.h"

using namespace Ogre;

class Player
{
public:
    Player(Root*, SceneManager*, RenderWindow*);
    ~Player(void);
    Camera* mCamera;
    void update(const FrameEvent&);
    bool isTouchingBelow();
//  bool isJumping();
    btPairCachingGhostObject* getGhostObject()
    {
        return mGhostObject;
    }
    void clearObjectTouchingNormal()
    {
        mNormals->clear();
    }
    void addObjectTouchingNormal(btVector3* vector)
    {
        mNormals->push_back(*vector);
    }
    btAlignedObjectArray<btVector3> getObjectTouchingNormal()
    {
        return *mNormals;
    }
private:
    btAlignedObjectArray<btVector3>* mNormals;
    double mTimeLastJump;
    WorldGenerator* mGenerator;
    bool mPressJumpLastUpdate;
//  btAlignedObjectArray<btVector3> getObjectTouchingNormal();
    Vector3 mLastVectorVelocity;
    //SceneNode* mCameraHelper;
    SceneNode* mMainNode;
    SceneNode* mBodyNode;
    SceneNode* mCameraPivot;
    SceneNode* mCameraYaw;
    SceneNode* mCameraPitch;
    SceneNode* mCameraHolder;
    SceneManager* mSceneManager;
    BtOgre::DebugDrawer* mDebugDrawer;
    //btRigidBody* mPlayerBody;
    btQuaternion* mDefaultQuaternion;
    Vector3 mStartPosition;
    PlayerController* mKinematicController;
    btPairCachingGhostObject* mGhostObject;
    //bool mIsJumping;
    Radian mLastRotation;
    btVector3 mBodyDimensions;
    /*bool mCameraCenterMovementFlag;
    Radian mCameraCenterYaw;*/
};

class ClosestNotMe : public btCollisionWorld::ClosestRayResultCallback
{
protected:
    btRigidBody* mMe;
public:
    ClosestNotMe (btRigidBody* me) : btCollisionWorld::ClosestRayResultCallback(btVector3(0.0, 0.0, 0.0), btVector3(0.0, 0.0, 0.0))
    {
        mMe = me;
    }

    virtual btScalar addSingleResult(btCollisionWorld::LocalRayResult& rayResult,bool normalInWorldSpace)
    {
        if (rayResult.m_collisionObject == mMe)
            return 1.0;

        return btCollisionWorld::ClosestRayResultCallback::addSingleResult (rayResult, normalInWorldSpace);
    }
};

Globals.h

#pragma once
#include <Ogre.h>
#include <vector>
#include "Player.h"

enum GameDifficulty
{
    GD_EASY,
    GD_NORMAL,
    GD_HARD
};

class GlobalVariables
{
public:
    static std::vector<Player*> players;
};
Pacha
  • 1,438
  • 3
  • 23
  • 46
  • 8
    Look at the first error. Usually this causes most of the rest of them. – Hogan Jul 17 '13 at 03:31
  • How do I look that? The errors are not numbered. – Pacha Jul 17 '13 at 04:03
  • 2
    This is one good reason to use source control. That way, you could diff against the latest good version, to isolate your changes. – Oliver Charlesworth Jul 17 '13 at 04:06
  • Sort not by error message, but by location or line number. – icktoofay Jul 17 '13 at 04:07
  • 5
    "The errors are not numbered." But they are presented in the sequence in which they were encountered. – Brian Cain Jul 17 '13 at 04:10
  • @BrianCain I can sort them like this: http://imgur.com/6VUkYK0 and the first error says `'Player': undeclared identifier`, but it is declared as I included the file where Player.h is. Here is the code http://pastebin.com/PqG2eQvR – Pacha Jul 17 '13 at 04:12
  • You should post your code here. You can mark the code and click on `{}` to format it nicely. Dont't forget to past your header file. It's probably the reason for the error message. – harper Jul 17 '13 at 04:16
  • Why don't you take a look at the raw error message from the compiler or the build log? It should refer to the actual file and line# it's happening on. – greatwolf Jul 17 '13 at 04:18
  • Did you `#include `? And `class GlobalVariables` is kind of cheating... – Crowman Jul 17 '13 at 04:19
  • @PaulGriffiths it is useless to include `vector`, as Ogre.h already includes it. – Pacha Jul 17 '13 at 04:24
  • 1
    What .cpp file was it compiling when the first error came up? – greatwolf Jul 17 '13 at 04:26
  • 5
    Statements like `most of the mentioned errors shouldn't be errors` is tantamount to saying the compiler is wrong about the error. Keep in mind that your interaction with a compiler is not a negotiation: it is *always right* and the code is wrong. All you have to do is see the code from its point of view. – wallyk Jul 17 '13 at 04:28
  • 2
    That's a header file, not a .cpp file. VS outputs a build.log file that shows how the IDE is calling the compiler and linker + any errors the compiler might have given back. Check there. – greatwolf Jul 17 '13 at 04:30
  • @greatwolf well the first error came up with a .h file, not a .cpp file. I looked at the compiler's output and the first error was that one. Saying that Player is undefined (which shouldn't be true as I included Player.h in other classes and they compiled perfectly a couple of days ago. – Pacha Jul 17 '13 at 04:31
  • Please also post `PlayerController.h`. What line of which file is the ` 'Player': undeclared identifier` error occurring on? – Brian Cain Jul 17 '13 at 04:32
  • @Pacha, when you hit the "GO" button on the IDE, the first piece of work that the compiler has is "compile `foo.cpp` into `foo.obj` please". `foo.cpp` includes `Player.h` and that's apparently where we encounter our first issue. So which source file (`foo.cpp`) was the compiler working on when it first complains about `'Player': undeclared identifier`? – Brian Cain Jul 17 '13 at 04:34
  • @BrianCain `Global.h`, I already posted the h file, here is the .cpp one: http://pastebin.com/P0GGizCT – Pacha Jul 17 '13 at 04:43
  • What is the first error? What is the line of code that the compiler complains about? – harper Jul 17 '13 at 04:50

4 Answers4

4

Scroll to the top of your error list, and deal with that one. If you're in Visual Studio, you can compile it and hit Ctrl-Shift-F12.

If you make some error in syntax (my usual one is an unmatched quote or brace), the compiler can lose its context, so everything from that point forward becomes unintelligible to it. The only way you'll get through it is to correct the first error found; and then--if there are still errors--the next one. At some point, you'll find that thing you did, and the rest of the errors will magically disappear.

Curt
  • 5,518
  • 1
  • 21
  • 35
  • the first error is ridicule, it says `'Player': undeclared identifier`, and I am declaring `Player.h` in that file. Also IntelliSense doesn't show any error on that line, just the compiler – Pacha Jul 17 '13 at 04:26
  • Unfortunately, the compiler is the one that matters. Intellisense perhaps doesn't have the entire translation unit. "Ridiculous errors" ‽ IMO the only thing worth ridicule *might* be a compiler bug. But what you are facing is likely not that. – Brian Cain Jul 17 '13 at 04:29
  • @Pacha, are you sure that's the very first error? Sounds like there might be an error in one of the headers that Player.h includes, if not in Player.h itself. – Dominique McDonnell Jul 17 '13 at 04:32
  • @DominicMcDonnell Both of the header Player.h includes are error free as I am sure I never modified them in a really long time (before this mess came up). – Pacha Jul 17 '13 at 04:34
  • @Pacha, Have a look what is included before the Player.h or globals.h in the cpp that is being compiled where the error occurs. A small bug that doesn't cause an error can cause errors in subsequent headers. – Dominique McDonnell Jul 17 '13 at 04:39
  • Since the cascade of errors starts before any real functional code, you can try commenting out blocks of the errant file, to pinpoint the location where the problem starts. It could be as simple--and stupid--as a non-printing character in an unexpected place. – Curt Jul 17 '13 at 04:44
  • Sorry for stupid question, but how do I know the order of compilations of the .cpp files? Google came up with nothing – Pacha Jul 17 '13 at 04:46
  • http://msdn.microsoft.com/en-us/library/ms235639(v=vs.80).aspx http://msdn.microsoft.com/en-us/library/fwkeyyhe(v=vs.71).aspx Try recompiling from the command line, and redirecting the content into a file. That will tell you the compilation order, and give you a *complete* listing of all the errors encountered. – Curt Jul 17 '13 at 04:47
  • @Pacha: "how do I know the order of compilations of the .cpp files?" - compiling them individually by hand would be an easy way to find out. – Crowman Jul 17 '13 at 04:59
2

Welcome to the wonderful world of c++ errors.

When faced with something like this start at the first error reported (Look at the output from the compiler). Then recompile. Repeat until there are no more errors.

There are a lot of different syntax errors that completely muck up the rest of the file. These include bad type in a declaration, missing semi-colon, and missing braces.

I've seen over 200 errors disappear with a one character fix.

Also, if you forget a semi-colon or brace in one header file, it might cause errors in the next included header. I've had really bad errors in windows.h, because I've included my header before it and forgotten something.

Dominique McDonnell
  • 2,510
  • 16
  • 25
1

Solving tricky compiler error problems like the one you describe become much easier when you dump the (annotated) preprocessed output and look at the information that the compiler is getting. cl.exe takes the /E argument in order to dump the preprocessed output to stdout (see also this SO answer). If you use that, and look at the error in that context, it should be clear.

An error like 'Player': undeclared identifier showing up in the file where you think you're defining that very identifier is likely caused by a circular dependency. For example, does PlayerController.h contain references to the Player class without a forward declaration?

Community
  • 1
  • 1
Brian Cain
  • 14,403
  • 3
  • 50
  • 88
0

Source control is key. Based on your comment and extra code, please also post player.h contents.

In general in such a horrible case I do binary search with commenting out large portions of the project.

An error in an h file included in several cpps is usually more likely to crate lots of errors from one little mistake. A cpp parsing issue only affects the cpp. Look for an error in an h file.

Also general word of advice, try to keep all the h file references in the cpp files and limit the references made to h files from h files to an absolute minimum, this will reduce include nightmares. As you can see player.h includes a large amount of h files. Each one of them could be the culprit, I suggest commenting them one by one and wait for an error about an undefined symbol instead of the errors you see now. This will mean that you no longer have a parsing error and now have a missing definition (thus the error is in the file you commented out or in one of the files it includes...).

madnut
  • 124
  • 5
  • All my .hs have `#pragma once` so this is out of the question, I checked them myself – Pacha Jul 17 '13 at 04:22
  • 1
    #pragma once has no effect on errors from compilations the errors will appear for every cpp that includes the h file. – madnut Jul 17 '13 at 04:26