protected の挙動が分からない

Question

地雷質問なのは理解した上で質問させていただきます。
言語仕様の話になると思うのですが、下記のコードの func2 がエラーになるのはおかしくないですか？
B は A を継承しているのですから別オブジェクトの protected を触れても問題ないと思うのですが。
どういう意図でこのような設計になっているのでしょうか？

class A {
protected:
    void call() { }
};

class B : public A {
public:
    void func1() { call(); } // <- ok
    void func2(A a) { a.call(); } // <- ng
    void func3(B b) { b.call(); } // <- ok
private:
    void call() { }
};

c# - Is there a way to reach a protected member of another object from a derived type? - Stack Overflow
C# ですが stack overflow で同様の質問がされており、出来ない旨と出来なくなっている理由（変更されたくない protected の内容を持ったクラスを継承してそこから呼び出すことで変更できてしまう）が書かれていますが、本当にそのためだけにアクセス不可にしているのでしょうか？
また、これを回避する方法があれば教えていただきたいです。お願いいたします。

Comments

[fana]

> どういう意図でこのような設計になっているのでしょうか？

これに関しては，実際にその設計を行った誰かに対して問うか，あるいはその誰かがそのような話を記した文面か何かを探す以外には，解は得られないと思います．
（そういう情報源無しに「こうだからじゃないの？」って言っても意味ないでしょうし）

> これを回避する方法があれば教えていただきたいです。

こっちに関しては，「代替策は無いか？」という話なのでしょうから，どうしてそんな不自然なアクセスをしたくなっちゃったのか？　本当は何をしたいのか？　etc... といったような具体的な話を述べた方が良いのではないでしょうか．

[YUKI_DAYO]

> どうしてそんな不自然なアクセスをしたくなっちゃったのか？
に関してですが、確かに設計が変な感じになっているのは否めないです。
既に素晴らしい回答を沢山いただいたので、実際の設計に関しての質問は新たに立ち上げようと思います。
追記：質問を立ち上げる前に回答などを参考に設計を考え直してみます。

Answer 1

protected と指定されたメンバは派生クラスのオブジェクト・ポインタ・参照を経由してのみ public と同等にアクセスできるというルールです。 (暗黙に this を経由する場合も含みます。)

このルールが制定された理由は「注解 C++リファレンスマニュアル」の 11.5 に書かれているのでそのまま引用します。 この文で「限定公開メンバ」と呼ばれているものは protected 指定されたメンバのことです。

派生クラスが、その基底クラスのどらかの型を持つオブジェクトの限定公開メンバへアクセスできると考えよう。 すなわち、限定公開メンバへのアクセスは、派生クラスのオブジェクト、それへのポインタ、あるいはそれへのリファレンスを経由する必要があるという制限を緩めてみよう。 この結果、クラスは、明示的なキャストを使わずに、無関係のクラスの規定クラス部分へ (それがあたかも自分自身のものであるかのゆに) アクセスできることになっただろう。 これは言語だけが許せるアクセスだったはずである。

この制限が、思いがけない事故に対抗する保護を与えていることを示す例はいくつか存在する。 たとえば、私が銀行を経営していて、多くの違う口座を持っているとしよう。 私は、すべての種類の口座に対する共通の情報を持つ規定クラス Account を持ちたい。 このクラスは、口座の残高の情報も含んでいる。 ゆえに、 Account のフレンドは、すべての Account から構成されるリストを調べることや、私の銀行の財政状態を渡しにいつでも知らせることができる。 しかしながら、各種類の Account は、それぞれ自分自身で、残高の更新のための規則 (たとえば、支払われる利息率はいくらか、利子はいつ複利計算されるのか、受理可能な預金の種類は何か、早期回収に対する特別のペナルティ等) を持っている。 したがって、異種類の口座である派生クラスは全て、残高を更新するためのコードを持つ。 しかしながら、 checking_accounts のメンバ関数は、 AutoLoan_account 中の預金残高にアクセスできないほうがよい。 この制限は、この種のアクセスを防げる。

