Sorry your browser is not supported!

Not sure that any of you can help me, but I've been trying to solve the same bug for more or less the entire day.

The issue is this:

Whenever I compile in Debug, the compiler throws a first-chance "access violation" exception. Compiling in Release works fine.

I've managed to pin-point the code that crashes everything to the dbLoadEffect() command, where I load the Deferred shader that Evolved wrote and Mista Wilson translated to the GDK. In fact, much of the graphical part of the code is taken straight from that sample.

However, does anyone have ANY even remotely connected idea of what might cause the exception? What does dbLoadEffect() do and how can it possibly cause a pointer to a null address, the way it does?

For anyone running into this; read up on pointers, inheritance and the new and delete keywords before you use them extensively.

Essentially, this happens when an uninitiated pointer is referenced, illegally.

Two ways to solve this:

*Use as little dynamic allocation as possible. Use instanced classes rather than pointers. Only use new/delete where you really need to. (Chances are you'll never need this.)

*Keep track of the order of execution. Make sure that nothing is referenced when it shouldn't be. This is actually a bigger pain than it sounds like. Especially if you have many layers of hierarchy between your classes.


Anyway, I've been told by better men than me that non-dynamic memory management is always better, because the compiler and program will know what to expect in terms of memory use and won't have to cope with what you throw at it during runtime.

I.e., do this:



...rather than this:

I agree that dynamic memory allocation should be used only when it's needed, but...



Chances are you'll need it all the time. There are many situations when you just don't know in advance how many objects of a class, or even how much memory for other types of data, your program will need. (The easiest example here is a game level editor, how do you know how many objects the user will create?) Dynamic allocation does have its place in programming and it is not bad in itself, if it is implemented carefully.



Not necessarily. It depends on the task to be solved. Also, static and dynamic allocation use different memory areas of the computer and with lots of data the static area can fill up. See:

http://www.learncpp.com/cpp-tutorial/79-the-stack-and-the-heap/

The examples that you gave are trying to instantiate a class within the class itself. I'd say you should never need to do it like this (in either form), unless you are trying to implement a singleton pattern and that needs a pointer too. The non-pointer version above will not even compile, it will give an error message ("myClass uses myClass which is being defined").

Anyway, we are completely off-topic here because all this discussion about memory allocation will not solve your problem. Since there is a month between your two posts, I suppose you solved the issue in the meantime and it was a bad pointer, or a pointer dereferenced before the object was created?

If the problem still exists, it would be good to post the code, then you have better chance of getting help. I'm sorry that you did not receive assistance the first time you posted but I wouldn't know either what the problem is without doing some serious debugging on the code. Unfortunately access violations are not easy to debug.

No, the problem is solved. But I do realize that my example was extremely bad...

Should really be a ClassA and ClassB, with the latter using an instance of the former.

No matter. What I've been told is to allocate memory beforehand, all the time. So if you want a certain type of object in the editor you mentioned, you'd pre-allocate the maximum number possible.

Might not be the best, but debugging dynamic allocation is a really tedious process. That's the really the biggest thing I learned when I ironed this out.