Best C++ game programming book recommendations

In article <MPG.1aa72bce211bc51b98973f@news.verizon.net>, Christer Ericson <christer_ericson@NOTplayTHISstationBIT.sony.com > wrote:
>In article <Lp4%b.4608$rb.62194@news.indigo.ie>, gerryq@indigo.ie
>says...
>> [...]
>> Yes, 'learn' how global functions increase encapsulation and how classes
>> should have no non-virtual member functions.
>
>Trying to lick your wounds here after Joe Foster nuked you on your
>ignorance about encapsulation in comp.programming? Tsk.

*Joe Foster* nuked *me*? On the contrary, he pointed to a thread where
Alexandrescu engaged in even more absurd nonsense than Meyers did in a
paper that was discussed on these groups some time ago. Joe pointed me
to a thread on the C++ moderated group in which Alexandrescu was
promoting his notions (literally, he was asserting that classes should
have no non-virtual functions). I pointed him to a post by Terry
Slevebo(?) on that thread, in which Alexandrescu's arguments were
comprehensively demolished and to which Alexandrescu could make no
reply.

If you think Joe defeated my arguments on comp.programming, I suggest
you look again at the thread(s). In fact, I don't think he was
attacking them strongly, really - I saw little direct defence of the
notions proposed.

The bottom line is that, whatever the quality of their texts, Meyers has
been promoting idiocies and Alexandrescu has been promoting worse
idiocies. And you have embarassed yourself once again by childish
sniping.

- Gerry Quinn

Christos Dimitrakakis <olethrosdc@oohay.com> wrote in message news:<pan.2004.02.25.19.50.58.130190.4476@oohay.co m>...

> He's referring to the fact that Andrei Alexandrescu's approach to C++ can
> be a bit extreme. It's almost like defining a whole new language on top of
> C++. Check out the loki library for some implementations of his ideas.

I would say "discovering" rather than "defining". The "language" is
already there

Regards,
Arkadiy

On Thu, 26 Feb 2004, Christer Ericson wrote:

> In article <Lp4%b.4608$rb.62194@news.indigo.ie>, gerryq@indigo.ie
> says...
> > [...]
> > Yes, 'learn' how global functions increase encapsulation and how classes
> > should have no non-virtual member functions.
>
> Trying to lick your wounds here after Joe Foster nuked you on your
> ignorance about encapsulation in comp.programming? Tsk.
>

Having skimmed the argument, would I be right in guessing an equally
effective solution is simply to indicate in the source which operations
are "primitive" on a class for the purpose of maintaining invariants, and
which can be/are expressed in terms of those primitive operations? We
don't care if the implementations of these functions change, all we need
is for the interface to remain consistant.

This way we also get to implement optimised versions of the member
functions that manually maintain the invariants rather than use the
primitive operations when it makes sense, something that can't be done
with the non-member non-friend function.

--
flippa@flippac.org

In article <Hyk%b.4682$rb.62270@news.indigo.ie>, gerryq@indigo.ie
says...
> [...]
> *Joe Foster* nuked *me*?

Yes, he completely destroyed you.


Christer Ericson
Sony Computer Entertainment, Santa Monica

In article <Pine.WNT.4.53.0402261339150.292@SLINKY>, flippa@flippac.org
says...
> [...]
> Having skimmed the argument, would I be right in guessing an equally
> effective solution is simply to indicate in the source which operations
> are "primitive" on a class for the purpose of maintaining invariants, and
> which can be/are expressed in terms of those primitive operations? We
> don't care if the implementations of these functions change, all we need
> is for the interface to remain consistant.

Meyer is talking about decoupling functions whenever possible as
this increases encapsulation. I don't see how your proposal
serves as effective decoupling.

As to why this increases encapsulation, I'm not going to repeat
Meyer's arguments. They can be found here:

http://www.cuj.com/documents/s=8042/cuj0002meyers/

A similar presentation is available here:

http://www.codeproject.com/gen/desig...f=100&forumid=
16188


> This way we also get to implement optimised versions of the member
> functions that manually maintain the invariants rather than use the
> primitive operations when it makes sense, something that can't be done
> with the non-member non-friend function.

This is a red herring, I'm afraid. The issue at hand has nothing to
do with optimization, it's purely about what encapsulation is (and
what it isn't).


Christer Ericson
Sony Computer Entertainment, Santa Monica

