quote:Original post by PumpkinPieman

Unhandled exception at 0x00427c6b in Twilight.exe: 0xC0000005: Access violation reading location 0xabababab.  

Something to keep in mind: when built in debug mode the compiler fills memory with certain values so you can better see what happens when stepping though. Codes like 0xcccccccc and 0xcdcdcdcd are used by Visual Studio to mark uninitialised memory, deleted memory and such (can''t remember the exact usage, sorry).

I''ve not seen the 0xabababab one before, what compiler is it? Looking though its docs should tell you what this particular code means.

It''s the one that comes standard with Visual Studio .net

Also, I tried making an operator that overloads delete.

	void operator delete(void *pUserData)	{		delete pUserData;		pUserData = NULL;	};

I don''t know, it seems to work though debug, but when it returns the variable that''s passed is unchanged, although it clearly is set to null within the function.

quote:Original post by PumpkinPieman
Also, I tried making an operator that overloads delete.

	void operator delete(void *pUserData)	{		delete pUserData;		pUserData = NULL;	};

I don''t know, it seems to work though debug, but when it returns the variable that''s passed is unchanged, although it clearly is set to null within the function.

It''s because the pUserData variable given to delete() is a copy (passed by value) of the variable passed. You are setting this local copy to NULL, but that local copy merely gets thrown out when it goes out of scope (the delete() function ends); meanwhile, the original is unchanged. Classic case of "pass by value vs. pass by reference confusion".

Trying to overload delete in this fashion is really unnecessary anyway. Just make a habit of setting to NULL every time you delete something; it''s a good habit to get into.

Josh
vertexnormal AT linuxmail DOT org

Check out Golem: Lands of Shadow, an isometrically rendered hack-and-slash inspired equally by Nethack and Diablo.