テンプレートクラス メンバにアクセスできない

Question

リンク内容
前回の問題に類似します。

template <class Param>
class func{
protected:
     Param _max;
     Param* _set;
     Param _num
....
}

template <class Param>
class func2 : public func<Param> {　// 継承
public:
   void test();
...
}

template<class Param>
void func2<Param>::test(class func<Param> *s1, class func<Param> *s2){
    int n = (s1->_max < s2->_num) ? s1->_max : s2->_num;

    for(auto i = 0; i < n; i++)
        s1->_set[i] = s2->_set[i];
    s1->_num = n;
}

このコードはエラーです。

クラスを関数のパラメータにしています。
s1->_max, s2->_num などの部分ですね。
protected継承を行っているのですが、テンプレートなので、thisを付けなくていけないのですが・・・
リンク内容

今回のような場合、どこにthisを付ければ良いのでしょうか？？
this->s1->_max // error!
s1->this->_max // error!

[ error: ‘int func<int>::_max’ is protected within this context ]
[ declared protected here Param _max; ]

privateやprotectedではなく、publicにすれば解決するんですが・・・
アクセス制限の方でちょっとpublicにするのは・・・って感じです。

friendでもできるのですが、継承してprotectedにしても可能なのではないかと思いまして・・・
しかし、テンプレートにするとできません。
protectedの問題を解決できません。
このようなメンバにはどのようにしてアクセスすれば良いのでしょうか？？

教えてください。

[追記]
thisを付けると継承したクラス内のメンバ変数にアクセスすることになり、パラメータの方ではない・・・のですね。

すると・・・継承によって他のオブジェクトのアクセス権を獲得するのは無理・・・ということですかね。
friendに頼らないと不可能・・・ぽいかなぁ

Answer 1

とりあえず、仮引数内にclassは必要ありません。
あってもいいですが、タイプ数の増加はコンパイルエラーの増加につながりますので、省いてしまうことをお勧めします。

さて、継承を利用して変数へのアクセスをしたいとのことですが、
求めている答えとは遠いかと思いますが、私見を述べさせていただきます。

継承を利用して変数へのアクセスするのはオブジェクト指向のカプセル化の概念に反するものだと思います。
(仕様上どうしても突破したい場合のためのfriendだと考えています。)

テンプレートクラスfuncに対する変更処理はfuncに持たせるべきであり、func2がfuncに対する特定の操作を纏めたクラスである場合、func2はfuncが持つ機能を呼ぶにとどめるべきだと考えます。
例えば、こうすればわざわざ親クラスの変数にアクセスせずとも事足りるはずです。

template <class Param>
class func{
public:
	void Union(const func<Param> *);
	func<Param>* difference(const func<Param> *);

	void test(func<Param> *s2){
		int n = (_max < s2->_num) ? _max : s2->_num;

		for(auto i = 0; i < n; i++)
			_set[i] = s2->_set[i];
		_num = n;
	}
protected:
	Param _max;
	Param* _set;
	Param _num;
};

template <class Param>
class func2{
public:
	void test(func<Param> *s1, func<Param> *s2){
		s1->test(s2);
	}
	func<Param>* difference(func<Param>* s1, const func<Param>* s2, const func<Param>* s3){
		auto ret = s1->difference(s2);
		ret->Union(s1->difference(s3));
		return ret;
	}
};

Comments

[strike1217]

ふむふむ・・・
なるほど！

funcとfunc2の持つ機能を分離しておいたほうが分かりやすいと思ったのですが・・・
結構難しいですね。

「func2はfuncが持つ機能を呼ぶにとどめるべきだと考えます。」
参考にさせてもらいます。

[strike1217]

friendによる実装はできるだけ避けるべきなんでしょうか？？

Answer 2

こんにちは。

とりあえず、継承したクラス・テンプレートのメンバ変数にアクセスするには、下記記述でできます。

template<class Param>
void func2<Param>::test(class func<Param> *s1, class func<Param> *s2)
{
    this->_max = 1;
    func2<Param>::_num = 1;
}

しかし、たぶん聞きたいことはこのようなことではないような印象を受けます。
どうも本質的な部分を勘違いされているっぽいです。

継承は、ある意味名前無しのメンバ変数を定義しているのと近いです。

#include <iostream>

struct Base
{
    int data0;
};

struct Derived : public Base
{
    int data1;
};

struct Included
{
    Base    base;
    int     data1;
};

int main()
{
    std::cout << sizeof(Derived) << "\n";
    std::cout << sizeof(Included) << "\n";
}

