On Fri, Jun 27, 2008 at 2:31 PM, John Engelhart
[EMAIL PROTECTED] wrote:
Lesson #2: Since there is so little documentation about the GC system, this
involves a lot of speculation, but I think it summarizes what's really going
on. This all started with an effort to keep a __weak reference to a
On Jun 27, 2008, at 12:31 PM, John Engelhart wrote:
-(BOOL)doSomething:(id)obj error:(NSError **)error
{
if(error != NULL) { *error = NULL; } // Make sure we clear the
error object
}
Why are you doing this?
It's sort of ambiguous as to what should be returned by the indirect
error
On Jun 27, 2008, at 12:31 PM, John Engelhart wrote:
Lesson #1: If you have any interest in performance, you must avoid,
at all costs, writing to a __strong pointer.
That's almost like saying:
If you have any interest in performance, you must avoid, at all
costs, using a high level
A few days ago, I decided to give leopards GC system another crack.
The experience was pretty much the same as all my other experiences
have been with Leopards GC system (several days wasted). I learned
two important things that I thought I would share:
Lesson #1: If you have any
On Jun 27, 2008, at 12:31 PM, John Engelhart wrote:
Lesson #1: If you have any interest in performance, you must avoid,
at all costs, writing to a __strong pointer.
If this were the case, all assignments to instance variables would be
exceptionally costly under GC. They are not --
