C++ sucks for games

Neo-LISPer wrote:

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

Yes I can. I can write a module that runs one or two functions from the
project as the whole program.

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

I guess the answer is: if you can't find anyone to join your C++ team,
start your project in a language that everyone likes.

Have you checked out D? It addresses a handful of your issues....

http://www.digitalmars.com/d/

Stewart.

Neo-LISPer wrote:
<snip>

Yes, it does suck -- however it sucks a lot less than a majority of the other
available languages.

If you ever decide to come out of your cave and re-join society in a beneficial
manner, you should probably consider thoroughly studying the topic of languages
and posting a comprehensive comparison of them w/ respect to a particular
task/topic (such as game programming).

just for the sake of those out there who are actually interested in the
possiblilty of using or not using c++ for their games, let me correct
some of the bullshit misinformation here. i have removed comp.lang.c++
from the post list, because to them, this is all basic knowledge. i left
comp.lang.lisp in because i do not know their posting rules, so this may
be relevant there. if not, i apologize.

my only experience with lisp is autolisp in autocad. it was ok, but
personally, i lean more to python. to each his own.

Neo-LISPer wrote:

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

*NON-STATEMENT*
i seriously doubt that. i would bet c++ programmers spend the bulk of
their time designing and testing - this is what separates professionals
from hobbyists. i have no numbers to back my claim up, but neither does
the op.

does anyone have any data on how c++ or lisp programmers divide their time?

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

*NON-STATEMENT*
again, no numbers. but the fact that there are a lot of failed c++-based
projects is probably most likely due to the fact that there are a lot of
c++-based projects.

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

*BULLSHIT*
actually, i'm sure you can with some tools (it wouldn't be hard to do),
but i don't really see that as the ultimate debugging tool. more likely
a crutch for programmers who don't know what they're doing and have to
program by trial and error. but that's just opinion.

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

*BULLSHIT*
the very nature of the c++ compile-link model is designed to allow you
to work in modules. poor design could force you to recompile the whole
thing for a trivial change, but that's not the language's fault, it's
the programmer's.

as for specificially executing a small portion, look up unit testing.

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

*SURREAL BULLSHIT*
there is so little sense in this statement that i don't even know how to
argue it. suffice it to say that every statement in the above is at
least mostly false.

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

*SOMEWHAT TRUE, BUT MISSES POINT*
firstly, the line: "those who do use it for games, have to write their
game logic in some other language" is bullshit. no-one "has" to do
anything in c++, or lisp i imagine. still many choose to voluntarily.
this statement also undermines the op's point (assuming he had any). if
c++ is so awful, why do people use it anyway, and go through the effort
of interfacing it with other languages? and are you saying that c++ is
fast and expressive, cause that seems contradictory to the rest of your
"argument"?

one of the fundamental tenets of design is to separate data from logic.
"game" logic is not the same as "program" logic. simply put, program
logic describes how the program works, and game logic describes how the
game works. good design would suggest that you could make a game engine
then use that same engine to run many different types of games. the game
engine is the program logic, and the game logic is part of the actual game.

here's an example. say i write a wicked fps game engine. the program
logic is how the engine interacts with the sound, graphics and input
hardware. now i make a game for that engine. some of the stuff i'll have
to add includes things like sound and graphics data, but i'll also be
adding game logic, like the flow of the game (ex. once you get into the
hangar, you then start the second chapter, the search for the
laboratory), descriptions of sub-quests (ex. to get the medal of honour,
you must destroy the missle launch computers before any of them fire)
and even the ai (ex. search for cover if any is available, otherwise
just bum rush the player). those things can change from game to game, so
they should be separate from the main engine.

the other important thing to consider is that proper programming
practice requires that if you change any part of a module, you have to
retest the whole thing. so if i were to include the game logic in the
game engine, and i wanted to make the ninjas more agressive, i'd have to
retest the whole game engine. that's just idiotic. so i make the game
logic separate.

