Re: Dodgy Code - Low Level Memory Management Question!

> On 26 Jan 2016, at 19:15, Jens Alfke wrote: > > >> On Jan 26, 2016, at 6:00 AM, Dave > > wrote: >> >> Sorry typeo in the pseudo code, it passes the object and it is retained…. > > Dave, if you want us to debug your code for you, then SHOW US THE ACTUAL > #*$

Re: Dodgy Code - Low Level Memory Management Question!

> On Jan 26, 2016, at 6:00 AM, Dave wrote: > > Sorry typeo in the pseudo code, it passes the object and it is retained…. Dave, if you want us to debug your code for you, then SHOW US THE ACTUAL #*$&% CODE! Don’t show us something else that _looks_ like real Obj-C but that you just typed into

Re: Dodgy Code - Low Level Memory Management Question!

On Jan 26, 2016, at 06:00 , Dave wrote: > > IOW, the autorelease will basically just be a NOP? An autorelease is never a NOP. It’s a “release later”, not a “release if necessary”. Rather than trying to count or balance retains globally, I think it’s easier to think in terms of ownership (+1 r

Re: Dodgy Code - Low Level Memory Management Question!

Hi Again \ > On 25 Jan 2016, at 19:22, Quincey Morris > wrote: > > On Jan 25, 2016, at 10:48 , Dave > wrote: >> >> myNewObject = [super initWithSomething: something]; > > This is a dangerous thing to do. At this point ‘self’ might not be a properly > initializ

Re: Dodgy Code - Low Level Memory Management Question!

Also, >> [LTWCacheManager addToCache: myID]; Should be [LTWCacheManager addID:myID withObject:myNewObject]; or some such (this is pseudo code really). > On 25 Jan 2016, at 19:06, Jens Alfke wrote: > > >> On Jan 25, 2016, at 10:48 AM, Dave > > wrot

Re: Dodgy Code - Low Level Memory Management Question!

Yes, A typeo, sorry! > On 25 Jan 2016, at 19:06, Jens Alfke wrote: > > >> On Jan 25, 2016, at 10:48 AM, Dave > > wrote: >> >> if ( myCachedObject == nil); > > The trailing semicolon on that line above must be a typo. It’s going to cause > the test to be ignore

Re: Dodgy Code - Low Level Memory Management Question!

On Jan 25, 2016, at 10:48 , Dave wrote: > > myNewObject = [super initWithSomething: something]; This is a dangerous thing to do. At this point ‘self’ might not be a properly initialized object, if the ‘super’ call returns a different object from ‘self’. You’re better off assigning the result t

Re: Dodgy Code - Low Level Memory Management Question!

> On Jan 25, 2016, at 10:48 AM, Dave wrote: > > if ( myCachedObject == nil); The trailing semicolon on that line above must be a typo. It’s going to cause the test to be ignored and the block below to always run. > { > self = myNewObject; > [LTWCacheManager addToCache: myID]

Dodgy Code - Low Level Memory Management Question!

Hi All, This is a bit dodgy so bear with me. I have a class that is a subclass of a third party framework. This is hard to explain, but I’m trying to make it into a singleton of kinds. When the framework wants an object of this particular class it alloc/init’s a new one. This calls the designa

Re: ARC and Manual Memory Management

I found fmdb’s solution instructive and very helpful. If you download the source and take a look it might give you some ideas. Rob ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin reques

Re: ARC and Manual Memory Management

up with a way of having the source code support both > ARC and Manual Memory Management without using #IFDEF or #IF ? > >>> > >>> I’ve never understood why the compiler doesn’t just ignore code like: > >>> > >>> [super dealloc]; > >>> >

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 21:12, Dave wrote: > > >> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: >> >> On 10 Aug 2015, at 13:59, Dave wrote: >>> Has anyone come up with a way of having the source code support both ARC >>> and Manual Memory Managemen

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 12:12 PM, Dave wrote: > > If it just ignored those constructs, it was be much less confusing, simply > because there would only one set of source code. It would be a mess, honestly. If you build + test a source file with ARC it’d be very easy to break it for MRR by forge

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 12:12 PM, Dave wrote: > >> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: >> >>> On 10 Aug 2015, at 13:59, Dave wrote: >>> >>> Has anyone come up with a way of having the source code support both ARC >>> an

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: > > On 10 Aug 2015, at 13:59, Dave wrote: >> Has anyone come up with a way of having the source code support both ARC and >> Manual Memory Management without using #IFDEF or #IF ? >> >> I’ve never understood why

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 1:11 PM, Uli Kusterer > wrote: > > The only reason I'm aware of is if you need to port to a platform that > doesn't support libArclite (like really old Mac/iOS versions). Targeting arclite isn’t such a good idea these days, IMO; I’ve found the later versions of Xcode som

Re: ARC and Manual Memory Management

On 10 Aug 2015, at 13:59, Dave wrote: > Has anyone come up with a way of having the source code support both ARC and > Manual Memory Management without using #IFDEF or #IF ? > > I’ve never understood why the compiler doesn’t just ignore code like: > > [super dealloc]; &

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 8:35 AM, Dave wrote: > > That’s fair enough, I was wondering if there was any deep reason. The thing > is I have library classes that I use in older projects that are non-ARC, I > was trying avoid having two sets of more or less identical files. Just add the compiler fl

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 13:21, Roland King wrote: > > >> On 10 Aug 2015, at 19:59, Dave > <mailto:d...@looktowindward.com>> wrote: >> >> Hi, >> >> Has anyone come up with a way of having the source code support both ARC and >> Manual Me

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 19:59, Dave wrote: > > Hi, > > Has anyone come up with a way of having the source code support both ARC and > Manual Memory Management without using #IFDEF or #IF ? > > I’ve never understood why the compiler doesn’t just ignore code l

Re: ARC and Manual Memory Management

On Monday, August 10, 2015, Dave wrote: > Hi, > > Has anyone come up with a way of having the source code support both ARC > and Manual Memory Management without using #IFDEF or #IF ? You could use a macro, and if ARC is enabled, then simply have it evaluated to do nothing. This

ARC and Manual Memory Management

Hi, Has anyone come up with a way of having the source code support both ARC and Manual Memory Management without using #IFDEF or #IF ? I’ve never understood why the compiler doesn’t just ignore code like: [super dealloc]; [MyObj release]; If it’s being compiled for ARC, that way both could

Re: Found It - Problem with Outline View and Manual Memory Management

> On 28 May 2015, at 17:56, Kyle Sluder wrote: > > On Thu, May 28, 2015, at 08:37 AM, Dave wrote: >> Hi, >> >> This is from Apple Sample Code so I thought something as fundamental as >> this would have been dealt with correctly. This is the copy method inside >> the “ImageAndTextCell” class, >>

Re: Found It - Problem with Outline View and Manual Memory Management

On Thu, May 28, 2015, at 08:37 AM, Dave wrote: > Hi, > > This is from Apple Sample Code so I thought something as fundamental as > this would have been dealt with correctly. This is the copy method inside > the “ImageAndTextCell” class, > > -(id) copyWithZone:(NSZone*) zone > { > ImageAndTextCell

Re: Found It - Problem with Outline View and Manual Memory Management

Hi, This is from Apple Sample Code so I thought something as fundamental as this would have been dealt with correctly. This is the copy method inside the “ImageAndTextCell” class, -(id) copyWithZone:(NSZone*) zone { ImageAndTextCell *cell = (BJImageAndTextCell*) [super copyWithZone:zone]; cell.

Re: Found It - Problem with Outline View and Manual Memory Management

> On 28 May 2015, at 12:56 am, Dave wrote: > > myCell = (ImageAndTextCell*) [cell copy]; > //*** It’s a “well known”* fact that a copy of an NSCell or an

Found It - Problem with Outline View and Manual Memory Management

Sorry, I meant: In I change this to: myCell = (ImageAndTextCell*) [cell retain]; //*** It doesn’t work? Presumably now I think about it, because the Image

Found It - Problem with Outline View and Manual Memory Management

Hi, I’ve Found it, please see line marked below. In I change this to: myCell = (ImageAndTextCell*) [cell copy]; //*** It doesn’t work, which is a bit of

Re: Problem with Outline View and Manual Memory Management

HI, A bit more on this, firstly the problem seems to be related to the ImageAndTextCell class and secondly looking at the awakeFromNIB method from SourceView, ImageAndTextCell is allocated, the property is set, but then it does nothing with it. I assume that under ARC ImageAndTextCell will be s

Re: Problem with Outline View and Manual Memory Management

ge; > } > } > > // set the cell's image > [myChildNode.nodeIcon setSize:NSMakeSize(kIconImageSize, kIconImageSize)]; > > (ImageAndTextCell*)cell.pTextCellImage = myChildNode.nodeIcon; > } > > > > > >> On 27 May 2015, at

Re: Problem with Outline View and Manual Memory Management

Hi, Sorry, I wasn’t very clear, the VC is my existing VC with the Source Vice Code from “myViewController” code added so this had to be converted to use manual memory management. I also converted the other supporting classes although as you point out, I could have just set the compiler flag

Re: Problem with Outline View and Manual Memory Management

> On May 26, 2015, at 11:34 AM, Dave wrote: > > The SourceView project is built using ARC, but my App uses Manual Memory > Management. When I moved the code over, I changed it to use release etc. and > changed any properties or iVar’s to use retain or assign. Why not leave t

Re: Problem with Outline View and Manual Memory Management

On May 26, 2015, at 1:34 PM, Dave wrote: > When I run the App, it displays the Tree View fine and Populates the two > sections, but it crashes due to an over-release if I select a file based item > - I found this by using NSZombies - it gives the error: > > *** -[NSImage release]: message sent

Problem with Outline View and Manual Memory Management

my App uses Manual Memory Management. When I moved the code over, I changed it to use release etc. and changed any properties or iVar’s to use retain or assign. The problem builds with no analyser warnings (which doesn’t mean as much as it used to, because I’ve found that the Analyser in XCode

Re: CALayer memory management [was: Tracking down CALayer problem in iTunes plug-in]

> I've narrowed this error down to a very simple test case. Could you post you test case? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-ad

CALayer memory management [was: Tracking down CALayer problem in iTunes plug-in]

I've narrowed this error down to a very simple test case. I have a CALayer subclass. In this subclass, I've added properties which are synthesized and retained (in fact, they are NSColors). I don't attempt to animate these properties. In my -dealloc method, I'm setting these properties to nil,

Re: A question of memory management style

Thanks for the suggestions. I decided to go with having the handler object retain itself and release itself when the interaction is completed. That avoids having to have more instance variables in the document object to track handlers and release them when done. Also, thanks for the pointers t

Re: A question of memory management style

r. If the caller does not > need to release the object, the method name should not be > createHandlerWIthXXX, but handlerWithXXX. That's not correct. Core Foundation's naming conventions treat "create" specially, but Cocoa's don't. This is specifically cal

Re: A question of memory management style

On Jul 17, 2011, at 10:32 PM, John Brownie wrote: > [HandlerClass createHandlerWith...] I think your model is correct, but Cocoa convention is that method names beginning with create confer ownership to the caller. If the caller does not need to release the object, the method name should not be

Re: A question of memory management style

Hi! > In the document object, I am observing such an event, then creating a handler > and calling it. I have handled creation either by explicit allocation such as > [[HandlerClass alloc] initWith...] or by writing a class method to create an > object like [HandlerClass createHandlerWith...]. I

Re: A question of memory management style

ut the analyzer warns me that the > handler is potentially leaking from the document class. > > So my question is, what model of memory management is appropriate? Should I > stick with what I have, where the document object creates the handler and > then forgets it, knowing that th

A question of memory management style

dling of a particular event, such as dropping text on a view, and encapsulating all the logic and interactions (dialogs where necessary) associated with that as a separate class. This is working fine, but the static analyzer of Xcode 3.2.6 doesn't like my memory management practice with this.

Re: Memory management and returned values from methods...

You make a very compelling point. On Jul 15, 2011, at 4:36 PM, Scott Ribe wrote: > On Jul 15, 2011, at 1:38 PM, Kevin Muldoon wrote: > >> However, there must be a better way than giving up control of releasing my >> objects to NSAutoreleasePool. > > How is this giving up control? There's alwa

Re: Memory management and returned values from methods...

On Jul 15, 2011, at 1:38 PM, Kevin Muldoon wrote: > However, there must be a better way than giving up control of releasing my > objects to NSAutoreleasePool. How is this giving up control? There's always an NSAutoreleasePool provided by the run loop which cleans up between handling events; all

Re: Memory management and returned values from methods...

On Jul 15, 2011, at 3:38 PM, Kevin Muldoon wrote: > Hey guys, > > I know of at least one way to fix this memory leak but I'm hoping to find a > few more ways. > > I'm chewing through a text file of 205,960 lines in a C while loop. All is > good until MyObject returns a value. Of course the ret

Re: Memory management and returned values from methods...

On Jul 15, 2011, at 12:38 PM, Kevin Muldoon wrote: > while (fgets(buffer, sizeof(buffer), filePointer) != NULL) { > > NSString *line = [[NSString alloc] > initWithString:[NSString stringWithFormat:@"%s", buffer]]; You could use -[NSString initWithUTF8String:] instead. Addi

Memory management and returned values from methods...

Hey guys, I know of at least one way to fix this memory leak but I'm hoping to find a few more ways. I'm chewing through a text file of 205,960 lines in a C while loop. All is good until MyObject returns a value. Of course the return value set to autorelease (Well, I suppose it would auto

Re: If No Memory Leaks, Is It Good Enough for Memory Management?

On Mon, Jun 20, 2011 at 12:26 AM, Bing Li wrote: > Dear all, > > I am still a new programmer of Cocoa. In my program, at least right now, > there are no memory leaks according to Instruments. Is it good enough for > memory management? No. This is not good enough. If you are do

Re: If No Memory Leaks, Is It Good Enough for Memory Management?

Google for Heapshot analysis. Tony Romano On 6/20/11 12:28 AM, "Bing Li" wrote: >Dear all, > >I am still a new programmer of Cocoa. In my program, at least right now, >there are no memory leaks according to Instruments. Is it good enough for >memory management?

Re: If No Memory Leaks, Is It Good Enough for Memory Management?

First, please tell me you have read up on memory management after every person on this list told you to do so. And bought a C book. That said, no, Instruments not showing any leaks is not itself sufficient to prove you are managing memory properly. For one, Instruments will generally only show

If No Memory Leaks, Is It Good Enough for Memory Management?

Dear all, I am still a new programmer of Cocoa. In my program, at least right now, there are no memory leaks according to Instruments. Is it good enough for memory management? What I designed is a TCP server which receives TCP messages. When I tested it, 200,000 XML were sent to it with a loop

If No Memory Leaks, Is It Good Enough for Memory Management?

Dear all, I am still a new programmer of Cocoa. In my program, at least right now, there are no memory leaks according to Instruments. Is it good enough for memory management? What I designed is a TCP server which receives TCP messages. When I tested it, 200,000 XML were sent to it with a loop

Re: Memory Management for an Array

The shown memory handling is wrong. Am 13.06.2011 um 16:31 schrieb Bing Li: > + (NSString *)read:(NSString *)xml Path:(NSString *)xPath This methods signature should be read:path: with a lowercase p. > { >// The Instruments indicated the following line got memory leaks. > The amount of

Re: Memory Management for an Array

Jun 13, 2011, at 3:37 AM, Bing Li wrote: > > > I think the memory management in my system is much better. I just used > Instruments to check potential leaks. To my surprise, I was still notified > that the following method got memory-leaking although the amount was small. > You ca

Re: Memory Management for an Array

, you have a bona-fide growth. Tony Romano On 6/13/11 7:31 AM, "Bing Li" wrote: >Dear Tito, Scott and all, > >Thanks so much for your replies! > >I think the memory management in my system is much better. I just used >Instruments to check potential leaks

Re: Memory Management for an Array

On Jun 13, 2011, at 7:31 AM, Bing Li wrote: > I think the memory management in my system is much better. I just used > Instruments to check potential leaks. To my surprise, I was still notified > that the following method got memory-leaking although the amount was small. > Could you

Re: Memory Management for an Array

Dear Tito, Scott and all, Thanks so much for your replies! I think the memory management in my system is much better. I just used Instruments to check potential leaks. To my surprise, I was still notified that the following method got memory-leaking although the amount was small. Could you

Re: Memory Management for XML Parsing

On Jun 12, 2011, at 2:44 AM, Bing Li wrote: > The NSArray, nodes, is created by xmlDoc. Since the method is not the owner, > nodes should be released here. No, you don’t need to release ‘nodes' since you didn’t allocate or copy it. > When a large number of XML is received, the > receiver's memo

Re: Memory Management for an Array

On Jun 12, 2011, at 12:29 PM, Bing Li wrote: > Do you think the below method is a correct solution to manage memory? I am > not sure if the array, nodes, could leak? Really, follow the memory management rules as written and as pointed out to you before. That is how you know you'

Re: Memory Management for an Array

Hi Bing, Looks good. One comment though: I would return nil instead of an empty string to differentiate an actual value (the empty string) vs. "nothing was read." -- Tito On Jun 12, 2011, at 11:29 AM, Bing Li wrote: > Dear all, > > Do you think the below method is a correct solution to manage

Memory Management for an Array

Dear all, Do you think the below method is a correct solution to manage memory? I am not sure if the array, nodes, could leak? Thanks so much! Best regards, Bing + (NSString *)read:(NSString *)xml Path:(NSString *)xPath { NSXMLDocument *xmlDoc = [[NSXMLDocument alloc] initWithXMLString:

Memory Management for XML Parsing

Dear all, I got another memory management problem. When an XML is received, it must be parsed using the below method. When a large number of XML is received, the receiver's memory is increased slowly. I tried to figure out where the memory leaks. I guess the method might cause this problem.

Re: Multithreading and memory management question

Hi Ken, > How are you spawning your threads? > If you use Cocoa methods, then they automatically retain the object which is > the target of the selector and the argument object for the life of the > thread.  So, you may be getting this automatically without realizing it.  If > not, then it shoul

Re: Multithreading and memory management question

On Apr 21, 2011, at 4:18 PM, eveningnick eveningnick wrote: > I have an application that has a shared object (which is a custom > container for elements - arrays, and which is protected by critical > sections in my code). I need to control it's lifetime - it should be > alive until the last thread

Multithreading and memory management question

Hello I have an application that has a shared object (which is a custom container for elements - arrays, and which is protected by critical sections in my code). I need to control it's lifetime - it should be alive until the last thread finishes working. Let me try to explain it using an example f

Re: Memory management about async object

Hi All, What if the handler retain itself, and then will perform some NSURLConnection tasks, that will async download some data, and receive some messages as a delegate by implementing connection:didReceiveResponse connection:didReceiveData connection:didFailWithError connection:didFinishLoading

Re: Memory management about async object

There's some good information on this in TechNote 2009 Also, here is some sample code you might find very helpful: as it does almost what you're descr

Re: Memory management about async object

On Dec 29, 2010, at 5:54 PM, James Bucanek wrote: > - (void) loadData { >DataHandler *myHandler = [[DataHandler alloc] init]; >// set this view controller itself as a delegate, when the data loading > finished, myHandler will call its callback method >myHandler.delegate = self; >[

Re: Memory management about async object

ention to it. The answer to your question is, I think, simple: Follow good memory management procedures. Retain objects until you no longer need to reference them, and then release them. More excellent advice. I'm just a fountain of wisdom. Having said that, if your connectionDidFinishLoading

Re: Memory management about async object

s just released. As a general rule, I would avoid releasing |self| since (conceptually) an object does not own itself. The answer to your question is, I think, simple: Follow good memory management procedures. Retain objects until you no longer need to reference them, and then release them.

Re: Memory management about async object

Hi Stephen, Thanks for your reply, so there is no any perfect solution for this kind of problem? And can you give me a specific example to demonstrate why why it is not safe to release these async objects inside a callback method and why not safe to autorelease it? Thanks. On Tue, Dec 28, 2010 at

Re: Memory management about async object

On Tue, Dec 28, 2010 at 12:18 AM, ico wrote: > My question is, when should I release the myHandler? Should I release it in > the myCallback, but after > myCallback method finishes, it will return point 1 indicated as above, and > that myHandler instance is just > released. > > Or there is a better

Memory management about async object

Hi, I am working on an app that will asynchronous to load data. Suppose I have a view controller with a method: in MyViewController: - (void) loadData { DataHandler *myHandler = [[DataHandler alloc] init]; // set this view controller itself as a delegate, when the data loading finished,

Re: NSTimer memory management

On Sun, Sep 26, 2010 at 5:39 PM, Jeff Johnson wrote: > On Sep 23, 2010, at 6:13 PM, slasktrattena...@gmail.com wrote: > >> In this particular case, though, I might just as well get rid of the >> timer altogether and go for NSObject's >> performSelector:afterDelay:/cancelSelector: instead. Jeff's >

Re: NSTimer memory management

On Sep 23, 2010, at 6:13 PM, slasktrattena...@gmail.com wrote: > In this particular case, though, I might just as well get rid of the > timer altogether and go for NSObject's > performSelector:afterDelay:/cancelSelector: instead. Jeff's > enlightening (and frightening!) discussion about implicit r

Re: NSTimer memory management

blem by itself when a > repeating timer is used. I don't see how a repeating timer makes a difference. The memory management is the same. >> What can happen is that your app gets into a situation where the only thing >> that retains a reference to your object is its own theTime

Re: NSTimer memory management

On Sep 23, 2010, at 3:50 AM, Jeff Johnson wrote: > Your object retains the timer, and the timer retains your object. That is > obviously a kind of retain cycle. I think, this kind of retain cycle is not a problem by itself when a repeating timer is used. > What can happen is that your app gets

Re: NSTimer memory management

Thanks all for the input. I'll take Scott's and Gregory's advice to not retain the timer. I've seen this advocated before, but always felt uneasy about not retaining my pointers. It just goes against all I ever learned about Cocoa. In this particular case, though, I might just as well get rid of t

Re: NSTimer memory management

slasktrattena...@gmail.com wrote: > Is this an over-release? > > timer = [ [NSTimer scheduledTimerWithTimeInterval: ...] retain]; > ... > [timer invalidate]; > [timer release]; Seems fine, although based on

Re: NSTimer memory management

How about: just don't retain the timer? It is not the ordinary Cocoa memory management pattern, but it works perfectly well. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list

Re: NSTimer memory management

x27;ve seen this pattern so many times I figured it was correct, > although it doesn't seem to comply with the memory management rules > (i. e. the timer is first implicitly released when invalidated, then > explicitly released again).This never caused a problem on my Intel, &g

Re: NSTimer memory management

it doesn't seem to comply with the memory management rules > (i. e. the timer is first implicitly released when invalidated, then > explicitly released again). It's a valid technique; when you call -invalidate, the run loop releases the timer (to balance the implicit -retain that it

Re: NSTimer memory management

: Hi, Is this an over-release? timer = [ [NSTimer scheduledTimerWithTimeInterval: ...] retain]; ... [timer invalidate]; [timer release]; I've seen this pattern so many times I figured it was correct, although it doesn't seem to comply with the memory management rules (i. e. the time

NSTimer memory management

Hi, Is this an over-release? timer = [ [NSTimer scheduledTimerWithTimeInterval: ...] retain]; ... [timer invalidate]; [timer release]; I've seen this pattern so many times I figured it was correct, although it doesn't seem to comply with the memory management rules (i. e. the time

Memory Management

I had a nasty memory bug. I spent hours and hours on it with nothing but increasing frustration as a result. Then I went back to basics and read Apple's "Memory Management Programming Guide". The problem was now readily apparent and easily fixed. This is an excellent doc

Re: Search Kit memory management

On Aug 1, 2010, at 2:26 PM, Michael Thon wrote: > I decided to spend more time on Search Kit first, to see if I can get it to > do what I want. As far as I know it is the basis of Spotlight, so I didn't > think I would have problem indexing large numbers of files. You'd think so, but I, too,

Re: Search Kit memory management

ly have one of those objects >>> retained at a time. I guess there is something basic about memory >>> management that I don't understand. Can anyone see something wrong with >>> this code? >> >> You appear to be managing memory correctly in that cod

Re: Search Kit memory management

On Aug 1, 2010, at 6:44 PM, Ken Thomases wrote: > On Aug 1, 2010, at 11:10 AM, Michael Thon wrote: > >> I should probably just stick to my observations and state that "Real Mem" in >> Activity Monitor is reduced by several hundred MB when the NSOperation >> finishes indexing a few thousand doc

Re: Search Kit memory management

On Aug 1, 2010, at 11:10 AM, Michael Thon wrote: > I should probably just stick to my observations and state that "Real Mem" in > Activity Monitor is reduced by several hundred MB when the NSOperation > finishes indexing a few thousand documents. Yeah, using "Real Mem" in Activity Monitor is

Re: Search Kit memory management

On Aug 1, 2010, at 3:12 PM, Ken Thomases wrote: > On Aug 1, 2010, at 1:43 AM, Michael Thon wrote: > >> I am indexing possibly tens of thousands of documents. No matter what I >> tried, I could not get search kit to release its memory, even after closing >> the index. The only way I could prev

Re: Search Kit memory management

> > Hi Mike, > > What happens if you periodically call SKIndexFlush() in your loop? > > After closing the index, did you use Instruments to confirm that your > allocated memory is still allocated or did you look at memory usage in > Activity Monitor? Due to unde

Re: Search Kit memory management

On Aug 1, 2010, at 1:43 AM, Michael Thon wrote: > I am indexing possibly tens of thousands of documents. No matter what I > tried, I could not get search kit to release its memory, even after closing > the index. The only way I could prevent memory usage from growing too much is > to do the in

Re: Search Kit memory management

documents. I don't find any memory leaks. In Instruments, I find that >> there can sometimes be hundreds of SKDocumentRef objects marked as living, >> though I would expect that I should only have one of those objects retained >> at a time. I guess there is something

Re: Search Kit memory management

t > there can sometimes be hundreds of SKDocumentRef objects marked as living, > though I would expect that I should only have one of those objects retained > at a time. I guess there is something basic about memory management that I > don't understand. Can anyone see somet

Search Kit memory management

ed as living, though I would expect that I should only have one of those objects retained at a time. I guess there is something basic about memory management that I don't understand. Can anyone see something wrong with this code? Thanks NSDirectoryEnumerator *dirEnumerator = [[NSF

Re: memory management of app delegate on iOS

On Mon, Jul 19, 2010 at 9:32 PM, Matt Neuburg wrote: > Yet the UIApplication object does NOT retain its delegate. So why doesn't > the app delegate vanish in a puff of smoke? Is the MainWindow nib subject to > different memory management rules? UIApplication might be retaining

memory management of app delegate on iOS

MainWindow nib loading. It is a top-level nib object. So it should be autoreleased. Yet the UIApplication object does NOT retain its delegate. So why doesn't the app delegate vanish in a puff of smoke? Is the MainWindow nib subject to different memory management rules? Thx - m. -- m

Re: Memory management on returning nil in init

i type lots of stuff all the way out its easier to debug and the compilers are very good at optimizing that sort of thing there is a big balance between efficiency, size, speed, clarity, etc its usually clarity that is in short supply On Wed, Jun 23, 2010 at 7:42 PM, Scott Anguish wrote:

Re: Memory management on returning nil in init

Yes, that works as well. The reason we’ve advocated the longer form is that it is clearer what is happening to those who are not as intimate with the quirks like this. I also recall reading (but don’t quote me on this) that the longer form generates less instructions. I can’t recall where thou

Re: Memory management on returning nil in init

On Jun 23, 2010, at 3:00 PM, Jens Alfke wrote: > Yes. Any expression of the form > > if(A = B) > > i.e. an assignment directly inside an if, will result in a warning that this > looks confusingly like a comparison. If you prefer the if(A = B) syntax, though, this can be worked around by

  1   2   3   4   >