C++ sucks for games

264 views
Skip to first unread message

Neo-LISPer

unread,
Oct 25, 2004, 8:11:44 AM10/25/04
to
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.

Maahes

unread,
Oct 25, 2004, 8:24:13 AM10/25/04
to
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_l...@yahoo.com> wrote in message
news:87k6tf9...@yahoo.com...

Hendrik Belitz

unread,
Oct 25, 2004, 8:31:51 AM10/25/04
to
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? -

Maahes

unread,
Oct 25, 2004, 8:25:44 AM10/25/04
to
I think he's suggesting its Lisp...

"Hendrik Belitz" <honkaonk...@fz-juelich.de> wrote in message
news:2u49l9F...@uni-berlin.de...

JKop

unread,
Oct 25, 2004, 9:08:22 AM10/25/04
to

> 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

Mikael Brockman

unread,
Oct 25, 2004, 9:16:36 AM10/25/04
to
JKop <NU...@NULL.NULL> writes:

Linux comes to mind.

JKop

unread,
Oct 25, 2004, 9:25:40 AM10/25/04
to

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


Really? What was it written in?

-JKop

Catalin Pitis

unread,
Oct 25, 2004, 9:29:10 AM10/25/04
to

"JKop" <NU...@NULL.NULL> wrote in message
news:o97fd.40000$Z14....@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


JKop

unread,
Oct 25, 2004, 9:31:21 AM10/25/04
to
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

Catalin Pitis

unread,
Oct 25, 2004, 9:42:05 AM10/25/04
to

"JKop" <NU...@NULL.NULL> wrote in message
news:Je7fd.40004$Z14....@news.indigo.ie...

It seems not :D

Catalin


Hendrik Belitz

unread,
Oct 25, 2004, 9:50:36 AM10/25/04
to
Catalin Pitis wrote:

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

Stefan Scholl

unread,
Oct 25, 2004, 9:57:08 AM10/25/04
to
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! :-)

Stefan Scholl

unread,
Oct 25, 2004, 9:59:06 AM10/25/04
to
On 2004-10-25 15:50:36, Hendrik Belitz wrote:

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

What's the color of the sky in your world?

Christopher Benson-Manica

unread,
Oct 25, 2004, 10:07:55 AM10/25/04
to
In comp.lang.c++ JKop <NU...@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.

cr88192

unread,
Oct 25, 2004, 10:14:02 AM10/25/04
to

"Catalin Pitis" <catali...@iquestint.com.renameme> wrote in message
news:2u4dcoF...@uni-berlin.de...
afaik dos was assembler...

Phlip

unread,
Oct 25, 2004, 10:26:16 AM10/25/04
to

"Neo-LISPer" <neo_l...@yahoo.com> wrote in message
news:87k6tf9...@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/bin/view/Main/TestFirstUserInterfaces


Frode Vatvedt Fjeld

unread,
Oct 25, 2004, 10:37:36 AM10/25/04
to
Christopher Benson-Manica <at...@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

Alex Drummond

unread,
Oct 25, 2004, 9:56:20 AM10/25/04
to
> 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.
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

JKop

unread,
Oct 25, 2004, 10:42:38 AM10/25/04
to

> 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

cr88192

unread,
Oct 25, 2004, 10:42:59 AM10/25/04
to
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_l...@yahoo.com> wrote in message
news:87k6tf9...@yahoo.com...

Paul Foley

unread,
Oct 25, 2004, 11:04:32 AM10/25/04
to
On Mon, 25 Oct 2004 15:50:36 +0200, Hendrik Belitz wrote:

> Catalin Pitis wrote:
>>
>> "JKop" <NU...@NULL.NULL> wrote in message
>> news:o97fd.40000$Z14....@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>"))

Alex Drummond

unread,
Oct 25, 2004, 10:22:32 AM10/25/04
to
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

Stewart Gordon

unread,
Oct 25, 2004, 11:06:00 AM10/25/04
to
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.

Stewart Gordon

unread,
Oct 25, 2004, 11:12:07 AM10/25/04
to
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.

Julie

unread,
Oct 25, 2004, 11:24:26 AM10/25/04
to
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).

Mark A. Gibbs

unread,
Oct 25, 2004, 11:34:45 AM10/25/04
to Neo-LISPer

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

Mark A. Gibbs

unread,
Oct 25, 2004, 11:50:18 AM10/25/04
to Phlip

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

JKop

unread,
Oct 25, 2004, 11:55:19 AM10/25/04
to

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


Retard.


-JKop

Mark A. Gibbs

unread,
Oct 25, 2004, 11:57:24 AM10/25/04
to

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

Kenneth Tilton

unread,
Oct 25, 2004, 12:53:40 PM10/25/04
to
In article <417cf072$1...@duster.adelaide.on.net>,
"Maahes" <maa...@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

Thomas Matthews

unread,
Oct 25, 2004, 1:28:03 PM10/25/04
to
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

Philippa Cowderoy

unread,
Oct 25, 2004, 1:44:04 PM10/25/04
to
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.

--
fli...@flippac.org

M Jared Finder

unread,
Oct 25, 2004, 1:58:40 PM10/25/04
to
Neo-LISPer wrote:
> Hey
>
> Recently, I researched using C++ for game programming and here is what
> I found:

