Nobody does an entire game in C++. Everybody I know in the industry uses some dynamic language (Lua, Python, Perl, Java, Lisp, ...) for the soft-and-gooey stuff, and C++ for the hard-and-performance-sensitive stuff. It's not even controversial to say this: it's the accepted norm.

Note that a "struct" will take significantly less memory in C++ than the equivalent table/hash in a scripting language; this matters to people on constrained platforms like consoles, but not as much on a PC. Unless your game is all about cramming 2000 minutes of custom character animation into a minimum spec machine of 128 MB, or something along those lines.

How refreshing... a discussion where we actually get close to a consensus. ^_^

Woops, i realized that with bobstevens' post my post developed an intire new meaning. I am mostly refering to the last 3 posts, _before_ bobstevens'.

To continue on bobstevens' idea :

Quote:Original post by sim27
C++ Cons:
- full controll over computer (do your own mem-managment, etc.)

In my opinion, this is not a real Con - instead, I found it to be a Pro.

When you have an application which can eat up to 1 GB or RAM (yes... we do, and this is the memory friendly version of our product :P), then you are happy to be able to control the way the memory is managed. Garbage collectors are generally a big black box. You know that some time you are enteninr the garbage collector. You know that it perform well. The problem is : when, how, what. I do not want my program to eat 1.5 GB because the gc has not been called yet.

Programming is still about controling :)

My own experience tends to prove me than every language has its own target application. Scripting languages are ok for things that need to be scripted. C# seems ok for high level system manipulation (just as current java in fact but java was originally aimed at low level development). Fortran is good for math because of its syntax and its big math libraries. perl is good for showing to your friend how obfuscated code can be (and therefore telling them that you're that 133t c0d3r everyone is talking about (yup... just joking :)).

And C/C++ is good for low level, system programming stuff. But he also proved to be good in a lot of other fields : UI, algorithms and so on. C++ is a very versatile language which can be adapted to nearly all situations whre a compiled program is required.

Now, speaking of the industry (whatever this industry is. I have been involved in the game industry some years ago but it is not the case for the moment). Rapid prototyping is a good thing. But rapid prototyping must evolve to a fully functional product. Obviously, I will not code a big system in python (nor in lua, nor in any scripting language). So why should I code my prototype using this language ? This will be a complete loss of time because I won't be able to reuse any part of that prototype code. Given the price we (me and my 4 people team) are selled to other companies, if I work during 3 month on a prototype product in a way which cannot be reused after that, I will be responsible of a net loss of nearly 150.000 USD.

Hope I'm clear (I'm somewhat tired :/).

Regards,

Quake1 uses scripts. Quake2 uses dlls. Quake3 uses scripts? Doom3 uses dlls. The reason for dlls is speed. But it really depends on what you're making and how much cpu you have to burn. C++ is popular because it's both fast and high level and there are lots of middleware libs using it. Opengl and DX for example. Asm is probably too low level for most but can speed things considerably so it's something to keep in mind. I don't believe in the common belief that once we got fast cpus we can afford slower langs. This is because we always needed fast cpus in the past because we found new things to suck up cpu cycles. We evolve as human beings and so do our needs.