Quote:Original post by ToohrVyk

Quote:Original post by Jaapio
Haha, I have a huge vector array where I store every CTextureHolder in.
I loop throught the array, check if the Texture is not NULL and then I call SaveTextureToBitmap.
So dont worry ;)

Famous last words. At least assert it to be true, it won't cost you more than a single line of code. This kind of practice is simple, quick to apply and will save your life countless times. Never trust yourself!

Without seeing more code, it seems to me far more likely that your pointer is NULL and causing undefined behaviour, than your vptr being somehow corrupted.

Assert??? (sounding like a complete idiot)
Sorry I have never heard of that term?

Quote:Original post by iMalc
You haven't got the following line anywhere in your code have you?:

memset(this, 0, sizeof(this));

If so, REMOVE IT!

Also, add the asserts as suggested, and make sure that you never call a virtual function from the constructor of a base class, or from a deleted object.

I am starting to think that the interface is being changed.
I mean now when I add it to the array it is "interfaced" with a texture class but later on for some reason the other program interfaces it with an resource class.

Hm hard to explain what I mean. I think Ill just post some more code torrow.

Quote:Original post by Jaapio
Assert??? (sounding like a complete idiot)
Sorry I have never heard of that term?

http://www.cppreference.com/stdother/assert.html

#include <cassert>assert(ptr != 0);

Quote:Original post by Enigma
I don't think your problem has anything to do with the vtable pointer. You have a default constructor which doesn't initialise any of the member variables. Odds are that you're calling this constructor, thus leaving Texture in an undefined state, and then trying to call SaveTextureToBitmap and dereferencing the invalid pointer. As to exceptions, you're catching all possible C++ exceptions. But the exception you're getting is an OS exception, not a C++ one.

Σnigma

There must be a way to catch those exceptions too.
I mean the watch does not explode when I have it evaluate a something invalid.

Quote:Original post by Lajnold

Quote:Original post by Jaapio
Assert??? (sounding like a complete idiot)
Sorry I have never heard of that term?

http://www.cppreference.com/stdother/assert.html

#include <cassert>assert(ptr != 0);

For as far as I can see now assert is ugly.
If the term evaluates false you get an ugly dialogbox.
No thanks Id rather check with an if statement.

Quote:Original post by Jaapio

Quote:Original post by Lajnold

Quote:Original post by Jaapio
Assert??? (sounding like a complete idiot)
Sorry I have never heard of that term?

http://www.cppreference.com/stdother/assert.html

#include <cassert>assert(ptr != 0);

For as far as I can see now assert is ugly.
If the term evaluates false you get an ugly dialogbox.
No thanks Id rather check with an if statement.

It's a debug tool. You should use it for things that should never cause you to see the dialog box. Consider it's ugliness punishment for screwing up when you do see it. Note that assert(x) also will not evaluate x unless _DEBUG is #defined, which means these checks are typically removed from Release builds.

(Or is that "will not evaluate x if NDEBUG is #define"d? I forget.)

It also has the nice property of stopping your debugger on the appropriate line, in anything half resembling a development environment.

Quote:There must be a way to catch those exceptions too.
I mean the watch does not explode when I have it evaluate a something invalid.

There is, in a manner of speaking. Typically, though, when these errors occur, you've already massively fucked up, and things may not be salvageable. Since your debugger needs to hook into the other applications address space and whatnot to evaluate watches and so forth, the debugger manages to limit such explosions to the program being debugged.

But if you really want to shoot your foot off like that, google "SEH Exceptions". Note that they're compiler extensions, not ISO C++, as the only thing the C++ standard requires is... well, nothing. The standard allows the implementation to launch nuclear missiles at a cow ranch in alaska at this point. If you're programming control software for nuclear silos, I'd even go so far as to say that this is a likely, eventual outcome.

Quote:Original post by Jaapio

Quote:Original post by Lajnold

Quote:Original post by Jaapio
Assert??? (sounding like a complete idiot)
Sorry I have never heard of that term?

http://www.cppreference.com/stdother/assert.html

#include <cassert>assert(ptr != 0);

For as far as I can see now assert is ugly.
If the term evaluates false you get an ugly dialogbox.
No thanks Id rather check with an if statement.

MaulingMonkey is correct, asserts are to catch programmatic errors, not user/input errors (ie, things that should never happen, in which case you would be wasting cycles on the if checks for "impossible" cases in shipped code). They are NOPs in release builds, so you will only see an "ugly dialogbox" if you are debugging, and a dialog box which breaks into the debugger at the correct line sure beats a blind crash.

Meaning assert is quite useless since my application is between 2 other application which sure as hell no debug versions (DirectX and an random chosen app).

So I readlly need to find some way to check if the v-table.

Why don't you just check to make sure the pointer isn't 0, then?? Or at least show us some more code, where you're using these TextureHolder objects.

Also, the code you showed won't compile - your class is named TextureHolder but the constructor and destructor is named CTextureHolder. This makes me wonder what it is you've actually pasted here...

It also looks like your default constructor leaves everything uninitialized; that'll make things harder to track down.

Quote:Original post by Jaapio
Meaning assert is quite useless since my application is between 2 other application which sure as hell no debug versions (DirectX and an random chosen app).

What the hell does "2 other application" have anything to do with the availability of a Debug mode for your project? Nada. Zero. Nothing. Nevermind that DirectX isn't an application.

Don't be so quick to write things off.

Quote:So I readlly need to find some way to check if the v-table.

This is incorrect for 99.999% of projects in your situation. The 0.001% that this would hold for would have programmers that already knew of SEH exceptions and their ilk, and wouldn't be anything that would use DirectX, and would definately use assert on top of SEH exception handlers. You're trying to patch the symptom, not the problem, and it's bound to fail horribly.