Access violation

The 0xbaadf00d address is a signal that you're accessing memory that has been allocated but not initialized. Check to make sure that the pointer you are using for your class is valid. (I.e. the problem is probably in the code allocating or accessing your class, not in the class itself.)

The problem is not the pointer, if i do

static int g_iTimer, g_MyTimer;

It works, but if i move that MyTimer to private and try to access it, it crashes (not that it is a normal int not a pointer), which is weird.

If you make it static, it's no longer a normal member of the class, so of course you're not going to get a problem if the pointer to the class is wrong. As I said, the problem probably isn't in your class code, it's a problem in the code allocating or using the class object. Somehow it looks like the pointer you're using for the class is using uninitialized memory.

SiCrane is correct - it looks like you've got a pointer to an Extras object someplace that you started using without calling new on it, or something like that. Your code using the class should look like one of the following:




Functions in C++ classes are called using a system called __thiscall, which means that all class member functions (except static functions) have a hidden parameter. This hidden parameter is turned into the "this" pointer that you can use inside the functions, and also tells the code how to find the instance of your class that the function should be working with.

If you do something incorrectly, like the following, you can get a bogus "this" pointer passed to your function, which will trip an access violation:

Extras *pBogus;pBogus->IWillProbablyCrash();

Note that you don't have to actually set the pointer to 0xbaadf00d yourself - the compiler, in debug mode, will fill your program's memory with that (and other special values) to help make it obvious when things are going wrong. Most likely this is what is going on in your program.

Static members (both variables and functions) are shared by all instances of your class, so there is no need for them to have a "this" pointer. This is why it's possible to have your program run correctly when certain members are static: if a class member function never accesses anything in the class that isn't static, then it will never need the "this" pointer, so a bogus pointer won't ever be accessed, and there won't be a crash.


Hopefully that should make it a bit more clear as to what's happening in your code.

Thanks both for replies, it seems that I got it to work, I've changed a lot of things, no idea which fixed, but still I continue with those errors, just it doesn't crash the game.

Also I am using that way I have on my constructor

Extras *m_kExtras;

and on my Init I have

m_kExtras = new Extras()m_kExtras->Init( pd3dDevice );

on my render I have

m_kExtras->Draw( AMARELO );

Same with the other functions I am using it all that way and I can't seem to find where that bad pointer or whatever you guys are calling it comes from, is there any way to find out?

I'm guessing you're using Visual Studio, in which case I'd highly recommend that you get familiar with the debugger. If this is correct, just press F5 in your solution and it should automatically enter debug mode. When the program crashes, it should offer you the chance to Break execution at the location of the crash, which will point you directly to the line of code causing the problem.

If that option isn't available, there's a couple of possible approaches, which should be combined for best results. The first is to use debug logging; you can use something simple like std::cout, or create a console window manually with the console API and write to it, or write to a file (usually the most effective option). A good logging system can save an incredible amount of time and effort in debugging, as it will help you locate specific problems and watch the behavior of your code as it runs. If you haven't already done so, I'd advise that you take some time to build a reusable logging system that you can incorporate into all of your projects.

The second technique is a form of divide-and-conquer. It goes by many names, but most commonly by "binary chop." Find a point in your code that is definitely before the crash, and a point that is definitely after it. (If these points aren't easy to find, just use the beginning and end lines of your program.) Now take the point in code roughly in the middle of the two, and disable everything after that point, effectively removing the second half of the code. If you still have a crash, the crashing line is in the first half; otherwise, it's in the second. Repeat this procedure several times until you've narrowed down the exact line of code that is crashing; that should hopefully get you enough information to find out the original cause of the crash. Picking the beginning and end points can be tricky, and disabling the chunks of code can sometimes be a fair bit of work; so look for ways to do it simply and easily (i.e. be lazy) without causing additional problems. Use of a logging system can make it much, much easier to find good splitting points for the test.

Hi Gangster!

Yes, there is a way... Post your code at the location you declare and initialize your Extras-Instance :)
But I think you should again read, what Apoch wrote. I think what he described solves your problem.

bye,

Gamma