Can anyone help me with this code?

Started by
16 comments, last by rip-off 17 years, 7 months ago
Rather than having people guess at the problem here, why don't you step through your code with the debugger and see exactly whats happening? Set a breakpoint at your allocation for the polygons array, and see what your howmany variable is, and what your array looks like after the allocation.

Your 0xC0000005 error message means you're dereferencing a pointer that is pointing somewhere it shouldn't, and the easiest way to spot that is really with the debugger.
Advertisement
This is the first thing I tried and I found thats something wrong with
the fread function when reading polygons data.It just doesnt read what it should(if I use the pointer, otherwise(with arrays) it works fine)...
The code isn't much complicated but I cant figure out what's wrong.So I asked
for help after a lot of searching
You are reading 2 bytes per unsigned int per polygon. This is a total of 6 bytes. However, sizeof(polygon_class) is 12. You don't see a problem with this?
You have undoubtedly tromped the heap somewhere. The code you posted is insufficient for me to tell where exactly the problem is. Either post a complete minimal example or replace all your raw pointer usage with SC++L constructs and recompile and debug with a checked SC++L implementation.

Σnigma
Stop calling fread.

Replace calls to fread with calls to typed_fread
template<typename T>size_t typed_fread( T* read_data, int count, FILE* file) {  return fread( read_data, sizeof(T), count, file);}


Usage example:
// use the type of numofP to figure out what to read:typed_fread(&numofP, 1, l_file);

or:
// Read into numofP.  If numofP isn't an unsigned short, fail to compile:typed_fread<unsigned short>(&numofP, 1, l_file);


In effect, "typed_fread" simply figures out the type of the variable you are reading for you.

Writing a typed_fwrite via the same syntax gets you the same advantage.

You are probably misaligning the size of the structures you are writing to with the amount of data you are reading.

[Edited by - NotAYakk on September 10, 2006 12:08:48 AM]
Quote:Original post by Lord_Vader
So?
When I replace the pointer in the class:
polygon_class* polygons; with an array:

polygon_class polygons[20000];

The problem may be this: when you do the latter, the mem for polygons-array happens to get allocated from a place which happens to have zeroed the memory (this is not just pointless speculation; If you have a Model object as a global variable, this is certainly the case).

Now when you read only 2 bytes to a 4-byte integer: "fread (&polygons.a, 2, 1, file);" the integer may end up having the data XXXX0000 (hex), assuming the mem was initially zero. But if you do dynamic allocation, the mem isn't zeroed and the variable will be XXXX???? where ???? is some random 16-bit number. Later when you access the indices by doing something like vertex[polygons.a] the index will be a huge number 385496394 instead of 12 like you meant, and cause an access violation.

Solution: Set polygons.a = 0 (for all a,b,c of course) before reading only 2 bytes.
Finally resolved.
Thanks all of you guys and especially:
Deyja
ikslm
NotAYakk
and the
Anonymous Poster

The problem was twofold:
1)It was a matter of size :) as the above said
2)One of the models I was loading had not texture coordinates so the coordinates
were missing from the file and the mapcoord pointer remained NULL(from the constructor) Result:acces violation when I was trying to display the model.

and by the way:

Quote:Original post by Enigma
You have undoubtedly tromped the heap somewhere. The code you posted is insufficient for me to tell where exactly the problem is. Either post a complete minimal example or replace all your raw pointer usage with SC++L constructs and recompile and debug with a checked SC++L implementation.

Σnigma


Can you tell me what is SC++L?
Standard C++ Library.

Like using std::vector to represent dynamic arrays, which would have helped you in your debugging.

This topic is closed to new replies.

Advertisement