In article <MPG.1aa87b2e3df800b3989741@news.verizon.net>, Christer Ericson <christer_ericson@NOTplayTHISstationBIT.sony.com > wrote:
>As to why this increases encapsulation, I'm not going to repeat
>Meyer's arguments. They can be found here:
>
>http://www.cuj.com/documents/s=8042/cuj0002meyers/
>
>A similar presentation is available here:
>
>http://www.codeproject.com/gen/desig...f=100&forumid=
>16188

This is not entirely similar as while it regurgitates Meyers'
philosophical arguments and whinges about how the meanies consider them
"politically incorrect", it seems to talk about legitimate cases where
non-member functions might be preferable.

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.

- Gerry Quinn

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.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Many situations can be clarified by the passing of time.
-- Theodore Isaac Rubin

In article <xeE%b.4804$rb.62335@news.indigo.ie>, gerryq@indigo.ie
says...
> [...]
> Do you accept what Meyers and Alexandrescu claim?

Since it seems you have a very specific interpretation of what
it is they're claiming, why don't you describe what _you_
think they're saying.

Me, I think Meyers is effectively regurgitating what Stepanov so
succinctly states here:

http://www.sgi.com/tech/stl/drdobbs-interview.html

to be summed in his own words as "A binary search is not an object.
It is an algorithm."

Reinterpreting, at the core of what these guys are saying is that
an object should be an (abstract) encapsulation of the representation
of some data. However, algorithms (or other operative methods) should
not be part of the object as they can be applied to many different
objects (with the same interface). Thus, including these algorithms /
methods in the object _weakens_ the encapsulation of the data structure.

In fact, this is (in theory, even though the implementation leaves
something to be desired) what Stepanov's STL is all about: the
separation of algorithms and data structures.


Christer Ericson
Sony Computer Entertainment, Santa Monica

This one looks promising:

http://www.amazon.com/exec/obidos/tg...glance&s=books

Beginning C++ Game Programming (Game Development Series)
by Michael Dawson


"jm" <john_20_28_2000@yahoo.com> wrote in message
news:c67e4bdd.0402231955.5aac84cb@posting.google.c om...
> I know there are many different possibilities here, but first let me
> say:
>
> I am not an expert C++ programmer - not even close.
>
> I do know the language or at least can follow it. I feel comfortable
> enough to use the a help file, Internet, etc. I understand basic
> Win32 programming (I understand on a basic level what is going on,
> winmain, messages, etc.). I am an experienced programmer in other
> language, mostly of the scripting type, however, perl, javascript,
> some C, VB.NET, other odds and ends.
>
> I am *not* looking to make 3D games or the next greatest game in the
> universe. I understand some basic concepts like recursion.
>
> That's about where it ends.
>
> I am yet another web page server side database driven kind of
> "programmer." But hey, I get paid for it (and I like it).
>
> I want to make graphical games, but as I said - 2D (DirectX or OpenGL,
> but prefer the former - no offense)
>
> I had the book "Game Programming: All in One." The C++ primer was
> okay (took that there and on the Internet a million times, nothing
> new), but when the "game" programming starts it's just line after line
> with no explanation. I do not want that again.
>
> I am on WinXP Pro. and own VS 6.0.
>
> Hope you understand where I am coming from and thanks for any advice
> on what book to get. Thanks.

In article <MPG.1aa9e7c5ec79c21a989743@news.verizon.net>, Christer Ericson <christer_ericson@NOTplayTHISstationBIT.sony.com > wrote:
>In article <xeE%b.4804$rb.62335@news.indigo.ie>, gerryq@indigo.ie
>says...
>> [...]
>> Do you accept what Meyers and Alexandrescu claim?
>
>Since it seems you have a very specific interpretation of what
>it is they're claiming, why don't you describe what _you_
>think they're saying.

Better still, I will quote them. At least they present their
wrong-headed notions with clarity.

<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. Do you consider them to be good
programming advice?

>Me, I think Meyers is effectively regurgitating what Stepanov so
>succinctly states here:
>
>http://www.sgi.com/tech/stl/drdobbs-interview.html
>
>to be summed in his own words as "A binary search is not an object.
>It is an algorithm."
>
>Reinterpreting, at the core of what these guys are saying is that
>an object should be an (abstract) encapsulation of the representation
>of some data. However, algorithms (or other operative methods) should
>not be part of the object as they can be applied to many different
>objects (with the same interface). Thus, including these algorithms /
>methods in the object _weakens_ the encapsulation of the data structure.

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

>In fact, this is (in theory, even though the implementation leaves
>something to be desired) what Stepanov's STL is all about: the
>separation of algorithms and data structures.

Almost all of the time, we are not programming something like the STL,
and our architecture should be appropriate to the task in hand.

- Gerry Quinn