私たちはよく、古典的な C++ と最新の C++ について話します。どういう意味ですか?まず第一に:現代の C++ とは?.単純な答えとそれほど単純ではない答えがありますか?簡単な答えは. Modern C++ は、C++11、C++14、および C++17 に基づく C++ の略です。あなたはそれを知っていると思います。この投稿とその後の一連の投稿は、それほど単純ではない答えに関するものです。
C++11 で革命が起こりました。その革命は C++14 で起こり、C++17 で進化します。 C++ 機能のタイムラインを概観すると、私の主張が明確になります。
C++11 以降に得られた膨大な量の機能とその影響の理由を見ると、2011 年以前の C++ と 2011 年以降の C++ は異なる言語であるという結論に達する必要があります。 1 つ目は従来の C++ と呼ばれ、2 つ目は最新の C++ と呼ばれます。したがって、2011 年以前とそれ以降では、C++ をプログラミングする慣用的な方法はまったく異なります。
今、あなたはすでにそれを知っています。質問に答えたい。この強力な機能は、C++ でのプログラミングに対する私たちの考え方をどのように変えましたか?私が答えたいのは、それほど単純ではない質問です。
2 つのリソース
探しているのは私だけではありません。利用可能な優れたリソースがあります。そのうちの 2 つを次に示します。
C++ のベスト プラクティス
Jason Turner による C++ のベスト プラクティスは、「C++ のベスト プラクティスの共同コレクション」です。これは、C++ を使用した最新のソフトウェア開発と、優れた C++ コードの一般的な考慮事項に関する非常に価値のある情報源です。これらの一般的な考慮事項には、コードの安全性、保守性、移植性、スレッド化、およびパフォーマンスが含まれます。
今日は、コードの一般的な考慮事項については強調しません。C++ のベスト プラクティスで彼が提供する一連のツールについて強調します。
彼の C++ ベスト プラクティスには、
- ソース管理
- ソフトウェアの構築
- 継続的統合
- gcc、clang、msvc などのコンパイラ
- 静的コード分析
- ランタイム チェッカー
- テスト
- デバッグ
あなたがプロのソフトウェア開発者である場合 (投稿を読んでいるからだと思います)、プロのソフトウェア開発プロセスで使用するツールを決定する必要がある場合は、この優れたリソースを使用して、ツールとは何かを理解する必要があります。
今日は、次の記事で何を書こうか考えてみたいと思います。私のメイン トピックは、C++ コア ガイドラインです。
C++ コア ガイドライン
要約の目標は次のとおりです。「このドキュメントは、C++ を適切に使用するための一連のガイドラインです。このドキュメントの目的は、人々が最新の C++ を効果的に使用できるようにすることです。「最新の C++」とは、C++11 を意味します。および C++14 (およびまもなく C++17) になります。"
編集者は Bjarne Stroustrup と Herb Sutter です。
C++ コア ガイドラインは、100 を超えるルールのセットです。これらの規則は、主要なセクションと補助的なセクションに分かれています。主なセクションは次のとおりです。
- 中:はじめに
- P:哲学
- I:インターフェース
- F:関数
- C:クラスとクラス階層
- Enum:列挙
- R:リソース管理
- ES:式とステートメント
- E:エラー処理
- 短所:定数と不変性
- T:テンプレートとジェネリック プログラミング
- CP:並行性
- SL:標準ライブラリ
- SF:ソース ファイル
- CPL:C スタイルのプログラミング
- プロ:プロフィール
- GSL:ガイドライン サポート ライブラリ
- FAQ:よくある質問への回答
導入部分を詳しく見てみたいと思います。次のようなメタルールを扱います:
- In.target:対象読者層
- In.aims:目的
- In.not:非目的
- In.force:施行
- In.struct:このドキュメントの構造
- In.sec:主なセクション
メタルールを言い換えましょう。 ターゲット読み取り r は C プログラマですらあります。 目的 ルールの目的は、開発者が最新の C++ (C++11、C++14、そしてまもなく C++17) を採用するのを支援することです。これらの規則は、静的型の安全性とリソースの安全性を強調しています。ルールは規範的なものであるため、ルールを理解する必要があります。ルールには目的と非目的があります .それらは最小限または直交することを意図したものではなく、連続して読む必要があり、チュートリアルの扱いに代わるものではありません.ルールは、古い C++ コードを新しいコードに移植するためのガイドであり、各言語の詳細で正確であるべきではないか、C++ の貧弱なサブセットを強制するか、または価値中立または完全である必要があります。各ルールには施行があります このガイドラインは、人々がコードを統一して最新化するのに役立つはずだからです。規則は統一された構造に従っています .構造はポイントで構成されています
- ルール
- ルール参照番号
- 理由
- 例
- 代替
- 例外
- 施行 ルールが「機械的に」チェックされる方法
- こちらもご覧ください
- 注意
- ディスカッション
正直なところ、(デザイン)パターンの文献を強く思い出します。
ここで構造の意図を明確にするために、ルール R.22 の短い例を示します。 R はリソース管理を表します:
R.22:make_shared()
を使用 shared_ptr
にする
理由
最初にオブジェクトを作成し、それを shared_ptr
に渡した場合 make_shared()
を使用する場合よりも、(ほとんどの場合) 1 つ多くの割り当て (およびその後の割り当て解除) を行います。 参照カウントはオブジェクトとは別に割り当てる必要があるためです。
例
検討:
shared_ptr<X> p1 { new X{2} }; // bad
auto p = make_shared<X>(2); // good
make_shared()
バージョンは X
に言及しています 一度だけなので、通常は new
を明示的に指定したバージョンよりも短く (速く) なります。 .
施行
(シンプル) shared_ptr
の場合に警告する new
の結果から構築されます make_shared
ではなく .
次は?
この投稿を締めくくる前に、最新の C++、特に C++ コア ガイドラインについて書く動機について、いくつか述べたいと思います。自分のモチベーションについて書いているときに、自分のモチベーションを短い文章で表現できないことに気付きました。これで、次の投稿が何であるかがわかります。