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.
Package management and build systems are one of the next big challenges C++ is going to face. In this article series, I offer some thoughts and ideas to solve that. This post is the third part, where we talk about a project’s build itself and how simple it could be.
A couple months ago I started a series of posts about build systems and package management. The first part explained the general outline of the issue and a potential solution. The second one delved a bit more in the details of toolchains and their configuration. In this third article, we will try to explore the description of a project itself.