Can I use "delete" to do the same job as HeapFree() on a char* object, if I did not allocate it's memory through the use of "new"? I have a feeling the answer is no (the same feeling I have that this is a stupid question), because I also have a feeling that the memory is being allocated on the stack, but I don't know for sure.

Thanks, in advance.

[quote author=Dyndrilliac link=topic=14325.msg146668#msg146668 date=1140539772]
Can I use "delete" to do the same job as HeapFree() on a char* object, if I did not allocate it's memory through the use of "new"? I have a feeling the answer is no (the same feeling I have that this is a stupid question), because I also have a feeling that the memory is being allocated on the stack, but I don't know for sure.

Thanks, in advance.
[/quote]

I think you answered your own question (you shouldn't use HeapFree() on memory allocated on the stack), but if you don't know where it is, just set a breakpoint when you get the memory and compare the value of the pointer to the stack segment register.

Thanks, I didn't know it was that easy to figure it out.

[quote author=Dyndrilliac link=topic=14325.msg146672#msg146672 date=1140541717]
Thanks, I didn't know it was that easy to figure it out.
[/quote]

Note that they're not necessarily identical (it's likely that they're not), but they should be relatively similar.

See MSDN for comprehensive information about Heap functions including HeapFree() and HeapCreate; you will find that new/delete are quite different from HeapCreate/HeapFree functions.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/heapfree.asp

Always match your allocation and de-allocation types.  The standard specifically does not require that an implementation support mixing methods.  Use delete for new, delete [] for new [], free for malloc or realloc, HeapFree for HeapAlloc or HeapReAlloc.  Although I've not seen an implementation which fails when you mismatch types, it's permissible for an implementation to handle such a situation so badly that your program suffers heap corruption or crashes.

The VC CRT will probably fail if you mix Heap* and the CRT memory allocation routines, since the CRT has its own heap metadata built on top of what the Heap* functions return (especially in debug builds).

I ended up using malloc(), realloc(), and free() together, is that ok?

Yes, but unless you actually need realloc, it's be better to use new/delete (imho).

Remember that you will have to manually call object constructors and destructors when using malloc/free with C++ classes.

[quote author=Skywing link=topic=14325.msg146781#msg146781 date=1140620489]
Remember that you will have to manually call object constructors and destructors when using malloc/free with C++ classes.
[/quote]

I learned this the hard way.  :)

Is there an easy way to keep track of all the different objects that I create, and then call their destructors, or automate the calling of the destructors?

Will calling their constructors manually get their destructors to be called?

[quote author=Dyndrilliac link=topic=14325.msg146967#msg146967 date=1140746067]
Is there an easy way to keep track of all the different objects that I create, and then call their destructors, or automate the calling of the destructors?

Will calling their constructors manually get their destructors to be called?
[/quote]

You could use smart pointers, which reference count the contained object and free it when the last reference goes away.  In general, you won't need this for objects contained within other objects, since you can have the destructor of the containing object free the contained object.

Calling constructors manually has no effect on whether the destructor is called.

If I were you, I would exclusively use the new/delete (and new[] / delete []) operators in your code, because you can overload them to use whatever underlying allocation methods you like with ease.

So, if you decide later on that you actually want to use HeapAlloc/HeapFree...then all you have to do is overload those operators and leave the rest of your code unchanged.  This will make your code much more flexible, and probably a lot cleaner too.