質問への回答

質問の歴史

C++11以前、任意の callable オブジェクトを格納するためには生の関数ポインタやカスタムのポリモーフィック基底クラスが必要でした。std::function の導入により、任意の callable を格納できる型消去ラッパーが提供されましたが、CopyConstructible 要件を義務付け、勾配が小さい functor に対してヒープ割り当てを避けるために Small Buffer Optimization (SBO) を使用しました。C++14 および C++17 で std::unique_ptr のようなムーブ専用型が普及する中、開発者は std::function が一意なリソースをキャプチャするラムダを格納できないという制限に直面しました。C++23 では、コピー要件を取り除き、ムーブ専用 callable をサポートしながら SBO のパフォーマンス利点を維持する std::move_only_function が導入されました。

問題

std::function は型消去を利用して実際の callable タイプを一様なインターフェースの背後に隠します。callable が内部バッファのサイズ（通常は16〜32バイト）を超えると、実装はヒープ上にストレージを割り当てます。ただし、根本的な制約は、std::function 自体がコピー可能であるため、型消去メカニズムは仮想ディスパッチを介して「クローン」操作を実装する必要があります。したがって、格納された callable は CopyConstructible でなければならず、std::unique_ptr やファイルハンドルをキャプチャするムーブ専用ラムダを除外します。これにより、開発者は std::shared_ptr を使用する（原子的なオーバーヘッドを追加）か、手動の仮想継承を使用する（間接的なオーバーヘッドを追加する）必要が生じます。

解決策

std::move_only_function はムーブ専用ラッパーであり、CopyConstructible 要件を排除します。これはムーブ専用の vtable パターンを介して型消去を実現し、ムーブのみ可能な callable を格納することを可能にします。std::function 同様に SBO を利用し、小さな functor を内部ストレージに直接配置し、ヒープ割り当てを行いません。これにより、ファクトリ関数から std::unique_ptr をキャプチャするラムダを返すパターンや、仮想ディスパッチのオーバーヘッドなしにコールバックをコンテナに格納することが可能になります。

#include <functional>
#include <memory>
#include <iostream>

// C++23 std::move_only_function の簡略化されたシミュレーション
template<typename Signature>
class MoveOnlyFunc;

template<typename Ret, typename... Args>
class MoveOnlyFunc<Ret(Args...)> {
    struct Concept {
        virtual Ret call(Args... args) = 0;
        virtual ~Concept() = default;
    };
    template<typename F>
    struct Model : Concept {
        F f;
        Model(F&& f) : f(std::move(f)) {}
        Ret call(Args... args) override { return f(args...); }
    };
    std::unique_ptr<Concept> impl;
public:
    template<typename F>
    MoveOnlyFunc(F&& f) : impl(std::make_unique<Model<F>>(std::forward<F>(f))) {}
    
    MoveOnlyFunc(MoveOnlyFunc&&) = default;
    MoveOnlyFunc& operator=(MoveOnlyFunc&&) = default;
    
    Ret operator()(Args... args) { return impl->call(args...); }
};

int main() {
    auto ptr = std::make_unique<int>(42);
    
    // std::function は失敗します：非コピー可能型のキャプチャ
    MoveOnlyFunc<void()> task = [p = std::move(ptr)] {
        std::cout << "Value: " << *p << "
";
    };
    
    task(); // 出力: Value: 42
}

実生活の状況

コンテキスト: 高頻度取引 (HFT) プラットフォームは、スレッドプールによるディスパッチシステムを通じて市場イベントを処理します。各タスクは応答を送信するためのネットワークソケットをカプセル化し、独占所有権と自動クリーンアップを保証するために std::unique_ptr<Socket> としてモデル化されます。

問題: 従来のディスパッチキューは型消去のために std::function<void()> を使用していました。生ポインタから std::unique_ptr にリソース管理を現代化する際に、コンパイルはラムダが非コピー可能であるとのエラーで失敗しました。これにより、std::function がムーブ専用 callable を格納できないため、マイグレーションがブロックされ、アーキテクチャの再考を余儀なくされました。

検討された解決策:

1. unique_ptr を shared_ptr に置き換える: ソケットの所有権を std::shared_ptr に変換することで、std::function のコピー可能性要件を満たします。

長所: 最小限のコード変更、標準 std::function との互換性。

短所: 原子的な参照カウントがマイクロ秒単位のレイテンシを引き起こし、HFT では受け入れられません。意味的には不正確: ソケットはタスク間で共有すべきではなく、所有権は独占的に移転する必要があります。

