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.
Related
Can I compile an Objective-C program to C?
I'm interested if this can be done so that it can be compiled with other C compilers.
I am aware that GCC can compile Objective-C.
Sure. For example, POC compiles Objective C to plain C code, and the recommended way to use it is to then compile that C code with gcc.
Of course the generated C is an unreadable mess, consisting mostly of calls (through generated extern declarations) to objc_runtime calls, so you'll need to link that runtime to your compiled code.
There's also an LLVM backend that generates C code from any frontend. So, you can plug in the clang Objective C frontend and the C backend and build your own ObjC-to-C compiler. The result will probably be even more unreadable than what POC generates.
Of course most people don't want to compile Objective C*, they want to compile "Objective C 4.0".** POC won't do that; only clang and llvm-gcc will (and in the future, most likely only clang). And they don't just want an Objective C runtime, they want the OS X or the iOS runtime, or at least OpenStep, which again pretty much means clang, llvm-gcc, or gcc.
The big question is, why do you want to do this? You will need to have an Objective C runtime to link to, and your C code will have to be compiled in a way that's ABI-compatible with the way that runtime was compiled, so… I'm not sure what you're going to gain over just compiling from ObjC to native code with gcc or clang in the first place.
* As in the language defined in Brad Cox's 1986 book and/or in his 1991 followup.
** Note that Apple explicitly decided not to call their latest revisions to the language "Objective-C 4.0"… or anything else. The last version with a name, or a real specification, was "The Objective-C 2.0 Programming Language". But Apple has continued to add features, and the "unnamed feature set that came in with the LLVM 4.0 frontend for Objective-C 2.0" is a bit of a mouthful.
Technically, yes, but it'll be really ugly. LLVM had a C backend — i.e. it could compile to C — up to version 3.1. There have been efforts to revive it but I can't speak as to their progress. There's also a C++ backend that is better maintained but doesn't quite do the same thing.
However you'll have the obvious problem that none of the Foundation libraries will be available on your target platform. No NSString, no NSArray, etc. Once you've found a working implementation of those you'll also have found a working Objective-C compiler.
It is possible to do OO programming in pure C.
Some strategies use pre-processor macros to make it easier and less error prone. Some strategies involve adding new syntax which is expanded to pure c by a pre-processor, along with a base object class and some methods for memory management.
It seems that Objective-C began as a project much like this
Do any tools exist that allow objective-c syntax to be processed to pure C?
Without having explored it, it seems do-able.
Just to clarify, I am not asking about compiling iOS code to other platforms, or asking about ports of the cocoa library to other platforms, I am wondering about ways of using oo techniques in pure-C, using Objective-C syntax and a preprocessor or precompilation step.
Portable Object Compiler. It's not capable of compiling modern Objective-C, but it sounds like it is perfect for what you're asking. Look here at a discussion of POC's shortcomings
The situation for C++ is more interesting. Cfront was the original C++ compiler that produced C code, but besides being long outdated it was commercial and cannot be (easily?) downloaded today. Fortunately, there is Comeau C/C++ which is supposedly very modern and standards compliant. It costs $50.
However, I wouldn't expect to get very readable C code from either of them (especially the full-featured Comeau).
It is possible to do oo programming in pure c?
Yes, as oo is a matter of philosophy. Look at glib and how you can do c style object: http://developer.gnome.org/glib/
Apple did it with Core Fundation: https://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/CFDesignConcepts.html#//apple_ref/doc/uid/10000122i
By the way: Do any tools exist that allow objective-c syntax to be processed to object oriented pure c?
Yeah: gcc (GCC 4.6 according to Wiki, never actually checked ;)) and clang, tools that you are usin everyday.
This is the Objective-C Runtime who make the obj-c obj-cAble, so you need libobjc.A.dylib library too. You can write obj-c in pure c code, since all message '[]', '#' directive and other obj-c stuff are converted in c after compilation.
No it's not possible, as all special (non-identifier) symbols of Objective-C can not be used as preprocessor macros. At least not with the standard C preprocessor.
Other preprocessors may be able to define macros with non-identifier names, although I don't know of any.
When talking about preprocessors in the early days of Objective-C (and also about C++) it's probably (and in the case of C++, definitively) a custom made parser that instead of outputting assembler or objective code outputted C code.
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
Is the gnu objective c compiler for windows the same as the compiler for Mac OS X (and Ipad)?
I want to write some code on windows and run it on the mac and ipad, objective C seems to be the best way to go for the Mac/Ipad but is the gnu compiler the same? I know the libraries cocoa etc are not available but this is not an issue we'll be writing different interface code for each platform (please no comments about this is not the right way etc).
tia,
Dave
The compiler is more or less the same, but the runtime systems are different. If you don’t use the new features from Objective-C 2.0 your code should work fine with both runtime systems. If you want to use the new features you have to use a different runtime. You can find more information here on the GNUstepWiki.
But you still need a framework that provides basic objects like strings, arrays, dictionaries and so on. You could use this part from The Cocotron, a framework that tries to make all of Cocoa available on Windows, Linux and other platforms.
I do not have a Mac, or an iPhone. However, the concept of taking C and making it more dynamic towards the idea of smalltalk, python or ruby is really attractive to me. I'd love to start on objective C.
Is objective C just a syntax superset of C or is it really like C. As in, can it be compiled with gcc etc..?
I do most of my programming in Ruby. Objective C seems so much more forgiving than C. You can write native extensions for Ruby in C. Can you write native extensions for Ruby in Objective C?
How can I get started with Objective C outside of owning an Mac/iPhone and having XCode?
Wikipedia says
Today it is used primarily on Apple's
Mac OS X and iPhone OS, two
environments based on, although not
compliant with, the OpenStep standard,
and it is the primary language used
for Apple's Cocoa API though it was
originally used as the main language
on NeXT's NeXTSTEP OS. Generic
Objective-C programs which do not make
use of these libraries can also be
compiled for any system supported by
gcc, which includes an Objective-C
compiler.
Objective-C today is often used in
tandem with a fixed library of
standard objects (often known as a
"kit" or "framework"), such as Cocoa
or GNUstep.
Maybe you should get a Linux vm if you are mainly running Windows and get GNUStep running.
apple contributed the objective c changes back to gcc (not that they had much choice, being GPL). So wherever you can set up gcc, you can set up an objective-c compiler.
Beyond that, the Gnustep environment can give you a bit of the flavor of the original OpenStep/NextStep environment.
Yes, you can write, compile and run objective c programs outside a MAC/IPhone
Please check the link below for details
http://www.otierney.net/objective-c.html#settingup
http://www.faqs.org/faqs/computer-lang/Objective-C/faq/
There's a difference between Objective-C the language, and the frameworks that Apple has built on top of it. Those frameworks consist of a bunch of objects which you can use in your code and are especially helpful if you're targeting the Mac or the iPhone. There are some similar objects for parts of it in GNUStep, but it's not a complete replacement for the Cocoa/etc library and especially doesn't cover anything iPhone related.
GNUStep and the Objective-C language (via gcc) are available for many platforms, and you can write your own programs that use Objective-C objects and interact with any C api from Objective-C.
Objective-C is a superset of C and so is not really more forgiving than C, but it is arguably more forgiving than C++ (an almost-superset of C). You can also mix Objective-C and C++ with GCC but that gets a little complicated, especially regarding exception handling.
For getting started and playing around with the language though, GNUStep and GCC would be a good way to go.
I don't see any compelling reason why you cannot use Objective C for native ruby extensions, except that you won't benefit much. You will still have to use the lower level C Api calls, since as far as i know, there aren't any ruby to objective-c bindings. Additionally, Objective C comes with a fairly substantial library of utility classes that, while helpful, won't easily justify their size and weight in the context of a ruby extension.
You can you this page for simple experiments with ObjC: http://www.codesign.cz/LearnObjC/