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.
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.
Assume I'm developing a typical Mac or iOS application using Apple's latest Xcode tools. Further assume that I am primarily developing this application using Objective-C and leveraging all of the relevant APIs from Apple's Cocoa or Cocoa Touch frameworks.
Let's say that I don't currently have any plans to use C++ or Objective-C++ in my code base, but I suspect that some time in the future I might want to sprinkle in a little Objective-C++ here an there.
So I'm considering naming all of my .m files as .mm instead, just in case. (This will have the desireable effect of a cleaner history in my SCM system, as I won't have to rename files later.)
Is this a bad idea? Is there any reason why using .mm files is definitely or significantly worse than using .m when the file doesn't actually contain any Objective-C++?
Presumably this file extension flips some switch in the compiler which will then have to parse the source code for not only ObjC, but also C++. Does this have a significant negative effect on build times for moderate-to-large code bases?
Does it have any other negative (or positive) effects that I should keep in mind?
NOTE: please do not respond with any comments about whether ObjC or C++ is better. That is not what this question is about.
It's not the worst idea, but it's not really a good idea, either.
The main purpose of Objective-C++ is to act as a bridge for Objective-C code that needs to use a C++ library. Thus, in most projects, almost all of the code is plain old Objective-C, with maybe a few .mm files to create a "wrapper" object to talk to the C++ library.
Therefore, it is extremely unlikely that you will need to change significant parts of your code over from Objective-C to Objective-C++. You shouldn't have a lot of file renames in your SCM history.
The main problem with using Objective-C++ everywhere is that you will be following "the road less traveled": 99% of the tutorials you read and open-source code you use and learn from will all be written to be compiled by the Obj-C compiler. Using the Obj-C++ compiler will be mostly the same, and probably won't make a difference most of the time, but you will eventually run into some problem that is due to Obj-C++ being compiled slightly differently, but when you find the bug it won't be obvious, and you'll spend a lot of time trying to diagnose it before you realize that it is because you are using a less well-tested compiler setup.
If you have a lot of C++ experience and find yourself "needing" features from C++ in your code, you probably don't really need them, you probably need to spend a little more time figuring out how to do the equivalent in Objective-C. When in Rome, do as the Romans do.
In general, "just in case" is not a good reason to stray from standard practice. You often wind up spending a lot of effort on something you aren't going to need.
Quote from Barry Wark:
The major disadvantage to using .mm over .m for "normal" Objective-C
is that compile times are significantly higher for Objective-C++. This
is because the C++ compiler takes longer than the C compiler. With
Xcode 3.2 and higher, Objective-C code can use the Clang frontend tool
chain to significantly speed up Objective-C/C compiling times. Since
Clang does not yet support Objective-C++/C++, this further widens the
gap in compiling times between the two.
BUT
UPDATE Feb 17, 2012 As of Xcode 4.0 (with LLVM 3.0), Clang has
supported Objective-C++. Even C++11 support is quite strong now.
So I think that its ok to use .mm as long as if you only use C features, .mm files should generate code that performs very similar to .m
As I wrote in a comment, C++ is not a strict superset of C, so it's possible you'd run into cases where you use e.g. C99 code which will not compile if you put it in an Objective-C++ file. I had this problem recently using C99 compound literals.
Yes, it's bad idea.
When I see a .mm file, I expect it to have C++ code (in addition to Objective-C of course). There are a few things not directly related to OOP that are a bit different in C++ comparing to C.
So name all your Objective-C files as .m. As soon as you need any C++ features – rename it to .mm and verify that everything works.
You get bonus points if you keep your header files C++–less.
.mm extension means Objective-C++ file. Compiler takes more time to compile c++ code than C code.
So, if it is not required, keep the extension as .m only.
From my experience (at Apple):
1) the xcode team thinks about c++ last (took forever to get blocks support in objc++)
2) objc++ is much slower in compiling
I can't seem to find an answer to this question by Googling. Can I assume that the Objective-C preprocessor works exactly identically to the C preprocessor, and that anything I read about the C preprocessor applies exactly the same way in an Objective C environment? Or are there subtle differences?
The official documentation from Apple states that Obj-C is a small superset to the language. As far as I can tell, the preprocessor is the same as regular C's (It's all based on the same open-source components, anyway). That's true with the GCC compiler (which is used elsewhere) and related tools; I would assume LLVM is the same as well but I can't speak for the latter.
Of note would be #pragmas, but then again they were meant to be implementation-dependent.
There are some subtle differences:
The include paths are different depending on what language you are using.
I believe that #import triggers a warning if you're not using ObjC.
The preprocessor may have some special cases to handle the ObjC #"string" syntax.
And, of course, most importantly, the language affects which macros are predefined (e.g, __objc__).
It's still cpp either way, though -- it's just operating in a different mode.
It's the same preprocessor. You can look at the Clang or GCC source if you want to see for yourself — as far as I can tell, aside from the fact that it uses the Objective-C lexer rather than the C one, it's the same.
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
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/