kaleberg":2opufi88 said:
Did they ever get NSArray to work? I tried using XCode and just creating an empty application that allocates and releases an empty NSArray caused an application crash. I wound up writing my own array code just as I did back in the 60s on an IBM 1130. So much for progress. XCode also has the annoying habit of becoming unable to build an application due to an update or inhaling while breathing between 0 and 90 degrees latitude, north or south as best I can tell. This requires tediously creating a new application and moving modules using cut and paste from your old working version to create a new working version. I'm amazed anyone can use this thing at all.
NSArray works, has worked for getting on for 20 years and is used in 1000s of applications by millions of people every day.
Does Apple plan to support XCode in the forseeable future? That might be news.
Considering they write all their software (including the OSs) in Xcode, and have just released a major update, I don't see why they would even consider dropping it.
Xavin":2opufi88 said:
Entegy":2opufi88 said:
JPan":2opufi88 said:
Errors in code are flagged while you type, and the system even offers suggestions on how best to fix them;
I always forget how far behind C/C++ development is behind Java. Eclipse has done this for Java since I can think.
Isn't that more on the IDE and not the language itself? I still hold Visual Studio in high regard for its error correcting/IntelliSense
The actual implementation of code completion and immediate errors is the IDE, but the design of the language is a huge factor in what the IDE can actually figure out in real time. Providing high quality realtime information about the code like VS does for C# requires very deep integration with the compiler, too.
It largely depends on the compiler to a degree. The reason why Xcode has been lacking, and why C/C++ dev environments in general are often seen lacking, is due to compilers, or more specifically GCC. It's GPL based and not designed to be an API (so can't be integrated easily), is slow, bloated and has crap error messages. LLVM/Clang changes much of that, by being designed to be modular, is fast, lean and knows a massive amount about your code. Whereas GCC knows something went wrong somewhere in a few line range, LLVM knows the exact character that is wrong, points to it and gives you a nice, clear error message.
In previous versions of Xcode, there was GCC for compiling and then internal parsers for handling syntax highlighting, refactoring, code completion etc. GDB also had it's own language parser. This led to large disconnects between the 3, especially as when a new language feature was added 3 parsers needed updating. With Xcode 4, Clang is the parser for the compiler (LLVM), syntax highlighting, refactoring, code completion, error checking/fixing and also for LLDB. This means they can focus on one parser, and even better than one parse is the one that is guaranteed to be the most accurate: the compiler parser.
That said, it is true that the language can play a large role. C#, like Java, is a strongly typed language, which means it is much easier to reason about prior to, and at, compile time. This allows for some very powerful tools. Objective-C, like Ruby or Python, is a weakly typed, highly dynamic language, which means it is near impossible to fully reason about until runtime. You can get a long way though, and static typing in Obj-C helps you find many silly errors. Of course, while you do lose the ability to produce quite as high quality tooling, you do gain in that you can often do the same thing with far less code. Ultimately it's the pros and cons of strong vs weak/dynamic typing and each developer has their own preference.
frej":2opufi88 said:
Is it really llvm 2._0_? Or just the apple 'version' and actually 2.8 or soon to be released 2.9?
Apple uses Clang's (the C/C++/Obj-C frontend for LLVM) version number, so it is Clang 2.0 on top of LLVM 2.8 or 2.9
