|
Lua isn't quite as insanely optimized on ARM as it is on (say) i386, but I don't think it's going to be prohibitively slow.
|
#
¿
Apr 7, 2011 21:43
|
|
|
|
| # ¿ Apr 29, 2024 15:16 |
|
|
samiamwork posted:Lua is optimized for i386? I'm not aware of anything architecture-specific in Lua. Are there optimized branches somewhere or something? The trunk Lua implementation, no, but if you're interested in high-performance Lua there's LuaJIT, which has a very strong argument for being the best dynamic-language implementation in the world.
|
|
#
¿
Apr 9, 2011 20:37
|
|
|
Small White Dragon posted:Hey Clang friends: For the open source project, we're hoping to have C++ '0x, C++ static analysis, and a lot of other things that aren't quite as user-visible like a much-improved exceptions model. I can't talk about future goals for the Apple product, but I will point out that companies contributing to open-source projects often develop crazy new features privately before pushing them to trunk. Like, say, LLVM's ARM backend, which was not contributed until after the iPhone was announced.
|
|
#
¿
Apr 19, 2011 22:20
|
|
|
modig posted:Useless rant: You're absolutely right that that's how it should work, but sadly that's just not how it actually does under the C separate compilation model. #import/#include directives have no idea what runtime libraries are associated with a header file, and even if they did, there's no way for the compiler to collect all that information and present it to the linker.
|
|
#
¿
Apr 23, 2011 21:08
|
|
|
Ender.uNF posted:Also, is there any publicly available information on Objective-C 3? Well, this guy really wants some kind of support for anonymous functions, and while I'm pretty sure we won't rip out blocks if/when we release something called ObjC3, you never know. Otherwise I hope not. 
|
|
#
¿
Apr 24, 2011 04:08
|
|
|
Not if you're not refining the parameter or return types and want callers to use your more accurate signature.
|
|
#
¿
May 15, 2011 02:45
|
|
|
wellwhoopdedooo posted:Oh SNAP you can do that in Obj-C? Yep. Not only you can do the nice covariant-return and contravariant-parameter cases, but you can also do: code:
|
|
#
¿
May 15, 2011 05:18
|
|
|
Zhentar posted:On a similar note, is there some way to do this without a warning (or suppress the warning)? Or would it be better not to do it at all... That's not totally unjustifiable, but I'm not surprised that it's not recognized as an exception to the warning. It's worth filing a bug about.
|
|
#
¿
May 17, 2011 21:48
|
|
|
It's just a constraint you need to deal with. You will not get any callbacks when the loop is complete, or if it's aborted part-way either normally or abnormally.
|
|
#
¿
May 28, 2011 03:33
|
|
|
No, because the default convention for methods is to return at +0, i.e. autoreleased or otherwise held.
|
|
#
¿
May 28, 2011 04:58
|
|
|
You need to read the Cocoa Memory Management Programming Guide.
|
|
#
¿
May 28, 2011 06:16
|
|
|
stray posted:I'm sure you guys get this question all the time, but I couldn't find an answer with search, so here goes. What's the difference between an ivar and a @property? I get that one has setter and getter methods when you @synthesize it, but is that it? There are practical consequences of that — for example, you can use key-value observing to get notified of changes to a property precisely because there are methods to hook — but at a high level, yes, that's it: a synthesized property is just a couple of methods wrapping an ivar, which (by default) has the same name as the property.
|
|
#
¿
Jun 2, 2011 18:13
|
|
|
pokeyman posted:So everyone who can should check out automatic reference counting, because it looks fantastic. It's like fake garbage collection! (I say this based entirely on the commit to the public llvm repository and in no way on anything under NDA.) Just to be clear, ARC itself is no longer under NDA, q.v., so you can run wild.
|
|
#
¿
Jun 16, 2011 06:30
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
Is point a Superclass* with the child method only declared on a subclass? Because you need to cast down to the subclass to make that type-check.
|
|
#
¿
Jun 21, 2011 00:50
|
|
|
You can still make a declaration for it with a category, but if the @interface and method are private to some implementation file then you're almost certainly not supposed to be accessing it.
|
|
#
¿
Jun 21, 2011 17:41
|
|
|
What Xcode are you using, and where are you synthesizing your property? shouldHideToolbar = YES; is accessing the ivar directly, not the @property, for which you would need to do self.shouldHideToolbar = YES.
|
|
#
¿
Jun 22, 2011 05:00
|
|
|
Clang (i.e. LLVM Compiler) supports @autoreleasepool {} independently of ARC.
|
|
#
¿
Jul 27, 2011 18:27
|
|
|
Please file a bug against the documentation; that's old information. The only reason that the recommendation is to release ivars directly instead of using a setter is to avoid problems from subclasses/swizzlers that screw with the setter — well, that and it's a message-send faster. In practice, this is usually only a problem for frameworks/libraries, not for user code. Generally, after an ivar is released during dealloc, you should never access it. If you actually manage that correctly, there's no reason to nil the ivar out, and not doing so saves you some insignificant amount of time.† Contrariwise, the reason to nil the ivar out is to be defensive: you're trying to avoid crashes by hoping that any code which accesses it will behave reasonably with a null value. But avoiding such crashes is not an unmitigated blessing, because avoiding the crash usually means not running code that you probably wanted to run, which means you get subtler bugs. There's no perfectly agreed-upon answer here, but I do have a recommendation: if you're really interesting in provoking crashes on invalid behavior, scribble nonsense into your variables (like (id) 0x12121212) instead of leaving them with their just-released values. † I don't mean this dismissively. It often happens that profiling your code shows something basically flat. That's good, but it doesn't mean you can't improve — it just means that all the easy work is done (or you have a major cost center that's been repeatedly inlined and thus distributed over a lot of different functions). The only way forward is to pick at a hundred tiny things, and the best way to do that is to not need to because you paid attention to small-scale performance when you wrote the code in the first place.
|
|
#
¿
Aug 2, 2011 08:01
|
|
|
Quotation marks are interpreted by the shell, not the kernel. You don't need them if you're splitting your command line up into separate arguments yourself.
|
|
#
¿
Aug 17, 2011 05:43
|
|
|
That would be me. Please note that, while it's always possible that this is a compiler bug, it's much more likely that your code is broken in some way that just happens to not explode on GCC.
|
|
#
¿
Oct 3, 2011 23:34
|
|
|
If you need to use CoreFoundation objects, you'll still have to retain and release those yourself. You'll also have to watch out for reference cycles, which will cause leaks. Otherwise, it's pretty much taken care of for you.
|
|
#
¿
Oct 5, 2011 18:41
|
|
|
DBFT posted:Is there a way of forcing a Framework to load? Right now I'm writing an app using VLCKit and the first time the video playing window shows there is a noticeable delay as the framework is loaded. Is there a reasonable way of forcing the framework to load at an earlier point (while the user is busy doing other things and so won't notice)? Run some code from it; even something like [SomeVLCClass class] should be fine.
|
|
#
¿
Oct 26, 2011 01:28
|
|
|
DBFT posted:[SomeVLCClass class] didn't do it. I need to figure out the least I can do while still getting it to import I guess... Then it's more than just loading the framework; there's probably some heavyweight initialization it has to do the first time it needs to load a video.
|
|
#
¿
Oct 26, 2011 22:02
|
|
|
Sewer Adventure posted:Here's something I learnt today: Yes. And [self superclass] will return the superclass of the dynamic type of self, so neither technically does what you're probably trying to do, which is to get the class object for the superclass of the class you're currently implementing, although -superclass will probably work just fine in typical application code that's never subclassed.
|
|
#
¿
Oct 27, 2011 04:48
|
|
|
pokeyman posted:How does one do this then? I have no earthly reason to do it, but now I'm curious. There's no direct way; you'd have to do something like [NSMySuperClass class].
|
|
#
¿
Oct 27, 2011 19:52
|
|
|
Kekekela posted:Yeah, this seems more like something for someone that actually wants to write iOS or OS X stuff from a PC. I've got an MBA at home for that, I just want something to code-doodle in when I'm at work. Well, Clang builds on Windows if you just want a compiler. I don't know off-hand if anyone's made an ObjC IDE that builds there.
|
|
#
¿
Oct 28, 2011 18:08
|
|
|
10.4 doesn't support blocks; the runtime support just isn't there. I mean, technically there are a couple things you can do with them, like pass them around (but not to any system functions, which do not exist) and never copy them ever, but if you're doing anything interesting at all, you will see failures. If you need to deploy back to 10.4, you must not use blocks. There are workarounds if you really want to pretend that blocks exist there, but the better answer is that 10.4 is a really old OS at this point, and OS upgrades are not that expensive.
|
|
#
¿
Oct 28, 2011 21:52
|
|
|
Making C++ classes inherit from ObjC classes is something that technically GCC lets you do, but only accidentally, and it has never actually worked unless you basically do everything yourself. I mean, your objects won't even get a class pointer, and you certainly can't define ObjC methods on your class, so I am skeptical that this was ever useful for you. Anyway, this is considered old badness, and Clang has never supported it. Your Xcode upgrade probably switched you to using Clang. Technically you can switch back to LLVM-GCC, but please just stop doing this. You really don't have to rewrite the entire world in Objective-C; you can have ivars of arbitrary C++ types (as long as they're default-constructible), you can write arbitrary C++ code in your method definitions, etc. You just can't naively mix the class hierarchies.
|
|
#
¿
Nov 1, 2011 03:17
|
|
|
Is that the "you're using a C++11 feature without turning on C++11" warning? Why don't you just turn on C++11? Otherwise, the Xcode 4.2 compiler should accept -Wno-c++0x-extensions.
|
|
#
¿
Nov 2, 2011 04:47
|
|
|
If the performance of your data structure is really important, you should see whether you can get away with writing it in Objective-C++ and using an STL data structure instead of NSArray. NSArray has something of a jack-of-all-trades design which is not primarily tuned for efficiency, and if nothing else, doing a message send for every access adds up pretty quickly.
|
|
#
¿
Nov 17, 2011 22:10
|
|
|
Sewer Adventure posted:Objective C++ is an abomination, you could just use CoreFoundation arrays if you care about message send overhead. I'm not trying to start a holy war about languages here. There are plenty of good reasons to use NSArrays, and most programs are not going to be noticeably limited by their performance. If you find that you are, though, moving to CFArray is not a significant change. CFArrays have the same not-particularly-optimal internal structure as NSArrays, and turning a message-send into a call is an improvement but not a major one. They also both force you to use ObjC/CF objects as the elements of your array, which is either totally fine or a major boxing/unboxing overhead, depending on what you're doing. Sewer Adventure posted:That way you get the added bonus of toll-free bridging. Toll-free bridging is not a bonus? I mean, don't get me wrong, it's a good thing that NSArrays and CFArrays are interchangeable, but it's not like it's some crazy feature that makes CFArray totally awesome. It's just the absence of what was previously a serious interoperability problem. If you don't need interoperability, and you're comfortable with C++ (which it's okay not to be!), and the performance matters, std::vector really is a significant upgrade.
|
|
#
¿
Nov 17, 2011 23:25
|
|
|
Sewer Adventure posted:Well the reason you cited was "message send overhead". "NSArray has something of a jack-of-all-trades design which is not primarily tuned for efficiency, and if nothing else, doing a message send for every access adds up pretty quickly." There's a lot of other overhead in NSArray; none of it is huge, but it all contributes. For example, all array accesses are bounds-checked and mutable arrays are actually deques. Will doing bounds checks or using a deque where you could have used a vector completely kill the performance of your application? Obviously not. Does it have an impact? Yes. Sewer Adventure posted:It's something you don't get from C++ arrays. You would have to write a bunch of code to convert your C++ arrays if you wanted to use them with UITableViews, for example I don't know why it would be more difficult to implement UITableViewDataSource in terms of a C++ vector than in terms of an NSArray. But yes, I did say that using a vector would really only be appropriate if you didn't need to pass it off as an NSArray*/CFArrayRef. Sewer Adventure posted:and you'd have to deal with the memory management yourself rather than rely on ARC. ARC should work just fine in Objective-C++. For optimal efficiency, you'd want to use C++11 and libc++ (because __strong objects can be efficiently moved), but it certainly works even in '03 or with libstdc++. Sewer Adventure posted:The performance of ObjC structures is perfectly fine, and there's absolutely no reason you would need anything else. I think the fact that none of the standard iOS apps (all of which perform great) use ObjC++ is a testament to this. ...which standard iOS apps are you referring to here? Because Safari/WebKit/UIWebView is a mix of ObjC++ and pure C++, and without breaking confidentiality I can tell you that I see a *lot* of ObjC++ code in the wild. And again, I will point out that I really don't think that container performance is going to be a noticeable overhead for the vast majority of code. The only place I can imagine it really mattering is if using an NSArray forces you to unnecessarily box up a ton of objects.
|
|
#
¿
Nov 18, 2011 04:00
|
|
|
Sewer Adventure posted:Webkit is legacy code (KHTML) that had been written in C++ from the beginning. Everyone I know that works on WebKit, including a lot of its technical leadership, would laugh you out of the room for suggesting that their use of C++ is simply a legacy holdover and that they'd be happier if it were written exclusively in Objective-C. Defining WebKit out of your sample is silly, because WebKit is one of only a few standard apps that both (1) actually has to work with large amounts of data and (2) cares about the speed of access to them. Stocks could hold its monitored ticker symbols in a linked list and do O(n^3) work on every UI refresh and it would be hardly one user in a million who ever even noticed a slowdown. The size of a typical address book is dwarfed by the number of DOM nodes on google.com. Mail is the only real competitor here, and Mail has serious performance problems with large mailboxes, although I doubt that has anything to do with NSArray. Again, I am not disputing and never did dispute that the Objective-C containers are perfectly fine for the vast majority of code. Their performance is sub-optimal but not indecently so, and even if they were unspeakably terrible, most code in the world has no serious performance constraints and only runs into problems due to poor choices at levels far above the choice of container implementation.
|
|
#
¿
Nov 18, 2011 06:25
|
|
|
y_y posted:This is still rather misleading, I'd wager that the container classes are optimized to be reasonably close to optimal given the restrictions and design choices they're under (e.g. dynamic dispatch, switching internal representations for NSMutableArray, etc.). They just do so much extra stuff that you may or may not need / want, that something else might be more appropriate for your usage. That's a fair assessment. I didn't mean to suggest that the container classes were particularly poorly implemented given their constraints. Incidentally, looking over the implementations some more, I would caution people (again, I mean people who care about this level of performance) against trying to access NSArrays with CF function calls; the CF functions will just turn around and do a message send when they detect an Objective-C object anyway. I think that article is quite a bit out of date; NSMutableArray seems to be a pretty standard deque now. Sewer Adventure posted:The only reason it is in C++ is because it started in C++. If Apple started a web renderer from scratch it would be in Objective C. Okay, look, I appreciate that you have a lot of loyalty to Objective-C and want to defend it against what you perceive as my unfair slights, but you are not actually contributing anything here besides unsubstantiated claims.
|
|
#
¿
Nov 19, 2011 01:21
|
|
|
ManicJason: See, there are good reasons why ARC just does that for you automatically. Zhentar posted:Are there any published ARC performance comparisons? I'm doing some investigation to convince my team to switch our project over to ARC, and it would be helpful if I had some measurements to address any concerns in that area. We have some internal data that I can't share, unfortunately. I can tell you that some people have seen respectable speedups, which honestly always surprises us, because we were really aiming for "not a significant performance regression". Apparently, insane amounts of stuff end up in the autorelease pool in a typical MRC program. Zhentar posted:Edit: has anyone else found the version of the static analyzer shipped with XCode 4.2 to give really poor results? Telling people "the compiler is smart enough to know when retain and release are needed!" would probably be a lot easier if the analyzer weren't giving us a hundred or so obviously incorrect memory management warnings Just to be clear, ARC and the static analyzer use totally different approaches. The static analyzer tries to track the flow of data through your code and flag things that it feels confident would be bugs if you were following the Cocoa conventions. It's kindof nice and fluffy to think of ARC as simply enforcing that analysis, i.e. inserting retains and releases where otherwise the static analyzer would warn. That could never actually work, though; the static analyzer is heuristic and intraprocedural, and all of its limitations (many of them inherent) would potentially turn into memory bugs. Instead, ARC emits code to enforce local rules like "this variable has an invariant of owning a +1 on the object it points to" and "we got a +1 value back, so we'd better release that at some point soon." Releasing an ivar is a good example of a place where the static analyzer has no idea and just has to assume you know what you're doing.
|
|
#
¿
Dec 26, 2011 06:35
|
|
|
Small White Dragon posted:So, rjmccall, when can we expect C1X support in Clang? Anything you're looking at in specific? Some things, e.g. _Atomic, are at least partially implemented in ToT and will therefore someday appear in a release near you. I haven't been following that standard very closely, I'll admit. Toady posted:I have to admit that I'm disappointed that the language in the documentation makes it sound as if garbage collection won't see further development. In spite of its drawbacks, I enjoyed the simplified accessors and lack of bridging casts between Objective-C and plain C code. I can say that the need for pervasive bridging casts in ARC is a known problem that we want to work on.
|
|
#
¿
Dec 28, 2011 05:01
|
|
|
|
| # ¿ Apr 29, 2024 15:16 |
|
|
The compiler should really be warning about that, sorry.
|
|
#
¿
Jan 24, 2012 05:41
|
|