Qtのシグナルスロット機構で基底クラス型のオブジェクトを非同期的に渡す際、派生クラスの特性やスレッド親和性によって予期しない動作が発生しやすい。本稿では、値渡し・参照渡し・ポインタ渡しそれぞれの動作特性と、実装上の課題を具体的なコード例を通じて整理する。

検証用クラス定義

以下にテスト用の基底クラスと派生クラスを定義する。デストラクタと仮想関数を明示し、インスタンスのライフサイクルとポリモーフィックな動作を追跡できる構成とする。

class BaseEntity
{
public:
    BaseEntity()
    {
        std::cout << "[BaseEntity] Construct: " << reinterpret_cast(this) << std::endl;
    }
    virtual ~BaseEntity()
    {
        std::cout << "[BaseEntity] Destroy: " << reinterpret_cast(this) << std::endl;
    }

    virtual void process() const
    {
        std::cout << "[BaseEntity] Execute: " << reinterpret_cast(this) << std::endl;
    }
    virtual void configure(int value) { data_ = value; }

private:
    int data_ = 0;
};

class DerivedEntity : public BaseEntity
{
public:
    DerivedEntity() { std::cout << "[DerivedEntity] Construct: " << reinterpret_cast(this) << std::endl; }
    ~DerivedEntity() override { std::cout << "[DerivedEntity] Destroy: " << reinterpret_cast(this) << std::endl; }

    void process() const override
    {
        std::cout << "[DerivedEntity] Execute: data=" << data_ << std::endl;
    }
    void configure(int value) override { data_ = value; }

private:
    int data_ = 0;
};

スレッド親和性と宣言形式による挙動比較

生産者（シグナル発行者）と消費者（スロット受け手）が同じスレッドに属する場合、および異なるスレッドに属する場合で、シグナル宣言のパラメータ型がコピー挙動に与える影響は以下のようになる。

同一スレッド環境で値渡しシグナルを発行した際のライフサイクルログは次の通り。派生クラスが基底クラス型としてコピーされる際、仮想関数テーブルは維持されるが、メモリアドレスは変化するため個別の破棄処理が実行される。

[BaseEntity] Construct: 0x7f8a1c0040a0
[DerivedEntity] Construct: 0x7f8a1c0040a0
[BaseEntity] Execute: 0x7f8a1c004080
[BaseEntity] Destroy: 0x7f8a1c004080
[BaseEntity] Execute: 0x7f8a1c004080
[BaseEntity] Destroy: 0x7f8a1c004080
[BaseEntity] Destroy: 0x7f8a1c0040b0
[BaseEntity] Destroy: 0x7f8a1c0040a0

異なるスレッド間では、イベントループによるキューイングが発生するため、参照渡しは安全ではなくなる。また、const&渡しも内部でシリアライズ・デシリアライズ時にコピーが発生する。

実装パターンと技術的課題

パターン1：宣言形式による分岐とスライス問題

単一スレッド設計の場合は参照渡しで十分だが、マルチスレッド環境では値渡しまたはconst参照渡しが必要となる。この際、派生クラスを基底クラス参照として受け取ると、仮想関数ディスパッチは機能するものの、メンバ変数の更新や型ダウンキャスト時に注意が必要である。

public slots:
    void handle(const BaseEntity& node)
    {
        const DerivedEntity* derived = dynamic_cast<const DerivedEntity*>(&node);
        if (derived) {
            derived->process();
        }
    }

強制的な参照キャスト（C-style cast）は未定義動作の危険を孕むため、dynamic_castの利用が推奨される。

パターン2：変換コンストラクタの導入

基底クラスから派生クラスへの変換を明示的に定義する手法。生産者側でシグナルを発行し、消費者側で派生クラス型の変数として受け取る際にコンパイラが変換コンストラクタを呼び出す。

class DerivedEntity : public BaseEntity
{
public:
    DerivedEntity() = default;
    DerivedEntity(const BaseEntity& base) : BaseEntity()
    {
        std::cout << "[DerivedEntity] Base-to-Derived conversion" << std::endl;
    }
    // 他メンバ省略
};

しかし、基底クラス側にしかないデータや、仮想継承構造の場合は情報が欠落する（オブジェクトスライス）。継承ツリーの深さが深いほど状態の同期が困難になるため、設計上は推奨されない。

パターン3：生ポインタによる所有権の移譲

ポインタをシグナルに含める手法。コピーオーバーヘッドを回避できるが、所有権管理が手動で必要になる。

signals:
    void dataReady(BaseEntity* node);

void producer()
{
    auto* node = new DerivedEntity();
    node->configure(42);
    emit dataReady(node);
}

public slots:
    void consumer(BaseEntity* node)
    {
        if (auto* derived = dynamic_cast<DerivedEntity*>(node)) {
            derived->process();
        }
        // delete node; // 複数消費者が接続されている場合、誰が削除するべきか不明確
    }

複数のスロットが同一シグナルに接続されている場合、所有権の归属が曖昧になる。あるスロットでdeleteを実行すると、他のスロットでダングリングポインタを参照してクラッシュする。意図的なメモリリークを防ぐため、所有権管理はシグナル機構内に埋め込むべきではない。

パターン4：カスタムディスパッチャの採用

Qtの信号スロット機構を迂回し、独自イベントハンドラを実装するアプローチ。

class EventRouter {
    std::vector<std::function<void(BaseEntity*)>> handlers_;
public:
    void registerHandler(std::function<void(BaseEntity*)> h) { handlers_.push_back(h); }
    void dispatch(BaseEntity* node) {
        for (auto& h : handlers_) h(node);
    }
};

この方式は呼び出し順序と所有権を一元管理できる反面、同期処理になりやすく、非同期メッセージパッシングの利点を失う可能性がある。スレッドセーフなキューとワーカープールを追加実装する必要が生じる。

アーキテクチャ的な代替案

継承構造をシグナルスロット間でまたがせることは、コピーコスト、スレッド安全性、所有権管理の観点から複雑さを増大させる。実務では、ポリモーフィズムを排除し単一の具象クラスで要件を網羅する、またはstd::shared_ptrを用いた共有所有権モデルを採用するのが現実的である。std::shared_ptr<BaseEntity>であればQtのQSharedPointerとの相互変換も容易であり、シグナル経由の自動メモリ管理とスレッド間の安全な受け渡しが両立する。コピーオーバーヘッドは現代のハードウェア性能とコンパイラの最適化により許容範囲内であり、設計の堅牢性を優先することが長期維持の鍵となる。