C vs. C++...

[Nevada]

Ok this is branching from my other thread. But I would really like to hear some arguments on the issue of C vs. C++. I chose C++ because of some of the features I heard it has over C, but mainly because I just ordered a book on C++. Anyway, I hear a lot about C being standard for game programmers. Why? I heard OOP is a big thing about it...

[fat-t]

Thats why i use c++ now. i learned it just for game programming and udg. a class just makes more sense to me than a structure and a buncha functions. plus it seems neater to go model.Draw(); instead of Draw(model);

[OneSadCookie]

C++ had a few goals:
1) be backward-compatible with C
2) be object-oriented
3) be efficient

Unfortunately, 2) and 3) are essentially incompatible goals. To get around this problem, C++ has two different "modes" of member function, virtual (inefficient) and non-virtual (efficient). Unfortunately, neither of these methods really provides the flexibility that you'd get in a truly object-oriented language.

To partially alleviate that lack of flexibility, they introduced templates. Now, don't get me wrong, templates are incredibly powerful and you can do a lot of cool stuff with them. They're also incredibly difficult to program with if you go beyond the basics, and produce impossible-to-read compiler errors if you make even a tiny mistake. They fix some of the flexibility issues, but only at compile-time, where the standard OO solution works at run-time too.

Then in order for all this to hang together, they had to introduce a second way of passing objects by reference, which makes it look like you're passing them by value when you're actually not, they had to allow you to overload operators with whatever meaning you want (nothing stopping you overloading + to mean "remove this object from the queue and send a message across the network"), they had to allow implicit conversions between user-defined types, and because there's no garbage collection, they had to allow you to run arbitrary pieces of code whenever your objects get destroyed.

So basically what you've got is C, with a few semantic differences which mean it doesn't behave quite like C, and a bunch of hacks on top to get some degree of object-orientedness.

The end result is, C++ isn't really any good for efficiency, since you can't tell what's going on just by looking at the code, and it's not really any good at object-orientedness, since you can't do everything you really want to for good object-oriented programming.

The solution then is either to find a language which allows you to use C at the low levels and a proper object-oriented language at high levels where efficiency isn't a concern (*cough*Objective C*cough*), or to use any high-level object-oriented language (*cough*Ruby*cough*) and call out to C functions for bits that are too slow.

Whichever you choose, programming the high-level logic will be much easier due to better OO support, and programming the low level will be much easier due to knowing what's going on and therefore being able to see why things are slow.

That's my rant for the day :)

[KenD]

Originally posted by OneSadCookie
That's my rant for the day :) [/B]

Yeah, we all know you don't like C++ and take any opportunity to bash it.

I love C++. And don't say ObjC is any more efficient when it comes to method calls. There's quite a lot going on behind the scenes there too when you call class methods. And you can use straight C and C++ just as well as C and ObjC. And then we have ObjC's horrible syntax...

My rant of the day.

KenD

[OneSadCookie]

Originally posted by KenD
And don't say ObjC is any more efficient when it comes to method calls.

Oh no. Quite the opposite, much slower than C++. Much more flexible, too.

And then we have ObjC's horrible syntax...

Objective C has the best syntax of any language I've ever used. Being able to distribute the method name amongst the arguments makes reading code like reading prose. You just don't get the situations you do in C/C++ where you have five or six arguments to a function and you can't figure out what the last two or three mean without looking at the docs...

[Mars_999]

Originally posted by OneSadCookie
Oh no. Quite the opposite, much slower than C++. Much more flexible, too.



Objective C has the best syntax of any language I've ever used. Being able to distribute the method name amongst the arguments makes reading code like reading prose. You just don't get the situations you do in C/C++ where you have five or six arguments to a function and you can't figure out what the last two or three mean without looking at the docs...

Muahahh learn to use descriptive words for variables and function parameters! Not this Foo(x,y,z) <- whatís that? I have read some of the top game programmers in the industry say the speed delta between C and C++ is minute.

[Hog]

Originally posted by OneSadCookie
...the arguments makes reading code like reading prose. ...

reading prose is hell difficult and requires alot of concentration to figure out the exact meaning. it's awfully fuzzy

[OneSadCookie]

Yeah, most of the time C and C++ will run at about the same speed (with GCC < 3.3 I sometimes found C++ to be noticeably faster than C).

The point is that if something isn't running fast enough, you know what's going on just by looking at the code in C. In C++ you pretty much have to disassemble it to figure out where all the constructors, destructors, and overloaded operators are coming from and if any of them is your problem.

Objective C is not "fuzzy", nor need prose be. In ObjC, though, most of the words you'd expect to be in an English sentence are present, and each argument to a function call is labeled. You're never left guessing as to what the intent was, or as to what it means to pass 3, false as the last two arguments to createWindow() because it'll be createWindow: level: show:.

Without having been exposed to the API or system before, you can jump right in and understand 99% of what's going on, without having to refer to any headers or documentation. Figuring out what an existing C or C++ system is doing usually means opening up about 100 files tracing function signatures.

[skyhawk]

Originally posted by OneSadCookie
Figuring out what an existing C or C++ system is doing usually means opening up about 100 files tracing function signatures.

