This question is related to one of my others about C: What can you do in C without “std” includes? Are they part of “C,” or just libraries?
I've become curious lately as to what is really contained the the core Objective-C language, and what parts of the Objective-C I've done for iPhone/OS X development is specific to Apple platforms.
I know that things like syntax are the same, but for instance, is NSObject and its torrent of NS-subclasses actually part of "standard" Objective-C? Could I use them in, say, Windows?
What parts are universal for the most part, and what parts would I only find on an Apple platform?
If you want, giving an example of Objective-C used elsewhere as an example of what is more "universal" would help me as well.
Thanks! =)
There are only two current implementations of the core Objective-C libraries, previously known as the NextStep (hence NS prefixes) and OPENSTEP: GNUStep and Apple's OS X. On Linux, if you maintain compatibility with the OPENSTEP specification, GNUStep works very well. However, the specification is ancient, and modern code for OS X will likely not work correctly (especially in the UI area). The situation on Windows is even worse.
You can use the Objective-C language anywhere GCC supports the build target. The "NS" classes are not part of the language proper.
If you're trying to maintain compatibility across platforms in your code base, stick to C or C++, only move UI specific behavior to Objective-C.
Objective-c is C plus these keywords:
#interface, #implementation, #protocol, #end, #private, #protected, #public, #try,
#throw, #catch, #finally, #class, #selector, #encode, #"string", #synchronized,
#property, #synthesized
Plus the message sending syntax: [anObject aMessage];
EDIT
Given that you have an objective-c compiler such as GCC you still need an Objective-c runtime in order to make the above stuff work. e.g. [anObject aMessage] is actually compiled to
objc_msgSend( anObject, #selector(aMessage));
...therefore the symbol objc_msgSend is one of several that must exist at runtime. In theory this could be provided by a compiler intrinsic but in practice you are probably going to link to an Objective-c runtime library - a quick search of my hard drive shows i have three installed:- Apple's, GNUStep, and Cocotron - there are more but Apple's (open source) is without doubt the most important and influential.
With an Objective-c compiler and runtime - but without any Apple Objective-c frameworks (NSObject, etc.) - you have a fabulous and very useful C-with-Classses that is much simpler (where simpler means 'better for me') than C++.
You can a lot on Windows using Cocotron, which is a free implementation of Apple's frameworks. It's not complete, and you may run into bugs, but if you're lucky, you can compile your Xcode project as a Windows app without too many changes.
None of the class library is part of the language itself. If you want to see the core Objective-C types, look in include/objc. The core language itself, without any added library, is really scant and not particularly useful.
In practice, however, Objective-C is just about never used outside of the context of an OpenStep framework like Cocoa or GNUstep. So you could view that as the de facto standard library, in which case Foundation is almost universal. (Not 100% of Foundation is that way, but the majority is.)
Related
I have integrated Lua with my ObjC code (iphone game). The setup was pretty easy, but now, I have a little problem with the bridging. I have googled for results, etc... and it seems there isn't anything that could work without modifications. I mean, I have checked luaobjc bridge (it seems pretty old and dicontinued), I heard about LuaCocoa but it seems not to work on iphone, and wax is too thick.
My needs are pretty spare, I just need to be able to call objc methods from lua and don't mind having to do extra work to make it work (I don't need a totally authomatic bridging system).
So, I have decided to build a little bridge myself based on this page http://anti-alias.me/?p=36. It has key information about how to accomplish what I need, but the tutorial is not completed and I have some doubts about how to deal with method overloading when called from lua, etc...
Do anybody know if there exist any working bridge between objc and lua on the iphone or if it could be so hard to complete the bridge the above site offers?
Any information will be welcomed.
Don't reinvent the wheel!
First, you are correct that luaobjc and some other variants are outdated. A good overview can be found on the LuaCocoa page. LuaCocoa is fine but apparently doesn't support iPhone development, so the only other choice is Wax. Both LuaCocoa and Wax are runtime bridges, which means that you can (in theory) access every Objective-C class and method in Lua at the expense of runtime performance.
For games and from my experience the runtime performance overhead is so significant that it doesn't warrant the use of any runtime binding library. From a perspective of why one would use a scripting language, both libraries defy the purpose of favoring a scripting language over a lower-level language: they don't provide a DSL solution - which means you're still going to write what is essentially Objective-C code but with a slightly different syntax, no runtime debugging support, and no code editing support in Xcode. In other words: runtime Lua binding is a questionable solution at best, and has lots of cons going against it. Runtime Lua bindings are particularly unsuited for fast-paced action games aiming at a constantly high framerate.
What you want is a static binding. Static bindings at a minimum require you to declare what kind of methods will be available in Lua code. Some binding libraries scan your header files, others require you to provide a special declaration file similar to a header file. Most binding libraries can use both approaches. The benefit is optimal runtime performance, and being able to actually design what classes, methods and variables Lua scripts have access to.
There are but 3 candidates to bind Lua code to an iPhone app. To be fair, there are a lot more but most have one or more crucial flaws or are simply not stable or for special purposes only, or simply don't work for iPhone apps. The candidates are:
tolua and tolua++
luabind
SWIG
Big disadvantage shared by all Lua static binding libraries: none of them can bind directly to Objective-C code. All require to have an additional C or C++ layer available that ultimately interfaces with your Objective-C code. This has to do with how Objective-C works as a language and how small a role it has played (so far) when it comes to embedding Lua in Objective-C apps.
I recently evaluated all three binding libraries and came to enjoy SWIG. It is very well documented but has a bit of a learning curve. But I believe that learning curve is warranted because SWIG can be used to combine nearly any programming and scripting language, it can be advantageous to know how to use SWIG for future projects. Plus, once you understand their definition file implementation it turns out to be very easy (especially when compared to luabind) and considerably more flexible than tolua.
OK, bit late to the party but in case others come late also to this post here's another approach to add to the choices available: hand-code your LUA APIs.
I did a lecture on this topic where I live coded some basic LUA bindings in an hour. Its not hard. From the lecture I made a set of video tutorials that shows how to get started.
The approach of using a bindings generation tool like SWIG is a good one if you already have exactly the APIs that you need to call written in Objective-C and it makes sense to bring all those same API's over into LUA.
The pros of the hand-coding approach:
your project just compiles with one standard Xcode target
your project is all C & Obj-C
the LUA is just data shipped along with your images
no fiddling with "do I check in generated code" to Git
you create LUA functions for just the things you want
you can easily have hosted scripts that live inside an object
the API is under your control and is well known
dont expose engine APIs to level building team/tools
The last point is just that if you have detail functions that only make sense at the engine level and you don't want to see those when coding the game play you'll need to tell SWIG not to bind those.
Steffens answer is perfect and this approach is just another option, that may suit some folks better depending on the project.
I am looking to develop an applicate for OS X with Apple's XCode for the iPhone. I have a few classes that I have defined for Visual C++, but they should be fairly cross-platform. So I would like to use those C++ classes, but my impression is that the GUI builder and everything else is built to use obj-C. Are there any examples of mixing these two languages into the same app?
Objective-C and C++ work together mostly seamlessly. You can store Objective-C objects in C++ classes, structs and collections, and vice-versa. The one caveat is that Objective-C classes won't call constructors or destructors on C++ data members unless the Call C++ Default Ctor/Dtors in Objective-C compiler option is set. But, since this is set by default on the current version of Xcode, this shouldn't be an issue.
On the whole, mixing C++ and Objective-C works very well, and is almost a universal practice in game development, since C++ provides much better support for math libraries.
Is there anyway to load an objective c script at runtime, and run it against the classes/methods/objects/functions in the current iPhone app?
MAJOR NOTE: The major reason I'd like to do this is to allow me to rapidly prototype an application, and then, after I'm done a major prototyping phase, take the scripts I was writing and compile them at build time instead. I don't ever plan on shipping an app with an objective c interpreter in it.
The reason i ask is that I've been playing around with iPhone wax, a lua interpreter that can be embedded in an iPhone app, and it works very nicely, in the sense that any object/method/function that's publically available in your Objective C code is automatically bridged, and available in lua.
This allows you to rapidly prototype applications by simply making the core of your app be lua files that are in the users documents directory. Just reload the app, and you can test out changes to your lua files without needing to rebuild the app in XCode - a big time saver!
But, with Apples recent 3.1.3 SDK stuff, it got me thinking that the safest approach for doing this type of rapid prototypeing would be if you could use Objective C as the interpreted code... That way, worst case scenario, you could just compile it into your app before your release instead. I have heard that the lua source can be compiled to byte code, and linked in at build time, but I think the ultimate safe thing would be if the scripted source was in objective c, not lua. That way your source is always in objective c, regardless.
This leads me to wondering (i've searched, but come up with nothing) if there are any examples on how to embed an Objective C Interpreter in an iPhone app? This would allow you to rapidly prototype your app against the current classes that are built into your binary, and, when your about to deploy your app, instead of running the classes through the in app interpreter, you compile them in instead.
With the iPad and OS 4, bluetooth and virtual keyboards can work with iPhones and iPads... That's going to make this type of rapid prototyping something much more useful, at least for dev time. If you have an interpreter built into your app and have it on your iPad, for example, you can code against the interpreter while on the road, without XCode. And to me, the most useful way to get the source back to an "apple approved" state would be if the scripts were Objective C.
Objective-C is really just C with a runtime and some syntactic sugar. It's an inherently compiled language (I don't think there are any production-ready interpreters for C, although I might be wrong).
Xcode used to have a feature called ZeroLink to speed up compile time, but removed it in Xcode 3 because it caused too many bugs.
It's not exactly impossible, but it wouldn't be easy enough to be worth it. Objective-C isn't normally an interpreted language. This isn't insurmountable — interpreted vs. compiled is just an implementation choice in most cases. For example, Ruby is traditionally considered an interpreted scripting language, but MacRuby compiles it down to code just like Objective-C produces. So it would be possible to write an interpreter for Objective-C, but nobody has done this. You would have to write it yourself.
Also, the rules forbid interpreters other than Apple's Javascript interpreter. So far this hasn't been enforced on anyone, but if you're trying to be a very straight arrow, interpreted code is unfortunately out as well.
Well, there's a couple worthwhile points to bring up:
Why interpret Objective-C code when you can compile it? I understand the "rapid prototyping" idea, but part of the reason to do that in, e.g., Lua, is because Lua is a much terser language than Objective-C. I don't know if interpreting Objective-C will have as much of a bonus.
If you want to have plugins or dynamically-loadable modules in your app, you can always compile them as a separate bundle and load them, using NSBundle or a similar mechanism.
All that said, I don't know of any Objective-C interpreters. You'd likely have to write your own. I'm not sure if it would violate Apple's guidelines or not: it'd still be Objective-C code, but I thought they had rules against interpreted code, too. (I suppose they never envisioned a hypothetical scenario in which Objective-C was interpreted, though.)
There is a basic Objective-C interpreter:
Check out the posting:
Is there an Objective-C Interpreter for the Mac?
Also:
http://forrst.com/posts/Beginnings_of_a_Objective_C_Interpreter-Tdl
Ch is a commercial C/C++ interpreter. It's made by a company called SoftIntegration.
Not on IPhone, but on Simulator, you can do this with
Dynamic Code Injection Tool
http://dyci.github.com/
There's also another tool, that works a little different way, but allows same functionality
http://injectionforxcode.com/
You should take a look at cycript. You can hook into apps, replace methods on the fly, change variables, you-name-it. It's an hybrid language between Objective-C and JavaScript.
You'll need to jailbreak your iDevice to install it.
Take a look at the documentation for objc_msgSend() and other parts of the Objective-C Runtime Reference. You can essentially parse text and send it to the runtime.
I've been learning C++ for some months now and find it an excellent language albeit its perks.
I was wondering what exactly is the so-called Objective-C++ and if it's worth learning it as a main development language to target Apple environments (ie. Mac OS X, iPhone OS). Searching around the web I only found a couple of good articles: mainly Wikipedia's entry and one from Mac Dev Center.
Wikipedia says:
Objective-C++ is a front-end to the GNU Compiler Collection which can compile source files which use a combination of C++ and Objective-C syntax. Objective-C++ adds to C++ the extensions Objective-C adds to C.
The Mac Dev Center article adds:
Apple’s Objective-C compiler allows you to freely mix C++ and Objective-C code in the same source file. This Objective-C/C++ language hybrid is called Objective-C++. With it you can make use of existing C++ libraries from your Objective-C applications.
The Apple article calls Objective-C++ a language. Is this right?
I would like to know the following:
Is it possible to learn and use Objective-C++ without knowing C/Objective-C?
Are there any good books, sites, forums, etc where one can get more information and/or help?
Are there any big projects done in Objective-C++ as far as you know of?
Yes you should learn Objective-C++ when you want to develop competitive comnerical strength (aka so good that people are willing to pay for them) Apple applications.
It is indeed nothing else the Objective-C and C++ combined in the same file.
For Objective-C use any of the hunderts of the popular apple development blogs/mailing lists/newsgroups. Especially the one directly provided by Apple.
For C++ this is the same, dozens of blogs/mailing lists/starter tutorials are there. But while C and its Objective-C add-on is pretty simple and easy to learn if you already understand programming. C++ is a total different and complex beast. Get a few good books and learn it (after 10 years you will be able to fully understand the language :-) but you can writing C++ programs with just a fraction of this knowledge.
So and now the magic question why you should use C++ when you could get away with Objective-C. The answer is pretty simple. Beside the obvious mentioned wrapping of existing C++ libraries, Objective-C is slow, first of all - method call. THe usual adivse is to do something serious in your methods to avoid this runtime penality that shows up in this language.
But especially for Containers you should really consider to use C++ templates. A vector is much much faster then an NSArray. If your dataset is large you will feel the difference. Also i find C++ containers easier to use because they avoid the typecasts you have to do with Objective-C.
With slow ARM CPU's on iPad and iPhone this is not premature optimization.
Unfortunately you can't mix C++ and Cocoa classes and therefore C++ should only be used for algorithmic data. For the GUI you have to use Cocoa and Objective-C classes.
Getting the right balance between C++ and Objective-C is some part of the skills you need to develop as a Apple programmer.
Objective-C++ is really just mixing Objective-C with C++. Since it allows syntax from both you could argue that it is a new language.
I primarily use ObjC++ (.mm source files) when I have to interface Objective-C code with some C++ library. It is convenient to be able to call C++ in that case. Personally I do not know a lot of people who actually really mix C++ and Objective-C.
OBJECTIVE-C++
Objective-C is a small set of extensions to ANSI C. Objective-C++ is the same set of extensions applied to C++. Apple’s Objective-C compiler is also an Objective-C++ compiler.
One of the advantages of Objective-C is that, as a super-set of ANSI C, it can be easily mixed with the millions of lines of existing C code in the world. Objective-C++ can be mixed with the millions of lines of C++ code that already exist. C++ features, such as name mangling, are fully supported by Objective-C++ so that direct linkage between Objective-C++ code and existing C++ code is possible.
Objective-C source code files are identified by the .m extension. Apple’s compiler treats files with the .M or .mm extensions as Objective-C++ source code. Additionally, the –x compiler option can be used to instruct Apple’s compiler to treat any input file as Objective-C++ source code.
Apple’s online documentation describes the features and limitations of Objective-C++ at http://developer.apple.com/techpubs/, and in the release notes that come with Apple’s developer tools. In general, Objective-C classes and C++ classes can be intermixed so that an Objective-C method can call a C++ member function and visa versa or a C++ class can include a pointer to an Objective-C object as a member variable. Objective-C classes cannot inherit from C++ classes or the other way around. The two class hierarchies must remain distinct. The semantics regarding instance creation and deletion are dramatically different between C++ and Objective-C. As a result, mixing them can be tricky, but the benefit of reusing existing C++ code in new Objective-C projects outweighs the complications that it introduces.
Some more practical points about Objective-C++
Gcc is at once a compiler for C, Objective-C, and C++. You can intermix C++ and Objective-C code to some degree. To instruct the compiler that a file contains C++ code as well as Objective-C, use the file extension .mm or .M instead of .m.
Following are some ways in which C++ and Objective-C code can be used together:
Objective-C objects can have fields that point to C++ objects, and vice versa.
Objective-C code can call methods on C++ objects, and vice versa.
Objective-C objects can have C++ objects (as opposed to pointers) as fields, but only if the C++ class has no virtual methods.
However, Objective-C and C++ are not completely compatible. Here are some things you can't do:
Objective-C classes can't inherit from C++ classes, and vice versa.
You can't declare Objective-C classes in C++ namespaces or templates, or vice versa.
You can't use C++ keywords for Objective-C variable names.
You can't call Objective-C methods with C++ syntax, or vice versa.
Finally, there are some restrictions that are imposed to avoid ambiguity:
You can't use the name id as a C++ template name. If you could, the declaration id< TypeName > var could be either a C++ template declaration or an Objective-C declaration using a protocol.
If you are passing a globally-scoped C++ variable to an Objective-C method, you need a space between the first and second colons.
You might find these link helpful :-
https://www.raywenderlich.com/62989/introduction-c-ios-developers-part-1
https://www.raywenderlich.com/62990/introduction-c-ios-developers-part-2
https://www.sitepoint.com/using-c-and-c-in-an-ios-app-with-objective-c/
https://github.com/sitepoint-editors/HelloCpp
1) i doubt it, because everyone of them is a superset of the C language.
i don't consider objective-c++ a totally new language. it is just a mix of both that gives you some additional possibilities - i.e. reuse existing c++ code, or use faster c++ in more time critical code sections, or use c++ code where no objective-c / cocoa interface is exposed (mainly hardware related lowlevel stuff like serial ports / ioctls, opengl, ...)
2) i think resources regarding this topics a
3) pass ... i mean what do you consider big. i just know from a bunch of projects (maybe not all of them commercial in the sense that you can buy the software in the store) that use this mix for the reasons listed in 1.
Plenty of large projects use some Objective-C++. Camino, Chromium, and Firefox, for example, are all substantial open-source projects that include Objective-C++.
Why did Apple decide to use Objective-C for the iPhone SDK and not C++?
It seems strange to me that they would not have chosen a language more popular than Objective-C. Is it because wanted to have something unique in their application which is not otherwise in general use?
Apple merged with NeXT in the '90s and Mac OS X was made from NeXT's operating system, NeXTSTEP. Objective-C was the official language of NeXTSTEP's application frameworks, which became Mac OS X's Cocoa. Mac OS X was then adapted into the iPhone OS, and Cocoa was made into Cocoa Touch. Objective-C has held up pretty well all along the way, and a lot of Cocoa's features would be difficult to translate into C++.
So essentially, it all comes from NeXT.
Objective C began life in 1983 I believe, created by Brad Cox and Tom Love. The idea of Objective-C was to take the purity and low-level control of C and merge that with true object-oriented features that would allow companies to customize system libraries that could communicate with the OOP layer of Obj-C. Essentially, it worked. Obj-C is a strict superset of C, unlike C++ which is most of C, but with many differences.
When Steve Jobs founded NeXT Computer (1985), he brought in some of his former Apple team and others. His best programmers were interested in using a language that expanded on C with the same speed benefits and system control. They chose Objective-C. NeXT eventually wrote many libraries and methods for the base language. These all begin with NS for Next Step. This was the name of the NeXT OS. By 1989 the Next Step OS was considered to be vastly superior to MS Windows or Mac OS, and many computer companies wanted to license it badly. Jobs simply didn't want to go in that direction.
Once Apple wised up and brought Steve Jobs back into the fold (1996), the infusion of Next Step OS into the new Mac OS X was really the key to Apple reviving its software and its programming strategy.
While C++ remains a truly excellent and powerful language, I find that Objective C has less flaws (just my opinion), and Apple's continued work on Cocoa libraries has made the Obj-C language a truly modern power with C underpinnings. Is it better than Java? Not sure. But for what it is primarily designed for (Mac OS, iOS) it is astonishingly good, if a bit overly verbose.
The greatest criticism of Obj-C is the syntactical styling, but any programmer that truly learns the language will quickly learn of its amazing power and seemless fit with all things Mac, iPhone, iPad.
Will any other platforms ultimately adopt Obj-C? not sure, but doubtful. But the Cocoa libraries are truly wonderful.
It's because Objective C has been the de facto language for Mac OS X development before it was Mac OS X. When Jobs left Apple to set up NeXT, the language Objective C was developed as a specific language that wasn't C++ and avoided many of its pitfalls. It therefore makes sense that any portable or consumer equipment (including Apple TV) use Objective C as their primary development language, and dropping down to the underlying C layer when needed for performance or interface issues.
Objective-C adds object oriented programming to C. It was used for NeXT, upon which a lot of OSX is derived. It supports all of C, and is simpler than C++.
http://discussions.apple.com/thread.jspa?threadID=2091191
Note that Objective-C is not a new language. It's been around since 1986 - well before Java or C#!
It has been in general use ever since NeXT, many real-world applications are around that make use of it.
Apple answered this very question here in 2010:
The Objective-C language was chosen for a variety of reasons. First
and foremost, it’s an object-oriented language. The kind of
functionality that’s packaged in the Cocoa frameworks can only be
delivered through object-oriented techniques. Second, because
Objective-C is an extension of standard ANSI C, existing C programs
can be adapted to use the software frameworks without losing any of
the work that went into their original development. Because
Objective-C incorporates C, you get all the benefits of C when working
within Objective-C. You can choose when to do something in an
object-oriented way (define a new class, for example) and when to
stick to procedural programming techniques (define a structure and
some functions instead of a class).
Moreover, Objective-C is a fundamentally simple language. Its syntax
is small, unambiguous, and easy to learn. Object-oriented programming,
with its self-conscious terminology and emphasis on abstract design,
often presents a steep learning curve to new recruits. A
well-organized language like Objective-C can make becoming a
proficient object-oriented programmer that much less difficult.
Compared to other object-oriented languages based on C, Objective-C is
very dynamic. The compiler preserves a great deal of information about
the objects themselves for use at runtime. Decisions that otherwise
might be made at compile time can be postponed until the program is
running. Dynamism gives Objective-C programs unusual flexibility and
power. For example, it yields two big benefits that are hard to get
with other nominally object-oriented languages:
Objective-C supports an open style of dynamic binding, a style that
can accommodate a simple architecture for interactive user interfaces.
Messages are not necessarily constrained by either the class of the
receiver or even the method name, so a software framework can allow
for user choices at runtime and permit developers freedom of
expression in their design. (Terminology such as dynamic binding,
message, class, and receiver are explained in due course in this
document.) Dynamism enables the construction of sophisticated
development tools. An interface to the runtime system provides access
to information about running applications, so it’s possible to develop
tools that monitor, intervene, and reveal the underlying structure and
activity of Objective-C applications.
Historical note: As a language, Objective-C has a long history. It was
created at the Stepstone company in the early 1980s by Brad Cox and
Tom Love. It was licensed by NeXT Computer Inc. in the late 1980s to
develop the NeXTStep frameworks that preceded Cocoa. NeXT extended the
language in several ways, for example, with the addition of protocols.