これは次の記事に対する批判・訂正記事です. 元記事が修正されたら削除されます.
おまえもしかしてまだ自分がモダンC++使わなくてもいいとでも思ってるんじゃないかね？
はじめに
何なのでしょうね？ コメントに書こうと思ったのですが長くなりそうなので. はじめに私のC++戦闘力は初心者です.
大正時代に西洋文化の風俗・流行を積極的に取り入れた若者達を, モガ・モボと呼んだそうです. モダンC++でモピでしょうか. モダンという言葉は相対的で, QiitaはすぐしぬC++99が発行されたときには不適切だと思います.
ドラスティックに変化したのはC++11であるという見解は一般的に賛同されそうなので, C++11がモダンであると定義してもよさそうです（2022年）. ですのでC++11がモダンであるとします.
私個人としては更新ごとに自身の知識も更新して, コードも再構築していけばいいのでは？という考えです.
まず, 非推奨だからダメです, は説明になっていないので特に言及しません. どうして非推奨になったのか, その代わりにどうすべきか, が最も重要だと思います.
スマートポインタ
auto_ptrという, ブロック内のnewで確保したリソースの解放を保障するポインタがありました. このポインタは配列には対応していない, コンテナやクラスのメンバに持つ用途を考慮していない, と用途が限定的でした. 用途が限定的なのに, その用途以外での使用を禁止することができなかったのが問題になっていました.
auto_ptrの代替として, unique_ptrが良いでしょう. auto_ptrが想定する範囲を含む一般的なリソース解放と名前のとおり所有者は唯一なことが保障されます, COMのような独自のリソース管理にも対応できなくもないです.
shared_ptrはリソースを共有したい場合に用います. 解法済みリソースへのアクセス, ２重解放やディープコピーの問題を解決します（するかもしれません, ディープコピーの問題はシステムの設計にも依存するのでスキップします）. 必ずunique_ptr以上のコストが必要です. 参照カウント方式で実装する場合, カウンタ用の追加のメモリ確保, ポインタサイズの増加やカウント増減のコストが必要です. 実際にみたイケていない事例では, Implイディオムにshared_ptrを使っていたことがあります.
ラムダ式
ソートのcomparisonや, 探索のpredicate程度だと何がしたいかは明確だと思います.
ファイバやグリーンスレッドではない, カーネルスレッドに渡す関数で, 通常数行ではオーバヘッドの方が大きくなると予想されるので考えられず, 数百行のコードになることでしょう. 数百行のコードが可読性が良いかどうかは個人の感想だと思います.
そもそも論として可読性が悪くなる原因は, メソッド名を考えなくて済むのような態度にあるのではないでしょうか. コードが自身を明らかに説明するように, シンボル名を吟味したほうがよいのではないでしょうか.
auto
仕事以外でコードを書く方や, 使い方を誤らなければ好きにすればと思いますが, 多用されたコードを見たいとは思わないです.
C#ですが, COCOAのコードはJavascriptかな？と思います, 私は分かり易いとは思いません. なんちゃって型推論について, 推奨する方々は他人の書いたコードを読むということ, したことがあるのでしょうか？（私事でげきおこ）.
書いた本人が理解していることと, 他人が見て分かり易いは別物だと思います.
constexpr
コンパイル時に評価してくれるかもしれない式, という認識でした.
マクロとは異なり副作用がなくは, マクロに副作用を埋め込むことができるのでしょうか？私は知らないので, 年明けにでもチャレンジしたいです（大嘘）, 意図しない置換とかそういう意味かと推測しますが.
まとめ
先生のCppConでの公演を見ていると最近はC++教育への関心が高いように思います. それでも, 先生の著書にたびたび出現するプログラマは自分のしていることを理解しているという趣旨の言は今でも有効なのかなと思います. C言語熟練者が有力ユーザであったころの名残はあるのかなと思います.
C++はセキュアになってもいないし, 実行効率がよりよくなってもいないと思います. セキュアな方法, 効率的な方法を選択できるようになりましたが, 誤用するとやはりアンセキュア, 非効率になる言語だと思います.