2

ここでは、特別なメンバー関数を明示的に宣言することについて議論しています。そうするのは悪い習慣ですか？つまり、コンパイラが生成したバージョンはメンバーごとの操作を実行します。まったく同じことを行うメソッドを実装する場合 ( three/five のルールを考慮してください)、それはより多くの作業であることに加えて、これは悪い習慣ですか?

もちろん、それは冗長であり、コード ベースを肥大化させると言えます。明示的な宣言を行うとデバッグが簡単になると主張する人もいます (たとえば、オブジェクトがコピーされるたびにブレークポイントを設定できるため)。

では、(以下のWiki ページExplicitに基づく例)のようなクラスを書くのは悪い習慣ですか、それとも単なる個人的な好みですか?

class Explicit {
    string msg;
public:
    Explicit() : msg("") {}
    Explicit(const Explicit& other) : msg(other.msg) {}
    Explicit& operator=(const Explicit& other) {
        if (this != &other) { msg = other.msg; }
        return *this;
    }
    ~Explicit()  {}
};
4

1 に答える 1

4

本当の冗長性は、これらの特別なメンバー関数の実装でデータ メンバーに言及するという事実にあります。

すべての冗長性と同様に、これはある日、一方を変更しても他方は変更しないというリスクを伴います。たとえば、データ メンバーを追加し、特別なメンバー関数を更新するのを忘れます。

= defaultC++11コンストラクトを使用しても、その特定の冗長性が回避されるため、何も問題はありません。

于 2013-08-19T11:28:45.877 に答える