c++protectedの動作がいまいちわからないです

Question

以下コードでコンパイラが嫌がる理由嫌がるようにした理由が分からないです

以下のようなコードを書いてコンパイルしたのですが、
protected within this context
というエラーが発生してコンパイルできません

Baseクラスにfriendをつければコンパイルは可能なのですが、
Baseクラスは抽象クラスですし、
実際に使用される場合ExtendクラスのBaseポインタには派生クラスであるAクラスのポインタが格納されるのでfriendつけるのは派生先だけで十分であるように思います。
基本クラスがまだ普通のクラスならばコンパイラが怒るのも納得できるのですが、
抽象クラスだったら継承クラスすべてでfriend宣言されていれば、別に怒る必要はないと思うのですが、コンパイラは何がそんなにいやなんでしょうか？(多分昔のc++コンパイラなら許してるのでは?)

#include <iostream>
 
using namespace std;

class Base {
     //friend class Extend;　//コメントアウト切ったらエラーは消える
     protected : virtual int print() const = 0;
     protected : virtual ~Base() {}
 };
 class A : public Base {
     friend class Extend;
     public : A(int k) : n(k) {}
     private :
     int n;
     int print() const { return n; }
 };
 class Extend {
     public : Extend(int);
     public : ~Extend() {  delete p; };　//deleteしたいがprotectecなので怒る
     private :
         Base* p;
 };
 Extend::Extend(int n) {
     p = new A(n);
 }
 int main(void)
 {
 }

Answer 1

Baseポインタには派生クラスであるAクラスのポインタが格納されるので

これを理解しているのはプログラマーだけです。

ExtendからみればpはBaseとしてしか保持しないので、たとえ自身のメソッド内でpにAのインスタンスを代入したとしてもBaseとしてしか扱いません。
pをAとして扱えるのはプログラマーによって明示的にキャストされた場合のみです。

delete p のタイミングではそれがvirtualであろうと、Extendから見れば呼び出すものはBase::~Baseなので、それはprotectedだからアクセスできないのです。

そうしないと、mmmisakiさんが思っているような例を許可した時、追加でB/C/DがそれぞれBaseから派生していて、A/BはBaseのfriendだけどC/Dはfriendでない場合、delete pの文脈は呼び出していいのかダメなのか判断できなくなります。
そのため、昔のコンパイラができたか、と言われたらそんなことは無いはずです。

Answer 2

抽象クラスだったら継承クラスすべてでfriend宣言されていれば、別に怒る必要はないと思うのですが、コンパイラは何がそんなにいやなんでしょうか？(多分昔のc++コンパイラなら許してるのでは?)

そのとおり、"すべてで"friendが指定されていれば問題ないでしょう
しかし、その全てで宣言されているかが判明するのはコンパイル時ではなくリンク時です
コンパイル時は1ファイル(とincludeファイル)しかみないので、
その他のファイルに何が書いてあるかはチェックしません

ですから、リンカーに「すべてかどうか」を申し送りする必要があるんですが、
リンカーの仕事はリンクすることで、構文チェックは仕事ではありません

コンパイルの段階でプロジェクトすべてのファイルを横断的に眺めてコンパイルできないの？と思います
実際、C#なんかはそんな感じですし、実現すればヘッダファイルも要らなくなるんですが、
そのへんは古い設計思想を引きずっているC++の弱点でもあります

Comments

[mmmisaki]

個人的にはこちらの回答が納得できたのでベストアンサーにさせていただきました！
ご回答ありがとうございました。

Answer 3

こんにちは。

protectedは派生先のクラスなら常にアクセスできるというアクセス指定子ではありません。
規格書の該当ページ（n3337ならp239の11.4 Protected member access）にある例から推測すると以下のようです。

Extend::Extend()
{
    print();    // OK
    p->print(); // ill-formed
}

派生先のクラス全部ではなく、派生先の同じインスタンスのみに限定されているようです。
protectedの主旨的に妥当な定義と感じます。

派生クラスではなく、同じクラスの場合は別インスタンスのprivateやprotectedメンバにもアクセスできます。でないとコピー・コンストラクタさえ書けなくなりますしね。

実際に使用される場合ExtendクラスのBaseポインタには派生クラスであるAクラスのポインタが格納されるのでfriendつけるのは派生先だけで十分であるように思います。

基本クラスがまだ普通のクラスならばコンパイラが怒るのも納得できるのですが、
抽象クラスだったら継承クラスすべてでfriend宣言されていれば、別に怒る必要はないと思う

確かにその通りですが、それをコンパイラの仕様とするには複雑すぎるように感じます。
そして、その仕様を採用することで便利になる場面が多数あるようにも思えません。
同様に感じる人が仕様を策定する人たちの中で多数派だったのかも知れません。