OneSadCookie Wrote:ObjC is a lot easier than C++... I think you'd be hard-pressed to find anyone who'd argue with that.

I didn't have to look any farther than my own body. That was easy.

Anyway, I've seen some hideous and entirely unreadable code by so-called C++ "pros", but it's the only language of the three that closely matched my old coding style. Obj-C and C++ both support object-oriented programming, but C++ more closely matched the BASIC syntax I was accustomed to. It's not a perfect fit of course, but it works.

C++ supports object-oriented programming?

You could have fooled me

OneSadCookie Wrote:C++ supports object-oriented programming?

You could have fooled me

I hope that was a joke.

Not really. Object-oriented programming is about objects and messages... 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.

Java and C# ride a very fine line.

C++, for me (and many will disagree) lies on the other side of the fence.

OneSadCookie Wrote:Not really. Object-oriented programming is about objects and messages... you can make a case that C++ has objects, but it certainly doesn't have messages.

From Wikipedia:

Quote:Method (also known as message) — an object's abilities. Lassie, being a Dog, has the ability to bark(). So "bark()" is one of Lassie's methods.

C++ certainly supports methods.

Yes, but Fred, being a Seal, also has the ability to bark(). However, in C++, given an Animal, there's no way to tell it to bark() without knowing whether it's a Dog, or a Seal, first. That's (my) distinction between "method" (an implementation detail) and "message" (an abstract concept of communication).

IOW, I want to be able to tell my Cat to bark(), and have it look at me confusedly, rather than refuse to recognize that the bark() of a Dog and the bark() of a Seal are fundamentally similar.

So you're arguing that C++ is not object-oriented because it uses static typing for its methods, which is not part of the object-oriented definition?

I absolutely hate how I occasionally make a typo in Obj-C code and instead of warning me about the typo (undefined method), the program compiles fine then either:

a) does nothing (message is ignored because it does not exist, there's a fun debug session)
b) crashes (ditto)

EDIT: Another fun problem with Obj-C is the overhead for the message passing, which causes Obj-C code to run slower than its equivalent C++ or C version. The main reason I'm using C++ now is because I originally wrote a collision detection function in Obj-C and had a max. throughput of 333,000 collisions per second, then the equivalent C/C++ code ran at 1 million per second with no optimizations.

The overhead doesn't matter so much in consumer applications where a few lost cycles here and there are unnoticeable, but in games where you're trying to squeeze every last drop of performance out of the code, it doesn't help that the language itself is working against you.

That, combined with the "better" syntax (completely opinion) had me hooked.

EDIT #2: (Off-topic, but I actually wrote the collision code in REALbasic first for prototyping, and it ran at a blistering 75 collisions per second!)

About performance: In code where method call overhead makes a difference, you can use IMPs (function pointers) to call Objective-C methods...or just go straight to C functions.

Also, let's try to keep the religious debates to a minimum, shall we?

ThemsAllTook Wrote:Also, let's try to keep the religious debates to a minimum, shall we?

Maybe you should split it off into a new thread? I know those of us who've been here for years have seen (and sometimes been a part of) the epic debates over c/c++/obj-c and know how it all turns out, but imikedaman and many others are relatively new here. They deserve to have some fun too!

AnotherJake Wrote:They deserve to have some fun too!

Fun will not be had here! This site is about games!!

OneSadCookie Wrote:Yes, but Fred, being a Seal, also has the ability to bark(). However, in C++, given an Animal, there's no way to tell it to bark() without knowing whether it's a Dog, or a Seal, first.

IOW, I want to be able to tell my Cat to bark(), and have it look at me confusedly, rather than refuse to recognize that the bark() of a Dog and the bark() of a Seal are fundamentally similar.

If they are all subclasses of Animal, where is the problem? Just make the Cat's bark metod:

Then,

Anyway, inline short methods (setters, getters and anything that is short and needs to have zero overhead) & operator overloading are things I miss in Obj-C.

PowerMacX Wrote: If they are all subclasses of Animal, where is the problem? Just make the Cat's bark metod:

Code:

void Cat::bark()
{
    lookConfused();
}

PowerMacX Wrote: If they are all subclasses of Animal, where is the problem? Just make the Cat's bark metod:

Code:

void Cat::bark()
{
    lookConfused();
}

Why not just:
and let inheritance take care of the rest?

Because I would have had to write a longer example (to show that Dog instances would really bark instead)

Animals don't bark, so having every animal implement a bark() method just so I can call it on Seals and Dogs is a very bad idea... just think of how many methods that do nothing in 90% of cases will be on the Aninmal class!

Having Dogs, (Cats) and Seals independently bark isn't enough in C++; Animal must bark too.