and if we like doing that?

[OneSadCookie]

Originally posted by skyhawk
and if we like doing that?

You're a masochist and I take no responsibility for lost time, money or sanity. Just don't ever try to claim I didn't tell you there was a better way!

(Also note, you can still do this in Objective C, it's just seldom necessary).

[skyhawk]

well... I am a masochist because I use Obj-C++... I like the Obj-C system calls and such, but when it comes to making my own classes, I find it easier to use C++ classes. I don't do anything funky with these classes other than using them to encapsulate data and having the functions being a part of the structure to use the data.

[henryj]

Ruby is the best language, followed by C++. C is for people who people who can't think past 2 source files (or learnt to program in 1965) and OBJ-C is for poofters who can't use real languages.

[Tycho]

Stolen from the OpenGL Programming Guide:

C
God's programming language.

C++
The object-oriented programming language of a pagan deity

Not that this forms any real argument, I just like the quote.

[Tycho]

I think saying any language is "the best" is asking for a flamewar. Let's get some Lisp zealots in here. The arguments will last for years...

[Hog]

Originally posted by Tycho
Let's get some Lisp zealots in here. The arguments will last for years...
probably not. it won't last for a few seconds in OSCs forum

[henryj]

Originally posted by Tycho
I think saying any language is "the best" is asking for a flamewar.

Not if you admit that I'm right.

[Zekaric]

Either is fine for what ever you want to do.

Personally I prefer C mainly because there is a lot less to know. Just take the manuals for each of the the languages. C is almost like a brochure compared to the tolstoy that is C++.

My opinion, whatever you can do in C you can automatically do in C++ (seeing that C++ is a superset so this is a given.) and conversely anything you can do in C++ you can do in C. The converse case will mean that you will have to organize the code better and may involve more coding on your part but it's all possible.

My preference is on the C side mainly because when I stated C++ wasn't available or just starting out. It's only recently it's been a viable option as the crossplatform issues have mostly been resolved. Early C++ compilers on various platforms were terrible in terms of compatibility of features. So I'm way more comfortable in C than C++. Go with what you are comfortable and fast in.

With C++ you have a nice library available, STL. This will save you oodles of time not having to recreate data structures that STL provides. It lets you get on with programming the important bits. There isn't really a C equivalent but is it possible to write a 'wrapper' around STL to let C programs have access to this library in an albeit limited fashion.

If you are starting then take your pick. Either is fine. Which do you feel is the language that will give you the most value in the long run. Go with that.

[AnotherJake]

Originally posted by Tycho
Stolen from the OpenGL Programming Guide:

Drats Tycho, I posted the same thing, you're too quick for me!

I'd like to add $.02. I personally think C++ is overkill for most stuff.

[B Rob]

I can look at well written C code and understand it rather easily, but C++ and Obj-C provoke a "what the hell is that" kind of reaction. Of course, I need to learn C++ and Obj-C before I make a final judgment.

[Mars_999]

Originally posted by skyhawk
well... I am a masochist because I use Obj-C++... I like the Obj-C system calls and such, but when it comes to making my own classes, I find it easier to use C++ classes. I don't do anything funky with these classes other than using them to encapsulate data and having the functions being a part of the structure to use the data.
Ditto

[Nevada]

What about cross-platform compatibility? Obviously ObjC won't work in Windows. C and C++ are probably the same though, but would it take longer to port C++ than C? Since the only things that need to be ported are from the system API's and frameworks, it probably doesn't make much of a difference.

[Zekaric]

Originally posted by Nevada
What about cross-platform compatibility? Obviously ObjC won't work in Windows. C and C++ are probably the same though, but would it take longer to port C++ than C? Since the only things that need to be ported are from the system API's and frameworks, it probably doesn't make much of a difference.

I work at a company that used to develop for Sun Solaris, Sun OS, SGI Irix, and Windows. C++ compilers on each of these platforms were very different and making comptible code for all platforms was some serious voodoo. C, due to it's simplicity, didn't have half of these issues. But yeah, lately I don't see this being as big of an issue as it was so it may not be a concern anymore. So porting should be the same which ever you choose.

I don't know if ObjC is on the windows side but I'm sure GCC might allow for it. Other then that I don't know of anyone using it on the windows side. Most have opted for C++ if anything.

Yes, mostly it will be OS specific that you'll get into cross platform headaches. Then it's probably best to use a lib that is cross platform to avoid these headaches. I always concern myself with cross platform worries even if I will never build for the other platform. I just like to keep the options open. :) But if you don't care for any other platform and only intend to support just one then this isn't an issue.

[OneSadCookie]

GCC should be able to compile Objective C on Windows, though you won't have access to Cocoa (unless the GNUstep team has made rapid progress :p).

For C++, Microsoft's C++ compiler is pretty incompatible with GCC. It's much easier to port from GCC to MSVC++ than the other way around :)

For other languages, it's mostly API differences which you'll have to deal with regardless of language. For games, SDL is a great way to avoid these problems.

[Nevada]

