Category Archives: C++

The tradeoffs in using -Weverything

In addition to well-known -Wall, clang offers another interesting warning flag: -Weverything. While it sounds like a “strictly better” option (the more warnings, the better?) it’s not.

This topic is already well covered by Arthur O’Dwyer’s blog post and the clang documentation.

Arthur makes a strong case against use of this flag. While the clang docs generally agree, though offering a slightly more lenient position:

If you do use -Weverything then we advise that you address all new compiler diagnostics as they get added to Clang, either by fixing everything they find or explicitly disabling that diagnostic with its corresponding Wno- option.

What I have not seen clearly expressed is how use of -Weverything is a tradeoff.

The downsides are:

  • Increased flag noise from having manually resolve contradicting flags (using  -Wno-c++98-compat and -Wno-missing-prototypes)
  • Friction in upgrading compilers. Upgrading may “break” your existing warning-clean code, because of new warnings that have been added. This means you need to resolve all of those issues (via fixing code, or adding new flags to disable warnings) before officially supporting the toolchain.
  • Exposure to “experimental” diagnostics that may be “lower quality”.

However, there are advantages:

  • Discovering useful new warnings that you may never have used otherwise
  • Finding and fixing bugs during compiler upgrades as a result of these new warnings

Whether you are working on a library or application will also affect your decision.

If you maintain a library (especially an open source one), it makes sense to avoid -Weverything. You have less control over which compiler versions your users use, and you want to avoid users encountering new warnings if they use a new compiler release to build the library. (Assuming you keep a warning-clean codebase).

However, if you are simply developing an application (especially a closed source one), it may make sense to use -Weverything. In this environment, you have complete control over the approved toolchain that can be used to build the project, and can have a transition period where new warnings are addressed. There will be more friction for toolchain upgrades, but you may find that the benefits in continually using the newest warnings outweigh that downside.

Thanks to Ryan Brown for teaching me this.

Surgical formatting with git-clang-format

If you’re already a 10x engineer, you probably won’t need this article. But for the rest of us, this is what I wish I knew about clang-format as an inexperienced C++ programmer: how to only format the changes in your pull request.


You may have already heard of clang-format. It auto-formats source files for languages including C and C++. You can aim it at a source file and format the entire thing using clang-format -i file.cpp.

If you’re contributing to a project that is already 100% clang-format clean, then this workflow works fine. But you’ll occasionally encounter a project that is not quite 100% formatted, such as LLVM, osquery, or Electron1.

For these projects, the “format entire files” workflow doesn’t work because you’ll incidentally format parts of the files that are unrelated to your contribution. This will add noise to your diff and make it harder for your reviewers.

In this case, you need a way to surgically format only the lines changed in your contribution. To do this, you can use the clang-format git extension. This article will cover the basics of git-clang-format, including a practical workflow that allows for messy development, and formatting at the end.

Continue reading

What they don’t tell you about demand paging in school

This post details my adventures with the Linux virtual memory subsystem, and my discovery of a creative way to taunt the OOM (out of memory) killer by accumulating memory in the kernel, rather than in userspace.

Keep reading and you’ll learn:

  • Internal details of the Linux kernel’s demand paging implementation
  • How to exploit virtual memory to implement highly efficient sparse data structures
  • What page tables are and how to calculate the memory overhead incurred by them
  • A cute way to get killed by the OOM killer while appearing to consume very little memory (great for parties)
Continue reading

Don’t confuse std::move and std::forward

This was a pretty interesting buggy scenario I found while reading the clang-tidy checks. If you’re writing a function that takes a forwarding reference (what looks like an rvalue reference, but whose type is a template argument), you need to be careful to not call std::move on it. You need to make sure to call std::forward instead. Otherwise, you might accidentally trigger a move on an object passed by a caller! This would be confusing, since their object would be moved from, and they never explicitly called std::move on it.

Continue reading

Getting bit by unique_ptr

I got bit by unique_ptr when implementing a linked list today. You need to be careful to manually release() the unique_ptr before resetting or you might accidentally free the entire list. This comes up when doing insertions and stuff like that.

Being pedantic about C++ compilation

Takeaways:

  • Don’t assume it’s safe to use pre-built dependencies when compiling C++ programs. You might want to build from source, especially if you can’t determine how a pre-built object was compiled, or if you want to use a different C++ standard than was used to compile it.
  • Ubuntu has public build logs which can help you determine if you can use a pre-built object, or if you should compile from source.
  • pkg-config¬†is useful for generating the flags needed to compile a complex third-party dependency. CMake’s¬†PkgConfig¬†module can make it easy to integrate a dep into your build system.
  • Use CMake¬†IMPORTED¬†targets (e.g.¬†BZip2::Bzip2) versus legacy variables (e.g.¬†BZIP2_INCLUDE_DIRS¬†and¬†BZIP2_LIBRARIES).
Continue reading