Hi, You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). On 80386's and 486's this made an incredible difference. Leaks could be detected at the point in which the leak occurred (e.g when all references to the object were gone) and either release it or throw an exception.
I think the overhead was an 8 bytes descriptor which was help in a private fast store SRAM for those in the know!) for each object allocated. In those days we were limited by the cost of the capacity of the devices. If Apple were to implement something like this I think there would be a massive increase in performance and reliability Cheers Dave On 9 Sep 2013, at 23:45, Patrick Cusack <livinginlosange...@mac.com> wrote: > I appreciate everyone's replies. It was a question asked in complete > humility. I agree that computers can do analysis much better than humans and > that the less code you write, the less you have to debug, so ARC makes a lot > of sense. My question really stemmed from Apple's WWDC lecture which appeared > to justify the switch on the flimsiest of grounds, ie no longer having to be > confused by [NSString stringWithFormat:] vs [NSString initWithString:] which > is a pretty easy memory management rule. > > As my main application is 32 bit (on account of the Quicktime API), I haven't > had much exposure to ARC yet. So I will be upgrading with Mavericks to ARC > and AVFoundation. > > Thanks for all of the comments. > > Patrick > > On Sep 9, 2013, at 7:29 AM, Alex Zavatone wrote: > >> >> On Sep 9, 2013, at 3:58 AM, Tom Davie wrote: >> >>> >>> On 9 Sep 2013, at 09:44, Kyle Sluder <k...@ksluder.com> wrote: >>> >>>> Thirded. I thought I wouldn't like it. As soon as I didn't have to manage >>>> retains and releases of temporary objects, the discipline completely left >>>> my mind. Now whenever I go back to non-ARC code I invariably make a ton of >>>> memory management errors, most of which are caught by the analyzer. >>>> >>>> --Kyle Sluder >>>> >>>> On Sep 8, 2013, at 11:18 PM, Alex Kac <a...@webis.net> wrote: >>>> >>>>> Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d >>>>> find weird errors that would be caused by some over-released object. We >>>>> cut a ton of code with ARC, and in the end we saw reliability go up and >>>>> actually even some performance. >> >> I think the big point is that if the compiler can figure out what is no >> longer needed and can be released, and the compiler can do this (at a >> reasonable cost to performance), then this is a no brainer. >> >> I'm sure there are special cases where you would want to do your own memory >> management. And in this case, you can always flag the class files to turn >> off ARC and manage memory yourself. >> >> Simply put, not having to worry about this gives more brain stack space to >> fill up with all the other parts of Cocoa and Objective-C that we need to >> keep track of and saves valuable developer time since it's now rare to have >> to deal with manual memory management mistakes. >> >> Cheers, >> - Alex Zavatone >> > > > _______________________________________________ > > 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-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com > > This email sent to d...@looktowindward.com _______________________________________________ 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-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
