> On May 18, 2015, at 1:11 AM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > > On May 17, 2015, at 23:59 , Britt Durbrow > <bdurb...@rattlesnakehillsoftworks.com> wrote: >> >> My understanding of retainCount is that it’s basically considered “taboo” >> because trying to use it without knowing exactly what you are doing tends to >> lead to pitfalls, and most people looking at it tend to think it means >> something that it doesn't. > > You’re right to be cautious, but you’ve come to the wrong conclusion. From OS > X 10.0 to 10.5 (and beyond for numerous apps), memory was managed manually > with ‘retain’ and ‘release’, and that certainly is “using” the retain count.
Yup. I started this whole cocoa-flavored adventure with the Currency Converter tutorial way back on 10.0 running on a G4 with the rounded plastic case. I’ve done it the manual way, taken out the trash (er, run under Garbage Collection), and transitioned my codebase to ARC too… :-) > > What was frowned upon was reckless *reasoning* about retain counts: “If the > retain count is such and such, and I do so and so, then XYZ will happen”. > Those sorts of arguments tended to blow up in peoples’ faces**. > > It is, however, valid to increment the retain count of a valid (that is, > live) object, and to reason that the object will stay alive at least until > you decrement the retain count. This is sufficient for your scenario. > > > ** For example: "If the retain count is 1, and I decrement it, the object > will be deallocated.” This is incorrect reasoning, because any code that > checks and decrements the retain count is subject to side effects that affect > the outcome. > In order to maintain graph coherency the object pool controller must ensure that there is only ever one object in memory with a particular UUID. Consequently, I can’t just have the object pool controller release the objects without assurance that nothing else is going to keep it around (and potentially use it after the object pool controller has replaced it with another object with the same UUID, reloaded from disk). Holding a weak link to the objects as well as a strong link does satisfy that constraint… but it’s a definite "code smell” (somewhat related to “don’t repeat yourself”) and it eats more memory, etc. I’ll do it if I have to, but… Is the reasoning that: 1: Not under ARC; 2: There is one known strong link to an object; 3: retainCount returned 1 Therefore, the only strong link to the object is the known strong link specified in item 2. … is that not valid? If not, why not? Note that I am *not* asserting that it will be deallocated, just that nothing else has a strong link to it that could use it in a detrimental way (most importantly, mutate it). :-) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
