Why C++?

http://www.gamearchitect.net/Articles/WhyC++.html

Nothing succeeds like success. The fact that C++ is the dominant language for game development gives it a lot of inertia. If you want to hire experienced programmers, it's much easier to recruit C++ gurus than it is to find OCaml talent. If you're going to develop for consoles, Microsoft and Sony provide C++ compilers, but for any other language you're on your own. And if you want to link with middleware, most modern game middleware packages--including Gamebryo, Havok, FMOD, SpeedTree and the Unreal Engine--are written in C++. Developing in another language, even C, is a lonely path.

The power of the C++ network effect is not to be underestimated. For example, Naughty Dog used an in-house LISP variant called GOAL (Game Oriented Assembly Lisp) for the Jak and Daxter titles. They had a significant investment in GOAL, for which they'd written their own compiler, linker and debugger. They supported dynamic reloading of code by a running game and reportedly generated tight, efficient assembly. After their acquisition by Sony, however, Naughty Dog were forced to transition to C++ development. "Sony wants us to be able to share code with other studios, and this works both ways - both other studios using our code and vice versa," posted Naughty Dog lead programmer Scott Shumaker.

C++ is the dominant language for game development

no, it's the dominant language for console/PC AAA game development. Not all games are big expensive blockbusters. Most of them are casual games on browsers and phones.

>>2
I found a game written using functi-anal language:
http://code.google.com/p/masterofmagicclone/source/browse/#git%2Fsrc

the code looks uglier than C/C++. Do we really want that prized functi-anality?

C/C++

            times (Run, Length-1) putPixel(X, Y++, Color);

Funct-anal language:

            for run = 0 to length - 1 do
              Allegro.putpixel bitmap !x !y color;
              y := !y + 1
            done

the guy writing this article is a moron.

I confess that I haven't worked with aspects or closures enough to even know whether they give great productivity improvements.

I'm skeptical of garbage collection because *stupid reason*

god I hate that shit. RAII IS A STUPID HACK. GET IT THROUGH YOUR THICK SKULLS

>>3
man, I don't even know ML and I already prefer this code to C++

>>4

doing mutable stuff in ocaml isn't as pretty as C/C++, but it can do it just the same...

>>4
macros

macros everywhere!

I don't hate C++, but that example is plain and simply idiotic

>>5
he would fit in on /prog/

i've fallen in love with XNA/C#. i can't imagine going back to C++ and suffering just for a few measly cycles.

>>1
Good job copypasting shit instead of using your own brain.
Ah you dont have one.
>>2-10
Good job responding to an obvious troll.

I'm not sure what the Naughty Dog example proves. Seems like they were doing just fine without C++. "It's popular" isn't an argument for quality.

>>12
The example proves that C++ is here to stay forever, better start using it or exit programming.

If you think garbage collection "just works," read this explanation of the complexities inherent in C# finalization.
I'm not a fan of garbage collection, but saying that it is complex because of finalization is akin to saying clothes suck because it's hard to clean them when they're stained with shit. Using destructors for anything else than deallocation is bad design.

>>14
to extend your metaphor to an earlier point in your post,
I'm not a fan of clothing
and this is what anti-GC people actually sound like to me

If you want to hire experienced programmers, it's much easier to recruit C++ gurus than it is to find OCaml talent.

Typical C++er attitude that programmers are good at languages rather than programming.

Just because C++ requires years of study and nobody can agree how it's supposed to work, does not make that true of basically any other language than maybe Common Lisp.

>>12
Were they making an argument for quality? I don't think so.

>>16
What?! Most of Common Lisp problems are legacy-related. Everything else, except CLOS, is straightforward. But CLOS is hard because OOP in general is hard.

>>18
Common Lisp
GC is shit.

What I don't understand is why `the industry' pushes these things. Obviously most `old school' developers and/or people who know what they are talking about agree that
• OO is shit;
• C++ is shit;
• Java is shit;
• C# is shit;
• UML is shit;
• `Paired programming' is shit;
• EnterpriseQualityCode is shit;
• GC is shit.

So why do these things become standard in industry? Are businesses that easily swayed by a few buzz words? Does nobody do the research?
It would take years to undo the damage all this has done. And it's just going to get worse and worse and there's nothing we can do about it.

>>20
what do you use then faggot?

>>18
there are CL programmers who don't use CLOS. Everyone has his favorite subset of the language, just like C++

>>20
Cool story bro.

>>22
CLOS is an external library. One can disable it completely.

>>20
The point of "paired programming" is to have non-ending argument about insignificances, instead of writing useful code.

>>25
（　≖‿≖）

>>24
Wrong. Why do people keep spreading this falsehood?

>>27
Standalone interpreters sometimes omit CLOS at all.

C++ is too complex. languages should help you, not fight you at every step of the way. compilers cant even understand it. they have to cheat and add in shit behind your back like virtual clasess. the assembly output looks obfuscated, so you cant even understand bugs when they occur so you have to code in a very specific, inexpressive and clunky style. too big, too many needless features that were put in simply to increase the language's popularity.

c++ is simply too big. you should use almost every language feature in any project of significant size. with c++, you actively try to avoid this, and most projects will limit themselves to a subset of the language. c++ makes it too hard to write good programs.

this is bad language design. when you have to pay for features you do not use (in language implementation complexity), that is bad design.

the only people who are allowed to use c++ are math wizards like sergei brin and larry page. math is the most powerful language that is available to us, but computers do not understand it natively. if you have a deep understanding of math, then it matters a lot less what language you implement the algorithms in.

i agree that garbage collection is shit, but memory is essentially infinite these days. the real problem is concurrency. time is the new space. c++ is esepeccialy awful at this problem, and java is not much better. i encourage you all to look at functional and concurrent languages if you want to keep your skill relevant. even my phone has two cores.

hand coded assembly is still about two times faster than the best C compilers. that's not enough. multicore has the potential to be at least n times faster. 

also Common lisp is kind of a shitty lisp. clojure and arc are much, much better. common lisp is like the c++ of lisps.


>>18

oop does not have to be hard. look at ruby

>still about two times faster than the best C compilers
Thats if you don't check asm output and improve your hand-coded C code.
Its easy:
1.insert timing RDTSC calls at critical points
2.at end of program display cycles spent in critical code.
Now check asm output for C:
every instruction has latency: there is opcode latency table for every processor
JMPs to non-obvious locations stop the pipeline,CPUs can't predict everything 
interfering with cache stalls the pipeline, like:self-modifying, cryptic code paths.
register starvation check, registers need to be used 100%
stack activity. Stack is still slower than registers, despite easy access
Reduction of function calls: inlining with macros/optimizations.
excessive memory accessess.
Using expensive Opcodes vs simpler 1 cycle code.
If code can't be optimized any further consider replacing it with inline asm

>>28
Then they aren't Common Lisp.

Pipeline hazards:
http://www.cs.iastate.edu/~prabhu/Tutorial/PIPELINE/hazards.html
Function calls:
http://publib.boulder.ibm.com/infocenter/iadthelp/v8r0/topic/com.ibm.xlcpp111.linux.doc/proguide/tvopfunc.html
Branch predictor:
http://igoro.com/archive/fast-and-slow-if-statements-branch-prediction-in-modern-processors/