Dealocating memory without calling the objects destructor?

Short answer: no.

Long answer: yes, but nobody is crazy enough to tell you.

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.



But this seems like a really, really bad idea.

Alan

__________________________________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.

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

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));  // allocateObject* 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]

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.