Who needs C++

[SevenThunders]

Sounds like you guys have some serious maintenance issues. Look, I don't want to denigrate your abilities or anything, but most code sucks. The language has much less to do with it than the programmers working on the project.

That's OK I didn't write that code . I did a lot of the algorithm design and signal processing work. I just happen to do a lot of programming as part my job and even sometimes as a hobby or for various research purposes. I happen to believe that the problem is more than just crappy programmers. (Though with the declining standards in education that's a problem too.) Rather I think there is a fundamental flaw in the way people develop software, either in the process that's involved or perhaps the tools themselves.

The complexity of a large project eventual overwhelms an ordinary human, and bugs, sometimes catastrophic can not seem to be avoided. Maybe some of the work done in proving program correctness or automatic test generation can mitigate this, but I'm not so sure. AI was held out as next big thing that was going to revolutionize our lives. However it turned out to be largely a huge disappointment. We still need to hire humans to write software.

[zacs7]

What 'bout FORTRAN ? !

[SevenThunders]

What 'bout FORTRAN ? !

Are you serious? Last time I programmed in fortran, I input my program using a stack of punch cards.

[Junior89]

I like C++ personally, but i don't have a bunch of experience with other OOP languages so i guess i can't really provide new insight

[Cactus_Hugger]

C has a lot of limitations of course

Limits? I'd say C is fairly unlimited, rather than limited. Granted, it takes more code to sometimes accomplish what you want, and it might be more complex than other languages, but that's the usual tradeoff you get: simplicity or power.

...in terms of rapid prototyping, memory management and a lack of modern language constructs.

Limited memory management? Like what? There's malloc() - what more is there to memory management? If you want something else, like garbage collection, it's probably implemented as a library. (Although I've never really had trouble with keeping track of memory...)

C++, however, IMHO, suffers by being overly complex, difficult to understand and often the execution model, how it actually get's translated to machine code and what the actual program control structure is, is highly obfuscated. (Just watching all the crap that gets called behind the scenes for simple memory management is an eye opener.)

..."behind the scenes" is the usual place for complex crap. It'd be a pity if the user had to deal with it...

I used to use C alot, and shunned away from C++. Until I bothered to look into C++, and saw that my C code resembled and used C++ constructs. That, and std::string and std::vector make life so much easier.

Language isn't that important though. Use what works best for the task at hand. I use C++ mainly for applications, although there are times when it isn't appropriate (web) or isn't available (embedded). The benefit of the existance of multiple languages is that we, as programmers, have a wider array of tools to use.

[SevenThunders]

Limits? I'd say C is fairly unlimited, rather than limited. Granted, it takes more code to sometimes accomplish what you want, and it might be more complex than other languages, but that's the usual tradeoff you get: simplicity or power.
Limited memory management? Like what? There's malloc() - what more is there to memory management? If you want something else, like garbage collection, it's probably implemented as a library. (Although I've never really had trouble with keeping track of memory...)

..."behind the scenes" is the usual place for complex crap. It'd be a pity if the user had to deal with it...

I used to use C alot, and shunned away from C++. Until I bothered to look into C++, and saw that my C code resembled and used C++ constructs. That, and std::string and std::vector make life so much easier.

Language isn't that important though. Use what works best for the task at hand. I use C++ mainly for applications, although there are times when it isn't appropriate (web) or isn't available (embedded). The benefit of the existance of multiple languages is that we, as programmers, have a wider array of tools to use.

Yet one hears arguments about development time, complexity, ease of maintenance, programming habits and so on. As I mentioned, in my field it's about a factor of 10 times faster to develop in matlab and your code has a greater chance of being correct. If Matlab had a compiler that achieved C-like performance, the choice would be a no brainer. Plus you hear stories about how certain languages (say Lisp) has given people a competitive edge.
http://www.xent.com/FoRK-archive/2001.04/0903.html

There have been similar stories about Smalltalk and even a lower level language like Forth. The last two are great for code reuse and code refactoring.

[h3ro]

Nothing beats MEL

[SevenThunders]

Nothing beats MEL

Is that used for animation?

[zacs7]

nah Fortran has been 'modernized'... This time the stack punch card is on screen

[DavidP]

I am a fan of both C and C++, although I use C++ more often because of the higher level constructs that the standard library offers, such as std::vector, etc. Although I could write my own classes for these, I would rather not do so. C doesn't really contain these, and so I tend to use C++ more.

Some of you have mentioned game development, and what they use. I think the best way to really see what professional game developers use is to go to id Software's website and download their code...because yes...they release their code....even to their newest game Doom 3, the code has been released.

If you look at it, you will notice that all their older games (Doom, Quake, Quake 2) all were strictly C. Nothing else was used. I don't think Assembly was even used because they were aiming to release their games for multiple platforms, and Assembly is not portable. So it was all strictly C.

When we arrive at Quake 3 we see a mixture of both C and C++ (if I remember right it was half and half pretty much).

As I look at the Doom 3 code it is almost all essentially C++, although knowing John Carmack and his past experience, I am sure there is loads of C code in those files that are all labeled with .cpp extensions.

Scripting languages do find their use in game development, but not in the core game development. They are often useful for AI.

[psychopath]

even to their newest game Doom 3, the code has been released

Not for free, I don't think. Not for Doom 3 anyway.

[h3ro]

Is that used for animation?

Its the scripting language used in Autodesk Maya. The language itself is very basic, but it gives you access to all the commands and UI stuff inside of maya except a few. But I guess you can access at least 95%, which makes it useful to write simple scripts to speed up your workflow. But its painfully slow, thats why im trying to learn C++

[DavidP]

>Not for free, I don't think. Not for Doom 3 anyway.

Oh yes it has. The engine code has not been released. The game code has been released. It is for free on id Software's website, and that is what I was referring to.

[zacs7]

How can you be sure the engine itself isn't entirely in C, and the game is a mix of C/C++ ? :P

[DavidP]

I never said anything about the engine code...But I did state that the game code was C++, or at least .cpp files, but probably with a LOT of C mixed in there. Although I did actually download the code and take a pretty good look at it, and it is very nicely object oriented, and there is quite a bit of C++.

But anyways, my point in posting all of that was to respond to the comments that were made such as this:

After playing around with various development models I have come to find that the paradigm used in gaming development these days is quite powerful. The low level, number crunching code is written in C or even assembler and the high level logic and configuration logic is often left to an embedded scripting language such as lua.

It's true that scripting languages are used in such programs, but not to the extent implied in that quote.