Ok. So if I do most of the programming (Like game logic, physics, etc.) in plain C++, then have separate functions specifically for, say, file I/O, input, or other system specific calls, then I would only really have to port those particular functions on the different platforms. So that should be a very small amount of code. And, I'm going to use OpenGL (GLUT) for the graphics so I should have no problem there(?). Are C++ compilers really that different on different platforms? If so, then I guess that would be a reason to get CodeWarrior right?

[Nevada]

Originally posted by OneSadCookie
GCC should be able to compile Objective C on Windows, though you won't have access to Cocoa (unless the GNUstep team has made rapid progress :p).

For C++, Microsoft's C++ compiler is pretty incompatible with GCC. It's much easier to port from GCC to MSVC++ than the other way around :)

For other languages, it's mostly API differences which you'll have to deal with regardless of language. For games, SDL is a great way to avoid these problems.

Hmm, I thought ObjC was Mac only. Anyway, what exactly is SDL? I'd really like to make my programs easy to port so I don't make a huge project that ends up being for Carbon only and take forever to port.

Also, if I were to get a PC specifically for porting purposes would it include a compiler which would accept GCC code? (Or at least be easy to port) Or should I reconsider the whole CodeWarrior thing?

[OneSadCookie]

ObjC is a language. It can't be tied to one platform.

Cocoa is an API. Currently, there's really only one implementation of it, done by Apple and running exclusively on Mac OS X. The GNUstep folks are bringing it to Linux (fairly quickly) and Windows (fairly slowly). Before Apple, of course, Cocoa belonged to NeXT...

SDL is a cross-platform library that takes care of windowing, graphics, setting up opengl, input (including gamepads and joysticks), sound, and threading. There are also a few libraries that generally go hand-in-hand with SDL, notably SDL_net (for networking) and SDL_image (for loading image files). All these libraries work on Mac OS X, Windows and Linux nearly ;) identically.

Your Windows PC won't come with dev tools. If you install Linux on it you can use GCC of course, and there are a few free C++ compilers for Windows, but if you want Microsoft's Visual C++ (which is very much the standard on Windows no matter how undeserving ;)) you'll have to pay through the nose.

[Nevada]

Cool. How but how is it able to behave the same on different platforms? Does it check the operating system and use the appropriate functions? So that would mean porting would be (almost) as easy as copy/paste to different compilers. Sure makes my life easier.:) Anyway, now back to trying to understand classes:blink: (Using a book almost as old as I am).

[OneSadCookie]

There's a completely different implementation of SDL for each platform it runs on (there are two or three completely different implementations for the Mac :p).

You never have to concern yourself with that, though. The point of SDL is that it's all hidden, and that the same source code should work identically on all platforms.

GLUT works much the same.

[Mars_999]

MSVC++ compiler is cheap $99. I use MSVC++ 6.0 and it works great under windows. But you will have more headaches than which compiler to use when you port code. Endianess, OpenGL ext on PC are called in a different way than Mac. I would suggest you use SDL and if your big thing is cross platform and use C or C++ with OpenGL. Their I said it OSC should be happy use C. WINDOZE is wrote using C. Hahhahh now thats a slam!:D Na it's not C's fault its the coders fault. Happy now.:p

[OneSadCookie]

Well, given Mac OS X and Linux are written in C, I'd hope it's nothing to do with the language :p

[Steven]

Originally posted by OneSadCookie
(which is very much the standard on Windows no matter how undeserving ;)) you'll have to pay through the nose.

Well that's not a first/only... ;)

[AnotherJake]

Originally posted by Nevada
Anyway, now back to trying to understand classes:blink: (Using a book almost as old as I am).
I'm sure somebody has already mentioned this somewhere but here's a free book on C++ that might be a little more up to date, which I believe is well written. http://mindview.net/Books/TICPP/ThinkingInCPP2e.html

[Zekaric]

Originally posted by Nevada
Ok. So if I do most of the programming (Like game logic, physics, etc.) in plain C++, then have separate functions specifically for, say, file I/O, input, or other system specific calls, then I would only really have to port those particular functions on the different platforms. So that should be a very small amount of code. And, I'm going to use OpenGL (GLUT) for the graphics so I should have no problem there(?). Are C++ compilers really that different on different platforms? If so, then I guess that would be a reason to get CodeWarrior right?

File IO is standard on all systems if you are dealing with the standard stream or stdio.h functions. If you want large file support (~2Gig+) then it's OS calls. File System support (Directories, paths, etc.) varies quite a bit between systems and can be a real PITA. Standard functions are there but aren't really complete for all that you want to do.

OpenGL is common on all systems. It's just the creation of a window for OpenGL that is the nasty bit. That's where GLUT, SDL, insert favourite substitute will come in to handle that. GLUT and SDL will also have an abstraction layer for input so you won't have to worry too much about platform issues there.


Originally posted by Mars_999
MSVC++ compiler is cheap $99. I use MSVC++ 6.0 and it works great under windows. ...

The 'cheap' MSVC is ~$100 but the thing to point out here is that this version doesn't have the optimizing compiler. It's the simple one that will produce possibly slow code. The pay through the nose one has all the optimizations to produce fast code. Whether or not you'll notice the difference in your project is another matter. For a lot of games I don't think it'll matter. YMMV.