上記のDerivedとIncludedの「メモリ・レイアウト」は同じです。data0, data1の順で並んでいます。
IncludedはBaseクラス型のメンバ変数に名前baseがついています。名前がついているので複数のBaseクラス型の変数を定義できます。
DerivedはBaseクラスを含んでいますが、継承であるため名前がありません。名前がないので継承できるものは１つだけです。

というような関係を定義するのが継承です。

friendでもできるのですが、継承してprotectedにしても可能なのではないかと思いまして・・・

friendでできることを継承してやろうとする発想が誤りなのです。
friendは単にアクセス制限を緩めるための仕組みです。継承のようにメモリ・レイアウトを伴う「実体」を定義するものとは概念が全く異なります。

---

ところで基底クラスがクラス・テンプレートだった場合、いつものようには基底クラスのメンバ変数にアクセスできません。リンク先に書かれているように「this->をつけるかBASE<T>::を付ける必要があるっぽい」です。

クラス・テンプレートは特殊化や部分特殊化できるため、どの定義が選択されるのか実体化されるまで決定できません。そのため、指定したメンバ変数があるかないか分からないのでコンパイルできないということのようです。
this->や基底クラス::は、実体化するまでは「あるかないか判らなくてもよい」ようにする効果があるようです。
詳しくはテンプレートの派生クラスから親クラスのメンバへのアクセスが判りやすいかも。

Comments

[strike1217]

ふむーー。
継承によってオブジェクトのアクセス権を獲得するのは無理ということですよね？

friendを継承するというやり方もあるようです。
http://d.hatena.ne.jp/aki-yam/20100420/1271775548

やはりfriendに頼らないとダメそうですね。

[Chironian]

> friendを継承するというやり方もあるようです。

単にクラスをfiriend指定して、そのクラスのメンバ関数を呼び出してアクセスしているだけです。
至極普通の使い方と思います。

なお、そのクラスを派生したクラスから、他のクラスのprivateメンバへアクセスしていると考えるのは誤りと考えたほうが好ましいと思います。
そのように表現すると、public関数でアクセスしているprivateメンバは、他のクラスからアクセスできるということになります。それはオブジェクト指向プログラミングの隠蔽を破壊する考え方です。

> 継承によってオブジェクトのアクセス権を獲得するのは無理ということですよね？

継承しても基底クラスのprivateメンバにアクセスできるわけではないです。
あっ、基底クラスのprotectedメンバにはアクセスできますね。
Baseクラスを派生したDerivedクラスは、「自分」の中にあるBaseクラスのprotectedメンバにアクセスできます。しかし、他のDerivedクラスのオブジェクトの中にあるBaseクラスのprotectedメンバにアクセスできません。と思ったら出来ました。これは知らなかった。
https://wandbox.org/permlink/pdhQ6AzkxHip4CE5

更にテンプレートにすると https://wandbox.org/permlink/5Tt0oFQUyLObGxUE
他のオブジェクトからアクセスする時は、thisや基底クラス指定はいらないようですね。
先程のリンク先にあるように、thisの場合と同様オブジェクト経由でのアクセスですから、名前解決がテンプレートの実体化より後になるからでしょう。

[strike1217]

クラスの継承か、friendかどちらにしてもアクセス権の獲得はカプセル化を破壊するため良くない・・・

そうすると、chironianさんなら今回のtestメンバ関数のようにクラスを渡して処理するような関数はどのようにして実装しますか？？

[Chironian]

privateメンバやprotectedメンバのアクセス権を獲得するという方法は、全てカプセル化を破壊する方法ですね。カプセル化するべき時にまで適用するとアウトです。でも、カプセル化する必要性が低い時に適用してもセーフと私は考えます。リンク先は、一般解として提示してあったのでアウトと感じました。

> chironianさんなら今回のtestメンバ関数のようにクラスを渡して処理するような関数はどのようにして実装しますか？？

例えば、ライブラリの内部からはアクセスできるが、ライブラリの外部からはアクセスできないメンバを定義したいケースがありますね。恐らく希望されている使い方は、このようなレベル分けして、一部のクラスからのみアクセスでき、他のクラスからはアクセスできないようにしたいのだと思います。そのための機能がfriendですね。ライブラリ内部からのアクセス許可であれば、許可したいクラスを全て把握できますから、概ね有用です。

friendで対応できない場合（ライブラリの外部の一部からprivateメンバにアクセスしたいケース）は、カプセル化を断念するかも知れません。設計を見直してそもそも外部からのprivateメンバアクセスを不要とするのが理想ですが、なかなかそうもできない場合がありますし。

[strike1217]

今回の場合は、friendで実装するのが良いということですね。
わかりました。
継承によってアクセス権を獲得するのはやめてfriendにします。