While I personally prefer Lisp for my side projects, C++ is not an
absolutely horrid language for game development. It is definitely much
better than C; overloading operators and templates allow a "weak man's
macro system" and virtual functions provide some much-needed dynamicness.

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

Why must both sides of the garbage collection debate go to such extremes?

Pro-garbage collectors say that garbage collection prevents all resource
leaks. I know that this is not true as I have seen many resource
"leaks" occurring because the programmer forgot that some part of the
code would hold a reference to some data.

Anti-garbage collectors say that garbage collection is fast, but with
unreliable slowdowns. While this is true, I have found that in
application development, the slowdown is not noticeable at all. I view
arena allocation and deallocation as a more game-centric garbage
collector, which works quite well in many games.

On the whole, I find that I rarely need garbage collection in my
programs. But when I do need garbage collection, I *really* need it. I
think Lisp is right here to default to the more general solution
(garbage collection) unless you explicitly tell it otherwise.

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

There is a very high failure rate among modern game development
projects, period. I don't think this has as much to do with the
programming language as it does with insane schedules/no real
direction/increased expectations. This is improving. Supposedly.

That doesn't mean that using a more high level language wouldn't speed
up development -- it would.

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

A REPL debugging mechanism allowing function definitions is extremely
cool. If it had an integrated unit-test tester, that would be super
good. It's so good that I find myself implementing a half-assed REPL
test loop for any language which doesn't have a built in one. In C++ it
looks like this:

void functionToTest( int a, string& b );

int main() {
int a;
string b;

while( true ) {
BKPT();
functionToTest( a, b );
}
}

Every reasonable debugger will let me change the values of a and b.
It's a Read, Eval, Print Loop with out the Reading. :P

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

I can't comment on this one way or the other, as I only have a few
months experience with Lisp. My guess is that the implicit interface
will prove similarly difficult to modify with Lisp as the static type
system does with C++.

Any eXtreme Programming Lispers or C++-ers care to comment?

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

This is a very valid point. Game logic is one of the most obvious
applications of a REPL and function redefinition at runtime, which is
why many games use a language such as Python that supports such
features. As stated above, this is a great feature for *any* part of
development.

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

Really? I find that function object emulate higher order functions
extremely well. It would be nice if the dispatch on them could be
either static (using templates and overloading) or dynamic (using
virtual functions), but it's simple to create such a library.

The main problem I have with function objects is that writing a separate
class is distributing logic in a way that's both confusing and annoying.
I should not have to write a separate class for this one function when
all the logic for that class is available to the compiler.

I already know about Boost.Lambda and I have found it to be impossible
to use. Every time I make a little change in my lambda function, I get
tons upon tons of errors. I last tried to use Boost.Lambda about a year
ago; has it improved its usability?

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

I assume you are thinking about closures like cl-ppcre uses. While this
is doable in C++ using template meta-programming, it's so convoluted to
not be usable. C++ really needs a macro system like Lisp's.

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

A better macro system would help here again. I know that I'd much
rather write:

DEF_ACCESSOR( int foo(), { /* code */ } );

than

int foo_impl() const { /* code */ };
int foo() const { return foo_impl(); }
int foo() { return foo_impl(); }

The first is just more to the point.

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

I have no idea what you are saying here. Can you give an example of a
problem where the solution in Lisp is much more visual than in C++?

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

Any language with flexible abstractions is going to have this problem.
Can you tell me if foo() is faster or slower to execute than bar(a,b)?

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

See above for my feelings on garbage collection.

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

I agree here as well. C++'s syntax is awful, and its deduction rules
are even worse. This made Boost.Lambda to be such a pain to use. A
good macro system would help here as well.

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

As stated before, macros would be nice. Unlike template meta
programming, I find that quasi quotation macros make sense.

> 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 seems to be quite easy to find good programmers for C++ projects.
It's hard to find great C++ programmers; the kind that think outside the
proverbial box. Lisp seems to encourage such thinking by its very
nature of being a programmable programming language. They're there, but
they are also much more rare.

If this is a good or bad thing is left to the company

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

Since you stated many strengths of Lisp, it is natural that on most of
these statements, Lisp is better. On the whole, Lisp and C++ are very
similar (except with regards to macros), Lisp and Python/Java/C#/your
favorite dynamic language even more so. Lisp and C++ just take
different approaches to what the default assumption should be:

Lisp tries to assume the most general, and let the programmer specify
specifics when the generic solution is too slow. Lisp prematurely
pessimizes.

C++ tries to assume the fastest possible thing, and let the programmer
specify generics when needed. C++ prematurely optimizes.

So which is worse? Premature optimization is the root of all evil, but
premature pessimization is the leaf of no good. I prefer to start with
the general case and then optimize the hell out of it if needed, but
other programmers differ.

-- MJF

M Jared Finder

unread,
Oct 25, 2004, 2:15:41 PM10/25/04
to
Mark A. Gibbs wrote:

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

But there is no reason they can't be. After all, structures are pattern
with all the following properties:

* (Speed)
You can access all the members of a structure in constant time.
* (Atomicness)
Given a pointer to a structure, you can access all of the members.
* (Heterogeneous)
A structure's members can hold different types

Given these requirements, its trivial to write a quasi quotation macro
that has all these properties; just place the members down in sequential
positions in memory. Why not automate that?

This is where Lisp macros shine; they allow you to express design
patterns *as code*, making describing them much more explicit, and using
them much easier. Templates somewhat serve this purpose, but I find
template meta programming to be way to confusing compared to the simpler
and more direct quasi quotation system. Compare the template meta
programming examples in Alexadrescu's "Modern C++ Design" to the quasi
quotation examples in Graham's "On Lisp".

-- MJF

Alex Drummond

unread,
Oct 25, 2004, 1:33:11 PM10/25/04
to
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

Alex Drummond

unread,
Oct 25, 2004, 1:46:04 PM10/25/04
to
Mark A. Gibbs wrote:

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

What if you make a change to a module that every other module depends on?
Then you have to recompile the whole program, which you wouldn't always
have to do in Lisp. Unit testing is not a pratical replacement for a REPL.
If you just want to (say) play around with some standard library functions
to prototype some new code, you cannot do that with a unit testing
framework. The Lisp philosophy is that if you want to execute some bit of
code, you should just be able to say: "execute this bit of code". There
should not be a unit testing framework complicating such a simple action.

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

It's semi-bullshit. Static type systems can make refactoring more tricky.
Ocasionally you might have to redesign your class hierachy. OP is just
exaggerating here.

> [discussion of game engine/logic separation]
Writing different modules of a program in a different language is not an
optimal modularisation technique. Ideally you would be able to write all
modules of your program in the same language (while still keeping them
entirely separate, if you wished). C++ makes this difficult in some cases.
The idea that high-level scripting languages are less powerful than C++ is
pretty absurd, given that they tend to have much better abstraction
features. The reason they are needed is that they are more powerful (at
least in the sense of fewer lines of code for the same bang).


Alex

Lisptracker

unread,
Oct 25, 2004, 2:47:32 PM10/25/04
to
"JKop" <NU...@NULL.NULL> news:aV6fd.39997$Z14....@news.indigo.ie...

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

With C++ you can't vary safe/fast mode on per function or per line
basis.

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

Actually, you can change program during execution (at least in VC++
7.1) however in half of cases you have to stop and recompile 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.

Than cut and add "main()" to another file and stop/start program each
time ??? In Lisp you can share intermediate data between small
portions of the program.

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

You forced to think of types all time. It's kind of unnecessary
foresight in many cases.

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

You have to use interpreter for scripting. Hardly It would be
interpreter of C++.

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

Really? IMHO they are very limited imitation of closures.



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

I.e. C++ self-reflection sucks.



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

So "cut and paste" technology is used all time ;-))

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

It means that on Lisp you can easily try current piece code to see it
does well and write another small piece. In C++ you forced to write as
much as possible before you start visualize results (maybe because
"edit and continue" doesn't work properly?).

> > 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);

From MSDN:

"The auto storage-class specifier declares an automatic variable, a
variable with a local lifetime. It is the default storage-class
specifier for block-scoped variable declarations

An auto variable is visible only in the block in which it is declared.
Few programmers use the auto keyword in declarations because all
block-scoped objects not explicitly declared with another storage
class are implicitly automatic. Therefore, the following two
declarations are equivalent:

// auto_keyword.cpp
int main()
{
auto int i = 0; // Explicitly declared as auto.
int j = 0; // Implicitly auto.
}
"
Is that automatic memory managment ???


> > Reference-counting schemes are usually slower than modern garbage
> > collectors and also less general.
>

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

What's the difference ??? Anyway reference-counting is slower than
modern generational GCs.

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

It means no macro. C preprocessor and templates is hardly comparable
with Lisp macro.



> > C++ programs are slow: even though the compilers are good at

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

You are mistaken: MS-DOS and Linux were not written in C++ (maybe
because C++ compilers at that time were very buggy). And also very
doubtful that Windows XP core was written in C++.

Many many things were not written in C++.

Lisptracker

Mark A. Gibbs

unread,
Oct 25, 2004, 3:50:03 PM10/25/04
to

Alex Drummond wrote:

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

ah, but it does, because there is a difference between general
references and c++ references, and that difference invalidates your
entire argument.

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

c++ references are non-owning references ("weak" references if you
will). therefore, no management required, or even really logical.

you are correct when you say that you do have to be concerned that the
underlying data does not go out of scope before the reference. however,
in practical code, all references are always valid. unless you perform
some acrobatics (ie, bad code design) or are dealing with threading
issues, references will naturally go out of scope before the "real"
object. there is no "management". the only things you do to references
is make them and use them. you can't copy them around really.

you really never need to know how data was allocated or where it is in
memory (and even which memory it is in) to work with it in c++, unless
you are allocating or freeing it, and that responsibility should be in
the same place. but by convention, when data is passed or returned by
reference, it is not the responsibility of any client code.

> If it was possible to
> write real-world C++ programs using only references and not pointers, I
> would take your point,

of course it's possible. but it's also possible to build an airplane
from scratch using only a screwdriver. it's just not really smart, or easy.

using references only is actually easy to do, it just unnecessarily
limits your design options.

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

references cannot cause memory leaks.

when passing bare pointers around (which i personally frown on), you
have to make clear in documentation who owns the pointer. otherwise,
yes, you can end up with memory leaks. or, you can do it the right way
and pass smart pointers around.

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

false. memory management becomes complex and scattered if you make it
complex and scatter it. the use or non-use of pointers or references
does not cause or solve that.

in good design, memory is freed by the same entity that allocated it.
the use of pointers or references does not invalidate good design. it
allows you to if you so choose, and sometimes that's a valid design
decision. but if your memory management is scattered and out of control,
that's your fault, not any language's.

