4 ms·
> you still can't figure out what methods a class has in the IDE. Maybe I don't understand what you mean but isn't that just an XCode auto-completion feature?
by chime 16y ago
> you still can't figure out what methods a class has in the IDE.
Maybe I don't understand what you mean but isn't that just an XCode auto-completion feature? Do you mean you can't see which methods belong to the class and which are inherited?
> It has some kind of 'automatic memory management'
Initially I was not too impressed by the alloc/retain/release/autorelease parts of Obj-C but now that I grok the concept well, I think it's awesome. I'm only coding for iOS devices but my understanding is that for OSX, there is a stable GC system. On iOS, you manage the memory yourself. I would have liked to not worry about memory at all but it's not a big deal after all. If you alloc/copy something, make sure you release it.
- fleitz 16y agoI mean the intellisense (autocomplete + docs + method signature) in xcode blows chunks compared to Visual Studio or even Eclipse. Lots of things individually in Obj-C/Xcode are minor annoyances, but when you add them all together it's a very annoying toolchain. Comparing the UI/Polish in Apple products to Microsoft products, I figured that XCode would be one of the best dev environments ever. I think it's one of the worst. It's not that any of the issues are insurmountable, I'd just rather not deal with them.
- madmoose 16y agoYes, it currently does suck. Thankfully the next version will intelligently incorporate Clang/LLVM which will improve the situation vastly.
- yardie 16y agoCompletely agree about the autocomplete and documentation in XCode. It's a complete waste and for a company that spends a lot of time focusing on snappy UIs I don't understand why its so slow...and stupid. The one redeeming quality is that Instruments and the tools package is quite nice. Our company pays good money to get the same level of software for visual studio.
- ido 16y agoI mean the intellisense (autocomplete + docs + method signature) in xcode blows chunks compared to Visual Studio or even Eclipse. That last sentence left me puzzled, seeing as how eclipse has much better "intellisense" for java than VS does for c++ & c# (at least out of the box - resharper brings it close to eclipse-levels with c#).
- scotth 16y agoAgree 100%. And if for whatever reason Resharper isn't available to you, then check out the Productivity Power Tools. They'll take you in the Eclipse direction. Not all the way, mind you, and they're buggy, but it's helpful nonetheless.
- limmeau 16y agoTo me, not familiar with ObjC/OSX memory management, the last sentence reads like "...it's not a big deal after all. If you malloc/fopen something, make sure you free/fclose it." Could you explain the difference?
- Leynos 16y agoRather than being responsible for ultimately disposing of an object, they need only tell the runtime that it is no longer needed. A retain count (a count on other parties with an interest in an object) is maintained by the runtime. When the retain count reaches zero, the object is freed. When an object is created (using alloc or copy), it has a retain count of 1. Another object can express its interest by calling the "retain" method. When it is done, the "release" method should be called. If an object is being returned, but shouldn't be freed right away, there is a mechanism called "autorelease" where the call to release is delayed until the end of the current runloop, giving other objects a chance to retain the returned object.
- blub 16y agoThis is almost as prone to failure as malloc/free, you still have to call functions by hand.
- Leynos 16y agoIndeed. I've become quite enamoured of late with the automatic reference counting in the Boost C++ library as a happy medium between GC and manual reference counting. Of course, ObjC has no static allocation, so that can't be done here.
- pornel 16y agoIf find it much easier than malloc/free. Cocoa uses autorelease pool for short-lived objects, so most of the time you don't have to free them. For long-lived objects you can use synthesized properties which handle retain/release for you. In other cases you "guard" your use of object with retain/release. You can use these in pairs in the same place, rather than having malloc() in one part of the program, and free() in another. You can freely pass reference to an object without worrying that you might free it while it's still referenced somewhere else. You don't have to think about ownership of an object.