C ++ 11で廃止されたC ++イディオムはどれですか？

新しい標準では、物事を行うための新しい方法があり、多くは古い方法よりも優れていますが、古い方法はまだ問題ありません。また、下位互換性の理由から、新しい標準が公式にあまり非推奨にならないことも明らかです。したがって、残っている問題は次のとおりです。

C ++ 11スタイルよりも確実に劣るコーディングの古い方法と、代わりに今できることは何ですか？

これに答えるには、「自動変数を使用する」などの明らかなことをスキップできます。

1. 最終クラス：C ++ 11は、finalクラスの派生を防ぐための指定子を提供します
2. C ++ 11ラムダは、名前付き関数オブジェクト（ファンクター）クラスの必要性を大幅に減らします。
3. 移動コンストラクター：std::auto_ptr右辺値参照のファーストクラスサポートにより、動作が不必要になる魔法の方法。
4. Safe bool：これについては前述しました。C ++ 11の明示的な演算子は、この非常に一般的なC ++ 03イディオムを取り除きます。
5. 縮小して合わせる：多くのC ++ 11 STLコンテナーは、shrink_to_fit()メンバー関数を提供します。これにより、一時関数と交換する必要がなくなります。
6. 一時的な基本クラス：一部の古いC ++ライブラリは、このかなり複雑なイディオムを使用しています。移動のセマンティクスでは、これはもう必要ありません。
7. タイプセーフ列挙列挙は、C ++ 11では非常に安全です。
8. ヒープ割り当ての禁止：= delete構文は、特定の機能が明示的に拒否されていることを示すより直接的な方法です。これは、ヒープ割り当ての防止（つまり、=deleteメンバーの場合operator new）、コピーの防止、割り当てなどに適用できます。
9. テンプレート化されたtypedef：C ++ 11のエイリアステンプレートは、単純なテンプレート化されたtypedefの必要性を減らします。ただし、複合型ジェネレータには依然としてメタ関数が必要です。
10. フィボナッチなどの一部のコンパイル時の数値計算は、一般化された定数式を使用して簡単に置き換えることができます
11. result_of：クラステンプレートの使用はresult_ofに置き換える必要がありdecltypeます。入手可能な場合にresult_of使用decltypeすると思います。
12. クラス内のメンバー初期化子は、デフォルト値を持つ非静的メンバーのデフォルト初期化のためのタイピングを節約します。
13. 新しいC ++ 11では、コードNULLをとして再定義する必要nullptrがありますが、STLの話を見て、なぜそれを反対したのかを学んでください。
14. 式テンプレートの狂信者は、C ++ 11に後続の戻り型関数構文があることを喜ばしく思います。30行の長い改行タイプはもうありません！

やめようと思います！

ある時点で、const値だけではなく値で戻る必要があると主張されました。

const A foo();
^^^^^

これはC ++ 98/03ではほとんど無害であり、次のようないくつかのバグをキャッチしている可能性もあります。

foo() = a;

しかしconst、C ++ 11では、移動のセマンティクスが阻害されるため、by by は禁忌です。

A a = foo();  // foo will copy into a instead of move into it

だからリラックスしてコーディングしてください：

A foo();  // return by non-const value

を放棄0してNULLを支持するようになったらすぐにnullptr、そうしてください！

非一般的なコードでは、0またはの使用NULLはそれほど重要ではありません。しかし、汎用コードでnullポインター定数を渡し始めるとすぐに、状況は急速に変化します。0a template<class T> func(T) Tに渡すとint、nullポインタ定数ではなく、として推定されます。そして、それをその後NULLポインター定数に戻すことはできません。これは、宇宙が使用されているだけでは存在しない問題の泥沼にカスケードしnullptrます。

C ++ 11は非推奨0ではなくNULL、nullポインター定数として使用します。ただし、コーディングしたようにコーディングする必要があります。

安全なブールイディオム → explicit operator bool()。

プライベートコピーコンストラクター（boost :: noncopyable）→ X(const X&) = delete

プライベートデストラクタと仮想継承を使用した最終クラスのシミュレーション →class X final

C ++ 11で基本的なアルゴリズムを作成することを避ける理由の1つは、標準ライブラリによって提供されるアルゴリズムと組み合わせたラムダの可用性です。

私は今それらを使用していますが、いまいましいループを再度書く必要がなく、count_if（）、for_each（）、または他のアルゴリズムを使用して、やりたいことをどれだけ頻繁に伝えるかは驚くべきことです。

完全なC ++ 11標準ライブラリでC ++ 11コンパイラを使用すると、 使用すると、標準のアルゴリズムを使用してを構築しないという言い訳はもうありません。ラムダはただそれを殺します。

どうして？

実際には（このアルゴリズムの記述方法を自分で使用した後）、意味を知るために暗号化を解除する必要があるいくつかのループよりも、何が行われるかを意味する単純な単語で構築されたものを読む方がはるかに簡単に感じられます。とはいえ、ラムダ引数を自動的に推定することは、構文を生のループと比較しやすくするのに役立ちます。

基本的に、標準的なアルゴリズムで作成されたアルゴリズムの読み取りは、ループの実装の詳細を隠す単語としてはるかに簡単です。

構築する低レベルのアルゴリズムがあるので、今考えなければならないのはより高レベルのアルゴリズムだけだと思います。

swap頻度の低いカスタムバージョンを実装する必要があります。C ++ 03では、swapコストのかかるコピーのスローを回避するために、効率的な非スローがしばしば必要ですstd::swap。2つのコピーを使用するため、swap多くの場合、カスタマイズする必要があります。C ++では、std::swap使用moveしているため、効率的でスローされない移動コンストラクターと移動代入演算子の実装に焦点が移ります。これらの場合、デフォルトで十分な場合が多いため、これはC ++ 03の場合よりも作業がはるかに少なくなります。

一般的にどのイディオムを使用するかは、経験を通じて作成されているため、予測するのは困難です。「効果的なC ++ 11」はおそらく来年、「C ++ 11コーディング標準」は必要な経験がまだないため、3年でしか期待できません。

名前はわかりませんが、C ++ 03コードでは、欠落した移動割り当ての代わりに次の構文を使用することがよくあります。

std::map<Big, Bigger> createBigMap(); // returns by value

void example ()
{
  std::map<Big, Bigger> map;

  // ... some code using map

  createBigMap().swap(map);  // cheap swap
}

これにより、swap上記と組み合わせたコピー省略によるコピーが回避されました。

C ++ 11標準を使用しているコンパイラーが次のコードでエラーにならないことに気付いたとき：

std::vector<std::vector<int>> a;

おそらくオペレーターが含まれているため>>、私は踊り始めました。以前のバージョンでは、実行する必要がありました

std::vector<std::vector<int> > a;

さらに悪いことに、これをデバッグしなければならなかった場合、これから出されるエラーメッセージがどれほど恐ろしいかを知っています。

ただし、これが「自明」かどうかはわかりません。

値による戻りは問題ではなくなりました。移動のセマンティクスや戻り値の最適化（コンパイラーに依存）を使用すると、オーバーヘッドやコスト（ほとんどの場合）がなく、コーディング機能がより自然になります。