> 3) Pass by smart pointer. Easy to understand, but usually more overhead than
> a GC.

i honestly have never heard that before in my life. please show me
numbers. here are mine, off a paper advocating garbage collection
(http://www.lisp-p.org/wgc/) no less:

manual gc type
0.0 0.0 static allocation
0.0 0.9 individual blocks
0.9 16.3 individual lists
0.3 15.3 blocks in random order (general case)

50 times slower. hm.

now, this page (http://www.boost.org/libs/smart_ptr/smarttests.htm)
shows that the worst case performance for smart pointers is about 3
times slower than naked pointers. therefore, smart pointers are still
about 17 times faster than garbage collection. again, please show me
your numbers.

the smart pointer included with my compiler std::auto_ptr<T> takes up
exactly the same amout of memory as a bare pointer. copying it costs one
4 byte stack push, one function call, one 4-byte memory access and one
4-byte memory write. interleaved on a modern processor, those operations
(according to my estimate) would cost the same a simple bare-pointer
copy in practical usage (taking things like return-value optimization
into account). in other words, there should be no measurable difference.

now, smart pointer is a category, not a specific type, so it's quite
possible that there are smart pointers out there that are more expensive
than a given garbage collector. but show me some numbers. i don't see
either std::auto_ptr<T> or std::tr1::shared_ptr<T> (aka
boost::shared_ptr<T>) being one of them.

one thing that most gc advocates i've talked to don't seem to get is
that when using garbage collection, *all* pointers are smart pointers.
the only difference between gc smart pointers and traditional c++ smart
pointers is that when they go out of scope, c++ smart pointers free the
memory, whereas gc smart pointers just indicate (doesn't matter how they
do it) to the garbage collector that the memory can be freed at its
convenience. of course, smart pointers in c++ could do the same thing,
and i have one that does. garbage collection is just a special case of
the smart pointer design pattern.

besides, with a garbage collected-only language, you can't practically
implement raii, and i think that's a serious flaw.

there are no perfect solutions, but by cobbling together a collection of
imperfect solutions, you can still do pretty well. i don't consider
garbage collection "new, untested, & questionable", as this page
(http://www.lisp-p.org/wgc/) bizarrely claims "C & C++ programmers" do.
if it is the best solution, i will use it. if it's not, i'll use
something else. but not having options sucks.

indi

Joe Laughlin

unread,
Oct 25, 2004, 3:20:43 PM10/25/04
to
JKop wrote:
>>> Come to think of it, what *wasn't* written in C++?
>>
>> Linux comes to mind.
>
>
> Really? What was it written in?
>
>
>
> -JKop

C and assembly. Look at the source for it.

And I don't think MS-DOS could've been written in C++, wasn't that before
C++ was around?

Howard

unread,
Oct 25, 2004, 4:13:24 PM10/25/04
to

"Neo-LISPer" <neo_l...@yahoo.com> wrote in message
news:87k6tf9...@yahoo.com...

Personally, I couldn't care less! What're you trying to accomplish, change
someone's mind? No, you're just trolling. So get lost, and let us do some
real work.

-Howard


Mark A. Gibbs

unread,
Oct 25, 2004, 4:24:50 PM10/25/04
to

Alex Drummond wrote:

>>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.
>
>
> What if you make a change to a module that every other module depends on?
> Then you have to recompile the whole program, which you wouldn't always

false. interface and implementation are separated by a bright line in c++.

if you change the *interface*, then yes, you have to recompile
everything. i don't know lisp, but i cannot believe that the same is not
true there.

if you change the *implementation* then you only have to recompile that
module and relink.

> If you just want to (say) play around with some standard library functions
> to prototype some new code, you cannot do that with a unit testing
> framework.

why not?

> The Lisp philosophy is that if you want to execute some bit of
> code, you should just be able to say: "execute this bit of code". There
> should not be a unit testing framework complicating such a simple action.

fair enough, but this is just a difference in philosphy. i don't see how
executing isolated "bits" of code is useful for any purpose but testing.
hence, 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.
>
>
> It's semi-bullshit. Static type systems can make refactoring more tricky.
> Ocasionally you might have to redesign your class hierachy. OP is just
> exaggerating here.

and making a pointless arguement. enough redesign will lead to complete
rewrites in any language. refactoring can always be tricky. about the
only point of contention is how much redesign and refactoring causes
problems in a given language, compared to another language. how would
you measure such a nebulous concept? if it can't be measured, it
shouldn't be argued.

besides, the argument can easily be turned around. static typing means
design locks, therefore looser typing ambiguates code because changes
may have unintended side-effects that stricter typing could avoid. there
is no point in making a comparison on a point like that.

>>[discussion of game engine/logic separation]
>
> Writing different modules of a program in a different language is not an
> optimal modularisation technique.

i never claimed it was optimal. i stated that every language has it's
strengths and weaknesses, and if you are going to be modularizing
anyway, and one module would be better to be done in another language,
go for it.

> Ideally you would be able to write all
> modules of your program in the same language (while still keeping them
> entirely separate, if you wished). C++ makes this difficult in some cases.

false. of course it's true that in a perfect world it would be best to
write a program all in one perfect language that does everything well.
nothing i have said suggests that that's not a good idea. however, as i
explained, game logic is not program logic, it is actually program data.
therefore, it is not a *module* of the program, it is *input* to that
program.

given that the game logic is so conceptually separate from the game
program itself, it's not really such a big step to do it in another
language that is simpler to interpret at runtime. as a bonus, you can
also choose a language that is easier on non-programmers so that more
people can make content for your game.

in fact - if your game is *really* kick-ass, it might be able to handle
game logic written in several languages, so that content creators can
choose what they like best.

as for your claim that c++ makes interfacing with other langauges
difficult in some cases - c++ has been interfaced with thousands of
other langauges. explain which cases you mean.

> The idea that high-level scripting languages are less powerful than C++ is
> pretty absurd, given that they tend to have much better abstraction
> features. The reason they are needed is that they are more powerful (at
> least in the sense of fewer lines of code for the same bang).

i usually avoid using the word "powerful" in this context, because it
leads to idiotic discussion. if i slipped it in this time, mea culpa.

"power" is nonsense in terms of a programming language. you claim that
power means better abstraction facilities. i could just as rightly claim
that it means performance.

in the general case, good abstraction negates good performance. why? you
said it yourself: "fewer lines of code for the same bang (ie, it does
more, i guess)". simplifying you get: "each line of code does more".
considering that "doing" anything "costs" in terms of speed and/or
memory, i could say: "each line of code costs more". therefore higher
abstraction is more expensive. qed.

now, if you need better abstraction and you are willing to sacrifice
performance, then by all means, use a high-level scripting language.
such is the case for game logic - it's not necessarily time critical,
and the more people that can contribute with greater ease, the better.
but don't ever waste my time by trying to argue that high-level
scripting languages are perfect for every job. no language is.

indi

Petter Gustad

unread,
Oct 25, 2004, 3:47:38 PM10/25/04
to
"Joe Laughlin" <Joseph.V...@boeing.com> writes:

> And I don't think MS-DOS could've been written in C++, wasn't that before
> C++ was around?

The first native C++ compiler I used under DOS was Zortech C++. This
must have been around 1988/1989.

Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

David Golden

unread,
Oct 25, 2004, 5:18:47 PM10/25/04
to
"Neo-LISPer" has been quoting the "Mike Cox" known-troll in his sig in
some previous postings to comp.lang.lisp [1] I gave him the benefit of
the doubt for a few posts, but that might tell you where he's coming
from if you've encountered "Mike Cox" trolling before. For some reason
"Mike Cox" started attempting to troll comp.lang.lisp a while back,
too, it's even possible Neo-LISPer and Mike Cox are the same person.

Note that it may more innocent (even if it is Mike Cox!), could be just
the overenthusiastic lisp newbie effect (no one more zealous than the
recently converted) - if so, then, Neo-LISPer, please don't do that.
Two wrongs don't make a right [2].

I urge people in both language communities to write games in whatever
languages they bloody well feel like, and to not feed the trolls. Like
I probably just did by posting this. Gaah.

[1]
http://groups.google.com/groups?q=group:comp.lang.lisp+Mike+Cox+neo-lisper&hl=en&lr=&ie=UTF-8&selm=87breve2mx.fsf%40yahoo.com&rnum=1

[2] See recent silly "Why Lisp Sucks for Games" thread on comp.lang.lisp
caused by an article by someone self-identifying as a microsoft c++
programmer and apparently feeling some compulsion to attack (somewhat
poorly) the use of lisp in games. Or, better, don't...


Alex Drummond

unread,
Oct 25, 2004, 4:38:25 PM10/25/04
to
> ah, but it does, because there is a difference between general
> references and c++ references, and that difference invalidates your
> entire argument.

No it doesn't.

> c++ references are non-owning references ("weak" references if you
> will). therefore, no management required, or even really logical.

No management is /possible/. If you use a reference incorrectly, management
might be /required/, but not actually performed. Say you have a function
which returns a reference to a newly allocated array (this is obviously a
dreadful thing to do, but you could do it) -- you would get a memory leak.
C++ itself does not stop you writing code like this. Hence, you still have
to think about memory management when you write code using references, if
only to say: "right, it's ok to use a reference instead of a pointer here".

> however, in practical code, all references are always valid. unless you
perform
> some acrobatics (ie, bad code design) or are dealing with threading
> issues, references will naturally go out of scope before the "real"
> object. there is no "management". the only things you do to references
> is make them and use them. you can't copy them around really.

I agree. But it's not trivial to use references correctly. You have to be
able to prove to yourself that what you actually want is a weak reference
to some data before you can be sure that you are not introducing memory
allocation bugs. It's not hard to do this, but you're still thinking about
memory management.

All this discussion is really missing the point anyway. Let's say for the
sake of argument that everything you've said re references is correct. You
still have exactly the difficulties I described when you're using pointers
in C++ -- you can either have complex memory management code, or you can
use inefficient reference counting (boradly speaking, there is obviously a
middle ground, and in simple programs memory management isn't too hard).

>> If it was possible to
>> write real-world C++ programs using only references and not pointers, I
>> would take your point,
>
> of course it's possible. but it's also possible to build an airplane
> from scratch using only a screwdriver. it's just not really smart, or
> easy.

That's exactly my point. Pointers (if not references) make memory management
hard. Writing C++ programs without using pointers is painful.

> when passing bare pointers around (which i personally frown on), you
> have to make clear in documentation who owns the pointer. otherwise,
> yes, you can end up with memory leaks. or, you can do it the right way
> and pass smart pointers around.

Yes, and to get back to what I was saying, smart pointers are not as
efficient as a good GC. This is, I emphasise, different from saying that a
program which uses smart pointers in places is less efficient than the same
program using a GC.

> in good design, memory is freed by the same entity that allocated it.
> the use of pointers or references does not invalidate good design.

In a simple program this is possible. You can't seriously be suggesting that
this little nugget of design wisdom (wise as it is) is going to make
programming in C++ almost as easy as programming in a language with a GC.
In my personal experience this just isn't the case (and I'm perfectly
capable of using smart pointers, etc., when it makes sense).

>> 3) Pass by smart pointer. Easy to understand, but usually more overhead
>> than a GC.
>
> i honestly have never heard that before in my life. please show me
> numbers. here are mine, off a paper advocating garbage collection

Reference counting is a really poor garbage collection method (both in terms
of performance and because of the problem of circular references). If a
large portion of your program uses reference counting, it will be less
efficient than the same program in a comparable GC'd language (unless the
comparable GC'd language is slower than C++ for other reasons, of course --
often the case).

