C++ sucks for games

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.

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



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

Neo-LISPer wrote:

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

--
To get my real email adress, remove the two onkas
--
Hendrik Belitz
- Abort, Retry, Fthagn? -

> 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

JKop <NULL@NULL.NULL> writes:

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

Linux comes to mind.

>> Come to think of it, what *wasn't* written in C++?
>
> Linux comes to mind.


Really? What was it written in?



-JKop

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

Catalin

Catalin Pitis posted:

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

"JKop" <NULL@NULL.NULL> wrote in message
news:Je7fd.40004$Z14.14518@news.indigo.ie...
> Catalin Pitis posted:
>
>>
>> "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.
>>
>> 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

It seems not

Catalin

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

--
To get my real email adress, remove the two onkas
--
Hendrik Belitz
- Abort, Retry, Fthagn? -