C++ Logo


Advanced search

Subject: Re: I've been asked to write a book
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2019-11-24 13:04:22

On Sat, Nov 23, 2019 at 1:47 PM chuck.allison via SG20 <
sg20_at_[hidden]> wrote:

> On my shelf is a book entitled Mathematics For Game Programming. It's
> good, laden with examples in context for its field. It assumes, however,
> that people already know programming and the rudiments of game programming,
> and that they already have a background in traditional mathematics.
> I can see a book entitled Modern C++ For Game Programming

"Yes, and..." notice the various different yet equally compelling books you
can imagine by fiddling with the title.

1. Modern C++ for Game Programming
2. Modern C++ for Game Programmers
3. Game Programming in Modern C++
4. Programming Games in Modern C++

If your target audience is non-programmers, I'd go with #4 (but personally
I don't think that path leads to success).
If your target audience is programmers trying to learn game programming,
I'd go with #3 (and I think that is the most compelling book title;
although it will not lead to the reader becoming a C++ expert, but merely a
game programmer).
If your target audience is game programmers trying to learn modern C++, I'd
go with #2 or possibly #1.

> I would caution against trying to introduce C++, especially with only a
> Python background. We have found at my university that after using Python
> for CS1 and CS2, we need an entire course introducing students to C++
> because the memory model is so different. Value semantics are difficult to
> grasp for such students.

Incidentally, this surprises me. (You have much more experience than I do,
of course.) For classical object-oriented programming, Python and Java and
C++ all share the same model; C++ just makes you write the pointers
explicitly. It's just that C++'s default is "everything works like int" --
even in Python and Java, when you copy an int you get a copy, not a
reference, so Python programmers already have to understand what a copy is.
C++ just extends that intuition to *all* data types by default.
So "value semantics" is like 5 minutes to explain the intuition. But then I
guess you have to explain destructors, copy constructors, assignment
operators... So that's probably a whole chapter, to a reader unfamiliar
with C++. Unfortunately, most readers who *do* know C++ are going to be
shaky on best practices in this area, too. So you'll have to spend at least
a full-page sidebar on this stuff, no matter what.

I suggest a narrow focus. Otherwise, "insane" may be an apt descriptor.
> There is a lot of C++20 that isn't needed in game programming, right?

I suggest avoiding new C++2a features altogether, in a book aimed at
- C++ newbies
- in a conservative industry.
There is no reason to tell game programmers about, say, the Ranges library,
or operator<=>, because these features won't be useful to them. And there's
no reason to tell industry programmers about Modules until
Modules-supporting compilers become common (maybe around 2022).
Another reason to avoid talking about C++2a stuff is that we simply don't
know what the right way to use these new features is. We have no tooling
for Modules yet; you can't say "compile with these driver flags" because
the driver flags aren't decided yet. (Here's my attempt, btw!

And I say all this having myself written a book about the C++17 STL
<https://amzn.to/34rWnt9> (including <memory_resource> and <filesystem>) in
mid-2017. :)

I agree that the most compelling way to organize the book would probably be
to present a series of game-related tasks, and then introduce only as much
"modern C++" as is necessary to accomplish each task. That way, the reader
is exposed to good C++ habits, but continues reading mainly because they're
interested in the "story arc" of the game-related tasks. The trick will be
figuring out how to synchronize the game-programming story arc with the C++
story arc, so that the simpler lower-level game-programming tasks don't
require arcane high-level C++ knowledge that won't be taught until the next

I'm intrigued by the idea of teaching processor architecture at the same
time as modern C++ at the same time as game programming, but I can't
imagine how you'd arrange that. Each topic has its own natural arc, and
synchronizing *all three* arcs seems impossible to me.

And I say all this having written a book with essentially no story arc at
all -- just a grab bag of proto-blog-posts. :) Writing a "textbook" has got
to be much harder!

my $.02,

SG20 list run by sg20-owner@lists.isocpp.org

Older Archives on Google Groups