1

重複の可能性:
const-correctness はコンパイラに最適化の余地を与えますか?

constここ数週間、意図しないプログラミング エラーを回避するために、可能であればすべての非静的メンバを作成する方法を開発しました。ただし、この方法は、特にエンティティ オブジェクトの場合、いくつかの大きな欠点をもたらします。たとえば、ポインターを使用するのではなく、そのようなエンティティ オブジェクトを直接集約することを選択した場合、代入演算子を呼び出すことができなくなるためです。

私の質問は、このconstメンバーの哲学がコンパイラーの最適化ボーナスを提供するかどうかです。

class User {
public:
    User(const std::string &, const std::vector<unsigned char> &);
    ~User();
    const std::string &getName() const;
    const std::vector<unsigned char> &getPasswordHash() const;
private:
    std::string name;
    std::vector<unsigned char> passwordHash;
};

このclassメンバーがconst. 通常、他のクラスは非 constUserオブジェクトを集約するという事実を考えると、ほとんどすべてのアルゴリズムはconst User &?を受け入れます。

では、メンバーは、すでに存在しているメンタリティconstに対して重要な最適化の機会を提供していますか? また、代入演算子を使用するのではなく、集約をconst User &使用して変更時にオブジェクトを再構築することを正当化できますか?const User *

早速のご指摘ありがとうございます！

4

2 に答える 2

2

SOとHEREでそれについてチェックしてください

于 2012-03-07T09:43:56.250 に答える
1

まず、語彙に関する注意: エンティティ オブジェクトは、定義上、ID を持っているため、代入をサポートしていません。あなたが意味するのは価値オブジェクトだと思います。

それ以外の場合: 通常、データ メンバーを const にするメリットはほとんどありません。お気づきのとおり、そうすると代入が不可能になります。つまり、値型の const にすることはできません。割り当てることができないエンティティ オブジェクトの場合、不変メンバー (識別子など) を const にすることにはある程度の価値がありますが、すべてのアクセスは制御する小さなコード ブロック内にあるため、値はそれよりもかなり小さくなります。constパブリック インターフェイスで。

もう 1 つの可能性は、そのようなメンバーの不変型を定義することです。として定義するよりもnameとして定義する方がはるかに表現力があり、型を持つ単一のデータメンバーしか含まれていない場合でも、それでできることは制限されます。(また、後で識別子の表現を変更することも容易になります。)Identifierstd::stringIdentifierstd::string

于 2012-03-07T09:49:43.287 に答える