はじめに
最近CppCon等のC++カンファレンスのプレゼン動画を色々見ていまして、その中から役立つとか面白いなと思ったものを紹介します。
How to Adopt Modern C++17 into Your C++ Code
Build 2018: Herb Sutter "How to Adopt Modern C++17 into Your C++ Code"
This talk should be good for you, should give you a nice overview of what modern C++ is with accessible code examples. (...)
Let's talk about classic and modern C++. (...) But C++ has a great backward compatibility story. We hardly ever break backward compatibility. So that code you wrote more than 20 years ago still works today.
But if you are updating it, if you are updating this function anyway, or you are writing a new code, you might find that you can do the same in fewer lines with equal efficiency. This is not turning C++ into C#. This is simply letting us spell efficient C++ more conveniently like in any modern languages.
(...) That does not mean that you should go and rewrite all the code in the left in right style unless you touch that function in any way. You do not need to rebuild the whole world. That code still works. But when you write a new code or when you're modernizing your code, this is the kind of thing you can do tactically throughout your code base. So a strong compatibility story, and remember the code in the left is just as clean now and safe, just as fast as ever.
All Your Tests are Terrible...
CppCon 2015: T. Winters & H. Wright “All Your Tests are Terrible..."
悪い例と良い例をユーモアを混じえて紹介しており、非常にわかりやすくまた面白いプレゼンです。
Googleで働く中で得たテストに関する発表者達の知見が紹介されています。
- 良いテストが備えている5つの条件
- Correctness
- Readability
- Completeness
- Demonstrability
- Resilience
ただし前提条件として「テストを書く」必要があります。
「テストを書かないより、悪いテストでもいいからとにかくテストを書け」だそうですｗ。
Whitespace ≤ Comments << Code
CppCon 2017: Walter E. Brown “Whitespace ≤ Comments ＜＜ Code”
内容をまとめると、「コメントを書くよりも、何をしているか読めばわかる良いコードを書こう」ということになるでしょうか。
- 間違っているコメントは価値がないどころか有害である。
- 正しいコメントでさえ使い物にならないか邪魔者である。
- 可能な限りコードを通して表現すること。
- 「名前を付けろ。説明するな。」
- わかりにくい名前をつけない。
- わかりにくいコードにコメントを加えるな。コードを書き直せ。
まさにその通りで。
書き直さずに一発で良いコードを書けるようになりたいなあ…
Efficiency with Algorithms, Performance with Data Structures
CppCon 2014: Chandler Carruth "Efficiency with Algorithms, Performance with Data Structures"
C++ doesn't give you performance.
It gives you control over performance.
パフォーマンスを求めるならば、非連続なデータ構造を使ってはいけません。
例えばstd::mapやstd::unordered_mapなど。
I am gonna really blame here I have no code that I have ever worked with which should have used std::map.
The Most Important Design Guideline
Scott Meyers – The Most Important Design Guideline
Effective C++で有名なScott MeyersがAPIデザインの原則を、実際にあった悪い例を紹介しつつ説明します。
ユーモアたっぷりなので退屈せずに最後まで聞けます。
- APIの原則: Easy to use correctly, hard to use incorrectly.
- The principle of least astonishment.
- Use progressive disclosure.
- Document before implementing.
- Introduce new types.
There is an important lesson here. If you are so fortunate as to designing interface that become so comfortable to people that they're still using it and clambering for it, twenty years later, you would like it to be an interface you would proud of.