この制限を取り入れた例は、デバイス・ドライバに関係するものと論理的に等価である。 ある種のデバイスに対するドライバは、ほかの種類のデバイスと関係している情報を偶然に更新し、その結果、システムは不思議な具合にクラッシュしてしまった。 偶然更新された情報は、共通の基底クラスへ格納されていて、適切な派生型ではなく、その基底クラスへのポインタを経由してアクセスされていた。 もちろん更新を行うための仮想関数を使用していたら、この問題は避けられていただろう。

この本は (C++ の設計が委員会主導になる前の) 設計者自身によるものなので設計意図が表れている文章だと思います。

要するに派生クラスから全面的にアクセスできるようにするのは寛容すぎるということです。 派生クラスだけに許したいアクセスを (protected 以外の方法で) コントロールしようとすると煩雑すぎて管理不能になるという Mark Linton の主張が元で protected は導入されており、煩雑なインターフェイスを設計するためにバグが入り込むくらいなら緩いアクセス制限があったほうがマシだという判断がありました。 しかし、制限のための指定なのに緩すぎてもろくなことにならないのも自明なので典型的に必要な制限としてこのへんが落としどころだったということなのでしょう。

---

想定しているデザインが悪いのでどうにかする言語機能を探しても糊塗にしかならない (美しく解決するなら根本的な見直しが必要) ということはお断りしておきますが、 protected のルールを活用するという前提であればとにかく「派生クラスを経由する」ということを満たしさえすればよく、以下の例で示すような方法を取れなくはないですね。

class A {
protected:
  void call() { }
};

class B : public A {
  struct C : private A {
    C(const A& x) : A(x) {}
    using A::call;
  };
public:
  void func(C a) { a.call(); }
};

int main(void) {
  A foo;
  B bar;
  bar.func(foo);
}

Comments

[YUKI_DAYO]

回答ありがとうございます。
なるほどこのような経緯があったのですね。
とても面白かったです！勉強になりました！！！
それにしても言語設計って本当に大変そうですね...

Answer 2

これを回避する方法があれば

何がしたいのかわからないけど，
class A の実装を弄ってもよいのであれば，class A にそれ用のメソッドを仕込めばよいのでは．

class A {
protected:
	void func2_( A a ){	a.call();	}  //←コレを仕込む
protected:
	void call() {  std::cout << "A::call()\n";	}
};

class B : public A {
public:
	void func1() { call(); } // <- ok
	void func2(A a){	func2_(a);	}  //←仕込まれたものを使う
	void func3(B b) { b.call(); } // <- ok
private:
	void call() {	std::cout << "B::call()\n"; }
};

Comments

[YUKI_DAYO]

回答ありがとうございます。
@Serbonis さんの回答同様、あまり美しくないですよね...

[fana]

言語仕様でできないことを何とか捻じ曲げようとしている事自体が，おそらくは「美しく」はないものであろうと思うので，その実現策を「美しく」用意しろ，ってのは無理難題ではなかろうか？

（「美しくない」を批判だとか受け取っているわけじゃないよ．ただ純粋に「美しい抜け道」って無理じゃね？　っていう）

Answer 3

callを呼び出すラッパーを静的メンバ関数で用意する方法はどうでしよう。不特定多数の派生クラスを意識しなくてよくなります。

class A {
protected:
    void call() { }
    static void call(A a) { a.call(a);}
};

class B : public A {
public:
    void func2(A a) { a.call(a); }
};

Comments

[YUKI_DAYO]

回答ありがとうございます。
分かりやすくていいとは思うのですが、あまり美しくはない（個人の感想です）ですよね汗

Answer 4

これを回避する方法があれば教えていただきたいです。

「特定のクラスにのみprivate/protectedへのアクセスを許したい」
なら friend が使えます。

#include <iostream>

class A {
  friend class B;
protected:
    void call() { std::cout << "A::call()\n"; }
};

class B {
public:
    void funcB() { call(); } // <- ok
    void funcA(A a) { a.call(); }
private:
    void call() {  std::cout << "B::call()\n"; }
};

int main() {
  A a; B b;
  b.funcA(a);
  b.funcB();
}

Comments

[YUKI_DAYO]

回答ありがとうございます。
そういえば friend とかありましたね。
完全に忘れていました。
使ったことのない機能なので調べてきましたが、依存関係がかなり複雑になりそうですね...