0

私はこのようなクラスを持っています:

class A {
    ...private functions, variables, etc...
public:
    ...some public functions and variables...

    A operator * (double);
    A operator / (double);
    A operator * (A);
    ...and lots of other operators
}

2 * Aただし、許可されるだけでなく、次のようなこともできるようにしA * 2たいので、クラスの外で次のような関数が必要になります。

A operator * (double, A);
A operator / (double, A);
...etc...

一貫性を保つために、これらすべての演算子をクラスの外に置くべきですか、それとも半分を内側に、半分を外側に保つべきですか?

4

3 に答える 3

2

私見、懸念は文体の一貫性ではなく、カプセル化の一貫性にあるべきです。通常、関数がプライベート メンバーへのアクセスを必要としない場合、その関数はクラスの一部であってはなりません。これは難しいルールではありません。ここでの引数を参照してください

そのため、オペレーターがプライベート アクセスを必要としない場合は、それらをすべて外部に配置します。それ以外の場合、それらはすべて次のように内部にある必要があります。

class A {
    ...
public:
    ...
    A operator * (double);
    A operator / (double);
    friend A operator * (double, A);
    friend A operator / (double, A);
    ...
};
于 2010-06-14T07:08:44.290 に答える
2

質問のコメントへの返信から、クラスでからdoubleへの暗黙の変換があるようです。A何かのようなもの:

class A
{
    // ...
public:
    A(double);

    // ...
};

この場合、フォームの演算子ごとにフリー関数を定義するだけです。

A operator*( const A&, const A& );

いずれかの側がAオブジェクトで、もう一方の側が暗黙的に に変換可能な場合に使用されAます。このため、対称二項演算子を関数から解放することが望ましい場合がよくあります。

*多くの場合、割り当てバージョンに関してバイナリを実装する方が簡単*=です。この場合、割り当てバージョンをメンバー関数にし*て、次のように定義します。

A operator*( const A& l, const A& r )
{
    A result(l);
    result += r;
    return result;
}

それ以外の場合operator*は、明らかにクラスインターフェイスの一部であるため、必要に応じて作成しても問題ありませんfriend

于 2010-06-14T21:21:04.147 に答える
1

つまり、いくつかの演算子 (最初のパラメーターとして持っていないものA) をクラスの外に配置する必要があるため、それらをすべてそこに配置して、人々がどこにあるかがわかるようにする必要があるということです。私はそうは思わない。可能であれば、クラス内に演算子を見つけることを期待しています。確かに「外側」のものを同じファイルに入れておくと役立ちます。また、外部のメンバーがプライベート メンバー変数にアクセスする必要がある場合、friend行を追加することは、それらのオペレーターをファイル内の他の場所で探すための大きなヒントになります。

friendオペレーターの実装が実際にパブリックのゲッターとセッターで実行できる場合でも、行を含めることはできますか? 私はそうするだろうと思います。私は、これらのオペレーターは実際にクラスの一部であると考えています。言語の構文では、それらが自由な関数である必要があるだけです。したがって、一般的にはfriend、ゲッターとセッターを使用せずに、メンバー関数であるかのように使用および記述します。friendステートメントが必要になった結果、ステートメントがすべてクラスの定義にリストされるようになるのは、うれしい副作用です。

于 2010-06-14T10:39:14.757 に答える