使ってそれを書いてみました。来れば、素直にそれを使うべきです。バイナリで動作を確認しました。使えないことに注意です。よって擬似的に式の中にテンプレートを書くことができるようになるからです。そのままメタプログラミングに使うのは難しいですが、うまく使えば面白いことができそうです。C++で遊ぼう上の話に加えて、io_service::run()を誰が呼ぶかという話についてのメモ。1つは上で紹介されているように、io_serviceを公開し、ユーザーにrun()させるパターン。client_.get_io_service().run();}もう1つはcpp-netlibがそうしているように、自分がio_serviceを作った場合は自分でrun()するパターン。m_thread;};どちらを使うかはお好みです。個人的には常にio_serviceを渡してもらえばいいと思っているもよう。11:27Boost.Asioでio_service::run()を包含する設計Tweet広告を非表示にするもっと読むコメントを書く2013-03-02Boost.Asioで非同期操作中に*thisの寿命が尽きることを防ぐC++Boost.Asioを使って非同期操作を書いていると、メンバ関数から起動した非同期操作の最中に*thisの寿命が尽きて困ることがあります。...)によって開始される非同期操作中に、*thisの寿命が尽きてしまう可能性があることです。reference)。この問題は、http_clientクラスのデストラクタで非同期操作をキャンセルするだけでは解決しません。objectのcancel()はそういう動作をします)。ユーザーとの間で、非同期操作の終了まで*thisを破棄しないという同意が何らかの形で成立していればいいですが、できればクラスの中だけでこの問題を解決したいものです。*thisをshared_ptrで管理するこの問題を解決するよく知られた方法は、*thisをshared_ptrで管理するようにし、ハンドラに*thisを指すshared_ptrを"埋め込む"ことで、非同期操作が終了するまで*thisを延命する方法です。具体的には、enable_shared_from_thisを用います。m_streambuf;};この方法の欠点は、クラスのインスタンスを常にshared_ptrで管理することをユーザーに強制する点です。非同期操作で使うメンバ変数が延命できればそれでいい場合は、そのメンバ変数のみshared_ptrで管理するという手もありますが、*thisそのものは延命できません。デストラクタでwaitする非同期操作が終了するまで待つwait()を用意しておけば、デストラクタでwait()を呼ぶことで、非同期操作中の*this破壊を回避することができます。実装としてはpromise/futureを使うのが良さそうです。stateがreadyになります(30.6.5/7、30.6.4/7)。wait()はfuture::wait()を呼び出してこれを待ちます。11:27Boost.Asioで非同期操作中に*thisの寿命が尽きることを防ぐTweet広告を非表示にするもっと読むコメントを書く2013-02-22C++/Boostでオブジェクトへのアクセスを同期する方法メモC++C++で、複数のスレッドから1つのオブジェクトにアクセスするときに同期をとる方法いろいろ。atomicを使う使える型は限られるが、お手軽。4000000これはatomic<T>を使う例。アトミックな操作を順に実行するだけのコードはアトミックでないことに注意。m_value;};メンバ関数内でロックをかける。内部ロックと呼ぶことにする。Javaでいうところのsynchronizedメソッドか。こちらも、単に"synchronizedメンバ関数"の呼び出しを連ねただけのコードはアトミックでないことに注意する必要がある。m_value;};場合によっては、read-lock/write-lockを使うと効率が上がる...かもしれない(この例はてきとー)。