stdplaceholder

The linux kernel has got, conservatively, thousands upon thousands of defects. The only reason to read it is in case you really need to know how it actually works, because the documentation for some syscall is wrong or your systems aren't working right in practice, or you need to know how some undocumented hardware works. Otherwise I'd say it's best left unread.

It results in slower generated code and much larger binaries, neither of which would be acceptable to Google (some of their binaries are already on the brink of being unbuildable, so a bunch of junk to enable exceptions is not possible.)

It's ambiguous in the article, and it's not specifically mentioned in the Google C++ Style Guide, but during code review at Google it's likely that a reviewer will object to this code:

  std::vector<int> v;
  v.resize(10, 42);

That form of std::vector::resize is discouraged because nobody can remember which argument is which. A reviewer would probably prefer:

  std::vector<int> v(10);
  std::fill(v.begin(), v.end(), 42);

Or even

  std::vector<int> v{42, 42, 42, 42, 42, 42, 42, 42, 42, 42};

I have some other quibbles with this article

* "Not marking it inline is a sure way to prevent inlining" is totally wrong) * The bit about using-directives is also pretty wrong. See https://abseil.io/tips/153 for why. And the example the author gives is terrible:

  void foo() {
    using namespace std::placeholders;
    std::bind(bar, _1, 2);

This doesn't even need a using-directive.

  void foo() {
    using std::placeholders::_1;
    std::bind(bar, _1, 2);

It's shorter, even.

To summarize, the Google C++ Style Guide is there to assist reviewers in reviewing new code. Contrary to what the author thinks, the guide doesn't prescribe anything. At Google decisions are always left to the reviewer. Read the Abseil libraries to see how the style guide applies and when it is ignored.