I find your comments very enlightening and constitute sound advice, Arthur.

My comment about Python alludes to the fact that everything in Python is an object, including ints. The int value one has only one object identifier:

>>> x = 1
>>> y = 4-3
>>> y
1
>>> x is y
True
>>> id(x)
4359375504
>>> id(x)
4359375504
>>> x.bit_length()
1
>>> z = [1,2]
>>> id(z[0])
4359375504
>>> type(x)
<class ‘int’>
>>> x.__sizeof__()
28
>>> int.__sizeof__(1)
28
>>> class C:
... def __init__(self):
... self.x = 1
...
>>> c = C()
>>> c.__sizeof__()
32
>>> id(c.x)
4359375504
>>> c.x is y
True

Wherever the value 1 appears, it is the same object, so nothing is held by value in Python. “Copying” an int isn’t really copying. It just makes multiple references to a shared, immutable integer.

C++, of course, uses value semantics, so things are copied unless you use a pointer or reference.

I believe game programmers need to understand how things differ in memory between Python and C++ as much as they need its speed. I don’t think what I illustrated above will be easy for newbies, nor for people going from Python to C++, where they really have to learn pointers. Just wanting to give input for Guy on his goals.

Chuck
On Nov 24, 2019, 12:04 PM -0700, Arthur O'Dwyer via SG20 <sg20_at_[hidden]>, wrote:
> 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 (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 chapter.
> >
> > 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,
> > –Arthur
> --
> SG20 mailing list
> SG20_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg20