There's the question of whether you are going for pure, dogmatic object-orientation, or something more pragmatic. Sometimes, you have chunks of data that make sense to be grouped together, and don't really have any behavior associated with them. Go wild with getters and setters there - it's a lot more future-proof and change-friendly than relying on public fields, instead, when it becomes necessary. Even better if you're using a programming language that has support for C#-style properties that sugar over the getter-setter boilerplate.
Especially if you are trying to program in a more functional style, you end up wanting lots of more behavior-poor data objects with public getters, though you would tend towards keeping your setters private, as leaning harder towards immutability tends to be the better choice.
Unfortunately this book is sort of verging on abandonware - it's been out of print for a while, the publisher has folded and been bought out by someone else, and the author doesn't maintain the website any more... The wayback machine has the author's website saved, so you can still get the code examples from here.
Kind of a shame, since thanks to Mickey Mouse it'll be lost to copyright limbo for the rest of any of our lifetimes.
I have a very dog-eared copy of that book sitting on my shelf. I thought it was fantastic when I got it, almost ten years ago, and I still think it's pretty good.
It's one of the few game development books I've found that works through the process of building out a non-trivial game, piece by piece. Granted, at the end of the book, you're going to have an unpolished, simple, early-2000s 3D Warcraft clone, but I think it fills in a lot of gaps between what you learn in the straight OpenGL/Direct3D graphics books, and the fairly abstract game design, Game Programming Gems-style topics books.
If nothing else, I think the chapter on random terrain generation is pretty nifty.
That being said, trying to update it to DirectX 11 is not a trivial endeavor. It makes use of a lot of the D3DX stuff that no longer exists or has no direct analog in D3D11, which can be problematic, particularly for the model animation.
I often find that converting something into X Starbucks coffees is a great way to rationalize prices. Sort of like the Big Mac price index, except it's something you buy even more without thinking about it. Is this game that I'm going to play for 40-100 hours worth four or five coffees?
Of course, by that metric, most things look like a steal.
The promised content is really appealing; but some reviews say it's plenty of bugs. If it was more recent, it'd be easier to find a solution to non-working lines of codes, but that is so long ago.. does it use OpenGL, DirectX or others?
I think the intent was to present an engine that could be done in either OpenGL or DirectX, but the implementation is all Direct3D. It's older code, but it's still Direct3D 9, so it's not as full of deprecated mess as it might be. Probably worth a flier if you can find a cheap second-hand copy.
It's dated now, but I have this tome on my shelf. It's not perfect, and I dunno how much of its design decisions make sense a decade later, but it is interesting for walking through building a whole game engine.
I wish there was an updated edition, or something analogous, but modern.
v.z=0; // or whatever you want for a non-asked-for swizzle
It'd be kind of tedious, but you could write out whatever swizzles you want as functions like that - there are only so many permutations for a 3D vector, and with a decent constructor defined, they would be one-liners.
In C#, this would probably be something I'd do with some read-only properties, which is effectively the same thing, just lets you do it without writing parentheses.
It's been a while since I was slinging C++, but I seem to recall that SDL (1.2) worked pretty nicely as a simple window management and input library to paper over the uglier ways you do that in raw Win32 code. For initializing DirectX, or binding an OpenGL context, all you really need is the HWND of your main window to bind to, which SDL exposes.
I don't think C# is going anywhere. It's the default language for doing any kind of business-related development in the Windows world, and stands to stay in that position for the foreseeable future. Microsoft is continuing to put a lot of investment in it, and if .NET Core, or whatever they have recently rebranded that as takes off, it might start to eat Java's lunch on *NIX-based systems. Whether or not you eventually go full-time into game development, getting good with C# wouldn't hurt your employability in other areas.
XNA is pretty much dead now, not having seen any updates since 4.0 in 2010, and officially discontinued in 2013. Monogame is an open port of XNA, that's being actively developed (3.4 last April).
If you are only interested in Windows, you can use SlimDX or SharpDX, which are pretty straight-forward wrappers around the C++ Direct X libraries. A number of the developers of these libraries are pretty active on here in the Direct X sub-forum.
SQL Express usually get installed with some defaults that are not always terribly useful if you actually want to use it.
If I recall, you usually have to go in and enable Named Pipes and TCP/IP access, which for some reason is disabled by default with Express, and modify your firewall to allow connections on the SQL ports. It may also be necessary to start the SQL service for the Express database engine, which sometimes I have seen does not get started on install, or is set with a Manual startup type.
Eh, I don't see this as a completely unreasonable request that someone ought to be slapped down for.
Most of the reputable publishers will put the source code for their books on their websites for free downloads, without any requirement that you prove that you have purchased the book, and quite often is published with very permissive licenses. If this is the LaMothe book that was published over 20 years ago, that may not have been the case, but it is effectively abandonware at this point (I tried looking it up on the publisher's website, but they have possibly the most broken search implementation I've ever seen). It's entirely possible that neither the publisher nor the author even has the source code any longer, and it only exists on whatever sufficiently non-scratched-to-hell CDs are still out there. At that point, you almost have a moral obligation to violate copyright, to ensure that the source code is not lost forever. It is unfortunate that there is not some sort of GoG for old programming books - far too many of them are little more use than kindling or toilet paper without the source code, or some obscure, unavailable helper library that is included in the source CD.
Unless this happened to be bundled into some mega ebook torrent at some point and is still alive, you are probably not going to have much luck.
You might want to investigate something a little more up-to-date. The concepts and theory in a book that old is likely still relevant, but the actual technical details are going to be completely irrelevant, unless you are writing code to run on DosBox.