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 l
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 poin
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
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 -- appli
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 interes
