//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.
Last edited by mv2112 on Fri Apr 16, 2010 8:13 pm, edited 1 time in total.
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.
My love is like a Haddoken, it's downright fierce!
Maevik wrote: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.
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.
qpHalcy0n wrote: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...
qpHalcy0n wrote: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.
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() ?
My love is like a Haddoken, it's downright fierce!
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.
Maevik wrote: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 wrote: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?
My love is like a Haddoken, it's downright fierce!
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.
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 wrote: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.
Falco Girgis wrote:It is imperative that I can broadcast my narcissistic commit strings to the Twitter! Tweet Tweet, bitches!