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

Short answer: no.

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

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

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.