Objective-C or C++ for a new game developer?

Sage
Posts: 1,066
Joined: 2004.07
Post: #46
In the OO category, I definitely agree that Objective-C wins hands down.

However, I don't care for having EVERYTHING be a class. The application itself, for instance. I like that C/C++ has the main function and the code is more straight forward and not constantly concerned with classes. I know you can do this with Objective-C, but it seems to defeat its purpose and become rather confusing (setting up the autorelease pool and releasing it, for instance).

But that doesn't mean that Objective-C isn't more OO, it just means that I prefer my C/C++ over it for about 70% of the stuff I work on. For some stuff, it just makes more sense to use Cocoa and Objective-C.

Edit: garbage collection != autorelease pool (I meant the latter)
Quote this message in a reply
Moderator
Posts: 1,562
Joined: 2003.10
Post: #47
Nick Wrote:I know you can do this with Objective-C, but it seems to defeat its purpose and become rather confusing (setting up the garbage collection and releasing it, for instance).
Minor nitpick: Autorelease pool != Garbage Collection. Garbage collection is necessarily automatic; objects have to be added to the autorelease pool manually.
Quote this message in a reply
Member
Posts: 37
Joined: 2006.08
Post: #48
(hi, first post)

The thing keeping me from C++ is the fact that it's such a large language that there is significant cost involved in adding it to my brain. I already do C, Objective-C, Java, Ruby, Python, and JavaScript. I don't need another language that has as many conecpts and paradigms as all the others combined!

Objective-C has a certain Zen about it. Why is that? Because of the simple fact that you can't do anything in Objective-C.

You can't actually do anything without having the basic functionality somewhere down the line written in C becuase it doesn't define anything besides the [object message: agument] syntax and a few keywords (and the "id" type). If you know C and you can grasp the messaging syntax then you have got Objective-C and can start leveraging it to make really powerful OO designs.

So anyway... if you want to make games for Windows or a console, then go for C++. Otherwise, stick with C and Obj-C on the Mac and make solid native applications that leverage the built-in stuff that you can't get anywhere else.
Quote this message in a reply
Member
Posts: 21
Joined: 2003.01
Post: #49
While I haven't ported what I am working on over to Windows yet, I've been successfully using the base classes of Cocoa on Mac OS X and the base classes of Gnustep to develop cross platform with Objective-C. I use SDL for input, timing and OpenGL.
Quote this message in a reply
Member
Posts: 321
Joined: 2004.10
Post: #50
This is a fascinating discussion guys. As a programmer (mainly C++ currently) I'm particularly interestest by the OSC's comment about messages.

Quote:you can make a case that C++ has objects, but it certainly doesn't have messages. Objective C, Ruby, Python, SmallTalk, are clearly object-oriented

I feel like I've never fully grasped the notion (power/elegance?) of "messages" in languages like Objective C or SmallTalk. Obviously I've very familiar with the C++ synta like:

anObject.someMethod(argOne, argTwo);

In ObjC I guess it would it be changed to something like:

[anObject someMethod:argOne, argTwo]

So, in short, can someone elaborate further on messages and why they are superior.
I realize from the above comments that they have some downsides, but like all engineering there are always tradeoffs.
Quote this message in a reply
Member
Posts: 37
Joined: 2006.08
Post: #51
WhatMeWorry Wrote:I feel like I've never fully grasped the notion (power/elegance?) of "messages" in languages like Objective C or SmallTalk. Obviously I've very familiar with the C++ synta like:

anObject.someMethod(argOne, argTwo);

In ObjC I guess it would it be changed to something like:

[anObject someMethod:argOne, argTwo]

So, in short, can someone elaborate further on messages and why they are superior.
I realize from the above comments that they have some downsides, but like all engineering there are always tradeoffs.

Close! This method call in C++ ...

calculator.multiply(numberOne, numberTwo);

... becomes ...

[calculator multiply:numberOne by:numberTwo];

The general convention in Obj-C is to give your methods clearly named arguments. This makes for VERY understandable code.

The power of messaging in Obj-C is that it is dynamic. This means that a message is sent using the Obj-C runtime to call a method on an object, instead of your program simply pushing the arguments around. This type of message can be encapsulated in an object and modified before execution. You can send a message to an object in a lot of different ways. You can also forward messages and do other neat things.

