C++ sucks for games

On 2004-10-25 15:08:22, JKop wrote:

> MS-DOS was written in C++. Window XP was written in C++. Linux was written
> in C++.

You're funny! :-)

In comp.lang.c++ JKop <NULL@null.null> wrote:

>> C++ game developers spend a lot of their time debugging corrupted
>> memory. Few, if any, compilers offer completely safe modes.

> AKA Retarded mode.
> (inspired response to obvious troll)

What part of "Do not feed the trolls" was hard to understand?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

"Catalin Pitis" <catalin.pitis@iquestint.com.renameme> wrote in message
news:2u4dcoF24ch55U1@uni-berlin.de...
>
> "JKop" <NULL@NULL.NULL> wrote in message
> news97fd.40000$Z14.14510@news.indigo.ie...
>>
>>>> Come to think of it, what *wasn't* written in C++?
>>>
>>> Linux comes to mind.
>>
>>
>> Really? What was it written in?
>>
> C
>
> Also MSDOS and MS WIndows were developed in C, as far as I know.
>
afaik dos was assembler...

Disclaimer: I don't dislike C++, but the responses to the OP's (mostly
valid) criticisms are pretty uninformed.

> The alternative, garbage collection, tends to corrupt memory too. Have you
> heard of a high-availability Visual Basic program?
>
> Game programmers need efficient and deterministic garbage collection. If
> they don't code it themselves, following healthy styles, they will corrupt
> memory.

Erm no, garbage collection does not corrupt memory unless the garbage
collector is buggy. Have you ever seen a VB program segfault? If you have
special requirements for garbage collection, you just need a garbage
collector tuned to your requirements (e.g. the real-time garbage collectors
available in some implementations of various languages).

>> Alternatively, you can't execute a small portion of the program
>> without compiling and linking the whole thing, then bringing your game
>> into a specific state where your portion of the code is being executed.
>
> Test isolation would help that. If objects are decoupled, you can write a
> test that plays with only one of them.
>
> Playing with unit test cases, and adding them very easily, is a great way
> to preserve all those little experiments, and convert them into
> constraints.

Unit tests help you to /test/ code, but not to debug it. When you've found a
bug, you still need to do the work of actually fixing the code. This is
much easier if you have an environment which supports dynamic redefinition
and interative compilation.

>> The static type system locks you into a certain design, and you can't
>> *test* new ideas, when they come to you, without redesigning your
>> whole class hierarchy.
>
> Then don't use the static type system.

Not using the static type system would entail not using C++ (unless you
intend to represent all your data as void * and fill your program with
casts).

>> C++ is so inflexible, even those who do use it for games, have to
>> write their game logic in some other language (usually very slow,
>> inexpressive and still garbage collected). They also have to interface
>> the two languages.
>
> You make that sound like a bad thing. Most programs have two languages
> (consider the glorious union of VB and SQL). Games need a scripting layer
> to decouple designing the game play from its engine. Most other
> applications with an engine use this model, too.

Clearly a separate scripting language is not desirable if you can avoid it
(performance and code overhead from interfacing the two languages, being
constrained by an enforced separation between interelated parts of the
program, etc.) It is difficult to avoid having a separate scripting
language in C++ because it doesn't support incremental compilation. It's
certainly not impossible to avoid it (Half-Life doesn't have one, for
example), but you pay the price: make a trivial mistake in your Half-Life
mod code and the fix-reload-test cycle can be a couple of minutes long.

>> When programming in C++ you feel like a blind person trying to draw
>> something. You don't _see_ the data structures that your procedures
>> will operate on. Lisp programming is much more visual.
>
> That's because you are familiar with Lisp.

Indeed, it's much easier to express complex data structures in Lisp.

>> C++ lacks higher-order functions. Function objects emulate them
>> poorly, are slow and a pain to use. Additionally, C++ type system does
>> not work well with function objects.
>
> So what? It also makes the Prototype Pattern a pain in the nuts. These
> issues are not in the domain, they are just implementation alternatives.

This makes no sense. Higher order functions are a win, period. Function
objects are just less powerful than higher order functions (assuming that
these functions are closures). If you've been paying attention to R&D in
programming languages for the past 20-30 years, you'll notice that higher
order functions are one abstraction mechanism that just about every new
language has adopted (often prior to the development of C++). They're so
useful that some people have invested a lot of time into hacking some kind
of HOF facility into C++ (c.f. the Boost Lambda Library).

