How to Determine If a C++ Object Has Been Deallocated

Testing if an object has been deallocated

It's not possible to "test" for this-- once an object is deallocated, it's gone, and the pointer to it is effectively garbage. Doing anything with it is liable to crash.

Sorry to be the bearer of bad news, but the only way to get this to work right is to make sure the memory management around (in this case) offers is correct at all uses-- retain and release correctly at all the points where that instance variable is manipulated, and it will never be non-nil garbage.

You should try running the static analyzer (Build->Build and Analyze) to start with-- this tool can help flag memory management pattern issues without a lot of extra digging on your part.

How can I check if an object is released?

You probably mean deallocated (destroyed), not released. Being released does not mean being deallocated, that's the point of reference counted memory management. Being released is not a state, you can't check for it; being destroyed is.

If you mean deallocated, then no, there is none. It is called weak reference, and Objective-C does not have them for reference counting. When an object is deallocated, nothing is automatically done to pointers to it; they become dangling pointers.

One technique is to have the object send a notification during deallocation, so that everything that holds a pointer can reset it to nil.

Generally, you must design your program in a way that no object pointer is used again after you called release on it. In the sample code you've given, you must not use BuildView again for anything else except assigning a new value.

Unit Test to verify object getting deallocated

Use _GTMDevLog :

See the Advanced Stuff | Unit Test Logging on this page.

More info on DevLogNAssert.

How to check if a pointer is freed already in C?

You can't. The way to track this would be to assign the pointer to 0 or NULL after freeing it. However as Fred Larson mentioned, this does nothing to other pointers pointing to the same location.

int* ptr = (int*)malloc(sizeof(int));
free(ptr);
ptr = NULL;

What happens when an NSArray element gets deallocated?

You should not release myCrib if you are not the owner. To do so is a violation of the memory management guidelines and will make your code extremely difficult to maintain. I cannot stress enough that you absolutely should never do this under any sort of circumstance. You're asking for crashes; the array has declared ownership of the object, and you must not subvert that ownership in any way.

So the answer here is: your code is absolutely wrong and you should fix it. If you can't fix it, you should trash it and start over and keep rewriting it until you've come up with another way to achieve the same effect without subverting object ownership. I guarantee that it's possible.

---

If what you want is a weak-referencing array, then there are a couple ways you can do this (this was just asked a couple of days ago):

1. NSPointerArray - weakly references its pointers. When you use garbage collection, they're autozeroing (ie, the pointers get removed when the object is deallocated). Unfortunately, this is not available on iOS.
2. CFMutableArrayRef - you can specify a custom retain and release callback, or just not specify one at all. If you leave them out, the array will simply not retain the objects it contains. However, this does not automatically remove the pointer when the object is deallocated.
3. DDAutozeroingArray - an NSMutableArray subclass I wrote the other day to provide a weakly-referencing and auto-zeroing array that works on both Mac OS and iOS. However, I strongly encourage you to use this only as a last resort; There are probably much better ways of doing what you're looking for. https://github.com/davedelong/Demos

c# memory allocation and deallocation patterns

In theory, if you have properly defined componentry, it should never be required to call Dispose() on your objects, as the finalizer should eventually take care of it.

That being said, any time you're using an object that implements IDisposable, it's a good practice to call Dispose() on the object as soon as you are through working with it.

For some of your specific points:

1) If you know you're "done" with the Form, you can call Dispose() on it. This will force a cleanup at that point in time of the unmanaged resources associated with the form.

2) In this case: if your object is just used in that method, use "using" instead:

using (MyObject myObject = new MyObject())
{
   // use your object
} // It'll be disposed of here for you

3) There are rare reasons to do this, but in general, no.

4) Events are a delegate - the memory associated with the delegate will be collected after the delegate itself becomes unrooted, which typically happens when the objects in question are unrooted.

Memory allocation/deallocation when working with C# and C++ unmanaged

It's really simple!

1. Depends
2. Depends

Eh, Sorry about that.

1. Under typical conditions, C# will keep track of the memory and get rid of it any time after it's no longer used on the C# side. It has no way of tracking references on the C++ side, so one common mistake in interop is that the memory is deallocated before the unmanaged side is done with it (resulting in loads of FUN). This only applies for cases where the memory is directly referenced, not when its copied (the typical case being a byte[] that's pinned for the duration of the unmanaged call). Don't use automatic marshalling when the life-time of the object/pointer being passed to unmanaged code is supposed to be longer than the run of the invoked method.
2. Under typical conditions, C# has no way of tracking memory allocations in the C++ code, so you can't rely on automatic memory management. There are exceptions (e.g. some COM scenarios), but you'll almost always need to manage the memory manually. This usually means sending the pointer back to the C++ code to do the deallocation, unless it used a global allocator of some kind (e.g. CoMemoryInitialize). Remember that in the unmanaged world, there is no one memory manager that you can safely invoke to dispose of memory; you don't really have the necessary information anyway.

This only applies to pointers, of course. Passing integers is perfectly fine, and using automatic marshalling usually means the marshaller takes care of most of the subtleties (though still only in the simplest case, so be careful). Unmanaged code is unmanaged - you need to understand perfectly how the memory is allocated, and how, when and who is responsible for cleaning up the memory.

---

Related Topics