2. ポリモーフィックタスク基底クラス: 抽象の Task インターフェースを実装し、仮想 execute() を持ち、キューに std::unique_ptr<Task> を格納します。

長所: クリーンな所有権の意味、コピー可能性の要件無し。

短所: 仮想ディスパッチのオーバーヘッド（vtable の間接呼び出し）が各呼び出しにナノ秒単位で追加されます。タスクオブジェクトごとにヒープ割り当てが必要で、ホットパスでメモリを断片化します。

3. カスタムのムーブ専用型消去: std::aligned_storage と手動 vtable を使用してテンプレートベースの型消去を手動で実装します。

長所: 最適なパフォーマンス、ムーブ専用サポート。

短所: 注意深いアライメント処理とデストラクタ管理が必要な壊れやすい実装。テンプレートメタプログラミングコードのメンテナンス負担。

4. C++23 std::move_only_function の採用: コンパイラをアップグレードして C++23 をサポートし、std::function を std::move_only_function に置き換えます。

長所: 標準化された解決策で SBO (小さなクロージャーのためのヒープ無し)、仮想ディスパッチのオーバーヘッドゼロ、ネイティブなムーブ専用サポート。独占的所有権要件に完全に適合しています。

短所: C++23 ツールチェインの可用性が必要です。新しい型を受け入れるために従存する API の更新が必要です。

選ばれた解決策: 取引会社のコンパイラが C++23 をサポートしていることを確認した後、解決策 4 が選択されました。マイグレーションはディスパッチキューの std::function<void()> を std::move_only_function<void()> に置き換える作業を含みました。

結果: システムはムーブ専用ソケットリソースを正常に処理しました。ベンチマークでは shared_ptr アプローチと比較してタスクディスパッチのレイテンシが 15% 減少し、SBO により小さなクロージャーで ゼロヒープ割り当て を実現しました。コードベースはカスタムの型消去ハックを排除し、メンテナンス性が向上しました。

候補者が見落とすことが多い点

なぜ std::function は callable が CopyConstructible である必要があるのですか？たとえ std::function オブジェクト自体が決してコピーされなくても。

候補者はしばしば、コピー可能性はコピーが発生する時にだけチェックされると仮定します。しかし、std::function は設計上 CopyConstructible です。型消去メカニズムは、ラッパーをコピーするために「クローン」操作を仮想テーブルに提供する必要があります。格納された callable がコピーコンストラクタを持たない場合、この操作を実装できず、型がインスタンス化時に互換性がなくなります。これは、ラッパーのタイプシグネチャから派生したコンパイル時の制約です。標準は、型消去レイヤーが std::function の自身のコピーセマンティクスを満たすことを保証するために、callable に CopyConstructible モデルを要求します。

Small Buffer Optimization (SBO) が std::function の移動中の例外安全にどのように関連しているのですか？

多くの候補者は std::function のムーブが noexcept であると仮定しています。ラッパー自体の移動は簡単ですが、内部バッファに格納されている callable（アクティブな SBO）の移動コンストラクタが noexcept でない場合、std::function のムーブコンストラクタは例外を伝播する可能性があります。これは、再配置中に強い例外安全性を必要とする std::vector のようなコンテナが要求する noexcept の保証に違反します。標準は、格納された callable の移動が noexcept であり、実装がそれに応じて最適化されない限り、std::function に対して noexcept のムーブを保証しません。この微妙な点は、パフォーマンスのために noexcept の移動操作に依存するコンテナに std::function オブジェクトを格納する際に重要です。

なぜ std::function はラップされた callable からその operator() への参照修飾子 (&& または &) を伝播できないのか、また std::move_only_function はこれをどのように解決するのか？

std::function の呼び出し演算子は常に const 修飾され、ラッパーを lvalue として扱い、callable の参照修飾子に関係なく処理されます。これにより、リソースを消費する callable（rvalue 修飾された operator()）をラッパーを介して呼び出すことができなくなります。std::move_only_function は、シグネチャが参照修飾子を指定できるようにすることでこれを解決します（例: std::move_only_function<void() &&>）。それは、メタデータまたは別の vtable エントリを格納し、ラッパーの値の状態を基になる callable に正しく伝え、lvalue と rvalue の呼び出しを区別できるようにします。これは、関数型パイプラインにおけるムーブセマンティクスにとって重要です。