>> C++ lacks automatic memory management and so it encourages copying
>> objects around to make manual memory management manageable.
>> Reference-counting schemes are usually slower than modern garbage
>> collectors and also less general.
>
> Prefer pass-by-reference above all other kinds, because its cognitively
> efficient and usually execution efficient.

"Usually" being the operative word. You're also missing the OP's point
completely. If you pass by reference, you enormously increase the
complexity of your memory management code. Sure, C++ has lots of ways to
encapsulate this complexity, but you still have to deal with it, and the
common methods of doing this amount to using a buggy and rather inefficient
GC.


Alex



Phlip wrote:

>
> "Neo-LISPer" <neo_lisper@yahoo.com> wrote in message
> news:87k6tf9ev3.fsf@yahoo.com...
>> Hey
>>
>> Recently, I researched using C++ for game programming and here is what
>> I found:
>
> As other industries using C++ - even for highly graphical, rich-content
> physics simulations - report fewer of these problems, the game programming
> culture itself might be to blame.
>
>> C++ game developers spend a lot of their time debugging corrupted
>> memory. Few, if any, compilers offer completely safe modes.
>
> The alternative, garbage collection, tends to corrupt memory too. Have you
> heard of a high-availability Visual Basic program?
>
> Game programmers need efficient and deterministic garbage collection. If
> they don't code it themselves, following healthy styles, they will corrupt
> memory.
>
>> Unsurprisingly, there is a very high failure rate among projects using
>> C++ for modern game development.
>
> That's because there's a high failure rate period, and most games use C++.
>
>> You can not even change function definitions while the program is
>> running and see the effects live (the ultimate debugging tool).
>
> There are those who don't need to debug. The game programming industry has
> only begun to adopt unit testing in a very few shops.
>
>> Alternatively, you can't execute a small portion of the program
>> without compiling and linking the whole thing, then bringing your game
>> into a specific state where your portion of the code is being executed.
>
> Test isolation would help that. If objects are decoupled, you can write a
> test that plays with only one of them.
>
> Playing with unit test cases, and adding them very easily, is a great way
> to preserve all those little experiments, and convert them into
> constraints.
>
>> The static type system locks you into a certain design, and you can't
>> *test* new ideas, when they come to you, without redesigning your
>> whole class hierarchy.
>
> Then don't use the static type system.
>
>> C++ is so inflexible, even those who do use it for games, have to
>> write their game logic in some other language (usually very slow,
>> inexpressive and still garbage collected). They also have to interface
>> the two languages.
>
> You make that sound like a bad thing. Most programs have two languages
> (consider the glorious union of VB and SQL). Games need a scripting layer
> to decouple designing the game play from its engine. Most other
> applications with an engine use this model, too.
>
>> C++ lacks higher-order functions. Function objects emulate them
>> poorly, are slow and a pain to use. Additionally, C++ type system does
>> not work well with function objects.
>
> So what? It also makes the Prototype Pattern a pain in the nuts. These
> issues are not in the domain, they are just implementation alternatives.
>
>> C++ programs can not "think" of new code at run-time, and plug that
>> new code into themselves in compiled form. Not easily, anyway.
>
> So, uh, use the scripting layer?
>
>> C++ coding feels very repetitive, for example, when writing class
>> accessors, you often have to write const and non-const methods with
>> completely identical function bodies. Just look at STL.
>
> It sounds like you need to tell us you are less than perfectly adept at
> C++. Have you used it for games?
>
>> When programming in C++ you feel like a blind person trying to draw
>> something. You don't _see_ the data structures that your procedures
>> will operate on. Lisp programming is much more visual.
>
> That's because you are familiar with Lisp.
>
>> Constructors and smart pointers make it hard to tell cheap operations
>> from expensive ones.
>
> All cheap and expensive operations are impossible to predict and hard to
> tell apart. Profile.
>
>> C++ lacks automatic memory management and so it encourages copying
>> objects around to make manual memory management manageable.
>> Reference-counting schemes are usually slower than modern garbage
>> collectors and also less general.
>
> Prefer pass-by-reference above all other kinds, because its cognitively
> efficient and usually execution efficient.
>
>> Most important, C++ syntax is irregular, and you often find yourself
>> typing repetitive patterns again and again - a task easily automated
>> in languages with simpler syntax. There are even books on C++
>> patterns, and some C++ experts take pride in being able to execute
>> those patterns with computer-like precision - something a computer
>> should be doing to begin with.
>
> C++ syntax is somewhat irregular. But it's lack of a 'read_mind' keyword
> disturbs me most.
>
>> C++ programs are slow: even though the compilers are good at
>> micro-optimizing the code, programmers waste their time writing
>> repetitive patterns in C++ and debugging memory corruption instead of
>> looking for better algorithms that are far more important for speed
>> than silly micro-optimizations.
>
> How could that complaint be specific to C++?
>
>> It's hard to find good programmers for C++ projects, because most of
>> the good programmers graduated to languages like Lisp or avoided C++
>> altogether. C++ attracts unimaginative fellows with herd mentality.
>> For creative projects, you want to avoid them like a plague.
>
> That's because educating someone to write low-risk C++ is difficult.
> Vendors have clogged our markets with low-quality languages that purport
> to allow inept programmers to write code at a lower risk than C++
> provides.
>
> Games must have high performance, so C++ is the leading language for now.
>