> now, this page (http://www.boost.org/libs/smart_ptr/smarttests.htm)
> shows that the worst case performance for smart pointers is about 3
> times slower than naked pointers. therefore, smart pointers are still
> about 17 times faster than garbage collection. again, please show me
> your numbers.

If this statement were remotely true, GC'd languages would use smart
pointers (which usually means reference counting) and not generational GC.
Most don't -- certainly not serious compilers like javac or cmucl. I didn't
read the paper very carefully, but it appeared to be comparing GC to manual
memory management in a limited variety of test cases. Smart pointers are
not really manual memory management; they're a poorly implemented GC
extension to the language. If you don't use them very often, you may get
better overall performance since you'd have 90% manual memory management
and 10% inefficient automatic GC (or something like that). Also, consider
space efficiency, in which reference counting quite obviously loses (like
everything here, this can be a minor or major issue depending on the
program you're writing). The way you compute the 17x figure is not
completely unreasonable, but given that it's a pretty crude combination of
results from two different tests both chosen to support a particular
argument, we shouldn't be too surprised if it's completely wrong. Once
again: if smart pointers are so fast, GC'd languages would use reference
counting and get roughly the same performance; in reality most don't.

IMO there's really no point in throwing around figures in a discussion about
GC performance. There are too many factors. I accept that manual memory
management is faster than GC in most programs, but when memory management
gets hairy, reference counting smart pointers are a pretty inefficient way
of getting automatic memory management. In these cases, a real,
non-reference-counting GC is likely to perform better, if only because it
will be more thoroughly tested and integrated with the language.

Alex

Thomas Stegen

unread,
Oct 25, 2004, 5:34:35 PM10/25/04
to
JKop wrote:
> 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.

Depending on the amount of memory and the size of each allocated block
garbage collection can be faster, or manual handling can be faster. If
you have many small to medium sized objects then garbage collection is
faster, otherwise not so. Copious amount of research exist. Start
some where around here:http://www.hpl.hp.com/personal/Hans_Boehm/gc/.

Retarded? It has nothing to do with being retarded. Sometimes the
requirements of a program is such that you cannot predict when a
resource can be freed without designing this into your program
(I can't really think of many examples where this is not the case)
and that can be hard. When GC can sometimes even make your program
faster... No brainer. (And for the reading impaired, I am not
saying... Nah, figure it out yourself)

--
Thomas.

Matthew Danish

unread,
Oct 25, 2004, 5:19:20 PM10/25/04
to
"Mark A. Gibbs" <x_gib...@rogers.com_x> writes:
> one thing that most gc advocates i've talked to don't seem to get is
> that when using garbage collection, *all* pointers are smart
> pointers. the only difference between gc smart pointers and
> traditional c++ smart pointers is that when they go out of scope, c++
> smart pointers free the memory, whereas gc smart pointers just
> indicate (doesn't matter how they do it) to the garbage collector that
> the memory can be freed at its convenience. of course, smart pointers
> in c++ could do the same thing, and i have one that does. garbage
> collection is just a special case of the smart pointer design pattern.

This paragraph demonstrates a serious misunderstanding of the
difference between scope, extent, and the way GC works. I suppose
that it is understandable that a C++ programmer might get scope and
extent confused (I certainly did when all I knew was C and C++). I
will try to make my explanation simple:

The scope of a variable, as you probably already know, is the portions
of source code from which it is accessible. The extent of a variable
is the period of time during execution of the program when the
variable is accessible. A Garbage Collector is concerned with the
extent of variables (and other places where objects can be referenced
from).

Simple distinction: scope is a source-code concept; extent is a
run-time concept.

In a C or C++ program, when you declare a local variable, what you get
is called a "lexically scoped, dynamic extent" variable. This means
that the scope of the variable is determined by lexical markers ("{"
and "}" here) and the variable only lasts as long as program control
is within this same scope. This happens to correspond to the
implementation of variables by storing them on the stack.

In a Common Lisp, Scheme, Smalltalk, Ruby, ML, or Haskell (among
others) program, when you declare a local variable, what you get is a
"lexically scoped, indefinite extent" variable. Once again, the scope
of the variable is determined by some lexical marker, but now the
extent is not known. It is no longer a simple matter to determine
when the variable is not needed any more. Sometimes it can be proven
that a variable is dynamic extent, or it may be declared that way, but
otherwise it must be assumed to be indefinite extent.

In C there is a concept of a "static" variable to a function. This
variable also has "indefinite extent."

In addition, Common Lisp also has the notion of an "indefinite scope,
dynamic extent" variable. This is often referred to as a "dynamically
scoped" variable, but this is a misnomer. Common Lisp calls these
"special variables" to distinguish them from normal lexically-scoped
variables, and they must be declared special before use.

High-level languages use lexically scoped, indefinite extent variables
because of a useful concept known as higher-order functions.
Higher-order functions are functions that can treat functions as
normal objects. When combined with lexical scope, this allows
variables to be "closed over" by inner functions which may be passed
to other functions or returned. If a variable is "closed over" by a
function that is returned from a function, then that variable cannot
go away, because that function may still need it later on. Hence,
"indefinite extent."

The simplest way to manage these indefinite extent variables is to use
Garbage Collection. When the GC is invoked, it locates all live,
accessible objects and treats the rest of the heap as free space.
There are a number of ways of doing this, such as marking live objects
somehow as you trace them, or copying them over into a new space. The
primary difference between GC and reference-counting is that
reference-counting must do book-keeping everytime a variable or a
reference is mutated, and GC does not.

There is no such thing as a "GC smart pointer," as evidenced by the
Boehm conservative collector which works on C programs. The closest
concept to a smart pointer would be the use of a bit which categorizes
a machine word as either a pointer or an integer, when you use a
precise collector (as opposed to a conservative collector). But this
occurs at a level below the actual language semantics; it is not
visible to the programmer.

--
;; Matthew Danish -- user: mrd domain: cmu.edu
;; OpenPGP public key: C24B6010 on keyring.debian.org

Alex Drummond

unread,
Oct 25, 2004, 5:02:43 PM10/25/04
to
Mark A. Gibbs wrote:
> false. interface and implementation are separated by a bright line in c++.
>
> if you change the *interface*, then yes, you have to recompile
> everything. i don't know lisp, but i cannot believe that the same is not
> true there.
>
> if you change the *implementation* then you only have to recompile that
> module and relink.

OK, mostly true. There are some exceptions though, for example relating to
the dynamic nature of CLOS and the types of sequences (e.g. replace a list
with a vector at runtime, and if your code only uses generic sequence
operations it won't break). Also, there need not be any recompiling in lisp
as such. You can recompile individual functions, or change the values of
individual variables. This can be a real help.

> fair enough, but this is just a difference in philosphy. i don't see how
> executing isolated "bits" of code is useful for any purpose but testing.
> hence, unit testing.

I really don't know what to say. I thought everyone found REPLs useful (but
perhaps not worth the trouble of implementing for a particular language, of
course). You can do the same stuff with unit testing, sure. It's like the
difference between the following two scenarios.

1) I want some bread. I go to the shop, buy some bread.
2) I want some bread. I create a shopping list containing the single item
"bread", the name of the shop and the expected result of the expedition
(i.e. I will have obtained some bread). I then go to the shop to buy the
bread, afterwards checking against the shopping list that I have indeed
bought bread.

It's very useful to be able to get the value of an expression in a few
seconds without having to edit and/or compile a file. I do it all the time
when I'm writing Lisp programs, and unit tests would be the Wrong Thing.
You should not be writing tests for prototypical code -- only
classes/functions/whatever which have stable interfaces. The last thing you
want is to have lots of throwaway legacy test code hanging around.

> besides, the argument can easily be turned around. static typing means
> design locks, therefore looser typing ambiguates code because changes
> may have unintended side-effects that stricter typing could avoid. there
> is no point in making a comparison on a point like that.

Yes fair point. Although it should be pointed out that C++'s static type
system is pretty gross compared to the state of the art (i.e. ML, Haskell,
etc.)

> i never claimed it was optimal. i stated that every language has it's
> strengths and weaknesses, and if you are going to be modularizing
> anyway, and one module would be better to be done in another language,
> go for it.

Yes I agree.

> false. of course it's true that in a perfect world it would be best to
> write a program all in one perfect language that does everything well.
> nothing i have said suggests that that's not a good idea. however, as i
> explained, game logic is not program logic, it is actually program data.
> therefore, it is not a *module* of the program, it is *input* to that
> program.
>
> given that the game logic is so conceptually separate from the game
> program itself, it's not really such a big step to do it in another
> language that is simpler to interpret at runtime. as a bonus, you can
> also choose a language that is easier on non-programmers so that more
> people can make content for your game.

Mostly fair points. However in Lisp you could actually compile the game
logic code at runtime, and use it as an input to the game engine program
without having to write an interpreter. All I'm saying is that this is a
very attractive alternative to having a separate script language, and in
Lisp you would still have the possibility of implementing a separate script
language, just as in C++.

> in the general case, good abstraction negates good performance. why? you
> said it yourself: "fewer lines of code for the same bang (ie, it does
> more, i guess)". simplifying you get: "each line of code does more".
> considering that "doing" anything "costs" in terms of speed and/or
> memory, i could say: "each line of code costs more". therefore higher
> abstraction is more expensive. qed.

Rather depends on how efficient each line of code is, and whether you end up
with the same number of lines, but I don't want to pick an argument on this
topic; I think we basically agree.

> now, if you need better abstraction and you are willing to sacrifice
> performance, then by all means, use a high-level scripting language.
> such is the case for game logic - it's not necessarily time critical,
> and the more people that can contribute with greater ease, the better.
> but don't ever waste my time by trying to argue that high-level
> scripting languages are perfect for every job. no language is.

I really wouldn't argue that. I'd argue that in Lisp you could have the
convenience of loading and compiling game logic code at runtime /and/ the
performance of a mature compiled language. No sacrifices necessary ;)


