On Jul 22, 2008, at 11:52 , Philippe Mougin wrote:
Le 22 juil. 08 à 06:21, Marcel Weiher a écrit :
http://portal.acm.org/citation.cfm?id=1035292.1028982
There are also interesting bits in their conclusion:
"This explains why highly optimized tracing and reference counting
collectors have
Le 22 juil. 08 à 06:21, Marcel Weiher a écrit :
On Jul 21, 2008, at 13:03 , Philippe Mougin wrote:
Le 21 juil. 08 à 20:50, Markus Spoettl a écrit :
I'm wondering if there is a general rule or mechanism that
suggests what to do in such a case. For instance, how are
delegates implemented i
On Jul 21, 2008, at 11:20 PM, Quincey Morris wrote:
Call me a retro coward, but I absolutely dislike the idea of GC. I
just don't see the point of it given the complicated implications
it can have.
But I hope you do see the irony of that last statement, in the
context of this thread.
I
On Jul 21, 2008, at 20:27, Markus Spoettl wrote:
Call me a retro coward, but I absolutely dislike the idea of GC. I
just don't see the point of it given the complicated implications it
can have.
But I hope you do see the irony of that last statement, in the context
of this thread.
FWIW,
On Jul 21, 2008, at 13:03 , Philippe Mougin wrote:
Le 21 juil. 08 à 20:50, Markus Spoettl a écrit :
I'm wondering if there is a general rule or mechanism that suggests
what to do in such a case. For instance, how are delegates
implemented in AppKit, are they retained? If so, when are they
On Jul 21, 2008, at 7:49 PM, Andreas Mayer wrote:
I don't know why you'd think the collection view might own the
item's view. You set the view for the view item, so the hierarchy
seems to be quite clear. (The collection view *might* retain the
view too. That's an implementation detail.)
We
On Mon, Jul 21, 2008 at 11:24 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
> On Jul 21, 2008, at 7:23 PM, Michael Ash wrote:
>>
>> Without investigating things more deeply, just from the basic stuff I
>> know about the classes in question, I'd assume that the
>> NSCollectionView owns the NSCollect
Am 21.07.2008 um 22:02 Uhr schrieb Markus Spoettl:
For example NSCollectionView, NSCollectionViewItem and its view. One
may or may not suspect the NSCollectionViewItem owns the
corresponding view. It may as well not own it and instead the
NSCollectionView owns both.
I don't know why you'
On Jul 21, 2008, at 1:03 PM, Philippe Mougin wrote:
In the general case, there is no rule or mechanism to deal with
retain cycles other than implementing something equivalent to a
garbage collector. In some situations, however, the specific
semantics and life-cycle of the objects you are dea
On Jul 21, 2008, at 7:23 PM, Michael Ash wrote:
Without investigating things more deeply, just from the basic stuff I
know about the classes in question, I'd assume that the
NSCollectionView owns the NSCollectionViewItems and the views, and the
NSCollectionViewItems would also own the views. Wher
On Mon, Jul 21, 2008 at 4:02 PM, Markus Spoettl
<[EMAIL PROTECTED]> wrote:
>>> But there are still cases where it is unknown which of the objects is
>>> going to be released first
>>
>> Care to name one?
>
> For example NSCollectionView, NSCollectionViewItem and its view. One may or
> may not suspe
Le 21 juil. 08 à 20:50, Markus Spoettl a écrit :
[...]
I'm wondering if there is a general rule or mechanism that suggests
what to do in such a case. For instance, how are delegates
implemented in AppKit, are they retained? If so, when are they
released. It can't be in -dealloc, otherwis
On Jul 21, 2008, at 12:28 PM, Ken Thomases wrote:
Actually, it is not against the guidelines, it is in keeping with
them.
See here: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#/
/apple_ref/doc/uid/2043-1000698
That explicitly discus
On Jul 21, 2008, at 12:21 PM, Andreas Mayer wrote:
I'm wondering if there is a general rule or mechanism that suggests
what to do in such a case.
About retain cycles:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html
"The solution to the probl
On Jul 21, 2008, at 1:50 PM, Markus Spoettl wrote:
By changing the reference from B to A to a weak reference which
doesn't retain and release A, the problem goes away. However,
generally speaking this is dangerous road to go (and against
memory management guidelines)
Actually, it is not
Am 21.07.2008 um 20:50 Uhr schrieb Markus Spoettl:
I'm wondering if there is a general rule or mechanism that suggests
what to do in such a case.
About retain cycles:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html
"The solution to the pro
Hi List,
in the course of debugging a -dealloc in a data structure that is
part of an NSDocument app, I've discovered that my document and all
it's data never gets deallocated. After some extensive digging I
nailed the problem down to mutual retain cycles (not sure this is the
right ter
17 matches
Mail list logo
