> On 29 Aug 2016, at 03:26, Andy Lee wrote:
>
> On Aug 24, 2016, at 4:25 PM, Jens Alfke wrote:
>>
>>> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn
>>> wrote:
>>>
>>> Now, will "setFormatter" call retain on "formatter&quo
On Aug 24, 2016, at 4:25 PM, Jens Alfke wrote:
>
>> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn
>> wrote:
>>
>> Now, will "setFormatter" call retain on "formatter" or not? Looking
>> at "retainCount" seems to suggest so, altho
> On 25 Aug 2016, at 6:24 AM, Andreas Falkenhahn wrote:
>
> If it retains, I could just do the following:
>
>[textField setFormatter:formatter];
>[formatter release];
>
> And I wouldn't have to worry about "formatter" any longer. If it doesn&
per.apple.com/library/ios/releasenotes/ObjectiveC/ObjCAvailabilityIndex/
>
>
>> On Aug 24, 2016, at 1:41 PM, Wim Lewis wrote:
>>
>>
>> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn
>> wrote:
>>> I have read Apple's memory management guide on
he weak attribute semantics in your own code, then you
should be able to use ARC.
https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ObjCAvailabilityIndex/
> On Aug 24, 2016, at 1:41 PM, Wim Lewis wrote:
>
>
> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn
>
On Aug 24, 2016, at 13:37 , Andreas Falkenhahn wrote:
>
> Thanks, this would make "setFormatter" a case of strong reference because
> it isn't documented otherwise...
To expand on what Jens said, slightly…
You’d need to check the docs for the version of the SDK you’re using. In a few
cases, th
On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn wrote:
> I have read Apple's memory management guide on retain/release and
> I think I've basically got it, but there's just one thing that
> I'm not confident about and that is "setXXX" methods which accept a
> On 24 Aug 2016, at 1:24 pm, Andreas Falkenhahn wrote:
>
> If it retains, I could just do the following:
>
>[textField setFormatter:formatter];
>[formatter release];
>
> And I wouldn't have to worry about "formatter" any longer. If it doesn&
On 24.08.2016 at 22:25 Jens Alfke wrote:
> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn
> wrote:
> Now, will "setFormatter" call retain on "formatter" or not? Looking
> at "retainCount" seems to suggest so, although I know that this
>
> On Aug 24, 2016, at 1:04 PM, Andreas Falkenhahn
> wrote:
>
> Now, will "setFormatter" call retain on "formatter" or not? Looking
> at "retainCount" seems to suggest so, although I know that this
> isn't reliable and shouldn't be d
On 24.08.2016 at 22:14 Ben Kennedy wrote:
>> On 24 Aug 2016, at 1:04 pm, Andreas Falkenhahn
>> wrote:
>> I have read Apple's memory management guide on retain/release and
>> I think I've basically got it, but there's just one thing that
>> I'
> On 24 Aug 2016, at 1:04 pm, Andreas Falkenhahn wrote:
>
> I have read Apple's memory management guide on retain/release and
> I think I've basically got it, but there's just one thing that
> I'm not confident about and that is "setXXX" methods whi
I have read Apple's memory management guide on retain/release and
I think I've basically got it, but there's just one thing that
I'm not confident about and that is "setXXX" methods which accept an
NSObject parameter and I don't know how I can know whether the
&q
On Fri, 31 Jul 2015 12:15:10 +0200, Jean-Daniel Dupas said:
>
>> Le 30 juil. 2015 à 18:26, Fritz Anderson a écrit :
>>
>> On 30 Jul 2015, at 11:03 AM, Trygve Inda wrote:
>>
>>> It seems Apple is using retain rather than copy for NSString propertie
> Le 30 juil. 2015 à 18:26, Fritz Anderson a écrit :
>
> On 30 Jul 2015, at 11:03 AM, Trygve Inda wrote:
>
>> It seems Apple is using retain rather than copy for NSString properties in
>> an NSManagedObject subclass.
>>
>> I was always under the imp
> On Jul 30, 2015, at 9:03 AM, Trygve Inda wrote:
>
> It seems Apple is using retain rather than copy for NSString properties in
> an NSManagedObject subclass.
So, you’re saying that if you store an NSMutableString into a dynamic
NSManagedObject property, and then mutate the ori
On 30 Jul 2015, at 11:03 AM, Trygve Inda wrote:
> It seems Apple is using retain rather than copy for NSString properties in
> an NSManagedObject subclass.
>
> I was always under the impression that copy should be used for NSString, so
> why the retain??
For an immutable s
It seems Apple is using retain rather than copy for NSString properties in
an NSManagedObject subclass.
I was always under the impression that copy should be used for NSString, so
why the retain??
Trygve
___
Cocoa-dev mailing list (Cocoa-dev
On 19 May 2015, at 17:52, Britt Durbrow
wrote:
> Yes, I am a bit concerned that it could become deprecated. I suppose that I
> could just override retain and release in that case; and track the retain
> count myself; although I seriously doubt that that functionality will be
>
On May 20, 2015, at 17:38 , Britt Durbrow
wrote:
>
> We are, in fact, on the same page at this point!
Yes, I think so too. But you’ve thereby done yourself out of the kittens.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not p
> On 21 May 2015, at 10:38 am, Britt Durbrow
> wrote:
>
> Also, generally speaking, I don’t want to have to go back to a manual
> retain/release model for the whole app (which is basically what using
> NSDiscardableContent entails; even though it isn’t literal -retain and
housekeeping. If you’re selectively releasing things from the cache, you
> might need to keep track of what you did, so that you re-retain the correct
> subset of OPC references later. If you don’t need to be selective, it’s
> easier because you just release everything in OPC at the
track of what you did, so that you re-retain the correct subset of OPC
references later. If you don’t need to be selective, it’s easier because you
just release everything in OPC at the start of the memory event, and re-retain
everything in OPC [that still has a non-
ference to an object as well, hence the temptation
>> to peek at the retain count. In other words it must be the “last owner”, for
>> some reason.
>
> Yes, exactly: the reason being that of maintaining graph coherency.
>
> Suppose we have these objects in play:
>
> The
hat you need to
know which objects are still ‘in use’. You can’t remove everything from the
dictionary, you can only remove things which are not currently referenced by
clients. Hence all the talk of inspecting retain counts to figure out if the
only thing referencing an object is the diction
* myItemID;
myItemID = @“ID-001”;
myPayloadItem = [[LTWPayloadItem alloc] initWithSomeParameters:xx];
[self.pPayloadDictionary setObject: myPayloadItem forKey: myItemID];
[myPayloadItem release];
// At this point, myPayloadItem has a retain count of 1
In no particular order:
> On May 19, 2015, at 8:37 PM, Graham Cox wrote:
>
> I think what the OP says he wants is that the cache can only release when it
> knows nobody else has a reference to an object as well, hence the temptation
> to peek at the retain count. In other w
> On 20 May 2015, at 2:17 pm, Quincey Morris
> wrote:
>
> My answer on this to Britt is that this is unknowable in general. *That* (or
> so I claim) is why it’s not safe to reason about retain counts. If Britt
> could be said to be wrong about anything, I’d say it’s t
> On May 19, 2015, at 8:04 PM, Quincey Morris
> wrote:
>
> Solution B: We retain each object as it enters the cache. That allows us to
> selectively mark objects purgeable by releasing them again. Drawbacks: None.
You still have to be really careful about threading here. How
not safe to reason about retain counts. If Britt could be
said to be wrong about anything, I’d say it’s this, the idea that “nobody else
has a reference” is a meaningful concept. For all practical purposes it isn’t**.
— It’s unknowable in general. Various parts of the system frameworks may hav
ferences.
> Drawback: We’re wasting memory for storing the additional strong references.
>
> Solution B: We retain each object as it enters the cache. That allows us to
> selectively mark objects purgeable by releasing them again. Drawbacks: None.
>
> The end.
>
I t
storing the additional strong references.
Solution B: We retain each object as it enters the cache. That allows us to
selectively mark objects purgeable by releasing them again. Drawbacks: None.
The end.
Note that there’s no objection (in either solution) on the basis of shaky
reasoning about r
t is able to do, though the method names it
uses are not ‘retain’, ‘release’ and 'retainCount'. As it’s a protocol, not an
object, you can implement it however you like.
I disagree (with Quincey) that you may as well use retain/release/retainCount
because the point is that those things ar
the
>> option to vaporize your toes; later you may not have access to a ray gun if
>> Apple decides that it's in the best interests of all concerned that they
>> retain their toes, not their objects.
>
> Restating a previous concern of mine:
>
>> However, it
to a ray gun if
> Apple decides that it's in the best interests of all concerned that they
> retain their toes, not their objects.
>
Restating a previous concern of mine:
> However, it’s not actually something that’s likely to get deprecated; and by
> paying very careful attenti
that they retain
their toes, not their objects.
I don't know what your app architecture looks like, but was wondering if you
could build in a supportable method of managing what's in the cache without
having to do other than a few localized changes.
One thought I had was to base all
inter collection;
that will only happen when the system no longer holds those strong links (FWIW,
this is one of the reasons why I am not drawing a distinction between
Referenced and Inaccessible).
> So, I’ve been trying to sell the idea that you only need one pointer — the
> weak one — an
re” strong reference is the cache’s
owning reference. Britt originally wanted to believe that this meant that the
cache contained the only strong reference, period, but I called this out as
invalid reasoning about retain counts, because there’s actually a 3rd case …
— “Inaccessible". There is
n be only one object per UUID; but if something points to an object that
>> the cache is trying to evict, that object won’t get deallocated from RAM
>> (because it’s retain count isn’t zero post eviction) but the object pool
>> controller won’t know about it still being in RAM (as
RAM, there
> can be only one object per UUID; but if something points to an object that
> the cache is trying to evict, that object won’t get deallocated from RAM
> (because it’s retain count isn’t zero post eviction) but the object pool
> controller won’t know about it still being
I don’t wish to butt in, since you seem to be doing fine and I probably don’t
have too much to contribute, but just pointing you at NSDiscardableContent for
a second, that has a “pseudo-retain count” type of mechanism that is
independent of the actual retain count.
I wonder if that couldn’t
orelease pool is drained in the
> main event loop.
But here we go, reasoning about retain counts — incorrectly. (Your first
sentence is just false, BTW, not incorrectly reasoned. An object can be in an
autorelease pool with no other strong link anywhere.) And you’ve got me doing
it too. W
ing: time and threads. Furthermore, the assumption that your
> peek at the object state will reliably (or ever) return a retain count of 1
> as opposed to (say) 2 is flawed. For example, if the object is in the
> autorelease pool, you’ll see a count of at least 2, but you won’t be able to
item 2.
>
> … is that not valid? If not, why not?
No, I think not. There are at least 2 dimensions of variability that can break
this reasoning: time and threads. Furthermore, the assumption that your peek at
the object state will reliably (or ever) return a retain count of 1 as opposed
On May 18, 2015, at 12:52 PM, Britt Durbrow
wrote:
> 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 as
ing 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 man
> 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.
What was frowned upon was
the
cache is trying to evict, that object won’t get deallocated from RAM (because
it’s retain count isn’t zero post eviction) but the object pool controller
won’t know about it still being in RAM (as it’s no longer in the cache), and
when the controller attempts to reload it from disk; there
Haha. Awesome! I didn’t even know this existed… thanks for the tip :-)
> On May 17, 2015, at 6:30 PM, Graham Cox wrote:
>
>
>> On 18 May 2015, at 11:14 am, Jonathan Hull wrote:
>>
>> Instead of having a central object pool, have the objects adhere to a
>> protocol which takes a method to b
> On 18 May 2015, at 11:14 am, Jonathan Hull wrote:
>
> Instead of having a central object pool, have the objects adhere to a
> protocol which takes a method to be called in low-memory situations
Yep. You could call it ‘NSDiscardableContent’ ;)
—Graham
I would avoid messing with the retainCount.
Have you looked at using NSCache to retain the objects in your pool?
Other approaches that you could try:
1) Your central object pool has an array which holds a strong reference to the
objects, and has a method (that can be called in a low-memory
On May 17, 2015, at 18:10 , Quincey Morris
wrote:
>
> I think you are on the right track with this, but instead of partitioning the
> objects into two containers, put all the objects in one container.
Er, I meant “put all the objects in both containers”.
ally increment the retain
count (once) of each object referred to. Under ARC, this has to be done by code
in a separate file that isn’t compiled under ARC, or you can get the same
effect by bridging to Core Foundation and using CFRetain/CFRelease. In this
scenario, you’d simply decrement all your ma
pool de-construct and release any graph segments that are not currently being
used outside of the object pool. However, this needs to happen only during a
memory pressure event, and not otherwise.
The only thing I’ve been able to come up with so far is somehow tracking the
retain count state of
2014, at 23:21, Howard Moon wrote:
> Oh, ok, thanks! Yes, that works, simply removing the (assign) or (retain)
> (leaving it as the default, strong).
>
> It's hard to follow examples I find on the internet since so many are out of
> date or don't use ARC, and there&#x
Oh, ok, thanks! Yes, that works, simply removing the (assign) or (retain)
(leaving it as the default, strong).
It's hard to follow examples I find on the internet since so many are out of
date or don't use ARC, and there's no easy way to tell them apart.
Thanks!
-Ho
> On Oct 15, 2014, at 1:58 PM, Howard Moon wrote:
>
> I think I resolved it… my data object's members were all declared using
> @property(assign). I changed those all to @property(retain), and it works
> now.
Don't use assign or retain in ARC, use weak and strong. (
You mit want to check out singleton creation if you want to access at data
object from multiple objects.
Just google for Matt Galloway singleton and the first link should show you what
you need.
This is geared for iOS but I suspect it should work fine if you are targeting
the Mac as well.
C
I think I resolved it… my data object's members were all declared using
@property(assign). I changed those all to @property(retain), and it works now.
Thanks,
Howard
On Oct 15, 2014, at 1:42 PM, Howard Moon wrote:
> Hi,
>
> I'm working on my first ARC-
Hi,
I'm working on my first ARC-enabled app, but am having a problem with
how to keep my delegate's member data alive.
At startup (in the delegate's applicationDidFinishLaunching: function),
my delegate initializes a data object (a member of the delegate) containing
some NSStri
On Thu, 17 Jul 2014 20:01:09 -0700, Jens Alfke said:
>Every once in a while I run into a bug in my code that’s triggered by
>self getting dealloced in the middle of a method. It’s usually something like
> - (void) someMethod {
> doSomeStuff;
> [self.delegate objec
more expensive as a method
>> call is involved.
>>
>> Gerd
>>
>>>> On Jul 17, 2014, at 11:23 PM, Andy Lee wrote:
>>>>
>>>> On Jul 17, 2014, at 11:01 PM, Jens Alfke wrote:
>>>> Once I’ve identified such a bug, the fix i
2014, at 11:23 PM, Andy Lee wrote:
>>
>>> On Jul 17, 2014, at 11:01 PM, Jens Alfke wrote:
>>> Once I’ve identified such a bug, the fix is easy: put a [[self retain]
>>> autorelease] at the top of the method. Except now I’m using ARC, and I
>>> can’t fin
rote:
>> Once I’ve identified such a bug, the fix is easy: put a [[self retain]
>> autorelease] at the top of the method. Except now I’m using ARC, and I can’t
>> find a simple way of doing it. I tried adding
>> __unused id retainedSelf = self;
>> but the optimi
doSomeMoreStuff to crash.
>
> Once I’ve identified such a bug, the fix is easy: put a [[self retain]
> autorelease] at the top of the method. Except now I’m using ARC, and I
> can’t find a simple way of doing it. I tried adding
> __unused id retainedSelf = self;
> but the optim
On Jul 17, 2014, at 11:01 PM, Jens Alfke wrote:
> Once I’ve identified such a bug, the fix is easy: put a [[self retain]
> autorelease] at the top of the method. Except now I’m using ARC, and I can’t
> find a simple way of doing it. I tried adding
> __unused id retainedSelf =
Stuff to crash.
>
> Once I’ve identified such a bug, the fix is easy: put a [[self retain]
> autorelease] at the top of the method. Except now I’m using ARC, and I can’t
> find a simple way of doing it. I tried adding
> __unused id retainedSelf = self;
[Conjecture] I haven’t
On Jul 17, 2014, at 8:40 PM, Roland King wrote:
> Using the objc_precise_lifetime attribute ensures the object stays alice to
> the end of the block.
>
> I think that's a bit better than abusing retain release.
I'm not sure if that is reliable. It's possible that t
Using the objc_precise_lifetime attribute ensures the object stays alice to the
end of the block.
I think that's a bit better than abusing retain release.
> On 18 Jul, 2014, at 11:23, Quincey Morris
> wrote:
>
>> On Jul 17, 2014, at 20:01 , Jens Alfke wrote:
>&g
On Jul 17, 2014, at 20:01 , Jens Alfke wrote:
> The only thing I’ve found that works is
> CFRetain((__bridge CFTypeRef)self);
> at the top of the method, and a corresponding CFRelease at the end, but this
> is pretty ugly
This seems to be the right way to do it. A CFBridgingRetain/CFBridg
];
doSomeMoreStuff;
}
where it turns out that the delegate method clears its reference to me, and
that was the last reference, causing self to get dealloced during the delegate
call, causing doSomeMoreStuff to crash.
Once I’ve identified such a bug, the fix is easy: put a [[self retain]
autorelease
On 27 Apr 2014, at 23:01, Glenn L. Austin wrote:
>
> On Apr 26, 2014, at 10:32 AM, Dave wrote:
>
>>> Autorelease isn't causing your problem, it's that you're misunderstanding
>>> what autorelease pools are and do. What Dave wrote is correct: it was
>>> your loop that was causing the memor
On 26 Apr 2014, at 9:29 pm, Dave wrote:
> needed 10 MB!
> 150MB!
> pools!
> undo it!
> no drains!
>
> bad news!
>
> that’s dogma!
> 110 MB difference! Amazing!
> it’s naff
>
> Cheers
> Dave
I think there's some merit in discussing the design decisions in Cocoa that we
have to live w
reat - you
>>> can’t avoid it BUT you can undo it!
>>
>>
>> I don’t really understand what you mean by “undo it”, but I the thing to
>> remember is that autorelease pools are not like garbage collection, you have
>> to be responsible for them in your own c
On Apr 26, 2014, at 10:57 AM, Jens Alfke wrote:
>
> Yes, there are mainstream garbage-collected platforms now like Android and
> .NET. Guess what, in those you also have to spend time baby-sitting memory
> management, when you diagnose why your app’s heap size explodes during some
> operation
I think (from my experience of some junior developers in my realm) some of
these expectations comes from the progression of how autocomplete writes
your code for you in Xcode, so if it leaves something off, it’s Xcode’s
fault.
I personally don’t agree, and I delay the timing for autocomplete. Xco
At least for me, I do think in terms of how autorelease works. Its second
nature. The moment I see a loop of any kind, I think about a temporary pool of
objects and if I should do something about it. I just simply have no issues
with autorelease and think of it as a great feature that I use with
On 4/26/2014, 10:48 AM, "Jens Alfke" wrote:
Autorelease is a great example of There Ain't No Such Thing As A Free
Lunch. (TANSTAAFL)
I can see a new T-shirt with the saying (unless someone else already
thought of it like the Exercise becomes Eggs Are Sides for Bacon):
[T]here [A]in't [N]o [S]u
build a ref-counted
object model from scratch that doesn’t use something like autorelease. (It’s
not hard, really, in fact it should take you an hour or less. All you need is a
base class with a retainCount ivar, a retain method that increments it, a
release method that decrements it and calls d
On Apr 26, 2014, at 10:32 AM, Dave wrote:
> Really, what OS other, makes you clean up after it?
Um.
You were making a joke, right? Or do you honestly think that Win32 or GTK or
POSIX or whatever don't require some attention to memory management?
Have you ever heard of malloc() and free()? Add
On 26 Apr 2014, at 15:40, Glenn L. Austin wrote:
> On Apr 26, 2014, at 4:29 AM, Dave wrote:
>
>>
>> On 26 Apr 2014, at 08:27, Jim McGowan wrote:
>>
>>>
>>> On 25 April, 2014 5:45:24 pm HKT, Dave wrote:
>>>
It’s not dogma! autorealease meant my App peaked at 150MB, whereas it
don’t really understand what you mean by “undo it”, but I the thing to
> remember is that autorelease pools are not like garbage collection, you have
> to be responsible for them in your own code in the same way that you are
> responsible for balancing new/init/copy/retain with release.
in the same way that you are
responsible for balancing new/init/copy/retain with release.
Jim
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderator
On 25 Apr 2014, at 04:45, Graham Cox wrote:
>
> On 25 Apr 2014, at 11:24 am, Dave wrote:
>
>> I always knew autorelease was bad news!
>
>
> No it isn't, at least not inherently.
Inheriently it leads to data dependant methods/code and that is definitely bad
news.
> But if you don't proper
On 25 Apr 2014, at 11:24 am, Dave wrote:
> I always knew autorelease was bad news!
No it isn't, at least not inherently. But if you don't properly understand it
then it can bite you. You've trodden this path before, and I don't want to
rehash all that, but you were wrong then as well. If you
];
}
];
Returns autoreleased theResponseData and/or theURLResponse and/or theErrorInfo.
These values are copied into properties with +1 retain count and passed up the
chain. This was all working fine and those copies were getting released, it was
the 3 autorelease objects from passed back in dataTaskWithURL
Sorry - got out of bed the wrong side this morning. I'm happy the bug report
was of some use. Leaks is a great tool, especially the graph, would be a shame
if what seem like relatively small bugs lead to the impression that "it just
doesn't work right". Perhaps few people are as KVO junkie as me
Thanks for the bug report. If you could see rdar://10109782, you'd see that
your report prompted a new discussion about the priority and schedule for this
bug.
On Apr 24, 2014, at 4:09 PM, Roland King wrote:
> "Engineering has determined that your bug report (16683382) is a duplicate of
> an
"Engineering has determined that your bug report (16683382) is a duplicate of
another issue (10109782) and will be closed."
.. that wasn't very worthwhile was it.
On 22 Apr, 2014, at 12:49 pm, Roland King wrote:
> There you go. 16683382
>
> On 22 Apr, 2014, at 2:55 am, Greg Parker wrote:
>
There you go. 16683382
On 22 Apr, 2014, at 2:55 am, Greg Parker wrote:
> On Apr 20, 2014, at 3:40 PM, Roland King wrote:
>> If however one of A or B happens to be KVO'ing the other, which happens a
>> lot in my code, I use KVO everywhere, Leaks doesn't find the cycle. That's
>> wrong, KVO doe
On 22 Apr, 2014, at 3:34 am, Dave wrote:
> Confusing results.
>
> I changed the property in question:
>
> @property (nonatomic,assign) id payloadObject;
>
Start with this - what do you want that property to be?
Strong/weak/unsafe_unretained?
Second - allocati
On Apr 21, 2014, at 5:18 PM, Kevin Meaney wrote:
> On 21 Apr 2014, at 21:09, Andy Lee wrote:
>>
>> The solution is to use a weak reference for one of the properties in the
>> cycle. In general, if one object conceptually "owns" the other, then the
>> "owning" object uses a weak reference an
se examples should be familiar from manual memory management. When
> implementing the delegate pattern under retain/release, the recommended
> practice is to have objects not retain their delegate, for the same reason of
> avoiding retain cycles.
___
On Apr 21, 2014, at 10:53 AM, Alex Zavatone wrote:
>
> On Apr 21, 2014, at 10:34 AM, Andy Lee wrote:
>
>> On Apr 21, 2014, at 8:27 AM, Dave wrote:
>>> Also, when I did this, I left the property attributes as “retain” and
>>> “assign”, I’m wondering if it
Confusing results.
I changed the property in question:
@property (nonatomic,assign)id payloadObject;
Ran leaks again and it reported another cycle - same thing, so I fixed that one
too and ran leaks again, which now shows no cycles/leaks.
Before when the test f
On Apr 20, 2014, at 3:40 PM, Roland King wrote:
> If however one of A or B happens to be KVO'ing the other, which happens a lot
> in my code, I use KVO everywhere, Leaks doesn't find the cycle. That's wrong,
> KVO doesn't make a strong reference, as you can tell from the 'freed when KVO
> was s
On 21 Apr 2014, at 15:53, Keary Suska wrote:
> On Apr 21, 2014, at 8:12 AM, Dave wrote:
>
>> @property (nonatomic,retain) id payloadObject;
>>
>> This is after I ARCed it, before that it didn’t specify it, e.g. it was
>> (nonatomi
On Apr 21, 2014, at 10:34 AM, Andy Lee wrote:
> On Apr 21, 2014, at 8:27 AM, Dave wrote:
>> Also, when I did this, I left the property attributes as “retain” and
>> “assign”, I’m wondering if it would be better to change them to “strong” and
>> “weak” ? Although, AFAIK
On Apr 21, 2014, at 8:12 AM, Dave wrote:
> @property (nonatomic,retain) id payloadObject;
>
> This is after I ARCed it, before that it didn’t specify it, e.g. it was
> (nonatomic). I must have made it retain when I was going through the
> propertie
On Apr 21, 2014, at 8:27 AM, Dave wrote:
> Also, when I did this, I left the property attributes as “retain” and
> “assign”, I’m wondering if it would be better to change them to “strong” and
> “weak” ? Although, AFAIK this shouldn’t make a difference?
For object properties, &quo
1 - 100 of 582 matches
Mail list logo