Alex

md

unread,
Oct 25, 2004, 6:00:55 PM10/25/04
to

"Neo-LISPer" <neo_l...@yahoo.com> wrote in message news:87k6tf9...@yahoo.com...
[snip]

don't feed the troll!


Vladimir Sedach

unread,
Oct 25, 2004, 6:06:58 PM10/25/04
to
JKop <NU...@NULL.NULL> writes:
> > 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.

By any reasonable standards, C++'s type system is a brain-damaged
throwback to the 1960s. Much better static type systems can be found
in languages like Haskell and ML. Hell, there's even an assembler with
a better type system:
http://www.cs.cornell.edu/talc/

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

Yeah, and with just a bit more typing, you've got yourself a Turing
machine. You can do anything you want in C++, so why would you ever
want to switch to a better language?

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

Where do you think the word "function" comes from? It comes from
mathematics, where it has a very well-defined meaning and certain very
well defined properties. One of these properties is that for any
input, it always returns the same output. This particular meaning has
been universally adopted by the computer science community. In almost
all languages (Miranda and Haskell are the only two exceptions I
know), what you call "functions" are actually procedures or
subroutines, in that they can return different outputs for the same
input. This includes pseudo "functional" languages like ML too, since
it has assignment, references and mutable arrays.

Vladimir

