|
rjmccall posted:Just to be clear, ARC itself is no longer under NDA, q.v., so you can run wild. Awesome! Run wild I shall.
|
#
?
Jun 16, 2011 07:58
|
|
|
|
| # ? May 16, 2024 21:03 |
|
|
rjmccall posted:Just to be clear, ARC itself is no longer under NDA, q.v., so you can run wild.
|
|
#
?
Jun 16, 2011 09:39
|
|
|
rjmccall posted:Just to be clear, ARC itself is no longer under NDA, q.v., so you can run wild. Interesting, but it looks to me like a "solution" to a nonexistent problem that only serves to increase complexity. Memory management is very simple and straightforward to begin with. This doesn't seem to take it to the point of "you can just ignore it" (ie. nothing to worry about), but rather to the point of "the compiler is going to do 90% of it for you, but you still have to be aware of managing your memory AND you'd better keep track of what 'magic' the compiler is and isn't doing for you" (ie. just one more thing to worry about). If I'm wrong, please do enlighten me.
|
|
#
?
Jun 16, 2011 12:18
|
|
|
Choadmaster posted:Interesting, but it looks to me like a "solution" to a nonexistent problem that only serves to increase complexity. The most obvious existent problem this helps solve is the lack of garbage collection on iOS. quote:Memory management is very simple and straightforward to begin with. Yet it's surprisingly hard to consistently do right, and is frequently a source of confusion for newcomers to the platform. (See the number of tired repostings of the memory management guide in this and previous threads.) It's not clear to me whether someone could soon write a nontrivial iOS/OS X app without writing a single retain. Like you point out, I'm not sure how much of an advantage it is to go from "always retain/release/autorelease like this" to "well sometimes you have to add this in here but normally it's ok". If we can somehow get all the way to "don't worry about it", that sounds ideal. (Also, reading the ARC document on the Clang site, I wonder if this is what rjmccall had in mind during the earlier discussion on exceptions...)
|
|
#
?
Jun 16, 2011 13:03
|
|
|
edit: never mind
LP0 ON FIRE fucked around with this message at 09:16 on Jun 17, 2011 |
|
#
?
Jun 16, 2011 15:59
|
|
|
Choadmaster posted:Interesting, but it looks to me like a "solution" to a nonexistent problem that only serves to increase complexity. Memory management is very simple and straightforward to begin with. Simple to begin with, complicated as application complexity increases. If memory management was so easy and straightforward, no applications would ever crash or leak memory. ARC attempts to remove the burden of managing object lifetimes from the programmer. It also introduces tools like zeroing weak references. pokeyman posted:It's not clear to me whether someone could soon write a nontrivial iOS/OS X app without writing a single retain. Xcode has been garbage-collected for years. I moved my project to ARC with ease. If you've been spoiled from writing code under GC, it's the same kind of convenience. If you've only ever used traditional reference counting, removing your dealloc methods will be cathartic. I believe automated memory management is an inevitable future for most application development. In fact, ARC is turned on by default for new projects. Toady fucked around with this message at 18:29 on Jun 16, 2011 |
|
#
?
Jun 16, 2011 18:09
|
|
|
I haven't looked at the ARC stuff too closely, but if there are no dealloc methods then how do you clean up when your object goes away?
|
|
#
?
Jun 16, 2011 18:43
|
|
|
Doc Block posted:I haven't looked at the ARC stuff too closely, but if there are no dealloc methods then how do you clean up when your object goes away? It's magic of course :P
|
|
#
?
Jun 16, 2011 18:51
|
|
|
Small White Dragon posted:So can you talk about what else is in the new version of Clang, yet? It's all open-source now, so if you're really burning to learn about the new instruction scheduler, I... can drag up someone who knows something about it? pokeyman posted:(Also, reading the ARC document on the Clang site, I wonder if this is what rjmccall had in mind during the earlier discussion on exceptions...) I've had this in mind for a lot of these discussions.  Choadmaster posted:Interesting, but it looks to me like a "solution" to a nonexistent problem that only serves to increase complexity. Memory management is very simple and straightforward to begin with. This doesn't seem to take it to the point of "you can just ignore it" (ie. nothing to worry about), but rather to the point of "the compiler is going to do 90% of it for you, but you still have to be aware of managing your memory AND you'd better keep track of what 'magic' the compiler is and isn't doing for you" (ie. just one more thing to worry about). So, first off, it's important to note that ARC is completely opt-in, and it's interoperable with manual reference-counting (MRC) as long as you follow the conventions on everything you touch from ARC, so you can totally ignore it if you personally never have any problems with memory management. Even if you use someone else's ARC code, you can just enable ARC for those specific files and leave the rest of your project alone. (You might have to add -fobjc-arc to your linker flags.) That said, while you're right that ARC does not completely free you from having to think about memory management in all cases, I think you are approaching it from a very procedural perspective. The specification has to describe it that way, because it really does have to be implemented in those terms, but that's not necessarily the best way to think about things. Consider it instead in terms of your object graph. ARC maintains the invariant that a strong variable (and they're all strong by default) always retains what it points to. If you've got a strong variable sitting around, you know the object in it is still valid to use, period. The only reason you should need to think about it further is when you realize you have a retain cycle and need to break it. Doc Block posted:I haven't looked at the ARC stuff too closely, but if there are no dealloc methods then how do you clean up when your object goes away? ARC destroys __strong and __weak instance variables at the same time that it would call the destructors of C++ instance variables, which is basically during -[NSObject dealloc]. You can still write dealloc methods in ARC if you need to; they're just not required for ivars, and [super dealloc] is called implicitly at the end.
|
|
#
?
Jun 16, 2011 19:22
|
|
|
Doc Block posted:I haven't looked at the ARC stuff too closely, but if there are no dealloc methods then how do you clean up when your object goes away? "It just works"  The dealloc method still exists, it's just getting filled in by the compiler instead of you having to actually write it out explicitly. It's a bit like if the compiler ran static analysis on your source and then fixed all the problems it found instead of throwing up analyzer messages.
|
|
#
?
Jun 16, 2011 19:25
|
|
|
rjmccall posted:ARC destroys __strong and __weak instance variables at the same time that it would call the destructors of C++ instance variables, which is basically during -[NSObject dealloc]. You can still write dealloc methods in ARC if you need to; they're just not required for ivars, and [super dealloc] is called implicitly at the end. Thanks, good to know. baronmasochist posted:"It just works" Yeah, I knew the compiler would clean up your ivars and whatnot, my curiosity was just more along the lines of how do you clean up an object with cleanup requirements beyond just calling release on some things if there's no dealloc method in ARC. but rjmccall answered that, so evidently you can still have dealloc if you need it. Doc Block fucked around with this message at 21:07 on Jun 16, 2011 |
|
#
?
Jun 16, 2011 20:37
|
|
|
I guess this is sort of a design/philosophy question. I have an object GCAge with a number of subclasses. One subclass is GCSimpleAge which basically contains a NSDateComponents (for years/months/days so I can do math with them) + some methods for writing out the info in various formats. Others are GCAgeKeyword (for things like "infant", "stillborn", etc). The data I'm building my objects from also contains "qualified" ages, such as "> 10y" (more than 10 years old) or "< STILLBORN" (though that doesn't really make sense, it's legal per the spec of the data format). I've currently implemented another GCAge subclass, GCQualifiedAge, with a convenience constructor like so (from the .h file): code:Edit: Are there any good blogs/books on how to best write Cocoa-like Objective-C? I seem to come up against this sort of thing often, where I'm writing something, and it just doesn't seem very Cocoa... Probably due to mostly doing Java and Python at work, and not really knowing what I'm doing in Cocoa (though Hillegass' book was great at teaching the fundamentals). Carthag Tuek fucked around with this message at 21:37 on Jun 16, 2011 |
|
#
?
Jun 16, 2011 21:20
|
|
|
Doc Block posted:Yeah, I knew the compiler would clean up your ivars and whatnot, my curiosity was just more along the lines of how do you clean up an object with cleanup requirements beyond just calling release on some things if there's no dealloc method in ARC. but rjmccall answered that, so evidently you can still have dealloc if you need it. Correct, you can override -dealloc and do your special cleanup. As was said, you don't do [super dealloc] anymore.
|
|
#
?
Jun 16, 2011 23:33
|
|
|
Edit- Problem solved
Jort fucked around with this message at 00:26 on Jun 17, 2011 |
|
#
?
Jun 17, 2011 00:21
|
|
|
Carthag posted:Edit: Are there any good blogs/books on how to best write Cocoa-like Objective-C? I seem to come up against this sort of thing often, where I'm writing something, and it just doesn't seem very Cocoa... If you have a developer account, check out some videos from past (especially 2010) WWDC sessions. Many sessions are quite full of sample code that's written Cocoa-like, and there are even sessions specifically about making your code Cocoa-like. (One that comes to mind is a session last year that was about how Cocoa methods are named.)
|
|
#
?
Jun 17, 2011 00:22
|
|
|
pokeyman posted:The most obvious existent problem this helps solve is the lack of garbage collection on iOS. ... If we can somehow get all the way to "don't worry about it", that sounds ideal. The solution to that is, of course, garbage collection. That may still be a year or two out, but i'm sure it'll come before too long (well, maybe not if ARC is all it's cracked up to be!). pokeyman posted:Yet it's surprisingly hard to consistently do right, and is frequently a source of confusion for newcomers to the platform. (See the number of tired repostings of the memory management guide in this and previous threads.) The problem here is that newcomers still have to understand memory management in this case. And they have to keep track of what the compiler is doing for them and figure out when to manually do it instead, rather than just learning to do it properly to begin with. I fear it'll end up being just another point of confusion, and we'll end up with newbies that treat it like GC, thinking they have nothing to worry about, and end up loving poo poo up unknowingly (kind of like how they sometimes assume "autorelease" is some GC like magic and they should just autorelease everything all the time). Toady posted:Simple to begin with, complicated as application complexity increases. If that's the case, you're doing it wrong. You generally shouldn't be thinking beyond the local scope (your method or class) anyway. "Do I have ownership of this object here? Do I need ownership of this object?" What the rest of your hugely complex app may or may not do with that object should be none of your concern. Toady posted:If memory management was so easy and straightforward, no applications would ever crash or leak memory. ARC attempts to remove the burden of managing object lifetimes from the programmer. People do forget things from time to time, but the static analyzer is usually pretty good about catching those mistakes now. Certainly, I would think anything ARC can be aware of, the static analyzer could be made to catch, as well. The problem as I see it is ARC doesn't free the programmer from worrying about memory management; it may take a lot of the grunt work away (which is great, don't get me wrong), but the programmer still has to be aware of their object lifetimes after all. Toady posted:Xcode has been garbage-collected for years. I moved my project to ARC with ease. If you've been spoiled from writing code under GC, it's the same kind of convenience. If you've only ever used traditional reference counting, removing your dealloc methods will be cathartic. I believe automated memory management is an inevitable future for most application development. In fact, ARC is turned on by default for new projects. I'm just worried this may cause more confusion for many people in the long run than it is worth. I guess I'm thinking more about how it'll impact people new to Objective-C who have little understanding of memory management. I hadn't even heard of ARC until last night, so maybe I'm way off base here . It certainly sounds like it can be a great effort saver if you know what you're doing; I will definitely try it out when I get a Lion- or iOS 5-only project.
|
|
#
?
Jun 17, 2011 01:42
|
|
|
Choadmaster posted:People do forget things from time to time, but the static analyzer is usually pretty good about catching those mistakes now. Certainly, I would think anything ARC can be aware of, the static analyzer could be made to catch, as well. The static analyzer is not a panacea; it's pretty awesome, but it's also worst-case exponential time, which means that in practice it just has to give up and stop analyzing paths at some point. It also has to be conservative about things it doesn't understand, because people just stop using tools that lean the other way. Choadmaster posted:I will definitely try it out when I get a Lion- or iOS 5-only project. Incidentally, you can use it in current environments if you're willing to live without weak references.
|
|
#
?
Jun 17, 2011 03:23
|
|
|
Choadmaster posted:The solution to that is, of course, garbage collection. That may still be a year or two out, but i'm sure it'll come before too long (well, maybe not if ARC is all it's cracked up to be!). Chris Lattner posted this to the objc-language mailing list: The primary advantage of GC over ARC is that it collects retain cycles. A secondary advantage is that "retained" assignments are "atomic" because they are a simple store. ARC has several big advantages over libauto GC: 1. It has deterministic reclamation of objects (when the last strong reference to the object goes away) where GC frees an object "sometime later". This defines away a class of subtle bugs that can exist in GC apps that aren't exposed because the collector doesn't trigger "in the buggy window". 2. The high water mark is generally much lower with ARC than GC because objects are released sooner. 3. libauto provides a fragile programming model, you have to be careful to not lose write barriers etc. 4. not all of the system frameworks are GC clean, and the frameworks do occasionally regress as they evolve. 5. ARC doesn't suffer from false roots. libauto conservatively scans the stack, which means that integers that look like pointers can root object graphs. 6. ARC doesn't have anything that kicks in and stops your app, causing UI stutters. libauto is pretty advanced as far as GC implementations go because it doesn't immediately stop every thread, but it still does usually end up stopping all the UI threads. quote:If that's the case, you're doing it wrong. You generally shouldn't be thinking beyond the local scope (your method or class) anyway. "Do I have ownership of this object here? Do I need ownership of this object?" What the rest of your hugely complex app may or may not do with that object should be none of your concern. I'm referring to relatively common memory management bugs like retain cycles, dangling weak references, and so on. quote:The problem as I see it is ARC doesn't free the programmer from worrying about memory management; it may take a lot of the grunt work away (which is great, don't get me wrong), but the programmer still has to be aware of their object lifetimes after all. You treat objects in terms of ownership. You get a compiler error if you try to retain or release.
|
|
#
?
Jun 17, 2011 03:27
|
|
|
I do most of my development at work in VB6, which pretty much has ARC without zeroing weak references. I'd say about 90%-95% of developers don't understand the retain cycle limitation. Some of those reasonably could understand it but haven't learned because we so rarely encounter leaks. The misunderstanding mainly shows up with people trying to break retain cycles within the object's destroy/dealloc method (although it could also be behind the strange VB obsession with setting local variables to Nothing before they fall out of scope).
|
|
#
?
Jun 17, 2011 04:34
|
|
|
I have a question about scheduling updates. I am using 2 scheduled updates, which will automatically unschedule and reschedule themselves based on a method within the scheduled function. I say this so you understand the schedules are fairly random. I am trying to compare the time since last scheduled update ran. ie: If schedule A has run within the last 0.5 seconds, delay schedule B by whatever amount of time it takes for it to be 0.6 seconds since schedule A ran. I need to do this for both schedule A and B, which are both random. Is there a way to check how long since a scheduled event ran? Is there a way to add the necessary delay to a scheduled event based on the amount of time since another scheduled event ran? Is there a way to check how long until the next scheduled event will run from the current point in time? What I am doing here is spawning objects at 2 places, which move horizontally across the screen. I need there to be at least 0.6 seconds between items on opposite planes (top/bottom), in order to allow my player (sprite) to be able to fit into the space between the sprites. It is ok to spawn 2 items really close on the same plane, but opposite planes need some spacing. ModeSix fucked around with this message at 07:25 on Jun 17, 2011 |
|
#
?
Jun 17, 2011 07:23
|
|
|
pokeyman posted:If you have a developer account, check out some videos from past (especially 2010) WWDC sessions. Many sessions are quite full of sample code that's written Cocoa-like, and there are even sessions specifically about making your code Cocoa-like. (One that comes to mind is a session last year that was about how Cocoa methods are named.) Thanks, I just signed up for a free one. I guess the "Session 138 - API Design for Cocoa and Cocoa Touch" video is the one you're talking about?
|
|
#
?
Jun 17, 2011 08:01
|
|
|
Carthag posted:Thanks, I just signed up for a free one. I guess the "Session 138 - API Design for Cocoa and Cocoa Touch" video is the one you're talking about? Yup, and that's definitely not the first time I got the name horribly wrong.
|
|
#
?
Jun 17, 2011 08:55
|
|
|
Choadmaster posted:Interesting, but it looks to me like a "solution" to a nonexistent problem that only serves to increase complexity. Memory management is very simple and straightforward to begin with. This is the most laughable thing I've ever read concerning writing software, anywhere, ever. A huge long history of nearly every non-trivial application people use having memory leaks, exploitable buffer overflows, et al proves this false. When you trust programmers to "do the right thing" they will inevitably fail, either through malice, ignorance, incompetence, or plain ol' human error. Frankly, if ARC encourages people to avoid problematic designs because they don't understand how to make the compiler shut up when they violate the ARC rules I'd count that as a net win. Choadmaster posted:The solution to that is, of course, garbage collection. That may still be a year or two out, but i'm sure it'll come before too long (well, maybe not if ARC is all it's cracked up to be!). The problem here is that newcomers still have to understand memory management in this case. Doubtful. Unless you ignore backwards compatibility and make some safe guarantees about what is and isn't a reference (see C#, Java, et al), then you will always have a sub-par GC because you can't compact so you end up with memory fragmentation issues. The desktop GC gets away with ignoring this problem by just using more memory. I might add that when you start mixing in C-style function calls into a GC environment you have to be aware of object lifetimes same as with ARC. In fact when you P/Invoke to native code from C# or drop into unsafe{} you had better be aware of that too. (Linq can also have side-effects as a result of lazy evaluation that you should known about). I don't see how ARC is any different in that regard... in fact I just fixed a Linq bug that was caused by a try/finally tearing down some state in the finally block that the try block used in a Linq query, which thanks to deferred execution caused a failure later in the program because the finally executed before the Linq lambda did. That doesn't mean people should abandon the compiler magic that makes Linq and lambdas work. The point is that ARC reduces the amount of boilerplate code you need to write. Since every line of code written is the potential for a new bug, anything that reduces the number of lines you need to write is a net win.
|
|
#
?
Jun 18, 2011 01:49
|
|
|
Ender.uNF posted:This is the most laughable thing I've ever read concerning writing software, anywhere, ever. A huge long history of nearly every non-trivial application people use having memory leaks, exploitable buffer overflows, et al proves this false. I didn't say it was foolproof. I said it seemed to me that human error is might simply be amplified when people start thinking they can ignore those altogether because they think the compiler is going to handle it all for them - when in fact they DO still need to be aware of the memory management rules AND (now) where the compiler can and can't handle it properly. I also acknowledged I had zero actual experience with it, and flat-out asked more experienced people to comment on my speculations. No need to be a pompous dickwad about it.
|
|
#
?
Jun 18, 2011 03:22
|
|
|
For what it's worth, I think your worries are totally reasonable; every advance has second-order effects as people adjust to the new world, and sometimes those can wipe out a lot of the good that the "advance" was supposed to bring. Where we disagree is that I believe the second-order response you're afraid of, that people stop thinking about memory management and assume the compiler will take care of it all magically for them, leads to a state that's not really all that bad: they might have some race conditions because loads and stores in ARC aren't implicitly atomic, and they might have some retain cycles because variables in ARC default to being strong references. Both are problems that can easily come up even when you're thinking reasonably carefully about memory management, the race condition would probably be a problem even in a GC'ed environment, and neither requires a particularly intricate understanding of the mechanics of retain/release to understand or fix — certainly far less intricate than a retain/release programmer needs to have today. So I am not that worried.
rjmccall fucked around with this message at 05:27 on Jun 18, 2011 |
|
#
?
Jun 18, 2011 05:23
|
|
|
Choadmaster posted:I didn't say it was foolproof. I said it seemed to me that human error is might simply be amplified when people start thinking they can ignore those altogether because they think the compiler is going to handle it all for them - when in fact they DO still need to be aware of the memory management rules AND (now) where the compiler can and can't handle it properly. I also acknowledged I had zero actual experience with it, and flat-out asked more experienced people to comment on my speculations. No need to be a pompous dickwad about it. Well I think an objective observer would tag the statement that memory management is easy to be at best naive and I think it rubbed a lot of people the wrong way. I'm not trying to be a dick. I also pointed out a situation where compiler magic led to a bug, but that bug exists whether I manually manage memory or not. People will adjust and the odds that they weren't leaking memory before or weren't exposing exploitable holes is very small if the rules of ARC are that confusing to them. Simulated fucked around with this message at 06:05 on Jun 18, 2011 |
|
#
?
Jun 18, 2011 06:01
|
|
|
Choadmaster posted:I didn't say it was foolproof. I said it seemed to me that human error is might simply be amplified when people start thinking they can ignore those altogether because they think the compiler is going to handle it all for them - when in fact they DO still need to be aware of the memory management rules AND (now) where the compiler can and can't handle it properly. Historically, compiler decisions have ended up being a net win, often beating out programmer decisions. In the worst case, you have the same issues that you already had with retain/release. However, that hasn't been my experience with ARC, even in prerelease form. Ender.uNF posted:Well I think an objective observer would tag the statement that memory management is easy to be at best naive and I think it rubbed a lot of people the wrong way. I'm not trying to be a dick. Admittedly, I was little miffed to be told I was "doing it wrong" for pointing out that memory management is not always an easy, straightforward process as application complexity increases.
Toady fucked around with this message at 03:19 on Jun 19, 2011 |
|
#
?
Jun 19, 2011 03:14
|
|
|
edit: nevermind, continue
|
|
#
?
Jun 19, 2011 05:32
|
|
|
What's the trick to getting nice clean numbers to appear in UITextFields? I'd like to set a digit limit, then get results like: 1234.5 12.432 13 14.002 0.001 So things like: - max 3 decimal places - drop decimals of zero - close enough? be an int - max digit limit drops decimals This is just for display. Is there an easy trick I'm missing, or do I need to start messing with the [NSNumber stringValue]? I want to completely eliminate the ellipsis from being shown.
|
|
#
?
Jun 20, 2011 00:06
|
|
|
You may want to look at the NSNumberFormatter class.
|
|
#
?
Jun 20, 2011 01:07
|
|
|
Flobbster posted:You may want to look at the NSNumberFormatter class. Brilliant, thanks.
|
|
#
?
Jun 20, 2011 14:00
|
|
|
Dudes! My customer in Hong Kong wants to test the IAP of my game; we're developing it in the UK. I didn't think there was any way to test IAP in the sandbox environment without running a debug build, which obviously I can't do because of... geography. Is there a way to test IAP in adhoc builds?
|
|
#
?
Jun 20, 2011 15:56
|
|
|
Akuma posted:Dudes! My customer in Hong Kong wants to test the IAP of my game; we're developing it in the UK. I didn't think there was any way to test IAP in the sandbox environment without running a debug build, which obviously I can't do because of... geography. Is there a way to test IAP in adhoc builds?
|
|
#
?
Jun 20, 2011 19:37
|
|
|
SecondConf (Chicago iOS/Mac conference) registration opened this morning and tickets are selling out fast. http://secondconf.com
|
|
#
?
Jun 20, 2011 22:42
|
|
|
I hate warnings, and I have this one that's been bugging me on a conditional in a class that's subclassed: if( [[point child] isEqual:node] ) { "No '-child' method found" Any easy way to get rid of it?
|
|
#
?
Jun 20, 2011 23:17
|
|
|
Are you including the subclass headers where you're using -child?
|
|
#
?
Jun 20, 2011 23:59
|
|
|
Carthag posted:Are you including the subclass headers where you're using -child? I'm including the header of the subclass in the class I'm using it with if that's what you're asking.
|
|
#
?
Jun 21, 2011 00:08
|
|
|
NOG posted:I hate warnings, and I have this one that's been bugging me on a conditional in a class that's subclassed: Is the child method declared in the @interface? edit: whoops, brain fart Larry Horseplay fucked around with this message at 00:19 on Jun 21, 2011 |
|
#
?
Jun 21, 2011 00:13
|
|
|
NOG posted:I'm including the header of the subclass in the class I'm using it with if that's what you're asking. Yeah that's what I meant. Really the only thing I can think of, sorry.
|
|
#
?
Jun 21, 2011 00:35
|
|
|
|
| # ? May 16, 2024 21:03 |
|
|
NOG posted:I'm including the header of the subclass in the class I'm using it with if that's what you're asking. Is the class @interface defined in that header? Or in the .m file?
|
|
#
?
Jun 21, 2011 00:42
|
|
