Godbolting your C++ code
A: Hi, Matt. I first want to congratulate you on the fantastic presentation you did at CppCon in Bellevue (at the end of the interview you can find an official video recording of Matt’s keynotes session). It was inspirational and highly informative!
While you share the story of Compiler Explorer in the session, could you briefly talk about the major reasons that made you want to work on it?
M: I work in the trading industry where performance can be really important. A friend and I were considering whether we could use range-for instead of a normal for-loop, but we wanted to be sure the compiler generated good code for the new feature. I hacked together a quick script to quickly dump the compiler output and Compiler Explorer was born! Once we had the tool, it became an invaluable way to explore different ways to write the same piece of code and see what the assembly looks like. Luckily, it turns out compilers are really good these days: one usually can write the C++ code as clearly as possible, and the compiler will generate great assembly for you.
A: Let’s talk about Assembly. Why do you think it’s important for the developers to check it? How does it benefit their development process?
M: As your CPU doesn’t run the C++ you write directly, I think it’s really important to have a look at the assembly from time to time. I don’t mean one should read every line of output, but even for those not working in high performance environments, knowing what the compiler and CPU are actually doing to make your code come to life is important. For example, it’s easy to accidentally make copies of things using
auto instead of
auto &. Often you can spot such unintentional copies if you look at the assembly output.
Having some idea on how the code you write maps to the instructions your CPU executes can inform high-level decisions. Some algorithms have very efficient implementations, if you know the compiler and CPU can use specific CPU instructions.
A: With Compiler Explorer, everyone has a chance to compare many compilers in detail. Do you think that an everyday developer can learn something useful from such an experience?
M: It’s an interesting exercise to take a small snippet of code and see how much the output varies by compiler, and by compiler setting. Some compilers have some pretty amazing optimizations, be it the ability to replace O(n) algorithms with constant-time ones, or very clever vectorization. It might even cause you to reconsider which compiler you use to build your code!
A: I see people are now using Compiler Explorer widely, sharing links to hundreds of code samples there. Herb Sutter uses links to metaclass examples running in the Compiler Explorer in his proposal. How do you feel about this massive Godbolting of the code? Does it make you feel more pressure?
M: Honestly, I’m still pretty much in shock about how much Compiler Explorer is being used these days. There’s a certain amount of pressure on making sure the site is always up, and the URLs last forever. Having Patreons now contributing to the site with monthly donations also adds to the pressure: I feel obligated to do a good job for them. Fortunately there’s now a growing number of folks helping out in adding features and administrating the site.
A: Apart from the Compiler Explorer, you have a job in a trading company in Chicago. What’s your usual technology stack there? I guess it’s a C++ job? Do you use Compiler Explorer in your duties there?
A: I know you are a CLion fan ;), but let me ask in general, why do you think it’s beneficial to use an IDE for C++ development? What are the main reasons from your point to move to an IDE?
M: I’m passionate about using the right tool for the job. I think there’s something about the tool you use that shapes the way you think about problems. I first noticed this when pair-programming with an accomplished Java programmer using IntelliJ IDEA: it was obvious the IDE formed part of his thought processes. His ability to write code, morph it using refactoring, and quickly iterate on design trade offs was impressive.
C++ has a high barrier to refactoring: the usual pattern is “global search and replace then fix up all the errors”. A simple class rename can take hours, and that makes it easy to put off doing it. That generally makes for poorer code quality in the long run, or prolonged refactoring tasks. With a good IDE, one can rename classes, find usages and modify interfaces quickly, and I think the code improves as a result.
A: Regarding the modern and (following Tony Van Eerd’s classification) postmodern C++, do you think we are moving in a right direction? What are your thoughts on Modules, Concepts, Metaclasses and other features that are under discussion in the committee now?
M: I’m super excited about the future of C++. I must admit, I was losing faith during the “template madness” years, where SFINAE and other tricks brought useful, but extremely arcane and hard to get right ideas and features to C++. With the dawning of
constexpr that all started to change, and with Concepts surely close, using templates will become a lot easier.
I’m a fan of fast build times and I’m hopeful Modules will undo some of the drawbacks of templates and
constexpr in terms of placing more implementation in headers.
Finally, Metaclasses – or something like it – will finally kill off the majority of the funny code generators one ends up writing. I’m particularly excited about that – provided the tools providers can step up and help with the debug situation.
A: One last question. What’s the trickiest piece of C++ code you’ve ever met? Feel free to share a link to the Compiler Explorer as an answer.
M: Some of my favourite snippets of code aren’t so much C++ as C: I’m still a low-level hacker at heart, so I love things like Bit Twiddling Hacks. Recently I needed to find the number of base ten digits in a number quickly and I ended up with a bit of code like this, which combines neat branchless bit trickery with some cool processor instructions.
A: Thanks Matt!