ould become into an iphone app, could I use the garbage
> collector or is better don't use it?
>
> Regards,
> Takeichi
> ___
>
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>
> Please do not post admin requests
Hi all, I'm beginning with an application for Mac OS X that in a
future could become into an iphone app, could I use the garbage
collector or is better don't use it?
Regards,
Takeichi
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
How do I use cocoas garbage collector in c++? It seems to be implemented in c++
with libauto:
http://www.opensource.apple.com/source/libauto/libauto-77.1/README.html?f=text
But I cant seem to find that much documentation on it.
Thanks,
Paul
Le 6 févr. 2010 à 17:55, Michael Ash a écrit :
> 2010/2/6 Frédéric Testuz :
>> Hi all,
>>
>> I'm beginning a new application targeting Snow Leopard only. So I want to
>> use the new tools (blocks) and garbage collection (GC). It will be my first
>> application using GC.
>>
>> I read some sites
2010/2/6 Frédéric Testuz :
> Hi all,
>
> I'm beginning a new application targeting Snow Leopard only. So I want to use
> the new tools (blocks) and garbage collection (GC). It will be my first
> application using GC.
>
> I read some sites on GC and blocks. In the blog of Mike Ash I found some ver
Hi all,
I'm beginning a new application targeting Snow Leopard only. So I want to use
the new tools (blocks) and garbage collection (GC). It will be my first
application using GC.
I read some sites on GC and blocks. In the blog of Mike Ash I found some very
interesting propositions. My questio
On Oct 10, 2009, at 1:14 AM, Gabriel Zachmann wrote:
So, is 20% CPU time for the GC thread normal?
That's a lot more than I'd expect based on what you're doing. Either
you've got code you haven't shown us that's allocating a ton of
objects during the animation, or some system framework (C
Thanks for the response.
So, is 20% CPU time for the GC thread normal?
Yup, that shows about 20% (of a core) being spent in GC.
Best regards,
Gabriel.
smime.p7s
Description: S/MIME cryptographic signature
___
Cocoa-dev mailing list (Cocoa-dev@
On Oct 9, 2009, at 7:23 AM, Gabriel Zachmann wrote:
http://zach.in.tu-clausthal.de/tmp/malloc1.png
http://zach.in.tu-clausthal.de/tmp/malloc2.png
http://zach.in.tu-clausthal.de/tmp/malloc3.png
Those are showing all malloc operations. Most of those are not garbage-
collected, so they don't af
It seems that about 20% of the time is spent in the Garbage
Collector thread!
Which is a bit surprising to me, since I don't allocate a large
number of objects (I think) -- just a small number of large objects
(the images).
The collector only chews CPU when there are lots of alloc
for some animations on the images.
>
> I've just profiled the screensaver under 10.6 using Shark on a dual-core
> MacBookPro.
>
> It seems that about 20% of the time is spent in the Garbage Collector
> thread!
Are you sure you aren't just seeing the GC thread sitting
On Oct 8, 2009, at 7:29 AM, Gabriel Zachmann wrote:
It seems that about 20% of the time is spent in the Garbage
Collector thread!
Which is a bit surprising to me, since I don't allocate a large
number of objects (I think) -- just a small number of large objects
(the images).
10.6 using Shark on a dual-
core MacBookPro.
It seems that about 20% of the time is spent in the Garbage Collector
thread!
Which is a bit surprising to me, since I don't allocate a large number
of objects (I think) -- just a small number of large objects (the
images).
Is there anyth
On May 10, 2009, at 7:22 PM, Chris Idou wrote:
Err, why isn't that a workaround? If retaining it but not freeing it
is a workaround, why wouldn't retaining it and freeing it after I am
done with it work?
Because the cache will end up with with a dangling pointer that you
can't do anything
2009 11:59:11 AM
Subject: Re: Garbage collector related crash
On May 10, 2009, at 6:35 PM, Chris Idou wrote:
Is it fixed in a later version of Leopard, or in Snow Leopard?
Snow Leopard.
And it is a workaround to release it in the finalizer of the object that
retains it and uses it?
On May 10, 2009, at 6:35 PM, Chris Idou wrote:
Is it fixed in a later version of Leopard, or in Snow Leopard?
Snow Leopard.
And it is a workaround to release it in the finalizer of the object
that retains it and uses it?
No.
b.bum
___
Cocoa-de
:47:43 AM
Subject: Re: Garbage collector related crash
On May 10, 2009, at 3:47 AM, Chris Idou wrote:
When you are saying "it is broken" on Leopard, what exactly do you say you know
is broken? GC in general, or the __strong thing, or ?
There is a bug internal the MD* API that c
On May 10, 2009, at 3:47 AM, Chris Idou wrote:
When you are saying "it is broken" on Leopard, what exactly do you
say you know is broken? GC in general, or the __strong thing, or ?
There is a bug internal the MD* API that causes this particular crash
because it creates dangling weak refe
ubject: Re: Garbage collector related crash
On May 8, 2009, at 12:47 AM, Chris Idou wrote:
> I've got an object that holds onto a CF ref:
>
> mdref= MDItemCreate(nil, (CFStringRef)path);
> [NSMakeCollectable(mdref) autorelease];
>
> I think I'm doing th
On May 8, 2009, at 12:47 AM, Chris Idou wrote:
I've got an object that holds onto a CF ref:
mdref= MDItemCreate(nil, (CFStringRef)path);
[NSMakeCollectable(mdref) autorelease];
I think I'm doing the right thing in the class declaration:
@interface MetadataItem : NSObject {
__strongMDItemRefmd
I've got an object that holds onto a CF ref:
mdref= MDItemCreate(nil, (CFStringRef)path);
[NSMakeCollectable(mdref) autorelease];
I think I'm doing the right thing in the class declaration:
@interface MetadataItem : NSObject {
__strongMDItemRefmdref;
@end
But every now and then:
CFTypeRefre
Hi Jeffrey,
I have a multithreaded application with several NSOperationQueues
and it appears as if under heavy load conditions I'm overwhelming
the garbage collector so-to-speak.
From what you describe, it looks like your analysis is spot on.
I essentially have three queues which c
I have a multithreaded application with several NSOperationQueues and
it appears as if under heavy load conditions I'm overwhelming the
garbage collector so-to-speak.
I essentially have three queues which can be processing different
types of operations simultaneously.
- If I load up
Folks, this is getting nowhere.
Chris Hanson (an apple engineer BTW) and Clark (and many others) have
stated the correct answer (simply summarized below)
time to put this one to rest. there is nothing to argue about here.
scott
On Jun 11, 2008, at 8:45 AM, Clark Cox wrote:
If you're goi
On Jun 11, 2008, at 12:29 AM, Jim Puls wrote:
For that matter, it may be worth pointing out John's confusion
between "sloppy" and "incorrect". He makes a decent point that
returning a mutable object when the method definition specifies an
immutable one is sloppy and, indeed, fraught with p
On Wed, Jun 11, 2008 at 12:01 AM, John Engelhart
<[EMAIL PROTECTED]> wrote:
>
> On Jun 10, 2008, at 11:28 AM, Charles Srstka wrote:
>>
>> I think the problem is that if NSArray has +[NSArray array] returning an
>> NSArray, then NSMutableArray has to return an NSArray also, since it can't
>> have a
On Jun 11, 2008, at 2:01 AM, John Engelhart wrote:
If you declare a method prototype as '-(NSArray *)resultsArray',
then you have explicitly communicated that a NSArray is going to be
returned. Not a NSMutableArray. Not 'Jimmies groovy array with red
pin stripes'. A NSArray. Period. A NS
On Jun 11, 2008, at 3:01 AM, John Engelhart wrote:
-(MyObject *)copyAndCombineWith:(MyObject *)object
{
MyObject *copy = malloc(sizeof(MyObject));
memcpy(copy, object, sizeof(MyObject));
copy->answer += answer;
copy->integerRING += integerRing;
return(copy);
}
Do not use malloc() to instan
On Wed, Jun 11, 2008 at 8:01 AM, John Engelhart
<[EMAIL PROTECTED]> wrote:
> A return type of NSArray * means something very explicit. "But all you can
> expect is an object that behaves like a NSArray, so returning a subclass of
> NSArray, like NSMutableArray, is perfectly legal!" You're exactl
Le 11 juin 08 à 09:01, John Engelhart a écrit :
On Jun 10, 2008, at 11:28 AM, Charles Srstka wrote:
I think the problem is that if NSArray has +[NSArray array]
returning an NSArray, then NSMutableArray has to return an NSArray
also, since it can't have a different method signature for th
On 11 Jun 2008, at 5:01 pm, John Engelhart wrote:
If you declare a method prototype as '-(NSArray *)resultsArray',
then you have explicitly communicated that a NSArray is going to be
returned. Not a NSMutableArray. Not 'Jimmies groovy array with red
pin stripes'. A NSArray. Period. A NS
On Jun 11, 2008, at 12:15 AM, Chris Hanson wrote:
This whole business about '(NSArray *) means NSArray AND any of
it's subclasses' is the result of sloppy thinking and confusing
'able to' with 'as per spec'.
No, you are wrong. It really is "per spec." That is an intentional
capability i
On Jun 11, 2008, at 12:01 AM, John Engelhart wrote:
This whole business about '(NSArray *) means NSArray AND any of it's
subclasses' is the result of sloppy thinking and confusing 'able to'
with 'as per spec'.
No, you are wrong. It really is "per spec." That is an intentional
capability
On Jun 10, 2008, at 11:28 AM, Charles Srstka wrote:
I think the problem is that if NSArray has +[NSArray array]
returning an NSArray, then NSMutableArray has to return an NSArray
also, since it can't have a different method signature for the same
method. As a result, if you called +[NSMut
On Tue, Jun 10, 2008 at 4:28 PM, Charles Srstka
<[EMAIL PROTECTED]> wrote:
> I think the problem is that if NSArray has +[NSArray array] returning an
> NSArray, then NSMutableArray has to return an NSArray also, since it can't
> have a different method signature for the same method. As a result, i
On Tuesday, June 10, 2008, at 08:29AM, "Charles Srstka" <[EMAIL PROTECTED]>
wrote:
>On Jun 9, 2008, at 5:55 PM, Hamish Allan wrote:
>
>> Sure. But it gives you *more* information than if it just returns
>> "id". I agree with you in all other respects of your post, but I don't
>> agree that +[NSA
On Jun 9, 2008, at 5:55 PM, Hamish Allan wrote:
Sure. But it gives you *more* information than if it just returns
"id". I agree with you in all other respects of your post, but I don't
agree that +[NSArray array] returns "id" because if it returned
"NSArray *" you'd have to have a separate decla
On Jun 9, 2008, at 1:39 PM, Chris Hanson wrote:
It is perfectly legal to return an NSMutableArray from a
hypothetical +(NSArray *)array method.
However, all the sender of that +(NSArray *)array message can know
is that the result can be treated as an NSArray. It can't know
whether an NSA
On Mon, Jun 9, 2008 at 7:39 PM, Chris Hanson <[EMAIL PROTECTED]> wrote:
> It is perfectly legal to return an NSMutableArray from a hypothetical
> +(NSArray *)array method.
>
> However, all the sender of that +(NSArray *)array message can know is that
> the result can be treated as an NSArray. It
On Jun 9, 2008, at 11:17 AM, Hamish Allan wrote:
On Mon, Jun 9, 2008 at 7:02 PM, Chris Hanson <[EMAIL PROTECTED]> wrote:
The reason these kinds of methods have a return type of (id) is
that there
is no way to say "returns an object of the receiver's class." For
example,
+[NSArray array] re
On Mon, Jun 9, 2008 at 7:02 PM, Chris Hanson <[EMAIL PROTECTED]> wrote:
> The reason these kinds of methods have a return type of (id) is that there
> is no way to say "returns an object of the receiver's class." For example,
> +[NSArray array] returns (id) rather than (NSArray *) because otherwi
On Jun 9, 2008, at 10:24 AM, John Engelhart wrote:
This is not a bug. This is fundamental to how object-oriented
programming works! You should always be able to pass an instance
of a subclass wherever an instance of the superclass is expected.
You're mistaken. You have statically typed t
On Jun 9, 2008, at 6:51 AM, Chris Hanson wrote:
On Jun 9, 2008, at 12:56 AM, John Engelhart wrote:
The semantics are preserved and identical results are calculated
(the 'meaning' is the same). The semantics do not require square()
to literally be called each time.
Yes, that is very clea
On Jun 9, 2008, at 2:56 AM, John Engelhart wrote:
Well, in the case of your example, you have a bug: You have
statically typed the class to NSArray, not your subclass. If one
applies the 'attribute only applies to the class it was specified
for' rule:
By statically typing the class to NS
On 9 Jun 2008, at 00:53, Chris Kane wrote:
On 7 Jun 2008, at 09:07, Antonio Nunes wrote:
On 7 Jun 2008, at 06:16, Ken Thomases wrote:
The issue is, how can one know when this technique is necessary?
By proper documentation. As Bill mentioned earlier, the
documentation needs to mention this
On Jun 9, 2008, at 12:56 AM, John Engelhart wrote:
The semantics are preserved and identical results are calculated
(the 'meaning' is the same). The semantics do not require square()
to literally be called each time.
Yes, that is very clear, because the compiler can have full knowledge
t
On Jun 8, 2008, at 10:03 PM, John Engelhart wrote:
The result from [data self] is invariant, it does not matter if it
is executed immediately after the object is instantiated or just
before [data release], the result is always the same.
There is no way in the Objective-C language as it curr
Le 9 juin 08 à 09:56, John Engelhart a écrit :
On Jun 8, 2008, at 11:48 PM, Chris Hanson wrote:
On Jun 8, 2008, at 5:39 PM, John Engelhart wrote:
On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:
This won't happen because each message expression -- just as with
function-call expressions -
On Jun 8, 2008, at 11:48 PM, Chris Hanson wrote:
On Jun 8, 2008, at 5:39 PM, John Engelhart wrote:
On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:
This won't happen because each message expression -- just as with
function-call expressions -- is a sequence point. The compiler
can't know
Date: Mon, 9 Jun 2008 01:03:16 -0400
From: John Engelhart <[EMAIL PROTECTED]>
On Jun 7, 2008, at 10:10 PM, Michael Ash wrote:
If you don't like undefined behavior, then C-based languages are a
poor choice. If you don't like nondeterministic object lifetimes,
then
garbage collection is a poor
to any function, method, or C-
only library function until the end of the enclosing block, regardless
of the behavior of the GC collector.
Using the raw UTF8String pointer is far, far more convenient, and very
likely to work 99.99% of the time without problems.
Convenience, however, rarely
On Jun 8, 2008, at 5:39 PM, John Engelhart wrote:
On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:
This won't happen because each message expression -- just as with
function-call expressions -- is a sequence point. The compiler
can't know what side-effects [data self] might have, so it can'
On Jun 7, 2008, at 7:11 PM, Chris Hanson wrote:
On Jun 6, 2008, at 5:36 PM, Quincey Morris wrote:
A little inner voice insists on asking, though, how we know some
future version of the compiler might not optimize '[data self]'
upwards before the loop, if it decides that nothing inside the
On Jun 7, 2008, at 6:59, Ricky Sharp wrote:
I will hope though that within the context of say memcpy, that the
GC thread could not collect data. For example, the following
should be safe:
memcpy(myLocalGCAwareBuffer, [data bytes], numberOfBytes);
No. This is equivalent to:
void *tmp0734
On 8 Jun 2008, at 01:23, Bill Bumgarner wrote:
One of the tenets of GCC is that *it controls the layout of the
stack always* and this is done quite explicitly because of
performance.
I think this is the crucial point when considering how any GC will
work with gcc.
If gcc controls the s
On Sun, Jun 8, 2008 at 3:10 AM, Michael Ash <[EMAIL PROTECTED]> wrote:
> In many cases, including this one, the release build is actually
> exposing faulty code, whereas the debug build is hiding it by working
> as the programmer wants it to despite the code not actually being
> correct.
My thank
On Sun, Jun 8, 2008 at 1:23 AM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:
> Consider:
>
> {
>int foo;
>
>... calculate on foo ...
>
>int bar = getirdone(foo);
>
>while(1) {
>func(bar);
>func2(bar);
>... etc ...
>}
> }
>
> Without being able to recycle th
Hi Peter,
On Sun, Jun 8, 2008 at 1:15 AM, Peter Duniho <[EMAIL PROTECTED]> wrote:
> Maybe it's just because I've been using GC systems more than you have, and
> so I've gotten used to thinking about memory allocations in the paradigm
> that GC systems impose.
I'm starting to realise that this is
On Jun 7, 2008, at 17:23, Bill Bumgarner wrote:
As well, if foo / bar fall in a register, then those registers would
have to be preserved for all of the while loop, too, either by not
being available to the bulk of the program (which raises some
serious codegen issues) or being moved out/i
> what the optimising compiler re-wrote for you.
If you don't like undefined behavior, then C-based languages are a
poor choice. If you don't like nondeterministic object lifetimes, then
garbage collection is a poor choice.
The compiler and garbage collector both do their jobs. They
On Jun 6, 2008, at 5:36 PM, Quincey Morris wrote:
A little inner voice insists on asking, though, how we know some
future version of the compiler might not optimize '[data self]'
upwards before the loop, if it decides that nothing inside the loop
references anything non-local:
This won't
On Jun 7, 2008, at 3:51 PM, Hamish Allan wrote:
Sorry to reply to myself, but I just remembered that pointers in
registers are also in the root set! That said, I don't think it
changes the substance of my proposal: that stack variables (i.e.
variables semantically placed on the stack by the progr
all objects reachable from root objects
and all possible references found by examining the call stacks of
every Cocoa thread."
Is that the actual specification for the garbage collector? Or just
some documentation provided by Apple?
In any case...
Are you seriously telling me that
On Sat, Jun 7, 2008 at 11:24 PM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> Sure, you could design NSData differently to mask a design problem in
> GC. But GC won't be easier to use than retain/release/autorelease
> without simple rules like "if you declare it on the stack, it's in the
> root set,
On Sat, Jun 7, 2008 at 7:35 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> This is pretty nitpicky. If it's in scope but you don't use it, then
> it doesn't matter. Kind of like a Zen koan: if an object is collected
> in the forest but nobody is pointing to it anymore, does it make a
> sound?
:)
I
ecifies that "Garbage collection is all
about what's being used or not"?
> Even if the compiler did not optimize away the
> use of the variable past that point in the code, if the GC system could
> otherwise determine you weren't ever going to use it again, it would _sti
On Jun 7, 2008, at 2:07 PM, Jean-Daniel Dupas wrote:
Le 7 juin 08 à 20:30, Michael Ash a écrit :
On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
I will hope though that within the context of say memcpy, that the
GC thread
could not collect data. For example, the fo
On Jun 7, 2008, at 1:30 PM, Michael Ash wrote:
On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
Finally, I think that usages of NSMutableData may also be a bit
tricky. In
my case I'll probably just obtain a copy of its bytes, manipulate
them and
then copy the result
Le 7 juin 08 à 20:30, Michael Ash a écrit :
On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
I will hope though that within the context of say memcpy, that the
GC thread
could not collect data. For example, the following should be safe:
memcpy(myLocalGCAwareBuffer, [d
On Sat, Jun 7, 2008 at 2:19 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
> The consequence of this should be either:
>
> (a) [data bytes] must promise to return a collectable object (so that the
> 'bytes' reference keeps it alive), or
>
> (b) [data bytes] must lock (pseudo-retain) something intern
On Sat, Jun 7, 2008 at 10:31 AM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>
>> The business about scanning the stack is essentially an
>> implementation detail; the promise that is being made is that objects
>> which you're sti
Date: Sat, 7 Jun 2008 15:31:43 +0100
From: "Hamish Allan" <[EMAIL PROTECTED]>
On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]>
wrote:
The business about scanning the stack is essentially an
implementation detail; the promise that is being made is that objects
which you're stil
On Sat, Jun 7, 2008 at 9:59 AM, Ricky Sharp <[EMAIL PROTECTED]> wrote:
> I will hope though that within the context of say memcpy, that the GC thread
> could not collect data. For example, the following should be safe:
>
> memcpy(myLocalGCAwareBuffer, [data bytes], numberOfBytes);
Not at all. The
On Jun 7, 2008, at 04:34, Michael Ash wrote:
Actually I think that it is about the char * pointer, and this bug
should be considered an NSData bug rather than a compiler bug or a GC
bug. The fact that it's really a design bug in NSData rather than
something that can be easily fixed definitely m
On Jun 6, 2008, at 7:27 PM, Quincey Morris wrote:
On Jun 6, 2008, at 15:48, Bill Bumgarner wrote:
The garbage collector does not currently interpret inner pointers
as something that can keep an encapsulating object alive. Thus,
the behavior is undefined and that it changes between debug
On Sat, Jun 7, 2008 at 2:18 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> The business about scanning the stack is essentially an
> implementation detail; the promise that is being made is that objects
> which you're still pointing to won't go away.
We're just interpreting this promise differently
On Jun 7, 2008, at 8:18 AM, Michael Ash wrote:
It *does* do this. The error is not in the GC, but rather in the
assumption that "declared in the current scope" is equivalent to "is
on the stack frame". This assumption is not valid. The fact that you
can't make this assumption is extremely incon
On Sat, Jun 7, 2008 at 8:47 AM, Hamish Allan <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 7, 2008 at 12:34 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
>
>> The problem here is
>> that you're expecting one pointer to keep a *different* pointer live,
>> which the GC does not make any guarantees about.
>
>
On Sat, Jun 7, 2008 at 12:34 PM, Michael Ash <[EMAIL PROTECTED]> wrote:
> The problem here is
> that you're expecting one pointer to keep a *different* pointer live,
> which the GC does not make any guarantees about.
Pre garbage collection, this was straightforward: as long as you
retain your NSD
On Sat, Jun 7, 2008 at 12:42 AM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:
> The easiest way to do this is to simply to use data once after the for()
> loop:
>
>NSData* data = ;
>const unsigned char* bytes = [data bytes];
>NSUInteger count = [data length];
>for (NSU
On Sat, Jun 7, 2008 at 12:31 AM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:
> Yes, it is an exceedingly important optimization. Most likely, that stack
> slot is being reused by some variable later on.
I can see how this might be "exceedingly important" for deeply
recursive functions, but for the
On Sat, Jun 7, 2008 at 7:13 AM, Ken Thomases <[EMAIL PROTECTED]> wrote:
> Nobody is claiming that it should. It's not about the char* pointer. It's
> about the NSData* pointer.
Actually I think that it is about the char * pointer, and this bug
should be considered an NSData bug rather than a com
inter. I'm
curious as to why Bill suggested his solution rather than directly
instructing the garbage collector, since that would seem to me the
more obvious solution. Is Bill's solution preferable in any way?
(After all, I'd like to improve to the level where I know what I&#
On Jun 7, 2008, at 12:03 AM, Bill Bumgarner wrote:
On Jun 6, 2008, at 9:16 PM, Ken Thomases wrote:
And... we're back to retain/release.
The issue is, how can one know when this technique is necessary?
The supposed rules of GC are, if it's in a stack variable, it's
safe. The compiler here
s solution rather than directly
instructing the garbage collector, since that would seem to me the
more obvious solution. Is Bill's solution preferable in any way?
(After all, I'd like to improve to the level where I know what I'm
doing ;-)
I can think of one significant d
I'm fairly satisfied with Bill's (and others') suggested workarounds
about how to keep the object from being collected, but if I might
ramble just a little:
On Jun 6, 2008, at 22:03, Bill Bumgarner wrote:
On Jun 6, 2008, at 9:16 PM, Ken Thomases wrote:
And... we're back to retain/release.
ested to
temporarily turn of garbage collection for this pointer. I'm curious
as to why Bill suggested his solution rather than directly instructing
the garbage collector, since that would seem to me the more obvious
solution. Is Bill's solution preferable in any way? (After all, I&#x
On Jun 6, 2008, at 9:16 PM, Ken Thomases wrote:
And... we're back to retain/release.
The issue is, how can one know when this technique is necessary?
The supposed rules of GC are, if it's in a stack variable, it's
safe. The compiler here is doing something behind the programmer's
back, wh
On Jun 6, 2008, at 10:48 PM, Antonio Nunes wrote:
On 7 Jun 2008, at 01:42, Bill Bumgarner wrote:
The easiest way to do this is to simply to use data once after the
for() loop:
NSData* data = ;
const unsigned char* bytes = [data bytes];
NSUInteger count = [data length
On Jun 6, 2008, at 5:36 PM, Quincey Morris wrote:
Thanks, and to Shawn for the same suggestion. It's a pragmatic
solution I can deal with.
A little inner voice insists on asking, though, how we know some
future version of the compiler might not optimize '[data self]'
upwards before the loop,
On 7 Jun 2008, at 01:42, Bill Bumgarner wrote:
The easiest way to do this is to simply to use data once after the
for() loop:
NSData* data = ;
const unsigned char* bytes = [data bytes];
NSUInteger count = [data length];
for (NSUInteger i = 0; i < count; i++)
On Jun 6, 2008, at 7:05 PM, Ricky Sharp wrote:
On Jun 6, 2008, at 6:42 PM, Bill Bumgarner wrote:
Sorry -- let me clarify. If the was either released in a
different thread or if were explicitly released in the above
code, then you would see the same crash. I didn't mean to imply
t
On Jun 6, 2008, at 16:42, Bill Bumgarner wrote:
The easiest way to do this is to simply to use data once after the
for() loop:
NSData* data = ;
const unsigned char* bytes = [data bytes];
NSUInteger count = [data length];
for (NSUInteger i = 0; i < count; i++)
On Jun 6, 2008, at 6:42 PM, Bill Bumgarner wrote:
Sorry -- let me clarify. If the was either released in a
different thread or if were explicitly released in the above
code, then you would see the same crash. I didn't mean to imply
that would be released under non-GC without some
On Fri, Jun 6, 2008 at 4:27 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
>
> On Jun 6, 2008, at 15:48, Bill Bumgarner wrote:
>
>> In any case, you need to make sure that stays alive throughout the
>> entire lifespan of the bytes pointer.
>
> But the puzzling question is: how?
CFRetain/CFRelease
On Jun 6, 2008, at 4:24 PM, Ricky Sharp wrote:
On Jun 6, 2008, at 5:48 PM, Bill Bumgarner wrote:
On Jun 6, 2008, at 3:23 PM, Quincey Morris wrote:
In a GC-only app, I frequently use a pattern along these lines:
NSData* data = ;
const unsigned char* bytes = [data bytes];
On Fri, Jun 6, 2008 at 4:27 PM, Quincey Morris
<[EMAIL PROTECTED]> wrote:
> But the puzzling question is: how?
Send a message to the NSData object after the block is done with the
byte pointer. ([data self])
-Shawn
___
Cocoa-dev mailing list (Cocoa-de
On Jun 6, 2008, at 4:18 PM, Hamish Allan wrote:
On Fri, Jun 6, 2008 at 11:48 PM, Bill Bumgarner <[EMAIL PROTECTED]> wrote:
The garbage collector does not currently interpret inner pointers as
something that can keep an encapsulating object alive.
But it's not the inner pointers I w
On Jun 6, 2008, at 5:24 PM, Ricky Sharp wrote:
I'm a bit confused by this. In non-GC, data would not be released
during the loop execution. Let's assume that it was autoreleased
during the 'get it from somewhere'. It would only be actually
released when execution returns to the main run
On Jun 6, 2008, at 15:48, Bill Bumgarner wrote:
The garbage collector does not currently interpret inner pointers as
something that can keep an encapsulating object alive. Thus, the
behavior is undefined and that it changes between debug and release
builds -- between optimization levels
1 - 100 of 104 matches
Mail list logo
