Strange STL bug

[firedraco]

Apparently I am managing to screw up the STL (lol)

I have this code:

istream& operator >> (istream& file, player& Player) { //this is a friend function
    //...
    Player.eq.reserve(20); //<-- This line errors somehow
    //...
}

Player.eq is an std::vector<object>;.

It gives me a "Memory Access Violation" error...and I have no clue why it's doing that...if you need more info please ask.

Error is: 0xC0000005: Access violation writing location 0x00000064.

[helios]

Typical sign of memory corruption.

[Disch]

check to make sure 'Player' is a valid reference. It's quite possible that &Player is NULL, hinting that you passed a null pointer to this function.

EDIT:

to clarify my rationale:

Access violation writing location 0x00000064.

Whenever there's an access violation reading/writing a location at or very close to zero (as is the case here), 99% of the time it's because you're dereferencing a NULL pointer.

If Player.eq is not a pointer, then the Player reference must be the problem.

[kempofighter]

Can you post an example that can be compiled by others that demonstrates the problem? I'd have to see the calling code and declaration/implementation for the Player class.

[firedraco]

I am calling it like this:

player* temp_player = new player;
temp_player->reset();
file>>(*temp_player);

I also tried:

player temp_player;
temp_player.reset();
file>>temp_player;

and it gave the same result...by the way, I am using the defaultly created constructor, would that change anything?

[Disch]

I don't see a problem there. What does reset() do?

[firedraco]

It simply goes through and clears all the vectors, and initializes the variables to the defaults that I want them to be (Basically the default constructor but I wanted to be able to call it whenever I want).

[Disch]

well I stand by my original diagnosis.

Try logging &Player at the beginning of the function and before the line that crashes to see if it gets corrupted. It's possible you have some stack corruption going on like helios suggested.

I'm reasonably sure that &Player is bad at some point, though. I don't see any other way you'd get this error (unless you're doing something totally nuts like memsetting the vector or something)

[firedraco]

Interesting...I have another vector <object> in my player class called inventory, and loading THAT works fine...I also checked &Player like you said and it seems all perfectly fine...none of the members seem glitchy or anything, and none of them have changed since I was updating them in the function.

[Hammurabi]

I have another vector <object> in my player class called inventory, and loading THAT works fine

Which is more evidence of memory corruption. You need to look carefully through your program to find it, particularly in reset.

Also, do you really want vector<object> or do you want vector<object*>, which you would need if you want polymorphism.

[firedraco]

Yep, it was memory problems, I went out of bounds of an array Oo...ultra fail on my part >.>

And about vector<object> vs vector<object*>, why would I need pointers instead of the objects? (objects/players are in separate inheritance "trees") Or is it for some other reason?

[Hammurabi]

Serves you right for using an array!

If object is a base class for different subtypes that you are storing in the vector, then you want to store object pointers in order to access virtual functions (and in particular, object's destructor should be virtual).

[firedraco]

Object currently does not have an inheritance going on with it, so would I still want/need object* it?

[Hammurabi]

It depends. If the object exists before it's put in the vector, then you may want to store a pointer, otherwise you'll get a copy of it. Of course, you may want a copy.

[jsmith]

Also depends upon whether or not the object is copyable and default constructible.

[firedraco]

Mmm, well the way the item system is going to work, I think I want copies instead of pointers. And yes, object is copyable and default constructable. Anyway, thanks for the help!

[kempofighter]

I thought it was rather odd to be calling vector's reserve function inside the operator>> with a hard coded value. You stated that your reset function clears the vector prior to making the call to operator>>. If the vector was previously filled, clearing it would not deallocate the memory anyway. Clear doesn't do that. It reduces the size to zero, but not the capacity. It is hard to learn anything from your experience without seeing more of the code. Glad you found the problem though.