<SOLVED>Destructors and access voilation reading location

[mv2112]

OK so i have a class called MapController and it has a std::vector of maps. Here is the MapController destructor:

Code: Select all

for(int i=Map.size()-1;i>=0;i--)
	{
		delete Map[i];    //std::vector<map*> Map
                //When i add maps to Map, i do: new map(args)
	}

Here is the destructer for the map object:

Code: Select all

 
//when i comment this destructor out, there is no more errors. Why wouldnt this work?
	if(sprite_sheet)
	{
		destroy_bitmap(sprite_sheet); 
	}
	if(MAP)
	{
		destroy_bitmap(MAP);
	}
	if(buffer)
	{
		destroy_bitmap(buffer);
	}

I cant figure it out.

[Maevik]

The vector class already encapsulates memory management. You're also using delete on a reference instead of a pointer.

Instead of using new and delete with you vector, use push_back() and pop_back(). This will call the map class constructors and deconstructors as it needs to. Keep in mind that it will only allocate and deallocate memory at certain intervals.

[mv2112]

The vector class already encapsulates memory management. You're also using delete on a reference instead of a pointer.

Instead of using new and delete with you vector, use push_back() and pop_back(). This will call the map class constructors and deconstructors as it needs to. Keep in mind that it will only allocate and deallocate memory at certain intervals.

I use this to add map objects:

Code: Select all

Map.push_back(new map(System));

I'll try pop_back.

EDIT:
IT worked!!! Thanks Maevik.

[qpHalcy0n]

Unfortunately in this case pop_back will not suffice.

pop_back will not invoke delete on memory allocated on the heap, which in this case it is.
If it were a case where he were just pushing on copies of whatever it is then this would be fine. In this case you have satisfied the runtime error, but now you have a big fat memory leak.

[mv2112]

Unfortunately in this case pop_back will not suffice.

pop_back will not invoke delete on memory allocated on the heap, which in this case it is.
If it were a case where he were just pushing on copies of whatever it is then this would be fine. In this case you have satisfied the runtime error, but now you have a big fat memory leak.

Yes this is true. Allegro SUCKS! For some reason you cant destroy bitmaps in the destructor. I just had to write a function that would destroy all bitmaps before main was over. I do have to say, you are a C++ guru qpHalcy0n...

[XianForce]

Unfortunately in this case pop_back will not suffice.

pop_back will not invoke delete on memory allocated on the heap, which in this case it is.
If it were a case where he were just pushing on copies of whatever it is then this would be fine. In this case you have satisfied the runtime error, but now you have a big fat memory leak.

Yes this is true. Allegro SUCKS! For some reason you cant destroy bitmaps in the destructor. I just had to write a function that would destroy all bitmaps before main was over. I do have to say, you are a C++ guru qpHalcy0n...

First off, I'd like to agree, that qpHalcy0n is one hella smart guy...

Secondly, I've never personally used Allegro, but I doubt it doesn't allow you to destroy bitmaps in destructors. There's probably something that your doing wrong. But then again, I have never used Allegro, so that is definitely something you may want to ask some people that have used Allegro.

[Maevik]

Will it produce a memory lead if he adds maps with the push_back() function, or just if he is adding instances with new and deleting them with pop_back() ?

[qpHalcy0n]

No, it doesnt matter how you get them in there. The std:: containers only see pointers. The implementation doesn't care beyond that. So it can't presume anything about them other than that they're pointers.....to something. So the clear methods, the pop methods and so forth don't invoke delete/free....which is problematic if you're sticking pointers to heap allocated memory in there.

[XianForce]

Will it produce a memory lead if he adds maps with the push_back() function, or just if he is adding instances with new and deleting them with pop_back() ?

Only if he's dynamically allocating the elements

[Maevik]

No, it doesnt matter how you get them in there. The std:: containers only see pointers. The implementation doesn't care beyond that. So it can't presume anything about them other than that they're pointers.....to something. So the clear methods, the pop methods and so forth don't invoke delete/free....which is problematic if you're sticking pointers to heap allocated memory in there.

So the answer then is to make your own doubly linked list and make sure it is allocating and deallocating?

[qpHalcy0n]

No, absolutely not.

It just means that if you're pushing on pointers to heap allocated memory that you have to MANUALLY go through and explicitly delete the memory because it is not implicitly deleted by std:: containers.

[mv2112]

I think my problem really did have something to do with allegro and destructors because this was my map destructor:

Code: Select all

       if(sprite_sheet)
       {
          destroy_bitmap(sprite_sheet);
       }
       if(MAP)
       {
          destroy_bitmap(MAP);
       }
       if(buffer)
       {
          destroy_bitmap(buffer);
       }

This didnt work. However, I made a function called map::Destroy():

Code: Select all

       if(sprite_sheet)
       {
          destroy_bitmap(sprite_sheet);
       }
       if(MAP)
       {
          destroy_bitmap(MAP);
       }
       if(buffer)
       {
          destroy_bitmap(buffer);
       }

Its exactly the same as the destructor and this works. It also worked when i called the destructor in main. Does the destructor get called at the end of main, or when the program ends?
There is a END_OF_MAIN() function after main in an allegro program.

[dandymcgee]

Were you shutting down Allegro before making those calls?

[mv2112]

Were you shutting down Allegro before making those calls?

If the destructors are called after the END_OF_MAIN(), then yes, thats why i think it worked when i made a destroy() function to destroy the bitmaps.

[dandymcgee]

Were you shutting down Allegro before making those calls?

If the destructors are called after the END_OF_MAIN(), then yes, thats why i think it worked when i made a destroy() function to destroy the bitmaps.

I'm not sure if your MapController object is represented by a pointer or not, so I'll give both examples.

If your MapController IS stored as a pointer you should be deleting it by calling delete myMapController; (or whatever you named the object) explicitly before shutting down Allegro.

If you MapController IS NOT stored as a pointer (ie. just a standard class object), you need to have a separate function (such as your Destroy function) that you call explicitly (NOT from the object's destructor) before shutting down Allegro OR you can leave the code in the destructor and call myMapController's destructor explicitly ( myMapController.~MapController(); ) before shutting down Allegro.

Remember: An object's destructor is not called until the object goes out of scope. In your case this doesn't occur until the program exits and at that point Allegro has already been terminated.