NSArray of weak references (__unsafe_unretained) to objects under ARC

Objective CIos5Ios4Automatic Ref-Counting

Objective C Problem Overview


I need to store weak references to objects in an NSArray, in order to prevent retain cycles. I'm not sure of the proper syntax to use. Is this the correct way?

Foo* foo1 = [[Foo alloc] init];
Foo* foo2 = [[Foo alloc] init];

__unsafe_unretained Foo* weakFoo1 = foo1;
__unsafe_unretained Foo* weakFoo2 = foo2;

NSArray* someArray = [NSArray arrayWithObjects:weakFoo1, weakFoo2, nil];

Note that I need to support iOS 4.x, thus the __unsafe_unretained instead of __weak.


EDIT (2015-02-18):

For those wanting to use true __weak pointers (not __unsafe_unretained), please check out this question instead: Collections of zeroing weak references under ARC

Objective C Solutions


Solution 1 - Objective C

As Jason said, you can't make NSArray store weak references. The easiest way to implement Emile's suggestion of wrapping an object inside another object that stores a weak reference to it is the following:

NSValue *value = [NSValue valueWithNonretainedObject:myObj];
[array addObject:value];

Another option: a category that makes NSMutableArray optionally store weak references.

Note that these are "unsafe unretained" references, not self-zeroing weak references. If the array is still around after the objects are deallocated, you'll have a bunch of junk pointers.

Solution 2 - Objective C

The solutions to use a NSValue helper or to create a collection (array, set, dict) object and disable its Retain/Release callbacks are both not 100% failsafe solutions with regard to using ARC.

As various comments to these suggestions point out, such object references will not work like true weak refs:

A "proper" weak property, as supported by ARC, has two behaviors:

  1. Doesn't hold a strong ref to the target object. That means that if the object has no strong references pointing to it, the object will be deallocated.
  2. If the ref'd object is deallocated, the weak reference will become nil.

Now, while the above solutions will comply with behavior #1, they do not exhibit #2.

To get behavior #2 as well, you have to declare your own helper class. It has just one weak property for holding your reference. You then add this helper object to the collection.

Oh, and one more thing: iOS6 and OSX 10.8 supposedly offer a better solution:

[NSHashTable weakObjectsHashTable]
[NSPointerArray weakObjectsPointerArray]
[NSPointerArray pointerArrayWithOptions:]

