Page 1 of 1
<SOLVED>Destructors and access voilation reading location
Posted: Fri Apr 16, 2010 7:34 pm
by 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.
Re: Destructors and access voilation reading location
Posted: Fri Apr 16, 2010 7:56 pm
by 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.
Re: Destructors and access voilation reading location
Posted: Fri Apr 16, 2010 8:11 pm
by mv2112
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.
I use this to add map objects:
I'll try pop_back.
EDIT:
IT worked!!! Thanks Maevik.
Re: <SOLVED>Destructors and access voilation reading location
Posted: Fri Apr 16, 2010 8:27 pm
by 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.
Re: <SOLVED>Destructors and access voilation reading location
Posted: Fri Apr 16, 2010 8:57 pm
by mv2112
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...
Re: <SOLVED>Destructors and access voilation reading location
Posted: Fri Apr 16, 2010 9:01 pm
by XianForce
mv2112 wrote: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.
Re: <SOLVED>Destructors and access voilation reading location
Posted: Sat Apr 17, 2010 2:01 am
by 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() ?
Re: <SOLVED>Destructors and access voilation reading location
Posted: Sat Apr 17, 2010 9:31 am
by 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.
Re: <SOLVED>Destructors and access voilation reading location
Posted: Sat Apr 17, 2010 9:32 am
by XianForce
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() ?
Only if he's dynamically allocating the elements
Re: <SOLVED>Destructors and access voilation reading location
Posted: Sat Apr 17, 2010 11:31 am
by Maevik
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?
Re: <SOLVED>Destructors and access voilation reading location
Posted: Sat Apr 17, 2010 11:47 am
by 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.
Re: <SOLVED>Destructors and access voilation reading location
Posted: Sat Apr 17, 2010 1:18 pm
by 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.
Re: <SOLVED>Destructors and access voilation reading location
Posted: Sat Apr 17, 2010 6:29 pm
by dandymcgee
Were you shutting down Allegro before making those calls?
Re: <SOLVED>Destructors and access voilation reading location
Posted: Sat Apr 17, 2010 7:21 pm
by mv2112
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.
Re: <SOLVED>Destructors and access voilation reading location
Posted: Sat Apr 17, 2010 7:39 pm
by dandymcgee
mv2112 wrote: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.