so that's why the game logic is separate, but why make it in another
language? because c++ is a very complicated language, and using it to
write a ninja's ai is like using a backhoe to plant a tulip. also, like
any powerful tool, if used incorrectly, you can take a limb off. the
power of c++ is not required when making game logic (most of the time,
there are exceptions). so instead, make your game logic in a simple
language so that the artists and game designers can understand it. that
way, valuable programmer time isn't diverted from optimizing and testing
the engine, and the game designers and artists get more control over the
game, which is what they want i imagine.

in summary: c++ is *so* flexible that it allows you to interface with
other langauges that are less powerful, but simpler. doing this allows
you to delegate non-critical sections of non-engine code to be written
in languages more easily learned and used by non-programmers.

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

*SURREAL BULLSHIT*
wha? the only thing i can partly understand there is that function
objects are a pain to use. fair enough. but that's a matter of opinion.
and as c++ compilers become more standards compliant, we'll be able to
take more advantage of thinks like Boost.Lambda, which mostly negates
the issue.

every other statement above is nonsense.

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

*BULLSHIT*
of course they can. and as easily as any other language's program too.
they can even be jit compiled, if you want, but they're so fast by
default that there isn't much interest in it.

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

*TRUE*
power comes at a price.

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

*OPINIONATED BULLSHIT*
i see my code and data perfectly well, thank you.

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

*IRRELEVANT BULLSHIT*
then rtfm to find out which operations are expensive. furthermore, you
can't accidently call a constructor (unless you really don't know what
you're doing) - constructor calls are blatantly obvious.

as for smart pointers, if your smart pointer is expensive to use, get a
better one. making an expensive smart pointer is not smart at all - in
fact, it's dumber than making an expensive 3d vector class (which is
remarkably stupid).

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

*SURREAL BULLSHIT*
c++ has automatic memory management. it's called the stack. as for
whether c++ "encourages" unnecessary object copying, considering the
many mechanisms c++ includes for avoiding it i'd have to say that's a
bit of a stretch. of course, if you *want* to manually manageme memory,
you're free to do so.

also... garbage collection requires reference counting, einstein. and
even if it didn't you can implement garbage collection in c++.

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

*UNCLEAR BULLSHIT*
i'm not 100% sure what you're talking about here. if you're talking
about repetetive syntax, i already conceded that above. but if you're
talking about *design patterns*, then you don't have a clue what you're
talking about.

design patterns are constructs used to model the behaviour of code. they
are not literal patterns of code.

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

*BULLSHIT*
complete crap.

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

*FUNNY BULLSHIT*
moo.

this is the first time i've been compared to a plague.

> It is my opinion that all of the above makes C++ a very bad choice for
> commercial game development.

i'm sure john carmack would love your input.

my own opinion is that any given game could be done in c++ alone with
not much problem. the same is true for lisp. however, combining the
strengths of the two would lend more power to the game programmer to
make better games with less work in less time. can't we all just get along?

indi

Phlip wrote:

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

stroustrup probably meant to put that in, but there would have been way
to many issues with null mind pointers.

indi

>>>>>> Come to think of it, what *wasn't* written in C++?
>
> Pretty much everything worthwhile.


Retard.


-JKop

Alex Drummond wrote:

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

i'm sorry, you don't know what a c++ reference is.

you do not increase the difficulty of memory management with c++
references, unless you're straddling two different threads. you don't
have to manage the memory of references at all - they are, after all,
references. references have no overhead either.

there is no complexity, and there is no encapsulation of c++ references
that I have ever heard of. nor can i see any valid reasons for it.

you may be thinking of some other kind of reference, as in
reference-counted references, aka smart pointers.

indi

In article <417cf072$1@duster.adelaide.on.net>,
"Maahes" <maahes@internode.on.net> wrote:

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

Post the C version (or just give a fuller spec) and I'll try it in Lisp.


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

