Enginuity's memory manager
Author
I have an idea how to improve this class but I don''t know if it''s safe. Basically, I''d like to reuse the memory from dead objects pool, even if the new object to be placed in the old slot is smaller than the original. To put it simply, is it safe to do something like this:
void* old = ::operator new(16);
// something is a class that takes up 8 bytes
something* new = new (old) something;
// ...
// clean up
delete old;
Is this gonna work even if class something has has stuff like virtual functions in addition to data members and regular functions? What happens if something constructor throws an exception?
From my understanding the IMMObject approach is flawed because it will ultimately delete items which are static, which != good.
By static I mean they are not located in the heap. I know static means something totally different in C++ code, but well its the opposite of dynamic
[edited by - 31337 on July 26, 2003 9:54:22 PM]
By static I mean they are not located in the heap. I know static means something totally different in C++ code, but well its the opposite of dynamic
[edited by - 31337 on July 26, 2003 9:54:22 PM]
Author
quote:Original post by 31337
From my understanding the IMMObject approach is flawed because it will ultimately delete items which are static, which != good.
By static I mean they are not located in the heap. I know static means something totally different in C++ code, but well its the opposite of dynamic
[edited by - 31337 on July 26, 2003 9:54:22 PM]
I fixed that issue by overloading the new operator.
Perhaps you should look into boost:
ool instead. I havent looked into it yet either but its probably done well comming from boost.
ool instead. I havent looked into it yet either but its probably done well comming from boost.quote:Original post by 31337
From my understanding the IMMObject approach is flawed because it will ultimately delete items which are static, which != good.
By static I mean they are not located in the heap. I know static means something totally different in C++ code, but well its the opposite of dynamic
[edited by - 31337 on July 26, 2003 9:54:22 PM]
You are incorrect.
quote:Original post by 31337
From my understanding the IMMObject approach is flawed because it will ultimately delete items which are static, which != good.
By static I mean they are not located in the heap. I know static means something totally different in C++ code, but well its the opposite of dynamic
[edited by - 31337 on July 26, 2003 9:54:22 PM]
Superpig points that out in his article when he introduces the memory manager. He''s also commented that he''s since gone back and fixed this, I believe by overloading new and delete; the new version will be included in the next article.
As for the original post, I don''t think that''s entirely safe--what if the new object is larger than the old one? Sooner or later, you''ll forget to check, and then you''ve got one object clobbering another. Of course, the dead objects pool is cleared out each frame, so I''m not really sure I see the need for re-using the space before that...?
-Odd the Hermit
Author
quote:Original post by Odd the Hermitquote:Original post by 31337
From my understanding the IMMObject approach is flawed because it will ultimately delete items which are static, which != good.
By static I mean they are not located in the heap. I know static means something totally different in C++ code, but well its the opposite of dynamic
[edited by - 31337 on July 26, 2003 9:54:22 PM]
Superpig points that out in his article when he introduces the memory manager. He''s also commented that he''s since gone back and fixed this, I believe by overloading new and delete; the new version will be included in the next article.
As for the original post, I don''t think that''s entirely safe--what if the new object is larger than the old one? Sooner or later, you''ll forget to check, and then you''ve got one object clobbering another. Of course, the dead objects pool is cleared out each frame, so I''m not really sure I see the need for re-using the space before that...?
-Odd the Hermit
I won''t forget to check because the dead objects list is gonna be a multimap, with the key being the available space in bytes. Then I''ll just look through the map with lower_bound(whatever_size_i_want). The only thing I''m worried about is placing a small object where a big object (buffer, etc) once was. I figure I could somehow subdivide this space, placing the new object in whatever space it needs and passing of the rest as vacant space so next objects can be placed in that.
I would like to point out that no, I am not incorrect. The version shown in the article will *NOT* work correctly. I would also like to point out that overloading the new operator will not fix the problem because the error in the approach occurs during the deletion of the object.
Even if you overloaded the delete operator so that it wouldn''t delete the object if it was not allocated in the heap, I don''t see any magical way for it to tell. And if its not located in the heap, than what is the freakin point of puting it in the objects list anyways?
While I am not the most knolwedgable C++ programmer, I can tell you that the IMMObject approach has flaws.
You said that superpig mentioned this problem in his article. While he does make a disclaimer saying that we don''t need to keep track of all memory, just memory allocated in the heap, his coding does not reflect that.
However, I really like his style and his approaches. I am greatly considering implementing similar memory management strategies for my new engine. I hope this helps.
Even if you overloaded the delete operator so that it wouldn''t delete the object if it was not allocated in the heap, I don''t see any magical way for it to tell. And if its not located in the heap, than what is the freakin point of puting it in the objects list anyways?
While I am not the most knolwedgable C++ programmer, I can tell you that the IMMObject approach has flaws.
You said that superpig mentioned this problem in his article. While he does make a disclaimer saying that we don''t need to keep track of all memory, just memory allocated in the heap, his coding does not reflect that.
However, I really like his style and his approaches. I am greatly considering implementing similar memory management strategies for my new engine. I hope this helps.
Author
quote:Original post by 31337
I would like to point out that no, I am not incorrect. The version shown in the article will *NOT* work correctly. I would also like to point out that overloading the new operator will not fix the problem because the error in the approach occurs during the deletion of the object.
Even if you overloaded the delete operator so that it wouldn't delete the object if it was not allocated in the heap, I don't see any magical way for it to tell. And if its not located in the heap, than what is the freakin point of puting it in the objects list anyways?
While I am not the most knolwedgable C++ programmer, I can tell you that the IMMObject approach has flaws.
You said that superpig mentioned this problem in his article. While he does make a disclaimer saying that we don't need to keep track of all memory, just memory allocated in the heap, his coding does not reflect that.
However, I really like his style and his approaches. I am greatly considering implementing similar memory management strategies for my new engine. I hope this helps.
Listen, you are wrong man. The delete operator will NEVER be called on an IMMObject allocated on the stack because collectgarbage function cycles through the dead objects list deleting only those elements which are on the list. How are objects placed on that list? When you create an MMPointer to an IMMObject, reference count is upped by one and this pointer is put on the live objects list. When reference count drops to 0, this pointer is removed from live objects list and put on dead objects list, where delete will be called on it sometime later. This will never happen for an auto object (correct behavior) because it's this pointer will NEVER be placed on live objects list (this is done in overloaded new), hence can never be placed in dead objects, therefore can never be called delete upon.
I'm tired of your ranting man, either learn C++ or stop criticizing valid code.
[edited by - fallenang3l on July 27, 2003 5:45:12 PM]
31337, before you start sounding like a cretan, I think you should look more into these topics: temporary object, local-stack-frame objects, and the C/C++ keyword auto, which is implicit on the formers. BTW, you sound like you are FOS, because you''re arguing with 25+ year-old gurus in the industry. I''m not one, but at least I know how to thoroughly read/understand the thread attached to the articles meaningfully named "discuss this article." In those debugging discussions, all of this BS was covered by people of various skill levels including myself. Stop trying to take other peoples credit by acting like you know what you''re talking about when you are blatantly just re-inventing the well-documented "wheel." No hard feelings buddy! 
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
