On Oct 26, 2010, at 15:47:09, Greg Parker wrote:
> On Oct 26, 2010, at 2:33 PM, Rick Mann wrote:
>> Sure seems like a conceptual inconsistency, but I guess whoever designed the
>> language thought it was too expensive to return a zeroed struct.
>
> It's an artifact of C compatibility. On each a
On Oct 26, 2010, at 2:33 PM, Rick Mann wrote:
> Sure seems like a conceptual inconsistency, but I guess whoever designed the
> language thought it was too expensive to return a zeroed struct.
It's an artifact of C compatibility. On each architecture, Objective-C messages
follow the same paramete
On Tue, 26 Oct 2010 14:13:23 -0700, Rick Mann said:
>Hi. I've run into a bug, and I'm wondering if I'm expecting the wrong
>behavior. If I do this:
>
>UIWindow* win = nil; // In reality, it's coming from somewhere else,
>but it's nil
>CGRect frame = win.bounds;
>
>Should I expect frame to be al
On Oct 26, 2010, at 14:31:11, Nick Zitzmann wrote:
>
> On Oct 26, 2010, at 3:13 PM, Rick Mann wrote:
>
>> Hi. I've run into a bug, and I'm wondering if I'm expecting the wrong
>> behavior. If I do this:
>>
>> UIWindow* win = nil; // In reality, it's coming from somewhere else, but
>> it's n
On Oct 26, 2010, at 3:13 PM, Rick Mann wrote:
> Hi. I've run into a bug, and I'm wondering if I'm expecting the wrong
> behavior. If I do this:
>
> UIWindow* win = nil; // In reality, it's coming from somewhere else, but
> it's nil
> CGRect frame = win.bounds;
>
> Should I expect frame to b
Hi. I've run into a bug, and I'm wondering if I'm expecting the wrong behavior.
If I do this:
UIWindow* win = nil;// In reality, it's coming from somewhere else, but
it's nil
CGRect frame = win.bounds;
Should I expect frame to be all zero? That's what I thought was the case, but
I'm getti