Joe Laughlin

unread,
Oct 25, 2004, 6:01:51 PM10/25/04
to
Petter Gustad wrote:
> "Joe Laughlin" <Joseph.V...@boeing.com> writes:
>
>> And I don't think MS-DOS could've been written in C++,
>> wasn't that before C++ was around?
>
> The first native C++ compiler I used under DOS was
> Zortech C++. This must have been around 1988/1989.
>
> Petter

And MS-DOS was first written in the early 80's.


William Bland

unread,
Oct 25, 2004, 7:49:17 PM10/25/04
to
On Mon, 25 Oct 2004 21:02:43 +0000, Alex Drummond wrote:

> I really don't know what to say. I thought everyone found REPLs useful (but
> perhaps not worth the trouble of implementing for a particular language, of
> course). You can do the same stuff with unit testing, sure. It's like the
> difference between the following two scenarios.
>
> 1) I want some bread. I go to the shop, buy some bread.
> 2) I want some bread. I create a shopping list containing the single item
> "bread", the name of the shop and the expected result of the expedition
> (i.e. I will have obtained some bread). I then go to the shop to buy the
> bread, afterwards checking against the shopping list that I have indeed
> bought bread.
>
> It's very useful to be able to get the value of an expression in a few
> seconds without having to edit and/or compile a file. I do it all the time
> when I'm writing Lisp programs, and unit tests would be the Wrong Thing.
> You should not be writing tests for prototypical code -- only
> classes/functions/whatever which have stable interfaces. The last thing you
> want is to have lots of throwaway legacy test code hanging around.

