On May 12, 2012, at 1:55 PM, Dave Fernandes wrote:
> So when a method is declared __attribute__ ((objc_returns_inner_pointer)),
> then LLVM tracks regular pointers like it would NSObject pointers to see when
> the owning object can be dealloced? Just want to make sure I understand.
In theory, t
On May 12, 2012, at 22:00 , Ken Thomases wrote:
> Well, you're the one who asserted something very concrete about when the
> interior pointer was deallocated. You were claiming that Andreas couldn't
> have seen what he said he saw. My point is that in the absence of a contract
> you can't be
On May 12, 2012, at 2:31 PM, Quincey Morris wrote:
> On May 12, 2012, at 10:17 , Ken Thomases wrote:
>
>> That's not necessarily so. And/or requesting the mutableBytes may do the
>> equivalent of retain+autorelease on the NSMutableData.
>>
>> Consider an inexact analog. The -[NSString UTF8Str
On May 12, 2012, at 13:55 , Dave Fernandes wrote:
> So when a method is declared __attribute__ ((objc_returns_inner_pointer)),
> then LLVM tracks regular pointers like it would NSObject pointers to see when
> the owning object can be dealloced? Just want to make sure I understand.
… to see when
Cool! That would eliminate some of the gymnastics I have been going through to
make sure I reference the NSData object some time after I use the internal
bytes.
On 2012-05-12, at 5:05 PM, Quincey Morris wrote:
> On May 12, 2012, at 13:55 , Dave Fernandes wrote:
>
>> So when a method is declare
On 2012-05-12, at 12:37 PM, Quincey Morris wrote:
> P.S. I think there's also another, better solution, but it involves adding a
> method to NSData/NSMutableData via a category:
>
> - (void*) interiorBytes __attribute__ ((objc_returns_inner_pointer)) {
> return self.bytes;
>
On May 12, 2012, at 12:56 , Jens Alfke wrote:
> No; -[NSString UTF8String] returns a char*, not an object.
I meant "object" in the more general sense of a block of allocated memory whose
lifetime is managed by a memory model. That includes (at least):
1. Obj-C objects.
2. CF…Ref objects.
3. A
On May 12, 2012, at 2:31 PM, Quincey Morris wrote:
> On May 12, 2012, at 10:18 , Charles Srstka wrote:
>
>> Ugh, so you’re saying that ARC isn’t actually as deterministic as we’ve been
>> led to believe?
>
> Indeterminism isn't the problem. Unmarked interior pointers *are*.
But if the behavior
On May 12, 2012, at 12:31 PM, Quincey Morris wrote:
> I think the difference is that for UTF8String, there is an API contract that
> promises the result will be an object (and it has the lifetime behavior of
> any returned object that is returned with +0 retain semantics, as the
> documentatio
On May 12, 2012, at 10:17 , Ken Thomases wrote:
> That's not necessarily so. And/or requesting the mutableBytes may do the
> equivalent of retain+autorelease on the NSMutableData.
>
> Consider an inexact analog. The -[NSString UTF8String] method seems to
> create an autoreleased NSData (or si
On May 12, 2012, at 12:17 PM, Ken Thomases wrote:
> That's not necessarily so. And/or requesting the mutableBytes may do the
> equivalent of retain+autorelease on the NSMutableData.
>
> Consider an inexact analog. The -[NSString UTF8String] method seems to
> create an autoreleased NSData (or
On May 12, 2012, at 11:37 AM, Quincey Morris wrote:
> No, the pointer returned by 'mutableBytes' is an interior pointer. It *isn't*
> an object pointer. (Well, as an implementation detail, it may happen to point
> to an object's memory, but it often doesn't.)
>
> As soon as the NSMutableData's
On May 12, 2012, at 11:37 AM, Quincey Morris wrote:
> No, the pointer returned by 'mutableBytes' is an interior pointer. It *isn't*
> an object pointer. (Well, as an implementation detail, it may happen to point
> to an object's memory, but it often doesn't.)
>
> As soon as the NSMutableData's
On May 12, 2012, at 08:27 , Andreas Grosam wrote:
> It seems, sending mutableBytes creates autoreleased objects (currently,
> tested with ARC only).
> Anybody experienced this, too?
>
> In code as below this may severely impact performance and tie up lots of
> memory, wh
It seems, sending mutableBytes creates autoreleased objects (currently, tested
with ARC only).
Anybody experienced this, too?
In code as below this may severely impact performance and tie up lots of
memory, which are apparently dependent on the size of the mutable data:
for (int i = 0; i
15 matches
Mail list logo
