Best C++ game programming book recommendations

In article <403F1B6D.6BC82065@alcyone.com>, Erik Max Francis <max@alcyone.com> wrote:
>Gerry Quinn wrote:
>
>> Do you accept what Meyers and Alexandrescu claim? If yes, it says a
>> good deal about your notions of OO architecture. If no, it says it
>> all
>> about your previous post.
>
>Since you disagree with Stroustrup himself about the nature of C++ as a
>multiparadigm language, I'd say you ain't one to talk, bub.

You have just posted the 'argument from authority' in its most naked and
infantile form.

- Gerry Quinn

Gerry Quinn wrote:

> You have just posted the 'argument from authority' in its most naked
> and
> infantile form.

Considering what you just claimed, you _really_ don't want people
analyzing each of your comments for logical fallacies, do you?

It's certainly true that abstractly an appeal to authority is a logical
fallacy and thus suspect. However, when you disagree with most other
people around you and recognized experts and your reasoning is no better
than "because I say so" (not to mention when it comes wrapped in
backpedalling and semantic distinctions), you ought to be prepared for
the not-so-shocking revelation that people are unlikely to take your
word for it.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Seriousness is the only refuge of the shallow.
-- Oscar Wilde

In article <mtj0c.5054$rb.63349@news.indigo.ie>, gerryq@indigo.ie
says...
> [...]
> Those seem clear enough, I think.

That they (Meyers and Alexandrescu) are advocating writing functions
as non-members over members when membership is not required seems
very clear, yes.

It's also very clear that you don't like this, but it's extremely
unclear what your objections are and what facts or experiences they
are based on. Why don't you enlighten us on this point, oh-leading-
OO-expert.


> Do you consider them to be good programming advice?

If your goal is to increase encapsulation, certainly.


> They show no indications of restricting their claims to what we would
> normally describe as algorithms.

Why (and when) should their advice be restricted?


Christer Ericson
Sony Computer Entertainment, Santa Monica

Erik Max Francis wrote:

> Gerry Quinn wrote:
>
>
>>Do you accept what Meyers and Alexandrescu claim? If yes, it says a
>>good deal about your notions of OO architecture. If no, it says it
>>all
>>about your previous post.
>
>
> Since you disagree with Stroustrup himself about the nature of C++ as a
> multiparadigm language, I'd say you ain't one to talk, bub.
>

I think you can validly disagree with Stroustrop about the nature of C++
even though he is the originator of the language. Especially when
you're talking about prescriptive matters about how one *should* use the
language.

IMO C++ is a dog's breakfast as a multiparadigm language, but quite
powerful and usefull as an OO language. My belief doesnt make
Stroustrop wrong, nor his belief make me wrong since matters of beleif
can't "trump" each other. Prescriptive claims can only be evaluated on
a "suck it and see" manner - try it and see if you like it.

Peter Ashford <me@here.there.com> wrote

> IMO C++ is a dog's breakfast as a multiparadigm language, but quite
> powerful and usefull as an OO language.

I think if you only consider OO capabilities of C++, it is hardly
better than Java (and much more difficult to port).

However, C++'s template capabilities, and especially template
metaprogramming, that's what gives the language the whole new
dimension, and makes it unique, especially for writing libraries (see
Boost). No other language around is even close.

IMHO.

Regards,
Arkadiy

On Mon, 29 Feb 2004, Arkadiy Vertleyb wrote:

> However, C++'s template capabilities, and especially template
> metaprogramming, that's what gives the language the whole new
> dimension, and makes it unique, especially for writing libraries (see
> Boost). No other language around is even close.
>

Except the functional languages many of Boost's techniques originated in?

--
flippa@flippac.org

In article <MPG.1aab747e64a7ea73989744@news.verizon.net>, Christer Ericson <christer_ericson@NOTplayTHISstationBIT.sony.com > wrote:
>In article <mtj0c.5054$rb.63349@news.indigo.ie>, gerryq@indigo.ie
>says...

Requoted, as I want to point a couple of things out:

><MEYERS>
>If you're writing a function that can be implemented as either a member
>or as a non-friend non-member, you should prefer to implement it as a
>non-member function.
>[His example]
>void nap(Wombat& w) { w.sleep(.5); }
></MEYERS>
>
><ALEXANDRESCU>
>Basically my belief is that nonvirtual member functions in general are
>an unnecessary cutesy in C++ that wahses people's brains, leads to bad
>programs, and will take many years to wear off.
></ALEXANDRESCU>

>> Those seem clear enough, I think.
>
>That they (Meyers and Alexandrescu) are advocating writing functions
>as non-members over members when membership is not required seems
>very clear, yes.

Alexandrescu is clearly saying that nonvirtual member functions in
general are bad. That seems a rather extreme definition of "membership
not required". But I will talk about the slightly less absurd statement
of Meyers below.

