まえがき
この記事は、 God Adapterという英語の記事からのオリジナル翻訳です。 C ++ロシアカンファレンスのビデオスピーチも見ることができます。
1要約
この記事では、必要な機能を追加して任意のオブジェクトを別のオブジェクトにラップできる特別なアダプターを紹介します。 適合オブジェクトは同じインターフェースを持っているため、使用に関しては完全に透過的です。 シンプルだが強力で興味深い例を使用して、共通の概念を順次紹介します。
2はじめに
警告 この記事で言及されているほとんどすべてのメソッドには、ダーティハックとC ++言語の異常な使用が含まれています。 そのため、このような倒錯に寛容でない場合は、この記事を読まないでください。
ユニバーサルアダプターという用語は、オブジェクトに必要な動作を普遍的に追加する機能に由来します。
3問題の声明
むかしむかし、共有データへのアクセスを簡素化するスマートミューテックスの概念を導入しました。 アイデアは単純でした。ミューテックスをデータに関連付け、データへのアクセスごとに自動的にlockとunlockを呼び出します。 コードは次のとおりです。
struct Data { int get() const { return val_; } void set(int v) { val_ = v; } private: int val_ = 0; };
しかし、このアプローチにはいくつかの問題があります。
3.1ブロッキング時間
ロックは、現在の式の実行時間全体にわたって保持されます。 次の行を検討してください。
std::cout << d->get() << std::endl;
Unlockは、 std::coutへの出力を含む、式全体の完了後に呼び出されます。 これは不必要な時間の無駄であり、ロックを取得する際の待ち時間が大幅に増加します。
3.2相互ブロックの可能性
最初の問題の結果として、暗黙のロック機構と現在の式の実行中の長いロック時間による相互ロックの可能性があります。 次のコードスニペットを検討してください。
int sum(const SmartMutex<Data>& x, const SmartMutex<Data>& y) { return x->get() + y->get(); }
関数がデッドロックを含む可能性があることはまったく明らかではありません。 これは、インスタンスxとy異なるペアに対して->get()メソッドを任意の順序で呼び出すことができるためです。
したがって、ロックにかかる時間の増加を避け、上記のデッドロックを許可しない方がよいでしょう。
4ソリューション
考え方は非常に単純です。呼び出し自体の中にプロキシオブジェクトの機能を実装する必要があります。 そして、オブジェクトとの対話を簡素化するには、 ->をに置き換えます. 。
簡単に言えば、 Dataオブジェクトを別のオブジェクトに変換する必要があります。
using Lock = std::unique_lock<std::mutex>; struct DataLocked { int get() const { Lock _{mutex_}; return data_.get(); } void set(int v) { Lock _{mutex_}; data_.set(v); } private: mutable std::mutex mutex_; Data data_; };
この場合、メソッド内でミューテックスを取得および解放する操作を制御します。 これにより、前述の問題が回避されます。
しかし、スマートミューテックスの基本的な考え方はコードの追加を避けることであるため、このようなレコードは実装には不便です。 推奨される方法は、両方のアプローチを活用することです。つまり、コードを減らし、同時に問題を減らします。 したがって、このソリューションを一般化し、幅広いユースケースに配布する必要があります。
4.1汎用アダプター
mutexを使用しない古いData実装を、 mutexを含む実装に何らかの形で適応させる必要があります。これは、 DataLockedクラスに似ているはずです。 これを行うには、メソッド呼び出しをラップして、動作をさらに変換します。
template<typename T_base> struct DataAdapter : T_base {
ここで、 data.set(v)呼び出しを延期し、 T_base::call(lambda)にT_base::call(lambda)ます。 T_base可能な実装はT_baseです。
struct MutexBase { protected: template<typename F> void call(F f) { Lock _{mutex_}; f(data_); } private: Data data_; std::mutex mutex_; };
ご覧のとおり、 DataLockedクラスのモノリシック実装を、作成されたアダプターの基本クラスの1つとして、 DataAdapter<T_base>とMutexBase 2つのクラスに分割しました。 しかし、実際の実装は非常に近い： Data::set(v)呼び出し中にミューテックスを保持します。
4.2その他の一般化
実装をまとめましょう。 MutexBase実装はDataに対してのみ機能しData 。 これを改善しましょう：
template<typename T_base, typename T_locker> struct BaseLocker : T_base { protected: template<typename F> auto call(F f) { using Lock = std::lock_guard<T_locker>; Lock _{lock_}; return f(static_cast<T_base&>(*this)); } private: T_locker lock_; };
ここでは、いくつかの一般化が使用されています。
- 特定のミューテックス実装を使用しません。
std::mutexまたは BasicLockableの BasicLockableを実装するオブジェクトを使用できます。 T_baseは、同じインターフェイスを持つオブジェクトのインスタンスです。 これは、 Dataでも、たとえばDataLockedなどの既に適合したDataオブジェクトでもDataLocked 。
したがって、以下を決定できます。
using DataLocked = DataAdapter<BaseLocker<Data, std::mutex>>;
4.3より一般化が必要
汎化の使用を止めることは不可能です。 入力パラメータを変換したい場合があります。 これを行うには、アダプターを変更します。
template<typename T_base> struct DataAdapter : T_base { void set(int v) { T_base::call([](Data& data, int v) { data.set(v); }, v); } };
また、 BaseLocker実装BaseLocker変換されます。
template<typename T_base, typename T_locker> struct BaseLocker : T_base { protected: template<typename F, typename... V> auto call(F f, V&&... v) { using Lock = std::lock_guard<T_locker>; Lock _{lock_}; return f(static_cast<T_base&>(*this), std::forward<V>(v)...); } private: T_locker lock_; };
4.4ユニバーサルアダプター
最後に、アダプターに関連付けられているテンプレートコードのサイズを小さくしましょう。 テンプレートが終了し、高度なイテレータマクロが機能します。
#define DECL_FN_ADAPTER(D_name) \ template<typename... V> \ auto D_name(V&&... v) \ { \ return T_base::call([](auto& t, auto&&... x) { \ return t.D_name(std::forward<decltype(x)>(x)...); \ }, std::forward<V>(v)...); \ }
DECL_FN_ADAPTER使用DECL_FN_ADAPTERと、 D_nameという名前のメソッドをラップできDECL_FN_ADAPTER 。 オブジェクトのすべてのメソッドをソートしてラップするだけです。
#define DECL_FN_ADAPTER_ITERATION(D_r, D_data, D_elem) \ DECL_FN_ADAPTER(D_elem) #define DECL_ADAPTER(D_type, ...) \ template<typename T_base> \ struct Adapter<D_type, T_base> : T_base \ { \ BOOST_PP_LIST_FOR_EACH(DECL_FN_ADAPTER_ITERATION, , \ BOOST_PP_TUPLE_TO_LIST((__VA_ARGS__))) \ };
これで、1行のみを使用してDataを調整できます。
DECL_ADAPTER(Data, get, set)
そしてそれだけです！
5例
mutexベースのアダプターを確認しました。 他の興味深いアダプターを検討してください。
5.1リンク数アダプター
何らかの理由で、オブジェクトにshared_ptrを使用する必要がある場合があります。 そして、この振る舞いをユーザーから隠す方が良いでしょう： operator->を使う代わりに、私はoperator.を使いたいoperator. 。 まあ、または少なくとも単純に. 。 実装は非常に簡単です。
template<typename T> struct BaseShared { protected: template<typename F, typename... V> auto call(F f, V&&... v) { return f(*shared_, std::forward<V>(v)...); } private: std::shared_ptr<T> shared_; };
アプリケーション：
using DataRefCounted = AdaptedShared<Data>; DataRefCounted data; data.set(2);
5.2。 アダプターの組み合わせ。
時々、スレッド間でデータを調べることは素晴らしいアイデアです。 一般的なスキームは、 shared_ptrとmutexを組み合わせることです。 shared_ptrはオブジェクトの寿命に関する問題を解決し、 mutex使用して競合状態を防ぎます。
適合した各オブジェクトは元のオブジェクトと同じインターフェースを持っているため、いくつかのアダプターを簡単に組み合わせることができます。
template<typename T, typename T_locker = std::mutex, typename T_base = T> using AdaptedSharedLocked = AdaptedShared<T, AdaptedLocked<T, T_locker, T_base>>;
この用途では：
using DataRefCountedWithMutex = AdaptedSharedLocked<Data>; DataRefCountedWithMutex data;
5.3非同期の例：コールバックから未来へ
未来へのステップ。 たとえば、次のインターフェイスがあります。
struct AsyncCb { void async(std::function<void(int)> cb); };
ただし、将来の非同期インターフェイスを使用したいと思います。
struct AsyncFuture { Future<int> async(); };
Futureインターフェイスは次のとおりです。
template<typename T> struct Future { struct Promise { Future future(); void put(const T& v); }; void then(std::function<void(const T&)>); };
一致するアダプター：
template<typename T_base, typename T_future> struct BaseCallback2Future : T_base { protected: template<typename F, typename... V> auto call(F f, V&&... v) { typename T_future::Promise promise; f(static_cast<T_base&>(*this), std::forward<V>(v)..., [promise](auto&& val) mutable { promise.put(std::move(val)); }); return promise.future(); } };
アプリケーション：
DECL_ADAPTER(AsyncCb, async) using AsyncFuture = AdaptedCallback<AsyncCb, Future<int>>; AsyncFuture af; af.async().then([](int v) {
5.4非同期の例：未来からコールバックまで
なぜなら それは過去に私たちを向け、それをホームタスクにしましょう。
5.5遅延アダプタ
開発者は怠け者です。 開発者との互換性のために任意のオブジェクトを適合させましょう。
これに関連して、怠とは、オブジェクトをオンデマンドで作成することを意味します。 次の例を考えてみましょう。
struct Obj { Obj(); void action(); }; Obj obj;
すなわち アイデアは、オブジェクトの作成を最後まで遅らせることです。 ユーザーがオブジェクトの使用を決定した場合、オブジェクトを作成し、適切なメソッドを呼び出す必要があります。 基本クラスの実装は次のとおりです。
template<typename T> struct BaseLazy { template<typename... V> BaseLazy(V&&... v) {
これで、重い遅延オブジェクトを作成し、必要な場合にのみ初期化できます。 ただし、ユーザーには完全に透過的です。
6オーバーヘッド
アダプターのパフォーマンスを見てみましょう。 実際には、ラムダを使用し、それらを他のオブジェクトに転送します。 したがって、このようなアダプタのオーバーヘッドを知ることは非常に興味深いでしょう。
これを行うには、簡単な例を考えてみましょう。オブジェクト自体を使用してオブジェクト呼び出しをラップします。 同一のアダプターを作成し、そのような場合のオーバーヘッドを測定してください。 直接パフォーマンスを測定する代わりに、さまざまなコンパイラ用に生成されたアセンブラコードを見てみましょう。
まず、 onメソッドでのみ動作するアダプターのシンプルなバージョンを作成しましょう。
#include <utility> template<typename T, typename T_base> struct Adapter : T_base { template<typename... V> auto on(V&&... v) { return T_base::call([](auto& t, auto&&... x) { return t.on(std::forward<decltype(x)>(x)...); }, std::forward<V>(v)...); } };
BaseValueは、同じ型Tから直接メソッドを呼び出すための同一の基本クラスです。
template<typename T> struct BaseValue { protected: template<typename F, typename... V> auto call(F f, V&&... v) { return f(t, std::forward<V>(v)...); } private: T t; };
そして、ここにテストクラスがあります。
struct X { int on(int v) { return v + 1; } };
以下に、 オンラインコンパイラで得られた結果を示します 。
GCC 4.9.2
f1(int): leal 1(%rdi), %eax ret f2(int): leal 1(%rdi), %eax ret
Clang 3.5.1
f1(int): # @f1(int) leal 1(%rdi), %eax retq f2(int): # @f2(int) leal 1(%rdi), %eax retq
ご覧のとおり、 f1とf2違いはありません。つまり、コンパイラーは、ラムダオブジェクトの作成と受け渡しに関連するオーバーヘッドを最適化し、完全に排除できます。
7結論
この記事では、追加機能を使用してオブジェクトを別のオブジェクトに変換できるアダプターを紹介します。これにより、変換と呼び出しのオーバーヘッドなしでインターフェースが変更されません。 ベースアダプターのクラスは、任意のオブジェクトに適用できるユニバーサルトランスフォーマーです。 これらは、アダプターの機能を改善し、さらに拡張するために使用されます。 基底クラスのさまざまな組み合わせにより、非常に複雑なオブジェクトを簡単に作成できます。
この強力で楽しいテクニックは、以降の記事で使用および拡張されます。
便利なリンク
[1] github.com/gridem/GodAdapter
[2] bitbucket.org/gridem/godadapter
[3] ブログ：God Adapter
[4] C ++ロシアレポート：ユニバーサルアダプター
[5] Video C ++ Russia：ユニバーサルアダプター
[6] Habrahabr：便利なC ++マルチスレッドイディオム
[7] オンラインゴッドボルトコンパイラ