These should give you containers that hold weak references (but note matt's comments below).

An example (updated 2 Feb 2022)

#import <Foundation/Foundation.h>

static BOOL didDealloc = NO;

@interface TestClass : NSObject
@end

@implementation TestClass
-(void)dealloc {
	didDealloc = YES;
}
@end

int main(int argc, const char * argv[]) {
	NSPointerArray *pa = [NSPointerArray weakObjectsPointerArray];
	@autoreleasepool {
		TestClass *obj = TestClass.new;
		[pa addPointer:(__bridge void * _Nullable)(obj)]; // stores obj as a weak ref
		assert([pa pointerAtIndex:0] != nil);
		assert(!didDealloc);
	} // at this point the TestClass obj will be deallocated
	assert(didDealloc);
	assert([pa pointerAtIndex:0] == nil); // verify that the weak ref is null now
	return 0;
}

If you run this you'll find that after adding the TestClass object to the pointer array pa, then releasing that object again, the pointer (which is internally a weak object ref) is now set to null as desired.

However, note that calling [pa compact] at the end will not remove the nil pointer as I'd have expected.

Solution 3 - Objective C

I am new to objective-C, after 20 years of writing c++.

In my view, objective-C is excellent at loosely-coupled messaging, but horrible for data management.

Imagine how happy I was to discover that xcode 4.3 supports objective-c++!

So now I rename all my .m files to .mm (compiles as objective-c++) and use c++ standard containers for data management.

Thus the "array of weak pointers" problem becomes a std::vector of __weak object pointers:

#include <vector>

@interface Thing : NSObject
@end

// declare my vector
std::vector<__weak Thing*> myThings;

// store a weak reference in it
Thing* t = [Thing new];
myThings.push_back(t);

// ... some time later ...

for(auto weak : myThings) {
  Thing* strong = weak; // safely lock the weak pointer
  if (strong) {
    // use the locked pointer
  }
}

Which is equivalent to the c++ idiom:

std::vector< std::weak_ptr<CppThing> > myCppThings;
std::shared_ptr<CppThing> p = std::make_shared<CppThing>();
myCppThings.push_back(p);

// ... some time later ...

for(auto weak : myCppThings) {
  auto strong = weak.lock(); // safety is enforced in c++, you can't dereference a weak_ptr
  if (strong) {
    // use the locked pointer
  }
}

Proof of concept (in the light of Tommy's concerns about vector reallocation):

main.mm:

#include <vector>
#import <Foundation/Foundation.h>

@interface Thing : NSObject
@end

@implementation Thing


@end

extern void foo(Thing*);

int main()
{
    // declare my vector
    std::vector<__weak Thing*> myThings;
    
    // store a weak reference in it while causing reallocations
    Thing* t = [[Thing alloc]init];
    for (int i = 0 ; i < 100000 ; ++i) {
        myThings.push_back(t);
    }
    // ... some time later ...
    
    foo(myThings[5000]);

    t = nullptr;

    foo(myThings[5000]);
}

void foo(Thing*p)
{
    NSLog(@"%@", [p className]);
}

example log output:

2016-09-21 18:11:13.150 foo2[42745:5048189] Thing
2016-09-21 18:11:13.152 foo2[42745:5048189] (null)

Solution 4 - Objective C

If you do not require a specific order you could use NSMapTable with special key/value options

> NSPointerFunctionsWeakMemory > > Uses weak read and write barriers appropriate for ARC or GC. Using NSPointerFunctionsWeakMemory object references will turn to NULL on last release.

Solution 5 - Objective C

I believe the best solution for this is to use NSHashTable or NSMapTable. the Key or/and the Value can be weak. You can read more about it here: http://nshipster.com/nshashtable-and-nsmaptable/

Solution 6 - Objective C

The simplest solution:

NSMutableArray *array = (__bridge_transfer NSMutableArray *)CFArrayCreateMutable(nil, 0, nil);
NSMutableDictionary *dictionary = (__bridge_transfer NSMutableDictionary *)CFDictionaryCreateMutable(nil, 0, nil, nil);
NSMutableSet *set = (__bridge_transfer NSMutableSet *)CFSetCreateMutable(nil, 0, nil);

Note: And this works on iOS 4.x too.

Solution 7 - Objective C

To add weak self reference to NSMutableArray, create a custom class with a weak property as given below.

NSMutableArray *array = [NSMutableArray new];

Step 1: create a custom class 

@interface DelegateRef : NSObject

@property(nonatomic, weak)id delegateWeakReference;

@end

Step 2: create a method to add self as weak reference to NSMutableArray. But here we add the DelegateRef object

-(void)addWeakRef:(id)ref
{

  DelegateRef *delRef = [DelegateRef new];

  [delRef setDelegateWeakReference:ref] 

  [array addObject:delRef];

}

Step 3: later on, if the property delegateWeakReference == nil, the object can be removed from the array

The property will be nil, and the references will be deallocated at proper time independent of this array references

Solution 8 - Objective C

No, that's not correct. Those aren't actually weak references. You can't really store weak references in an array right now. You need to have a mutable array and remove the references when you're done with them or remove the whole array when you're done with it, or roll your own data structure that supports it.

Hopefully this is something that they'll address in the near future (a weak version of NSArray).

Solution 9 - Objective C

I've just faced with same problem and found that my before-ARC solution works after converting with ARC as designed.

// function allocates mutable set which doesn't retain references.
NSMutableSet* AllocNotRetainedMutableSet() {
    CFMutableSetRef setRef = NULL;
    CFSetCallBacks notRetainedCallbacks = kCFTypeSetCallBacks;
    notRetainedCallbacks.retain = NULL;
    notRetainedCallbacks.release = NULL;
    setRef = CFSetCreateMutable(kCFAllocatorDefault,
    0,
    &notRetainedCallbacks);
    return (__bridge NSMutableSet *)setRef;
}
    
// test object for debug deallocation
@interface TestObj : NSObject
@end
@implementation TestObj
- (id)init {
   self = [super init];
   NSLog(@"%@ constructed", self);
   return self;
}
- (void)dealloc {
   NSLog(@"%@ deallocated", self);
}
@end


@interface MainViewController () {
   NSMutableSet *weakedSet;
   NSMutableSet *usualSet;
}
@end

@implementation MainViewController

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil {
    self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
    if (self) {
        // Custom initialization
      weakedSet = AllocNotRetainedMutableSet();
      usualSet = [NSMutableSet new];
   }
    return self;
}

- (IBAction)addObject:(id)sender {
   TestObj *obj = [TestObj new];
   [weakedSet addObject:obj]; // store unsafe unretained ref
   [usualSet addObject:obj]; // store strong ref
   NSLog(@"%@ addet to set", obj);
   obj = nil;
   if ([usualSet count] == 3) {
      [usualSet removeAllObjects];  // deallocate all objects and get old fashioned crash, as it was required.
      [weakedSet enumerateObjectsUsingBlock:^(TestObj *invalidObj, BOOL *stop) {
         NSLog(@"%@ must crash here", invalidObj);
      }];
   }
}
@end

Output:

> 2013-06-30 00:59:10.266 not_retained_collection_test[28997:907] > constructed 2013-06-30 00:59:10.267 > not_retained_collection_test[28997:907] addet to > set 2013-06-30 00:59:10.581 not_retained_collection_test[28997:907] > constructed 2013-06-30 00:59:10.582 > not_retained_collection_test[28997:907] addet to > set 2013-06-30 00:59:10.881 not_retained_collection_test[28997:907] > constructed 2013-06-30 00:59:10.882 > not_retained_collection_test[28997:907] addet to > set 2013-06-30 00:59:10.883 not_retained_collection_test[28997:907] > deallocated 2013-06-30 00:59:10.883 > not_retained_collection_test[28997:907] > deallocated 2013-06-30 00:59:10.884 > not_retained_collection_test[28997:907] > deallocated 2013-06-30 00:59:10.885 > not_retained_collection_test[28997:907] *** -[TestObj > respondsToSelector:]: message sent to deallocated instance 0x1f03c8c0

Checked with iOS versions 4.3, 5.1, 6.2. Hope it will be useful to somebody.

Solution 10 - Objective C

If you need zeroing weak references, see this answer for code you can use for a wrapper class.

Other answers to that question suggest a block-based wrapper, and ways to automatically remove zeroed elements from the collection.

Solution 11 - Objective C

If you use a lot this comportment it's indicated to your own NSMutableArray class (subclass of NSMutableArray) which doesn't increase the retain count.

You should have something like this:

-(void)addObject:(NSObject *)object {
    [self.collection addObject:[NSValue valueWithNonretainedObject:object]];
}

-(NSObject*) getObject:(NSUInteger)index {

    NSValue *value = [self.collection objectAtIndex:index];
    if (value.nonretainedObjectValue != nil) {
        return value.nonretainedObjectValue;
    }

    //it's nice to clean the array if the referenced object was deallocated
    [self.collection removeObjectAtIndex:index];

    return nil;
}

Solution 12 - Objective C

I think an elegant solution is what Mr. Erik Ralston propose on his Github repository

https://gist.github.com/eralston/8010285

this are the essential steps:

create a category for NSArray and NSMutableArray

in the implementation create a convenience class with a weak property. Your category will assign the objects to this weak property.

.h

 #import <Foundation/Foundation.h>
    
@interface NSArray(WeakArray)

- (__weak id)weakObjectForIndex:(NSUInteger)index;
-(id<NSFastEnumeration>)weakObjectsEnumerator;

@end

@interface NSMutableArray (FRSWeakArray)

-(void)addWeakObject:(id)object;
-(void)removeWeakObject:(id)object;

-(void)cleanWeakObjects;

@end

.m

#import "NSArray+WeakArray.h"

@interface WAArrayWeakPointer : NSObject
@property (nonatomic, weak) NSObject *object;
@end

@implementation WAArrayWeakPointer
@end

@implementation NSArray (WeakArray)


-(__weak id)weakObjectForIndex:(NSUInteger)index
{
    WAArrayWeakPointer *ptr = [self objectAtIndex:index];
    return ptr.object;
}

-(WAArrayWeakPointer *)weakPointerForObject:(id)object
{
    for (WAArrayWeakPointer *ptr in self) {
        if(ptr) {
            if(ptr.object == object) {
                return ptr;
            }
        }
    }
    
    return nil;
}

-(id<NSFastEnumeration>)weakObjectsEnumerator
{
    NSMutableArray *enumerator = [[NSMutableArray alloc] init];
    for (WAArrayWeakPointer *ptr in self) {
        if(ptr && ptr.object) {
            [enumerator addObject:ptr.object];
        }
    }
    return enumerator;
}

@end

@implementation NSMutableArray (FRSWeakArray)

-(void)addWeakObject:(id)object
{
    if(!object)
        return;
    
    WAArrayWeakPointer *ptr = [[WAArrayWeakPointer alloc] init];
    ptr.object = object;
    [self addObject:ptr];
    
    [self cleanWeakObjects];
}

-(void)removeWeakObject:(id)object
{
    if(!object)
        return;

    WAArrayWeakPointer *ptr = [self weakPointerForObject:object];
    
    if(ptr) {
        
        [self removeObject:ptr];

        [self cleanWeakObjects];
    }
}

-(void)cleanWeakObjects
{

    NSMutableArray *toBeRemoved = [[NSMutableArray alloc] init];
    for (WAArrayWeakPointer *ptr in self) {
        if(ptr && !ptr.object) {
            [toBeRemoved addObject:ptr];
        }
    }

    for(WAArrayWeakPointer *ptr in toBeRemoved) {
        [self removeObject:ptr];
    }
}

@end

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionEmile CormierView Question on Stackoverflow
Solution 1 - Objective CyujiView Answer on Stackoverflow
Solution 2 - Objective CThomas TempelmannView Answer on Stackoverflow
Solution 3 - Objective CRichard HodgesView Answer on Stackoverflow
Solution 4 - Objective CEraView Answer on Stackoverflow
Solution 5 - Objective CYaniv De RidderView Answer on Stackoverflow
Solution 6 - Objective CArtFeelView Answer on Stackoverflow
Solution 7 - Objective CHarish Kumar KailasView Answer on Stackoverflow
Solution 8 - Objective CJason CocoView Answer on Stackoverflow
Solution 9 - Objective CeugView Answer on Stackoverflow
Solution 10 - Objective CpaulmelnikowView Answer on Stackoverflow
Solution 11 - Objective CCiprian CView Answer on Stackoverflow
Solution 12 - Objective CEnrico CupelliniView Answer on Stackoverflow