C++11
C++20 で UTF-8文字列リテラルが型が追加される。
文字リテラルについては C++17 から。
もしかすると、特殊なアクセスクラスを定義できるかも。
パフォーマンス向上という側面があるのか。
あと、昔から見かける throw キーワードは C++11で非推奨、 C++17 で削除（コンパイルエラー）。
知ってたけど使ってなかった。
知らんかった。
あまり使うことは無いと思うけど。
以前の記事でコメントいただいたもの。 Singleton で使える。
まだ自分の実装で使う機会に遭遇していない。
目玉飛び出た。
いい加減、癖つけるべきかな。
あれ？ :: 居るんだっけ？ 許可されただけの話？
個人的には嫌だけど仕様としては明確に許可されている。
パラメータパックの拡張はたまに忘れる。
[[noreturn]] は知っていたが [[carries_dependency]] は知らんかった。
explicit ってコンストラクタ以外でもあるのね。
進化中。C++17 で更にバージョンアップ。（beginとendの型が異なってもOKになる）
まじ？
デフォルトコンストラクタで初期化子を並べるより初期化ミスが減る気がする。
C++14
constexpr 関数内で変数の書き換え許可ができるらしい。関数自体はコンパイル時定数だけど、副作用作れるのね。
ラムダ式で template 使える。
当たり前だが、具体化しないと std::function には詰め込めない。
ラムダ式のキャプチャ指定子で std::move が使えるのはこの子のお陰なので C++14 以降となる。
生ポインタ使う機会が少ないから微妙だけど、こんな事ができるのね。
おっ！と思ったが、科学技術計算系じゃないと縁が無いかも。
ちなみに、この件のデフォルトテンプレート引数のサポートは C++17 から。
気をつけないと、C++11でエラーが多発するかも。
auto がいっぱい。何となく今後のバージョンで後置式のルールが変わりそうな予感。
地味に便利。何桁毎に区切るかは任意。
C++17
#if defined を拡張した感じだが、 template で特定の型だとエラーが発生するため制御を分けたい場合なんかに重宝しそう。
いつか使うかも。
POD 系のデータ変換とかで無理やりが無くなるかも。
変数定義がスコープに収まって便利かも。慣れが必要だな。
これは捗る。
ようやく出たか。
あと、 inline の定義って、関数が（積極的に）展開されるって意味だけじゃなく、同一アドレスに配置されるという意味があるのを再確認。
これで、生成ヘルパー関数が不要になりそう。
そんな制約あったのね。 C++17 で制約撤廃。
const 的な感じ。
ここで言う「コピー省略」とはコピーコンストラクタを起動させないという意味。
clang で NRVO (Named Return Value Optimization)を std::move で返却すると「やる必要無いよ」的な警告出たような。要確認。
ライブラリとか作るときに便利。
これは偉大。 TypeScript の文字列リテラル型みたいの作れるかも？
auto a += ++b; 問題がこれにて終結。（++b が先に評価される）
基本的に代入式以外は左が先に評価される。
std::launder って何者だ？
へぇ〜（小並感）
ここでようやくか。。。ちなみに型はどうなるんだ？？参照はできるんか？？
やりたければ、可変引数テンプレートにしろってやつね。
ん？ あ！ なるへそ！！
確かに今まで面倒だったけど、実際、あまり使うケース無いかな。
そのうち使うかもだけど C++14 を考えると、今のところ取り立てて必要なものでもないかな。
これやってたらゲンコツものでしょ。
ちゅうか、この記事で std::exchage を知ったわ。
さよなら。 でも、別な機能で復活するかもね。
C++20
<=> 宇宙船演算子。 これで得られる値はboolではなく 比較カテゴリ型 という特殊な型になる。数値比較が困難なものに対する順位付けを一般化した感じ。コンパイラで演算子を許容して、ライブラリで実装するという珍しいパターン。
最近はぬるま湯な環境をターゲットにして開発してるから、ビットフィールドを使う場面が減ったなぁ。。。
SFINAEを利用した実装パターンを整理しているんだろうな。SFINAEによる恩恵は大きいものの、可読性の低さや、エラーが難解というデメリットを排除する活動の一貫だと思う。
そもそも .* なんて使ったことなかったので利用用途不明。ディスパッチテーブルとかで使うのかな？
意図して、自身の非const参照を受けるコンストラクタなんて書かないけど、templateでは問題となるな。
クラス内クラスが非publicで定義されていた場合、その子クラスは親クラス内だとしても非publicはアクセスは禁止だったのに、実際はアクセスできるコンパイラーが続出して、そのままグレーな状態で取り扱われていたらしい。Javaって、こんな感じだったような。でも、templateでは厳格に規制されていたので、一緒にグレーにするという話。friendって使えたような気もするが、気のせいだったかな？
お〜、これでunit型が効率よく作れますな。それはそうと、この説明内で空の型であっても、ユニークなアドレスを割り当てるために大きさが0にはならない。ということにガクブル。
そもそも、構造化束縛ってプリミティブ型だらけだとバグの温床になりそう（例えば座標のx,yをy,xで受けたりとか）だから、tupleの展開では使うかもだけど、サンプルのような使い方ってするかなぁ？
理由は分かるが、罠にならないか心配。
地味に助かる。
あ〜、もっと早くこれがあれば、階層構造を持つオブジェクトのデストラクタでスタックオーバーフローするのを防げたかもだわ。
C からの移植を考慮したものらしい。また、他にもこれにより解決するものがあるみたいだけど、そこまで攻めたコードは書きたくない。
switch-case文で、スコープ指定が長いと、重要な右側が見えなくなるということがなくなるな。
ようやく仕様になった。でも、中途半端だな。せめて順序は自由になってほしい。
構造化束縛で定義した変数をラムダ式へキャプチャできるようになった。
暗黙の型変換が効くのか否かが違うのか。。。これ、どっちかに寄せて欲しい。（できれば暗黙の型変換しない方に）
未確認