"Neo-LISPer" <neo_lisper@yahoo.com> wrote in message
news:87k6tf9ev3.fsf@yahoo.com...
> Hey
>
> Recently, I researched using C++ for game programming and here is what
> I found:

As other industries using C++ - even for highly graphical, rich-content
physics simulations - report fewer of these problems, the game programming
culture itself might be to blame.

> C++ game developers spend a lot of their time debugging corrupted
> memory. Few, if any, compilers offer completely safe modes.

The alternative, garbage collection, tends to corrupt memory too. Have you
heard of a high-availability Visual Basic program?

Game programmers need efficient and deterministic garbage collection. If
they don't code it themselves, following healthy styles, they will corrupt
memory.

> Unsurprisingly, there is a very high failure rate among projects using
> C++ for modern game development.

That's because there's a high failure rate period, and most games use C++.

> You can not even change function definitions while the program is
> running and see the effects live (the ultimate debugging tool).

There are those who don't need to debug. The game programming industry has
only begun to adopt unit testing in a very few shops.

> Alternatively, you can't execute a small portion of the program
> without compiling and linking the whole thing, then bringing your game
> into a specific state where your portion of the code is being executed.

Test isolation would help that. If objects are decoupled, you can write a
test that plays with only one of them.

Playing with unit test cases, and adding them very easily, is a great way to
preserve all those little experiments, and convert them into constraints.

> The static type system locks you into a certain design, and you can't
> *test* new ideas, when they come to you, without redesigning your
> whole class hierarchy.

Then don't use the static type system.

> C++ is so inflexible, even those who do use it for games, have to
> write their game logic in some other language (usually very slow,
> inexpressive and still garbage collected). They also have to interface
> the two languages.

You make that sound like a bad thing. Most programs have two languages
(consider the glorious union of VB and SQL). Games need a scripting layer to
decouple designing the game play from its engine. Most other applications
with an engine use this model, too.

> C++ lacks higher-order functions. Function objects emulate them
> poorly, are slow and a pain to use. Additionally, C++ type system does
> not work well with function objects.

So what? It also makes the Prototype Pattern a pain in the nuts. These
issues are not in the domain, they are just implementation alternatives.

> C++ programs can not "think" of new code at run-time, and plug that
> new code into themselves in compiled form. Not easily, anyway.

So, uh, use the scripting layer?

> C++ coding feels very repetitive, for example, when writing class
> accessors, you often have to write const and non-const methods with
> completely identical function bodies. Just look at STL.

It sounds like you need to tell us you are less than perfectly adept at C++.
Have you used it for games?

> When programming in C++ you feel like a blind person trying to draw
> something. You don't _see_ the data structures that your procedures
> will operate on. Lisp programming is much more visual.

That's because you are familiar with Lisp.

> Constructors and smart pointers make it hard to tell cheap operations
> from expensive ones.

All cheap and expensive operations are impossible to predict and hard to
tell apart. Profile.

> C++ lacks automatic memory management and so it encourages copying
> objects around to make manual memory management manageable.
> Reference-counting schemes are usually slower than modern garbage
> collectors and also less general.

