On Apr 30, 2008, at 10:35 PM, Melissa J. Turner wrote:
NSAutoreleasePool *pool = [NSAutoreleasePool new];
id exception;
Should be initialized to nil:
id exception = nil;
@try {
// insert code here
} @catch (NSException *ex) {
exception = [ex retain];
@throw ex;
} @fin
On Thu, May 1, 2008 at 2:05 AM, Paul Bailey <[EMAIL PROTECTED]> wrote:
> The class documentation for NSAutoreleasePool notes that release is a no-op
> on garbage-collected environments, and one should use drain to give the
> garbage collector a hint to do its job (that's my limited understanding)
The class documentation for NSAutoreleasePool notes that release is a no-op
on garbage-collected environments, and one should use drain to give the
garbage collector a hint to do its job (that's my limited understanding).
It notes that drains behaves the same as release in a memory managed
environm
On Apr 30, 2008, at 7:27 PM, Jens Alfke wrote:
I also changed the pool calls to the current recommended names: +new
and -drain.
Can you point me to where the official documentation recommends the
use of +new over +alloc-init?
Thanks,
j o a r
__
On Apr 30, 2008, at 19:59, Chris Suter wrote:
On 01/05/2008, at 12:27 PM, Jens Alfke wrote:
On 30 Apr '08, at 5:53 PM, Graham Cox wrote:
If throws an exception won't that mean that is
leaked? (and all of its contents up to that point too; applies to
both of our code examples).
Yup.
On 01/05/2008, at 12:27 PM, Jens Alfke wrote:
On 30 Apr '08, at 5:53 PM, Graham Cox wrote:
If throws an exception won't that mean that is
leaked? (and all of its contents up to that point too; applies to
both of our code examples).
Yup. You can work around that by using @finally:
Well, because of Matt's post I read up more on autorelease pools. The
docs state:
"If you release an autorelease pool that is not the top of the stack,
this causes all (unreleased) autorelease pools above it on the stack
to be released, along with all their objects. If you neglect to send
On 30 Apr '08, at 5:53 PM, Graham Cox wrote:
If throws an exception won't that mean that is
leaked? (and all of its contents up to that point too; applies to
both of our code examples).
Yup. You can work around that by using @finally:
for (i = 0; i < count; i++)
{
If throws an exception won't that mean that is
leaked? (and all of its contents up to that point too; applies to both
of our code examples). Or is there some special handling of
autorelease pools when an exception is thrown? If so, I wasn't aware
of it - can you point to the relevant docs
Or you could go with:
-(IBAction) Generate:(id) sender
{
for (i = 0; i < count; i++)
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSImage* tempSource = [[[NSImage alloc]
initWithContentsOfFile:sPath[i]] autorelease];
// autorelease tempSour
On 30 Apr 2008, at 11:08 pm, Roland King wrote:
ok but why? I assume if this works that the NSImage alloc/
initWithContentsOfFile: is doing a retain/autorelease.
Of course that wouldn't violate the letter of the memory management
documentation, which really just tells you that if you alloc/i
ok but why? I assume if this works that the NSImage alloc/
initWithContentsOfFile: is doing a retain/autorelease.
Of course that wouldn't violate the letter of the memory management
documentation, which really just tells you that if you alloc/init an
object, you are responsible for freeing i
-(IBAction) Generate:(id) sender
{
for (i = 0; i < count; i++)
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSImage* tempSource = [[NSImage alloc]
initWithContentsOfFile:sPath[i]];
// some code
[tempSource release];
I deleted everything that was between NSImage* tempSource = [[NSImage
alloc] initWithContentsOfFile:sPath[i]; and [tempSource release]; so
basically this is the code (sPath is a NSString array containing path
names):
-(IBAction)Generate:(id)sender
{
for (i = 0; i < count; i++)
Use a local autorelease pool, like this:
- (IBAction)Generate:(id)sender
{
// some code
for (i = 0; i < count; i++) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSImage *tempSource = [NSImage imageWithContentsOfFile:sPath[i]];
// some code
[pool release]
You have no guarantee that a method like -initWithContentsOfFile: is not going
to add many allocations to the autorelease pool (which probably exists at your
top runloop). In my code, in places that sit in tight processing loops, I've
had to create an autorelease pool at the top of the loop whic
Of course, if that's the case, simply wrapping the whole section of code
with its own autorelease pool will cause the memory to be released at the
end of each iteration.
Paul
On Tue, Apr 29, 2008 at 12:37 PM, Graham Cox <[EMAIL PROTECTED]> wrote:
> It sounds like something in "some code" is also
Hi,
Calling -[NSObject release] is almost never a guarantee that your
object will be deallocated. By releasing tempSource in your code
you're simply stating that you no longer need that object and that
Cocoa can free up the memory taken by the object **when appropriate**
(i.e., when nobod
It sounds like something in "some code" is also retaining tempSource
(probably autoreleasing it), so that the release at the end of the
loop is not actually releasing, but the subsequent release of the
autorelease pool at the end of the event is doing so.
So without "some code" it's hard to
Hi everybody,
I am writing an application where, at some point in time, the user
clicks a button and for a great amount of images the average pixel
values are calculated and stored in an array.
Basically this looks like this:
-(IBAction)Generate:(id)sender
{
// some code
for (i =
20 matches
Mail list logo
