別の可能性: 集計を使用します。次に、boost.variant をライブラリのユーザーに直接公開しないので、将来の改善の自由度が高まり、一部のデバッグ タスクが大幅に簡素化される可能性があります。
一般的なアドバイス: 集約は継承よりも緊密に結合されていないため、バリアントのみを取得する既存の関数にオブジェクト インスタンスを明示的に渡したい場合を除いて、デフォルトの方が優れています。さらに、基本クラスは継承を念頭に置いて設計する必要があります。
問題の集計の例: 私が理解している限り、無料の関数は既に存在し、バリアントを使用します。バリアントの唯一のデータ メンバーを持つクラスを定義し、メンバー バリアントを使用して既存のフリー関数を呼び出すだけのパブリック メンバー関数を提供するだけです。
class variant_wrapper {
boost::variant<A,B> m_variant;
public:
variant_wrapper(...) : m_variant(...) {} // whatever c_tor you need.
void f() { f(m_variant); }
};
このアプローチを使用すると、実装にboost.variantを使用しているという事実を抽象化し(ライブラリのユーザーのtypedefを介してすでに行っています)、後でそれを変更する自由を与えます(最適化または機能拡張などのために)。値を不変にしたり、アルゴリズムへのアクセスをデバッグするためのより単純なアプローチをとったりすることができます。
集計の欠点は、ラッパーを static_visitor に渡すことができないことですが、ユーザーはバリアントがあることを知らず、単にメンバー変数を渡すことを知っているため、ここでは大きな問題は見られません。
最後の暴言: C++ は Java ではありません。ライブラリのユーザーを修正する必要があります...
必要なのは C# 拡張メソッドです。そのようなものは C++ には存在しません。ただし、boost.variant の再実装/実装コピーは行わず (メンテナンスの負担)、継承もしません。可能な場合は集約を使用してください。