This is a great article on Objective-C:
http://www.gnustep.org/resources/ObjCFun.html
Quote this message in a reply
Member
Posts: 304
Joined: 2002.04
Post: #52
Its the age old tradeoff between speed and flexibility.

Im not an expert and Ive probably got some terminology wrong but here is my take on the differences and a link to look at.

In C++ a method call is almost the same as a function call. At *compile time* the compiler knows that the object has the method and can compile a very quick call to it in your code. The compiler wont compile unless the object has the right method.

Pro: very fast
Pro: can find errors at compile time
Con: brittle - hard to prevent interdependencies between objects.


In Objective C, Ruby, Javascript etc... you send a message, the object gets the message, it sees if the message is one that it can respond to and if so it calls the right code. This happens at *run time*. The compiler may warn you it doesnt think an object responds to a certain message, but will happily compile anyway.

Con: slow
Con: many errors you wont find until running (although unit tests may help)
Pro: More flexible code. Because objects arent forced to inherit from each other they can have fewer dependencies and its easier to move things around and swap one type of object for another.

Its because of the dynamic nature of Objective C that Interface Builder can work the way it does. Its what makes things like notifications in Cocoa so elegant. It allows you to add new methods to objects that you dont even have the source code to (categories in Objective C). You can create a forwardInvocation: method to catch any messages your object gets sent that it doesnt understand and send them to a different object. Lots of neato stuff.

In prototype based languages you dont even have classes really - you *clone* an object that already exists and then add/replace new variables and methods all at run time. Anarchy!

My uninformed opinion on what to use where:

Use c or c++ for game engines. 3D engines, 2D engines, collision, physics, etc... You dont want your Vector or Point or Matrix objects to be in Ruby.

Use Objective C and Cocoa for Mac applications and stand alone game editors. Great (maybe the best?) for being able to quickly and flexibly build gui based apps. Processors are so fast that the hit you take in speed b/c of Objective C dynamicness is no longer an issue. There are bindings for many other languages so you could use Ruby or Python or something instead of Objective C if you fell in love with one of those languages.

Use scripty interpreted languages (Ruby, Javascript, Python) for game logic, bots, etc...

if you have the time read:

http://www.mindview.net/WebLog/log-0066

here is an interesting snippet:

"What is the best of both worlds? In my own experience, it's very helpful to create models in a dynamic language, because there is a very low barrier to redesigning as you learn. Possibly more important, you're able to quickly try out your ideas to see how they work with actual data, to get some real feedback about the veracity of the model, and change the model rapidly to conform to your new understanding.

I think this approach has great benefits over simply modeling with UML, or this new fad of model-driven architecture. Those produce a model that is a fantasy and only after some complex transformations do you have something that expresses and tests your ideas. My experience with complex transformations of this kind is that they weigh you down and discourage you from experimenting and making changes. With a dynamic language, on the other hand, the model becomes the code and vice-versa, and so you're able to experiment without the inertia of something like MDA. I think this lightness is very important, because it is far closer to the way our brains work.

Once you've worked out and tested a model using a dynamic language, is it then worth transforming it into a statically-typed language? My experience with Python has not compelled me to do this for two reasons:

Once I get something working in Python, it seems to work pretty well. The benefits of transforming the model into a statically-typed language at that point are few. Other's experience with significant Python programs seems to support this – large Python programs seem to be surprisingly bug-free.

I usually find that any program that is used regularly will be changed. It is much easier to change the program in Python than it is in a statically typed language, so I have further incentive to leave it in Python."

hth, Codemattic
Quote this message in a reply
Member
Posts: 161
Joined: 2005.07
Post: #53
Wow, well said, codemattic. Smile
Quote this message in a reply
Member
Posts: 304
Joined: 2002.04
Post: #54
thanks imikedaman!

In retrospect I think I made a mistake posting the link I did. It talked more about dynamic vs static *typing* which is different than WhatMeWorry was asking about messages. But it is still interesting - and gives a good feel for the tradeoffs between different language features and how that shapes your program design - so Ill leave it in with this note here and maybe we can discuss typing next!!
Quote this message in a reply
Post Reply