Prefer pass-by-reference above all other kinds, because its cognitively
efficient and usually execution efficient.

> Most important, C++ syntax is irregular, and you often find yourself
> typing repetitive patterns again and again - a task easily automated
> in languages with simpler syntax. There are even books on C++
> patterns, and some C++ experts take pride in being able to execute
> those patterns with computer-like precision - something a computer
> should be doing to begin with.

C++ syntax is somewhat irregular. But it's lack of a 'read_mind' keyword
disturbs me most.

> C++ programs are slow: even though the compilers are good at
> micro-optimizing the code, programmers waste their time writing
> repetitive patterns in C++ and debugging memory corruption instead of
> looking for better algorithms that are far more important for speed
> than silly micro-optimizations.

How could that complaint be specific to C++?

> It's hard to find good programmers for C++ projects, because most of
> the good programmers graduated to languages like Lisp or avoided C++
> altogether. C++ attracts unimaginative fellows with herd mentality.
> For creative projects, you want to avoid them like a plague.

That's because educating someone to write low-risk C++ is difficult. Vendors
have clogged our markets with low-quality languages that purport to allow
inept programmers to write code at a lower risk than C++ provides.

Games must have high performance, so C++ is the leading language for now.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

Christopher Benson-Manica <ataru@nospam.cyberspace.org> writes:

>> (inspired response to obvious troll)

> What part of "Do not feed the trolls" was hard to understand?

> Christopher Benson-Manica | I *should* know what I'm talking about - if I
> ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[I wouldn't normally participate in a flame-infested thread like
this, but since you're so literally asking for for things you need
to know..]

While I agree that the OP was trolling by posting his article to
c.l.c++, it is still my opinion that he was in many parts correct and
the "inspired" response was nothing but a display of complete
ignorance. Many of the issues raised by the OP are truly something you
need to know about (if you don't already), regardless of which
programming language you prefer, IMHO.

--
Frode Vatvedt Fjeld

> While I agree that the OP was trolling by posting his article to
> c.l.c++, it is still my opinion that he was in many parts correct and
> the "inspired" response was nothing but a display of complete
> ignorance. Many of the issues raised by the OP are truly something you
> need to know about (if you don't already), regardless of which
> programming language you prefer, IMHO.


Ignorance? Arrogance maybe? (no pun intended)

As for the issues raised being truly something you need to know about... do
you need to tell a child not to eat its own excrement? No. Why? It figures
that out for itself. If you're writing code and you have "new" all over the
place and you've no "delete"'s, then you'll figure out the aim of the whole
"Garbage Collection" ideal. I myself am not retarded, so I've no need for
"Garbage Collection". If, hypothetically speaking, I forsaw that I would
temporarily become retarded (a golfclub to the head maybe), then I would
make use of auto_ptr, but that has yet to happen.

Isn't great how we're all entitled to our own opinions! ;-P


-JKop

many of these issues may exist, but are not that big of a deal really, and
there is the problem that higher-level languages often have a poor c
interface and typically need interface stuff to be written to access c code
(and thus most system api's, along with parts of the project likely being
written in c).
c++ is typically much better at accessing c code than most other languages.

any other issues are fairly minor (there is a lack of convinient syntax for
many things, but these things are not that hard to pull off through other
means). some things would be nice (syntactic closures and lexical scoping,
....), but do not justify many other costs.

using languages other than c or c++ tends to end up being more expensive.

this post can be generally be referred to as trolling, however.


"Neo-LISPer" <neo_lisper@yahoo.com> wrote in message
news:87k6tf9ev3.fsf@yahoo.com...
> Hey
>
> Recently, I researched using C++ for game programming and here is what
> I found:
>
> C++ game developers spend a lot of their time debugging corrupted
> memory. Few, if any, compilers offer completely safe modes.
>
> Unsurprisingly, there is a very high failure rate among projects using
> C++ for modern game development.
>
> You can not even change function definitions while the program is
> running and see the effects live (the ultimate debugging tool).
>
> Alternatively, you can't execute a small portion of the program
> without compiling and linking the whole thing, then bringing your game
> into a specific state where your portion of the code is being executed.
>
> The static type system locks you into a certain design, and you can't
> *test* new ideas, when they come to you, without redesigning your
> whole class hierarchy.
>
> C++ is so inflexible, even those who do use it for games, have to
> write their game logic in some other language (usually very slow,
> inexpressive and still garbage collected). They also have to interface
> the two languages.
>
> C++ lacks higher-order functions. Function objects emulate them
> poorly, are slow and a pain to use. Additionally, C++ type system does
> not work well with function objects.
>
> C++ programs can not "think" of new code at run-time, and plug that
> new code into themselves in compiled form. Not easily, anyway.
>
> C++ coding feels very repetitive, for example, when writing class
> accessors, you often have to write const and non-const methods with
> completely identical function bodies. Just look at STL.
>
> When programming in C++ you feel like a blind person trying to draw
> something. You don't _see_ the data structures that your procedures
> will operate on. Lisp programming is much more visual.
>
> Constructors and smart pointers make it hard to tell cheap operations
> from expensive ones.
>
> C++ lacks automatic memory management and so it encourages copying
> objects around to make manual memory management manageable.
> Reference-counting schemes are usually slower than modern garbage
> collectors and also less general.
>
> Most important, C++ syntax is irregular, and you often find yourself
> typing repetitive patterns again and again - a task easily automated
> in languages with simpler syntax. There are even books on C++
> patterns, and some C++ experts take pride in being able to execute
> those patterns with computer-like precision - something a computer
> should be doing to begin with.
>
> C++ programs are slow: even though the compilers are good at
> micro-optimizing the code, programmers waste their time writing
> repetitive patterns in C++ and debugging memory corruption instead of
> looking for better algorithms that are far more important for speed
> than silly micro-optimizations.
>
> It's hard to find good programmers for C++ projects, because most of
> the good programmers graduated to languages like Lisp or avoided C++
> altogether. C++ attracts unimaginative fellows with herd mentality.
> For creative projects, you want to avoid them like a plague.
>
> It is my opinion that all of the above makes C++ a very bad choice for
> commercial game development.

On Mon, 25 Oct 2004 15:50:36 +0200, Hendrik Belitz wrote:

> Catalin Pitis wrote:
>>
>> "JKop" <NULL@NULL.NULL> wrote in message
>> news97fd.40000$Z14.14510@news.indigo.ie...
>>>
>>>>> Come to think of it, what *wasn't* written in C++?

Pretty much everything worthwhile.

>>>> Linux comes to mind.
>>>
>>>
>>> Really? What was it written in?
>>>
>> C
>>
>> Also MSDOS and MS WIndows were developed in C, as far as I know.

I doubt it. I'd bet MSDOS was written in assembler.

> You're totally correct in this. But most higher-order toolkits are written
> in C++.

> BTW: I don't know a single piece of "real" software that was written in LISP

I.e., you're ignorant. [By the way, it's spelled "Lisp", not "LISP"]

> (AFAIK even Emacs only uses LISP as an extension and scripting language:
> Something that is really bad bevhaviour according to the original troll ..
> eerrh ... poster).

Which Emacs? Emacs was original TECO macros (hence the name), then
Lisp. (Some) Unix versions are now written in C with (a crufty
ancient) Lisp as "extension language", yes (but there's hardly any
call for your "only": a fair amount of the core functionality is in
Lisp, and there's rather more Lisp than C there)

> I am also awaiting good examples for LISP 3D-Engines, LISP- OS kernels, LISP
> device drivers, LISP text processors or LISP numerical toolkits. Feel free

Google for "Mirai" and "Genera", for starters.

[You C++ types still have a way to go to catch up to 1980's Lisp :-)]

--
Malum est consilium quod mutari non potest -- Publilius Syrus

(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(#\@) "actrix.gen.nz>"))

JKop wrote:
<snip>
>> C++ coding feels very repetitive, for example, when writing class
>> accessors, you often have to write const and non-const methods with
>> completely identical function bodies. Just look at STL.
>
> Incorrect.
>
> If both function bodies are identical, then there's no need to write
> a non- const version.
>
> If there exists both a const version and a non-const version, then
> this indicates that one version alters the object, while the other
> doesn't. Conclusion: different code.
<snip>

Actually, it tends to indicate that one version returns a non-const
pointer/reference and the other returns a const pointer/reference.

[Followups trimmed]

Stewart.