C++ sucks for games

N

Neo-LISPer

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

=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=

Neo-LISPer said:
...

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.
My opinion to others:

Do not feed the trolls. Please!
 
M

Maahes

hmm. I remember vividly doing lisp at uni.
I think the assignment was a simple long division problem. I remember that
only a few people in the entire class managed to work out a way of achieving
it... I problem that is a newbie would do in C without breaking a sweat.

After that, no-one ever used lisp again...

...except the Jax & Daxter developers. Their game engine runs on an
interpretted lisp platform (I believe) and has spawned some of the most
impressive platformers I've ever seen...

So the moral is....
I don't know, but I won't be switching to Lisp any time soon...
Maybe its good once you get the hang of it...
But I think it may be too recursive & bottom-up programming for most brains
to want to deal with...
 
H

Hendrik Belitz

Neo-LISPer said:
Some senseless stuff

Besides your poor trolling attempts (most of your arguments just show that
you have no knowledge of C++) you don't even tell us what the alternative
to C++ in game programming could be.
 
J

JKop

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

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

There's a 90% failure rate for lions when hunting. They still eat.

I would presume that that "very high failure rate" becomes a bit lower when
you're dealing with proficient C++ programmers.
You can not even change function definitions while the program is
running and see the effects live (the ultimate debugging tool).

Nothing to do with the language. Such a debugging tool could be developed,
why not develop it?

I myself wouldn't use it.
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.

That's because there's no such thing as "half a program". If you really want
this, copy-paste it to another file and just append:

int main(){}

to the end of it.
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.

Bullshit. Vague bullshit.
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.

Provide an example. I myself forsee no reason or motive to do or have to do
this.
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.

"function objects". Get over it! It's just syntatic sugar!
C++ programs can not "think" of new code at run-time, and plug that
new code into themselves in compiled form. Not easily, anyway.

"think of new code at run-time". That's because it takes intelligence to
write code, something which computers lack. As for the code coming from
somewhere else, well it's done extremely easily actually - we call it
dynamic linkage.
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.

You could also make the non-const version call the const version, and then
just do something extra.
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.

"procedures"? Never heard of them. I've heard of "functions" alright. I must
say I don't... see... your argument, no pun intended.

If you have a function which takes in an object of a certain class, or as
you call it "data structure", then... (actually, it's so simple I'm not even
going to finish this paragraph).
Constructors and smart pointers make it hard to tell cheap operations
from expensive ones.

Bullshit. Vague bullshit.
C++ lacks automatic memory management and so it encourages copying
objects around to make manual memory management manageable.

int auto k = 4;

int* auto p_w = new int(4);
Reference-counting schemes are usually slower than modern garbage
collectors and also less general.

Which "garbage collector"? "less general" = vague bullshit.
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.

I don't see your argument. I've never encountered such.
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.

There's books on a lot of things.
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.

Define "programmers". I myself don't fit into the inuendo of a definition in
the above.
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.

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

Come to think of it, what *wasn't* written in C++?
It is my opinion that all of the above makes C++ a very bad choice for
commercial game development.

My opinion differs.


-JKop
 
M

Mikael Brockman

JKop said:
AKA Retarded mode.


There's a 90% failure rate for lions when hunting. They still eat.

I would presume that that "very high failure rate" becomes a bit lower when
you're dealing with proficient C++ programmers.


Nothing to do with the language. Such a debugging tool could be developed,
why not develop it?

I myself wouldn't use it.


That's because there's no such thing as "half a program". If you really want
this, copy-paste it to another file and just append:

int main(){}

to the end of it.


Bullshit. Vague bullshit.


Provide an example. I myself forsee no reason or motive to do or have to do
this.


"function objects". Get over it! It's just syntatic sugar!


"think of new code at run-time". That's because it takes intelligence to
write code, something which computers lack. As for the code coming from
somewhere else, well it's done extremely easily actually - we call it
dynamic linkage.


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.

You could also make the non-const version call the const version, and then
just do something extra.


"procedures"? Never heard of them. I've heard of "functions" alright. I must
say I don't... see... your argument, no pun intended.

If you have a function which takes in an object of a certain class, or as
you call it "data structure", then... (actually, it's so simple I'm not even
going to finish this paragraph).


Bullshit. Vague bullshit.


int auto k = 4;

int* auto p_w = new int(4);


Which "garbage collector"? "less general" = vague bullshit.


I don't see your argument. I've never encountered such.


There's books on a lot of things.


Define "programmers". I myself don't fit into the inuendo of a definition in
the above.


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

Come to think of it, what *wasn't* written in C++?

Linux comes to mind.
 
J

JKop

Catalin Pitis posted:
C

Also MSDOS and MS WIndows were developed in C, as far as I know.

Catalin



HHHHHHaaaaaaaaaaaaaaaaa ha ha haaaaaaaaaaaaaaaaaaaaaaaa

HHaaaaaaaaaaaaaaaaa HHHHHAaaaaaaaaaa

ha ha ha


OOOHhhhhhhhhh, it's too much.


Didn't we switch from coal to oil yyeeaarrss ago?


-JKop
 
C

Catalin Pitis

JKop said:
Catalin Pitis posted:




HHHHHHaaaaaaaaaaaaaaaaa ha ha haaaaaaaaaaaaaaaaaaaaaaaa

HHaaaaaaaaaaaaaaaaa HHHHHAaaaaaaaaaa

ha ha ha


OOOHhhhhhhhhh, it's too much.


Didn't we switch from coal to oil yyeeaarrss ago?


-JKop

It seems not :D

Catalin
 
H

Hendrik Belitz

Catalin said:
C

Also MSDOS and MS WIndows were developed in C, as far as I know.

Catalin

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

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
to copy your whole project source code for these topics to your
news-transfer-daemon /dev/null...
 
A

Alex Drummond

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).
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.
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).
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.
That's because you are familiar with Lisp.

Indeed, it's much easier to express complex data structures in Lisp.
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).
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
 
P

Phlip

Neo-LISPer said:
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.
 
A

Alex Drummond

BTW: I don't know a single piece of "real" software that was written in
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).

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 to copy your whole project source code for these topics to your
news-transfer-daemon /dev/null...

I don't want to feed the troll, but you're showing some pretty incredible
ignorance. Just go to the "success stories" section of any lisp vendor's
website if you want to find some examples of real applications written in
lisp.

LISP 3D-Engines: None that I know of, I expect there's one or two.
LISP kernels: Plenty. Google for "lisp machine".
LISP device drivers: Same as for kernels.
LISP numerical toolkits: Probably they exist; don't know of any. This is
just a library issue.


Alex
 
F

Frode Vatvedt Fjeld

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

JKop

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
 
C

cr88192

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,480
Members
44,900
Latest member
Nell636132

Latest Threads

Top