Quote: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.

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.

Quote: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.

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.

Quote: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

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.

Quote: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.

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 ).

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.

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?

Quote: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 ).

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?

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.

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 (Using a book almost as old as I am).

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 ).

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.

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! Na it's not C's fault its the coders fault. Happy now.

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