Thanks everyone: I'm just watching the feedback rolling in and considering
my position. Please don't stop your input nor think I don't care: I would
rather wait until there's a bit of silence before I dive in with my
responses.

Cheers,
G

On Mon, 25 Nov 2019 at 01:08, Chuck Allison via SG20 <sg20_at_[hidden]>
wrote:

> 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!
> <https://quuxplusone.github.io/blog/2019/11/07/modular-hello-world/>)
>
> 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 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
>
> --
> SG20 mailing list
> SG20_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg20
>