NSArray of weak references (__unsafe_unretained) to objects under ARC

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.

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

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 vectorstd::vector<__weak Thing*> myThings;// store a weak reference in itThing* 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@endextern 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] Thing2016-09-21 18:11:13.152 foo2[42745:5048189] (null)