同僚がいくつかのライブラリをクリーンアップしています。そうすることで、彼は C++ のAPI 設計を読んでおり、C++ クラスでのコピーを明示的に有効または無効にすることについて話しています。これは、Sutter と Alexandrescu がC++ Coding Standardsで述べていることと同じです。
彼は、このアドバイスに従うべきだということに同意しますが、どちらの本も、いつ有効または無効にするかを指示する指針となる原則については述べていないようです。
いずれかのガイダンスはありますか？ありがとう！
これは、アプリケーションでクラスが果たす役割によって異なります。クラスが値を表していない限り、アイデンティティは重要ではありませんが、コピーと割り当てを禁止する必要があります。同様に、クラスが多形である場合。原則として、クラスタイプのオブジェクトを動的に割り当てる場合は、コピー可能にしないでください。逆に、クラスがコピー可能である場合は、そのインスタンスを動的に割り当てるべきではありません。（ただし、いくつかの例外があり、セマンティクスが別の方法で主張している場合でも、動的に割り当てて大きなオブジェクトのコピーを回避することは珍しくありません。）
低レベルのライブラリを設計している場合、選択はあまり明確ではありません。のようなものstd::vectorは、アプリケーションで多くの役割を果たすことができます。それらのほとんどでは、コピーは適切ではありませんが、コピーを禁止すると、適切な場所では使用できなくなります。
DeadMG とは対照的に、ほとんどのクラスはコピー不可であるべきだと思います。
Stroustrup が著書「C++ の設計と進化」に書いた内容は次のとおりです。
「個人的には、コピー操作がデフォルトで定義されており、多くのクラスのオブジェクトのコピーを禁止していることを残念に思っています」
コピーできないクラスは、ルールではなく、例外であるべきです。名前付きミューテックス、一意の所有権ポインターなど、コピー中に値のセマンティクスを保持できない場合にのみ、クラスをコピー不可にする必要があります。それ以外の場合、クラスはコピー可能でなければなりません。多くの C++ ライブラリはコピー可能性に依存しています。
クラスが本来行うべきことを実行できるようにするには、できるだけ少ないコードを書くように努めるべきだと思います。誰もクラスをコピーしようとしておらず、近い将来にコピーされる予定もない場合は、コピー コンストラクターや代入演算子などを追加しないでください。クラスをコピー不可にするだけです。
いつか実際にクラスをコピーしたい場合は、コピー コンストラクターなどを追加します。しかしそれまでは、クラスをコピー不可にするということは、テストおよび保守するコードが少なくなることを意味します。
コピー セマンティクスは自動的に提供されるべきか、まったく提供されるべきではないと心から信じています。
ただし、不適切に作成されたライブラリは、手動のコピー コンストラクターの恩恵を受ける場合があります。
C++ では状況が大きく異なることに注意してください (通常、標準ライブラリではコピー セマンティクスが必要になるためです!)。