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.
I was in Bristol last week for the 2018 edition of ACCU. Now is the time for me to give my feedback about the talks, share what I learnt and complain about English food.
I must start by confessing to some ignorance: I didn’t know about ACCU, what they did or how long they’ve been around until last year when somebody asked me if I planned to submit a paper there.
“How should a function handle in-out arguments?” is an old question that still come back from time to time. There’s a lot of advice out there, yet the solutions are still debated. In this post I try my hand at offering an alternative.
A couple weeks ago, Arvid Gerstmann made a (somewhat innocent :D) remark on twitter that sparked some debate:
It may have come as a surprise to some that I moved to C++11 on my day to day job only very recently. One question it often raises is “how can you work without Modern C++?”. In this article I’ll try to defend that Modern C++ has almost nothing to do with C++11, 14 or 17.
In a recent episode of CppCast, Jason Turner asked me to give my perspective on what the life of a C++ developer was in the day to day business. As I explained, my company has been releasing versions of a financial software for more than 30 years now and we only made the move from C++03 to C++11 in the last months.