C++ Delegateではなく単にクラスのインスタンスを引数にではダメなのでしょうか

Question

C++のデザインパターンでDELEGATEというものがあります。
私がテストしてみたデリゲートはこちらです。
このデリゲートは柔軟性があり型も一貫していて美しいプログラムにもできる点が個人的にとても好きです。

しかし、このデリゲートは便利ではありますが以下の点で疑問を感じます。

単にクラスのインスタンスをハンドラとして引数にとり、必要とする関数へ渡すのではダメなのか

という点です。

このことは参照先のURL内ですでに非現実的であると提言されてはいますが、イマイチ理解できません。

以下を見てください。

---

ディレクトリ構造がツリー構造であれば上層部であるClsMに下層クラスのインスタンスを持たせておき、
それを必要とする(ClsA内でClsBの関数を実行したり)クラスへ引数で渡してあげれば簡単です。

---

しかしこれが非現実的である理由がイマイチわからないのです。
仮に相当の理由があったとしても、デリゲートの扱い方(というよりは置き方)に悩みます。

デリゲートはデリゲートとして別ファイルに別クラスとして書いておいて、
画像例で言うところのClsMにデリゲートインスタンスを生成して引数で必要とする下層クラスへ渡すべきなのか？
しかしそれでは画像の方法のがシンプルですしやってることは変わりません。

単に必要なクラスのインスタンスを引数で渡してやるのではどのような問題があるのか？
そしてデリゲートの扱い方をどうすべきなのか？

以上の点について教えてください。

Answer 1

リンク先をざっと見た限り，単に，
「必要な時に実行すべき処理を指定する手段として，俺はあらかじめファンクタを渡しておくぜ！」
というだけの話にしか見えません．
（そして，複数の処理を実行したくなるからCompositeパターンで，的な）

---

単に必要なクラスのインスタンスを引数で渡してやるのではどのような問題があるのか？

「イベントが起きた場合に必要な何かせねばならんだろうな」という処理部分と，「必要なクラス」がべたべたの依存関係になりますよね．
上記の必要な何かという言葉の部分が，「何か」ではなくて完全に具体的な実装がそこに埋まる形になる．

「この時にはこの特定の処理しかしないのだ」と決まりきっているものを実装している状況であれば，それでＯＫでしょうけど，リンク先でやっているのはそういう話ではなくて，イベントハンドラの登録的な話でしょうから．

Comments

[Tololololo]

ありがとうございます。
ようやくリンク先の言っていることがスッキリしてきました。
確かにイベントハンドラとしての登録だけで処理を他方で実行できるのであれば
ディレクトリ関係であったりに依存しなくても済みますね。

Answer 2

こんにちは。

単に必要なクラスのインスタンスを引数で渡してやるのではどのような問題があるのか？

どのメンバ関数を呼び出すのか指定できない点が問題なのではないかと思います。
また異なるクラスのインスタンスを保持するためには、それなりの工夫が必要になります。その工夫の一つが基底クラスへのポインタを使う方法ですね。それをちょっと拡張してメンバ関数も指定できるようにする手法のようです。

そしてデリゲートの扱い方をどうすべきなのか？

今となっては面倒なだけなので、リンク先の目的であれば使う必要まではないと思います。

C++11以降ならstd::functionとラムダ式を使えば簡単です。
std::functionは関数ポインタだけでなく関数オブジェクトも保持できます。（残念ながら事実上メンバ関数は保持できません。メンバ関数ポインタは保持できますが、その場合は当該クラスのインスタンスを保持できないのです。）
しかしラムダ式は関数オブジェクトですから、std::functionで保持できますので、ラムダ式から目的のメンバ関数を呼び出せば、リンク先の目的を果たせると思います。

以下のようなイメージです。

#include <iostream>
#include <functional>
#include <list>

class DoorBell
{
    typedef std::function<void(int)> FuncType;
    std::list<FuncType> m_eventList;
public:
    void setOnOpenHandler(FuncType func)
    {
        m_eventList.push_back(func);
    }
    void OnDoorOpen()
    {
        for (auto func : m_eventList)
        {
            func( 0 );
        }
    }
};

class Dog
{
public:
   void AroundGarden( int value )
   {
       std::cout << "Dog::AroundGarden(" << value << ")\n";
   }
};

class Cat
{
public:
   void SleepInKotatsu( int value )
   {
       std::cout << "Cat::SleepInKotatsu(" << value << ")\n";
   }
};

int main()
{
    Dog dog1;
    Cat cat1;

    DoorBell doorBell;
    doorBell.setOnOpenHandler( [&](int value){ dog1.AroundGarden(value); });
    doorBell.setOnOpenHandler( [&](int value){ cat1.SleepInKotatsu(value); });

    doorBell.OnDoorOpen();
}

wandbox

Comments

[Tololololo]

サンプルコードの提示ありがとうございます。
Chirorianさんのコードは私の参照先のものよりもとてもスッキリしています。
こちらの方が圧倒的に短いコードで理解しやすいです。
動作速度については少し工夫しなければならないかもしれません。
https://dpaste.de/Ne42
扱い方についてはもう一考してみます。

[Chironian]

あれ？　有意に遅いですか？　どのような方法で調べました？
リンク先を見ても確認方法を読み取れなかったので。

[Tololololo]

リンク先のコードでは初期化をのぞいて（デリゲーターをセットする段階。つまりはlist配列にハンドラ登録する段階。）デリゲーターを介しての関数アクセス段階のみでの動作速度を調べています。
付随条件として関数へのアクセスを複数回行った場合を想定しています。(100000回)

っと言う形での確認方法として載せています。

[Chironian]

なるほど。ソースを載せていたのですね。見落としていました。
しかし、たぶん何か間違っていると思います。
std::function＋ラムダ式が数倍も遅くなるということは考えにくいです。（多少の差はでるでしょうが）
また、ポインタ方式とデリゲート方式が同等というのも考えにくいです。
ポインタ方式は最適化により事実上実行時間は0になる筈です。
かと言って最適化OFFの性能は無意味です。速度を問題にする時の使い方ではありませんので。

真面目なベンチマークは結構苦労します。volatile変数が結構便利です。最適化抑止しますから。

[Tololololo]

アドバイスありがとうございます。
volatile変数なるものは初耳でした。
正常なベンチマークが出るまで考え直してみます。