I wonder which Lisp you were using. The modern Common Lisp has all kinds
of ways to iterate, some simple, some complex, and one (LOOP) which is
effectively a built-in iteration mini-language. So no one is forced to
do recursion, and many Lispniks frown on it style-wise if an iterative
approach would work.

Recursion takes a while to get the hang of, but not long and then it can
be quite elegant.


kenny

Neo-LISPer wrote:

> Hey
>
> Recently, I researched using C++ for game programming and here is what
> I found:
[Snip -- This section already commented on by others elsethread.]

>It is my opinion that all of the above makes C++ a very bad choice for
> commercial game development.
It is your opinion and you are welcome to it.

My observation from watching shows on video games is that there
are only a handful of different types. My guess is that the
engine is written in some language, Pascal, C++, Lisp, and
each "level" is written in a higher level language. Once the
engine is working, they don't change it. Most of the changes
are made using the higher level language. A video game project
doesn't want its time wasted in coding up each level in C++,
C, Pascal, Ada or whatever. A less time-consuming method is
to write each level using a higher level language. Many
game shops have specialized languages for their engines.

Perhaps you need to learn that the choice of the language
is not the issue. The issue is the quality of the product
that one can produce using the given language. If the
shop dictates that assembly is the language, then the
company must produce the best quality product using
assembly. In many shops, there is no choice on which
language can be used. You use their language and live
with it.

So if you are independently developing games, then by
all means, use the language you are most comfortable
with. However, do the rest of us a favor and keep
your opinions of other languages to yourself. The
issue of the "best" language for a given project is
and will always be a religous issue.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

I do know what a C++ reference is. I was using the term rather ambiguously
between a reference in general (i.e. a C++ pointer or a C++ reference) and
an actual C++ reference, because it doesn't make much difference.
References increase memory management complexity just as much as pointers
do; the only difference is that you can't really do any memory management
with a reference, so it's only /correctly/ useable in bits of code which
can take a reference/pointer to a data structure without worrying how it
has been allocated. This does not in any way simplify the management of
references (general concept) in C++ -- you still have to think about who
"owns" the memory that is referenced (general concept), and either keep all
the details in your head, or use C++ smart pointers along with an
inefficient reference-counting method or some such. If it was possible to
write real-world C++ programs using only references and not pointers, I
would take your point, but the fact remains that passing by
reference/pointer invloves more thinking about memory management than
passing by value, which cannot possibly cause a memory leak (unless you
have something funky in a copy constructor).

To move away from the technicalities, you have basically three memory
management options in C++:

1) Pass by value. Sometimes inefficient, easy to understand.
2) Pass by pointer/reference. Usually efficient, memory management becomes
complex and scattered throughout the code.
3) Pass by smart pointer. Easy to understand, but usually more overhead than
a GC.

(This is not to say that one of these methods must be used exclusively
throughout a program).


Alex



Mark A. Gibbs wrote:

>
> Alex Drummond wrote:
>
>>>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.
>
> i'm sorry, you don't know what a c++ reference is.
>
> you do not increase the difficulty of memory management with c++
> references, unless you're straddling two different threads. you don't
> have to manage the memory of references at all - they are, after all,
> references. references have no overhead either.
>
> there is no complexity, and there is no encapsulation of c++ references
> that I have ever heard of. nor can i see any valid reasons for it.
>
> you may be thinking of some other kind of reference, as in
> reference-counted references, aka smart pointers.
>
> indi

On Mon, 25 Oct 2004, Mark A. Gibbs wrote:

> c++ has automatic memory management. it's called the stack.

And won't manage your memory unless you fit a certain usage pattern, but
hey.

> also... garbage collection requires reference counting, einstein. and
> even if it didn't you can implement garbage collection in c++.
>

It doesn't require reference counting, and reference counting is severely
flawed as GC systems go - the only real advantage being the predictable
performance. You can at best implement conservative GC for a C++ program.
A proper garbage collector needs to know more about the structures it's
working on than a C++ implementation can hope to discover about arbitrary
data.

--
flippa@flippac.org