While the majority of videogames have a relatively short lifespan, some are still actively developed for years or even decades after their initial release. Let’s see how they can keep up with new techs.
World of Warcraft was initially released in 2004. Wikipedia tells me the latest expansion was published last summer, 14 years after release. The original game could run on Windows 98. Today it requires both hardware and software that didn’t exist at release.
Copy and Swap is an elegant (if venerable) C++ idiom than I learnt to appreciate for quite some time without much afterthought. It’s simple, clean and does the job. But is there a catch?
Once upon a time, in the 90s, we started preaching one of the oldest pillars of Modern C++ that is RAII. We taught programmers the simple rule that a constructor must leave an object in a usable state, that we should able to copy it, and that the destructor must clean all owned resources, no matter what.
Is the C++ committee out of touch with its users, or is the game development crowd out of touch with the rest of the C++ community? Following the recent debate on social media, I offer a small introduction of that ‘Modern’ C++ thingie.
This was my third CppCon and (spoiler warning) the last one in the Seattle neighborhood. Time for a trip report.
CppCon 2018 was held in Bellevue, Washington, on the last week of September this year. Flying from Stockholm proved a bit more painful than from Paris, as no direct flights are offered. My trip started somewhere around 11:15 at ARN, and ended in SEA around an eternity later (official sources settling around 15 hours).
Are the problems we face really unique? What is the chance that we’re the first to encounter them? How can we gain insights from others who already solved them? Why aren’t we? Are unicorns real??!
Picture this situation: a new developer joins a team. Sooner or later, he discovers the existing codebase and starts playing with it. Some time may pass, but at some point he encounters a pattern he finds weird. Maybe he read a case against it in a book, or heard it in a talk, or simply learned from experience that this is probably not the recommended way of solving that particular problem.