>It's also very clear that you don't like this, but it's extremely
>unclear what your objections are and what facts or experiences they
>are based on. Why don't you enlighten us on this point, oh-leading-
>OO-expert.

Quite obviously, I think that there are other reasons for using member
functions than the sole reason of virtuality. In this, I should imagine
that I am in the mainstream.

>> Do you consider them to be good programming advice?
>
>If your goal is to increase encapsulation, certainly.

You are wriggling now, but even so you are wrong, and here's why. There
is more to "encapsulation" than "encapsulation of declared data
members". When you understand that, you can see how wrong-headed
Meyers' approach is. Let's take a second look at his example:

void nap(Wombat& w) { w.sleep(.5); }

What is that 0.5, sitting out among the global functions? Why it's a
variable telling Wombat how long to nap for! This is not encapsulation,
it's the opposite of encapsulation! Wombats have an ability to nap, and
the variable saying how long they should nap for ought to be
encapsulated inside Wombat. Or if you're not anti-preprocessor [and
since declarations of internal const values in C++ are simply not
general enough at this time to be worthwhile, it would be silly to be]
it should be in a line in Wombat.h saying:
#define WOMBAT_SLEEP 0.5

The blunder Meyers is making is to have a mechanical understanding of
"encapsulation" in terms of declared variables. In object oriented
programming, encapsulation is something that applies to classes as a
whole. Meyers creates an extra global variable that should belong to
the class, and pretends that he has made the class more encapsulated.
In fact he's splattered bits of it all over the shop.

(In another thread I pointed out another problem with the above - it's
utterly limited and artificial. You can't make some wombats long
nappers and some wombats short nappers. Thinking about that again shows
how napping is something a particular wombat does, and that it should be
a member function even if at this time it does not require access to
member variables.)

Encapsulation *should* be an important goal - but proper encapsulation,
not Meyers' half-baked variety.

>> They show no indications of restricting their claims to what we would
>> normally describe as algorithms.
>
>Why (and when) should their advice be restricted?

It was *you* who implied they were talking about algorithms, and
libraries such as STL. I was merely pointing out that they were not.

- Gerry Quinn

In article <4041C807.6AB48A46@alcyone.com>, Erik Max Francis <max@alcyone.com> wrote:
>Gerry Quinn wrote:
>
>> You have just posted the 'argument from authority' in its most naked
>> and
>> infantile form.
>
>Considering what you just claimed, you _really_ don't want people
>analyzing each of your comments for logical fallacies, do you?

Please, analyse away. That's what I come here for, it's the ad hominem
insults that I can take or leave.

>It's certainly true that abstractly an appeal to authority is a logical
>fallacy and thus suspect. However, when you disagree with most other
>people around you and recognized experts and your reasoning is no better
>than "because I say so" (not to mention when it comes wrapped in
>backpedalling and semantic distinctions), you ought to be prepared for
>the not-so-shocking revelation that people are unlikely to take your
>word for it.

I don't think I've backpedalled or made semantic distinctions in this
debate, and it certainly doesn't shock me when people are unprepared to
take my word for it.

But do I disagree with the most of the people around me? Christer is
trying hard to evade having to actually agree with what Meyers and
Alexandrescu say. You've said nothing at all on the subject. And I
suspect many of the recognised experts would disagree vehemently with
some of the notions put forward by M and A.

- Gerry Quinn

Philippa Cowderoy <flippa@flippac.org> wrote

> > However, C++'s template capabilities, and especially template
> > metaprogramming, that's what gives the language the whole new
> > dimension, and makes it unique, especially for writing libraries (see
> > Boost). No other language around is even close.
>
> Except the functional languages many of Boost's techniques originated in?

I have to admit my total ignorance on the subject. I actually meant
"OO language". But if you want to compare, I guess a fair question
would be: can, say, lisp emulate OO techniques (in the same manner C++
emulates functional techniques)?

Regards,
Arkadiy

In article <2f56064a.0402292127.37a35e0a@posting.google.com >, vertleyb@hotmail.com (Arkadiy Vertleyb) wrote:
>Peter Ashford <me@here.there.com> wrote
>
>> IMO C++ is a dog's breakfast as a multiparadigm language, but quite
>> powerful and usefull as an OO language.
>
>I think if you only consider OO capabilities of C++, it is hardly
>better than Java (and much more difficult to port).
>
>However, C++'s template capabilities, and especially template
>metaprogramming, that's what gives the language the whole new
>dimension, and makes it unique, especially for writing libraries (see
>Boost). No other language around is even close.

My view on the 'multiparadigm' thing: template metaprogramming, like
assembler, is for special cases. For big important libraries that will
see massive re-use, it's great. For 99% of programming, you should
never consider touching it.

- Gerry Quinn