This is interesting. I thoroughly agree with you of course, the REPL is
invaluable.

The interesting thing is, I see my unit tests as a serialisation of my
REPL sessions... because that's literally what they are. I wrote an ELisp
function that takes a buffer full of my interactions with beanshell (a
Java interpreter), and creates a new buffer containing source for a
collection of unit tests that JUnit can execute. Each test simply
executes the code that I typed in the REPL, line-by-line, and checks that
any values returned are the same as they were when I was using the REPL.
The only caveat is, of course, dealing with unprintable values. That's
usually pretty easy to fix with just a little manual editing of the
resulting tests though.

It's been a long while since I wrote a unit test by hand - these days I do
them all this way. I don't think it's a coincidence that I have much
higher test coverage than any of my colleagues who write all their tests
by hand.

Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele

WTH

unread,
Oct 25, 2004, 10:33:48 PM10/25/04
to
<snip crap>

LOL, you're hilarious. Stop researching and write a game, then tell us what
you should write it in.

WTH


Petter Gustad

unread,
Oct 26, 2004, 2:28:21 AM10/26/04
to
"Joe Laughlin" <Joseph.V...@boeing.com> writes:

> Petter Gustad wrote:
> > "Joe Laughlin" <Joseph.V...@boeing.com> writes:
> >
> >> And I don't think MS-DOS could've been written in C++,
> >> wasn't that before C++ was around?
> >
> > The first native C++ compiler I used under DOS was
> > Zortech C++. This must have been around 1988/1989.

> And MS-DOS was first written in the early 80's.

That was my point...

Kaz Kylheku

unread,
Oct 26, 2004, 2:58:11 AM10/26/04
to
Philippa Cowderoy <fli...@flippac.org> wrote in message news:<Pine.WNT.4.53.0410251841150.1476@SLINKY>...

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

Predictable? Not so!

You can't always be sure how much the next Release() call is going to
cost!

Sometimes you drop the last reference on some object which is holding
on to a bunch of last references to other objects which are holding on
to more last references to yet more objects ...

Espen Vestre

unread,
Oct 26, 2004, 5:24:07 AM10/26/04