pete added a comment. In D55869#1337723 <https://reviews.llvm.org/D55869#1337723>, @js wrote:
> In D55869#1337711 <https://reviews.llvm.org/D55869#1337711>, @dexonsmith > wrote: > > > In D55869#1337706 <https://reviews.llvm.org/D55869#1337706>, @js wrote: > > > > > The ObjFW runtime itself does not contain anything about release, retain > > > or autorelease - these are all part of ObjFW (as in the framework). As > > > ObjFW also supports the Apple runtime, as well as mixing with Foundation > > > code, it so far only provides objc_retain and objc_release when they are > > > missing, to make ARC work. They just call into the corresponding methods > > > on the object and do nothing else. > > > > > > How will this change work from the Apple runtime? Will > > > objc_retain/objc_release call the retain/release on the object if it > > > implements its own? Should I drop my own retain/release implementation > > > from my root object if I am compiling against the Apple runtime? > > > > > > Yes, the idea is that the specialized runtime functions are fast paths for > > the common case, but they still fall back if the object has overridden them. > > > I am guessing not just overridden, but also a root class providing one? IOW, > the fast path is used when the class does not have the retain or release > method at all? In that case, LGTM as is. The Apple runtime is using a bit on each realized class to track the overriding. The root class defaults to not having a custom RR, ie, it appears that its version of RR is considered equivalent to objc_retain. Presumably that would apply to other root classes too, although i'm not 100% sure. I did see some special handling of NSObject in there too so perhaps only its RR is equivalent to objc_retain/objc_release. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D55869/new/ https://reviews.llvm.org/D55869 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
