Jump to content
  • Advertisement
Sign in to follow this  
ElChico

Dealocating memory without calling the objects destructor?

This topic is 5039 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I know this may sound insane but I was wondering if there is a way I could de-allocate memory (after a call to new) without ever calling the objects destructor? For instance: (global) ::delete - calls the objects destructor automatically. This does not work... There has to be a way since the global delete performs this task, but I can not seem to find it...

Share this post


Link to post
Share on other sites
Advertisement
Why would you want to? Explain what you are trying to do and maybe we can help.

But generally, no. If you used new to create it you have to use delete to destroy it, and that will call the destructor. The only way around it would be some sort of nasty hack involving malloc and placement new.


char * buf = malloc(sizeof(Object)); // allocate the memory required
Object * obj = new (buf) Object; // set up the object (including call the constructor)

...

free(buf); // release the memory



But this seems like a really, really bad idea.

Alan

Share this post


Link to post
Share on other sites
__________________________________Background__________________________________
Well, I am creating a reference counting memory manager at the moment and it uses a free-list within the dead objects. These dead objects have all had their destructor called already but I save the memory until I run a garbage collection on the memory manager.
So, my memory manager crashes the application if someone has a memory managed object that can only be destructed once.

It has come to my attention that I need a new design, but I seemed so close to having the memory manager fully working so I was willing to go aside from "safe coding" just this once.

Share this post


Link to post
Share on other sites
So when an object is created you first search the dead list. If one is on there you resurect is (recall its constructor?), if not, you new one. When you delete one you call its destructor and add it to the dead list?

You should probably read this page for lots of reasons why you should never call the destructor yourself, although I'm impressed, you seem to have invented a whole new reason :-)

If your intrested, I've heard that this book about memory managment strategies is pretty good.

Alan

Share this post


Link to post
Share on other sites
Quote:
Original post by Alan Kemp
The only way around it would be some sort of nasty hack involving malloc and placement new.

*** Source Snippet Removed ***

But this seems like a really, really bad idea.


First of all its not a bad idea at all, to seperate the concept of allocation/deallocation & construction/destruction is legitimant in certain contexts and it would be "really, really inefficient idea" not to in these contexts, this is what STL allocator types do.

Secondly malloc is not the only way to dynamically allocate uninitialized memory, if you explicitly invoke operator new with just the size of memory you need it will only allocate and not initialize it.

Thirdly your code example is most likely to leak resources why? if you use placement new you must explicitly invoke the destructor for user-defined types before you deallocate the memory otherwise the destructor will never be invoked. So with that in mind your code should look like this:


#include <new>

void* buf = ::operator new(sizeof(Object)); // allocate
Object* obj = new (buf) Object; // construct
...
obj->~Object(); //destroy
::operator delete obj; //de-allocate



Quote:
Original post by Alan Kemp
You should probably read this page for lots of reasons why you should never call the destructor yourself, although I'm impressed, you seem to have invented a whole new reason :-)


No such thing as never but generally yes, some of the exceptions to this rule is writing STL allocators, writing your own memory manager (like what ElChico is doing with freelists).

@ElChico for writing freelists you be insane not to seperate allocation/deallocation construction/destruction of memory, just make sure you know what your doing and provide a safe interface. You should know that the C++ standard library has STL iterators & algorithms specifically to work with uninitialized memory:

raw_storage_iterator,
uninitialized_copy,
uninitialized_copy_n,
uninitialized_fill,
uninitialized_fill_n,
temporary_buffer,
get_temporary_buffer,
return_temporary_buffer

I'd suggest you read about that on chapter 8 on this page, and you may aswell read about the STL allocator concept.

I'll remind you that if you use placement new you must explicitly invoke the destructor for user-defined types it will never be implicitly invoked, just remember the pattern and you'll be fine:

1. allocation
2. construction
3. destruction
4. de-allocation

[Edited by - snk_kid on January 5, 2005 5:25:41 AM]

Share this post


Link to post
Share on other sites
Tanks allot guys; I got it working with a mixture of Alan's advice and some examples from the references that where posted.
I really appreciate your time and concern. You guys are the #1 source of information for me and you don’t understand how much GameDev and devoted individuals that contribute to this site help me out!

snk_kid awesome STL reference page, that really helped (and will continue to) me out man!

After tacking a look at some of the examples from the references posted I got some incite on a better design for my memory manager (which enables it to be allot more efficient), but I think I will leave that for another project.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!