Having recently read up a on Objective-C it strikes me as a fairly neat language with plenty of cool features.
I have no intention of doing any iPhone development, however I understand that GCC is able to compile Objective-C code and so I wanted to know - Is Objective-C a viable alternative language to C99 for Windows development?
In particular:
Is anyone currently doing Windows development using Objective-C?
Are there any runtime components that would need to be distributed with my applications?
I understand that Objective-C is a superset of C, does this mean that it is possible to use any C-compatible library? (for example the Windows API)
Would I get garbage collection in my applications?
I've found Cocotron and GNUstep which are often mentioned when talking about using Objective-C on other platforms, however as GCC can already be used to compile Objective-C I don't really understand why I would need these.
Are there any other pitfalls or traps I might run in attempting Windows development using Objective-C?
With respect to your first question, I don't know if anyone is seriously doing development on windows with Objective-C, but there may be, though those numbers would probably be less than those doing serious work with a language like whitespace.
Secondly, you would need, at a minimum the objective-c runtime. There are two runtimes, NeXT's (now Apple's) runtime, and the GNU Objective-C runtime. They are not compatible. If you are on a non-NeXT and non-Apple platform, such as windows, you have no choice, GNU runtime only.
Objective-C is a superset of C, and yes you can use the Win32 API if you so desire directly in your objective-c code. As well, you would only get garbage collection if you use a conservative collector, and it ties in with the libraries you're using. In short: No.
What GCC has is support for the objective-c language, and runtime, no standard library. What the GNU objc runtime provides you with in terms of a standard library, is two objects: Object, and NXConstantString class, which is needed to support the #"" syntax. Object is merely a base class. Not very useful, eh? This is why frameworks like Cocotron and GNUstep exist — to give you access to an implementation of OPENSTEP/Cocoa.
Regarding pitfalls or traps, yeah: Your application, even using Cocotron or GNUstep may never be portable to the Mac for instance, or you may get bit by things like typed selectors in the GNU objc runtime, or a plethora of other problems. Let me finish answering this by posing another question: What pitfalls or traps might you run into targeting .NET? I'm sure some if not most of those apply in this case too. Standard pitfalls and traps apply.
I hope this helps.
There is no mature solution yet. If you develop the solution itself, you can do it anyway. But if you're not, it's not the time.
For compiler tools, there is LLVM/Clang which are open-source under BSD license.
The compiler is sponsored by Apple, so it compiles Objective-C completely, and is becoming primary compiler for Apple. So compiler is no problem anymore.
Problem is runtime environment library. Objective-C language is depends it's runtime to execute. The runtime defines all behavior of object system and some more. Runtime environment library is core system and different with framework library like Cocoa or Quartz. in .NET, it's CRE, not .NET framework class library.
Without runtime, program cannot be executed like .NET program executed on Windows without .NET runtime.
For more details, check this conversation:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-January/007593.html
Related
I'd like to ask if gnustep's toolchain is appropriate for netbsd development where one'd normally use plain C. I'm interested in the benefits of Obj-C only with basic APIs like NSObject's reference counting and dynamic stuff.
My question is twofold:
is gcc's Obj-C ABI compatible with gcc's C ABI? so that I can use regular C libraries
is Obj-C's runtime layer good to go where netbsd targets embedded?
Thank you in advance!
is gcc's Obj-C ABI compatible with gcc's C ABI? so that I can use regular C libraries?
This has nothing to do with the ABI at first glance. Objective-C is a strict superset of C, so it's true on every platform that you can use C code with Objective-C code. You can even call Objective-C methods from plain C code using the Objective-C runtime library.
is Obj-C's runtime layer good to go where netbsd targets embedded?
I don't exactly see what the question is here. Are you asking whether it is possible to port GNUstep to embedded platforms? If so, I'd say yes, it should normally be possible (with the appropriate constraints of an embedded system), but in my opinion, it's too heavyweight for embedded development.
If you aren't interested by AppKit, you may also take a look at https://webkeks.org/objfw/.
Runtimes may contain assembly bits that you will want to verify that they will actually work on specific CPU type. Old Foundation library like libFoundation may also suite your needs. If you want to use thing like Objective-C++ or Objective-C 2.0, I'd recommend clang instead of gcc.
This question pops up quite often here, even if just implicitly when users mistag their iOS questions. So, what’s the difference between Xcode, Objective-C and Cocoa?
Objective-C is a programming language. It could be said that it’s just a description of what valid Objective-C programs look like and what they mean. If you have a source code listing written in Objective-C, you need an interpreter or a compiler to put the listing to work. Languages like Objective-C are usually compiled, so most people use a compiler (like LLVM). Objective-C is almost exclusively used to develop for iOS and OS X, but there are other uses, too – as an example, some people write Objective-C for Linux.
You can use a text editor to write the sources and a compiler to turn them into an actual programs, but with modern technologies there’s much more to take care of, so that there is another program to make your job easier. These are called Integrated Development Environments, or IDEs. An IDE offers you a convenient way to edit the sources, compile them, debug the resulting programs, read the documentation, and many other things. Xcode is one such IDE. An important observation here is that Xcode does not compile your sources itself, it just calls the standalone compiler (LLVM). And Xcode is not the only IDE you can use to develop Objective-C apps – there’s AppCode, for example.
Writing iOS or OS X apps from scratch each time would be very time-consuming. That’s why Apple provides the developers with a good set of libraries. The libraries are simply a huge amount of source code written by Apple, and this source code takes care of most things that apps have in common. These libraries are called Cocoa.
Now, if you can’t figure out how to extend a class, you are most probably talking about Objective-C. It doesn’t have anything to do with Xcode or Cocoa, you could be very well writing some GNUstep code for Linux using Vim as an IDE and GCC as a compiler. On the other hand, if your Xcode build process fails because of some mysterious setting, or if you’re trying to build a static library in Xcode, that’s clearly an Xcode issue. And if you can’t figure out how to use some NSObject facility or the NSFileManager class, that’s Cocoa. (But it doesn’t have to be Xcode-related, as you could use AppCode or TextMate as your IDE!)
Originally available on my blog. Feel free to link to the blog post or this question when retagging or explaining the difference.
Xcode is the integrated development environment (IDE)—the application—that developers use to write software for iOS and/or OS X. It includes the editor, the build system (determining what to build to produce the desired target), and quite a few other things.
Objective-C is the main language that developers write such software in. They may write bits of it in pure C, use C++ or combine it with Objective-C (producing Objective-C++), or write some or all of the program in another language entirely, such as MacRuby, Java (with j2objc), or C# (with MonoTouch).
Xcode includes the Clang compiler, which turns code written in Objective-C, C, and a few other languages into executable code. Most error messages come from Clang, and Xcode relies heavily on it for search indexing, syntax highlighting, and name completion of Objective-C code.
Cocoa and Cocoa Touch are application frameworks. Each one is a suite of many individual frameworks (libraries stored in folders named blahblah.framework), such as:
Foundation (both): General object-oriented utilities, including NSString, NSURL, NSFileManager, etc.
Core Foundation (both): Mostly the same thing, but different, mainly in having a C-based API rather than Objective-C
Application Kit (Mac): Application and windowing framework
UIKit (iOS): Application and windowing framework
Core Graphics (both): Drawing
Core Animation (both): Sprite-management and animation framework
(and many, many more where they came from, especially on the Mac)
So:
You can use a framework besides Cocoa or Cocoa Touch, but you'll have to have some Cocoa/Cocoa Touch code, at some level, in order for your application to talk to the system, receive events, draw, etc. Frameworks that specifically target Mac and/or iOS will include the relevant wrappers for you, at varying levels of quality.
You can use a language besides Objective-C, but you'll have lots of syntactic awkwardness, as most of Cocoa and Cocoa Touch are designed for Objective-C's unique syntactic features (particularly selectors).
You can use an editor besides Xcode, and you can even use a build system besides Xcode (such as make), but Apple's App Stores expect apps built a particular way (especially with regard to code signing), so unless you're not targeting the App Stores, any other build system has to replicate what Xcode does or risk its users getting rejections.
A clear mistake is failing to differentiate Xcode from everything else. Xcode is the tool you are using to program in - to edit code, run code, etc. So if you are having trouble with the tool (e.g., the window doesn't show you your code properly, or you're having trouble drawing your interface, etc.), that's an Xcode problem.
If you don't understand why your code doesn't work, you're probably having an Objective-C problem or a Cocoa problem. But you won't necessarily know which.
It's an Objective-C problem if the root of your trouble is that you don't know how the language works (e.g. you don't know what the asterisk is for, or that declaration is not instantiation, or that messages to nil do not error out but don't do anything either).
It's a Cocoa problem if you don't grasp the delegate architecture or how a view controller works.
But my experience of the way people pose questions is that you may be ignorant of which of these you are ignorant of. I don't mean you personally, I mean all of us. This can make it difficult to pose the question properly because you don't know what exactly it is that you don't know — if you did, you'd know it and you probably wouldn't be having a problem (you'd be fixing the problem and on to the next thing).
There are lots of oop languages, but I couldn't find any that has conveniences like garbage collection, but compiles natively to machine code. Sort of like between C and java/c#. One interesting language I found was Vala, but that's limited to the GNOME platform and is not that well-known
Go is probably closest.
But why on earth do you want it natively compiled anyway?
JIT compilation of portable bytecode has proved to be an extremely effective strategy. It compiles down to native code at runtime (so you get up to the performance of native code after the first few iterations) and it avoids the issues of having to build and manage platform-specific compiled binaries.
Are you thinking about C++? That is in high usage and can be compiled on nearly any (major) platform.
In the case you want to use an oo language that compiles down to native code you will "always" have to use header files and stuff as the elf format doesn't support oo (There is no class information in elf).In case you want to use classes from external libs you need to make the compiler aware somehow about the fact that there are classes, functions, etc. that are declared outside of your project. In C++ this is solved by the use of header files. So that's, I think, a major drawback in native object oriented languages. To resolve that issue a few tweaks would need to be made to elf/loader/linker in order to support the kind of features (like "linking" against "classes") you might expect. Even though mechanism for garbage collection could be implemented even in native languages. But that seems no good for os implementation.
There are C++ libs to do that for userspace apps like:
Boehm collector
Smart pointers
I am trying to compile a library originally written for Cocoa. Things are good until it looks for the function marg_setValue(). It says there is a syntax error before char in
marg_setValue(argumentList,argumentOffset,char,(char)lua_toboolean(state,luaArgument));
(it's talking about the third argument, not (char) )
I am trying to port LuaObjectiveCBridge to the iPhone. It has two choices, either using Runtime or Foundation. I have discovered there are some problems with foundation so I am trying runtime. But the compiler is not co-operating.
Check to see if you can get rid of the marg_XXX macros:
they are deprecated and not considered as reliable.
marg_list is to be used with objc_msgSendv which is absent from modern runtime.
I suggest to go with NSInvocation. It is pretty simple to use, and powerful enough for a bridge. Check this entry for completeness.
The modern Objective-C ABI/API is available on Cocoa Touch. It lacks some of the legacy features of the 32-bit desktop runtime (namely, ones that were horrendously fragile).
marg_setValue() and friends are a part of that legacy runtime that is not supported in Objective-C 2.0. It was -- always was -- broken anyway. You aren't missing much.
The real question is: What are you trying to do?
It seems that Cocoa seems to be the main platform for Objective-C. GCC (which Xcode uses) supports Objective-C so it must be available on a wide range of platforms.
Are there any notable cross-platform projects that use Objective-C but not Cocoa (or its open source cousin GNUStep)? Is it really used outside the Apple ecosystem?
Objective-C has also been popular in the scientific and financial services communities. There are still many Objective-C based applications deployed in banking, mostly on the trading analysis front. A friend works on a nearly million line of code Objective-C based analysis and trading engine for which they have written their own class hierarchy from scratch.
At one point, one of the more popular Linux window managers was written in Objective-C. That was a few years ago and may no longer be the case.
The LLVM compiler also compiles Objective-C, including having full support for Blocks. It is quite portable, too.
There is also David Stes's Portable Object Compiler. It compiles Objective-C to C and uses a class hierarchy that is based quite directly upon the original ICPak class hierarchy from StepStone.
It seems what you're asking is if Objective-C is ever used without Cocoa, or GNUstep, or Cocotron, or any API like them.
The answer is basically no. Without an API like Cocoa (or GNUstep, etc.), Objective-C isn't very useful. For example, without NSObject, retain and release wouldn't even exist. A ton of very important features are built into these APIs, so it's somewhat pointless to use Obj-C without one of them.
Yep, there sure are. The one I can think of from the top of my head is Cocotron. An effort to port AppKit to Windows.
http://www.cocotron.org/
Aside from that, Objective-C can be used on any platform that gcc will run on. You won't have the wealth of frameworks that are available in Cocoa on OS X or the iPhone, although as you mentioned, GNUStep does a pretty good effort.