C++のenable_shared_from_thisを使う
はじめに
カブクの甘いもの担当の高橋憲一です。
相変わらず日々甘いものを食しながらC++でZ軸を触るコードを書いています。最近のお気に入りはローソンの「あんこ天国」という名前のあんぱんです。中のあんこが透けて見えるほど薄い生地にたっぷりのあんこが包まれていて満足度が高く、食べるとコーディングが捗ります 🙂
スマートポインタを使っていて遭遇した問題
C++プログラマにとってstd::shared_ptrやstd::unique_ptrなどのスマートポインタを使うことは、もはや疑う余地のないことではありますが、こんな場面に遭遇したことはありませんでしょうか。
std::make_shared<Foo>()
でstd::shared_ptrとして生成したあと、そのFooのクラスの中で自分自身(this)をどこかのコンテナに入れたい。
そんな状況を作り出した自分のコード設計が悪いのかと最初は考えあぐねていたのですが、幸い世の中に同じ状況に遭遇する人は多いようで、それを解決してくれるものがC++11以降では標準で用意されていました。
std::shared_ptrの意図しない領域解放
std::shared_ptrはリファレンスカウントにより、そのポインタが指し示すメモリ領域を管理してリファレンスカウントが0になった際にその領域を解放してくれます。
auto foo = std::make_shared<Foo>();
とすることで、オブジェクトのインスタンスをヒープ領域に生成し、参照するポインタをstd::shared_ptrの管理下におくことができます。
auto hoge = foo;
というように、他のstd::shared_ptr<Foo>
型の変数に代入して複数箇所で使用し、hoge、fooのどちらもスコープから外れた際にリファレンスカウントが0になり、指し示す領域は解放されます。
ここまでで、Fooのクラスの外で使う分においては何も困ったことは起こらないはずです。
しかし、Fooのクラスのメソッド内でthisを外部と絡む処理で使いたい場合、例えばstd::vector<std::shared_ptr<Foo>>
というコンテナに入れたいというような場合にどうすれば良いのでしょうか。
ここでもし、
auto p = std::shared_ptr<Foo>(this);
というように、単純にthisを新たにstd::shared_ptrで包んで、同じポインタを異なるstd::shared_ptrで管理するとどのようなことが起きるか…想像するだけで恐ろしいです。
具体的には複数のstd::shared_ptrで同じメモリ領域を管理してしまうことになります。すなわち、1つ目のstd::shared_ptrではリファレンスカウントが0より大きいのにもかかわらず、2つ目のstd::shared_ptrのリファレンスカウントが0になった際に、その領域が解放されてしまうということが起こります。ここで1つ目のstd::shared_ptrはまだ領域が有効だという認識ですので、その領域への参照が発生した際に、解放済み領域へのアクセスという不正な処理が発生します。
もちろん、一度std::shared_ptrに委ねた領域のポインタを生で管理する(std::vector<Foo *>
というコンテナを用意してthisを入れる)ようなことも避けるべきです。そんなことをしたらコンテナの預かり知らないところでstd::shared_ptrのリファレンスカウントが0になって領域が開放され、このコンテナの要素が指し示す先を参照した際にやはり解放済み領域への不正アクセスが発生します。
解決策 std::enable_shared_from_this
まず、std::enabled_shared_from_this<Foo>
というように、そのクラス自身をテンプレート引数として指定したクラスをpublic継承します。
class Foo : public std::enable_shared_from_this<Foo> {
//
};
実際にstd::shared_ptr管理下のthisが必要な場所で、例えば
auto p = shared_from_this();
というようにします。これで二重管理することなくFooのクラスの中でstd::shared_ptr配下のthisを得ることができます。
実際に動作するコードです。
macOS Mojave (version 10.14.4) + clang (Apple LLVM version 10.0.1) の環境と、Ubuntu 16.04.1 LTS + gcc (version 5.4.0) の環境で確認しました。
g++ -std=c++17 sharedPtrTest.c++
というようにしてコンパイル、リンクします。
実行例:
radius=0.9
radius=0.1
a.use_count=1
b.use_count=2
c.use_count=2
3つのCircleオブジェクトが作成され、そのうちsmall cirlceとして判定された半径が1.0より小さなものが2件(bとc)出力されています。つづく3行ではa, b, cそれぞれのリファレンスカウントが出力されます。bとcはstd::vectorのコンテナに格納されていますので、その分リファレンスカウントが1つ増えて2になっています。これは10行目のshared_from_this()により返されたものが別のstd::shared_ptrを作成するのではなく、最初に作成されたstd::shared_ptrに結び付けられているということを示しています。
std::enable_shared_from_thisを使用する例がEffective Modern C++の4章に載っているのは安心材料の一つです。”The line creating 〜 is a stylistic abomination. (〜を作成する行は見た目も醜悪です。)といったような言い回しが出てくる書籍ですので、もし良くない用法だとしたらバッサリ切り捨てられているはずです。
さいごに
カブクでは実行時に高いパフォーマンスが必要とされる3DメッシュデータやCADデータを扱う処理をC++で実装しています。C++によるプログラミングの腕に覚えがあり、3Dデータを扱う処理に興味があるという方はぜひ kenichi.takahashi@kabuku.co.jp までご連絡ください。
追記(2019年4月19日)
まだ私がC++プログラマとして駆け出しだった頃(1996~1998年くらい)の師匠から「ブログ記事を興味深く読ませてもらいました」と連絡をいただきました。師からの久しぶりの便りに喜んだのも束の間、「一つ気になったのは、shared_from_this()を導入することで生のポインタ経由でCircleクラスを使うことを禁止しなくては危険なような気がすることです。shared_from_this()を呼ぶ前に、少なくとも1つのshared_ptrを構築済みでないといけないようですので。」という、全くもって的確なツッコミをもらい、この記事を書いたことで思いがけず師を前にする懐かしくもあり心地よい緊張感を味わうことになりました。
実はブログ記事用にサンプルコードを用意するにあたり少々手を抜いてしまいまして、本来ならコンストラクタはprivateとして宣言することでクラス利用者からは隠蔽し、ファクトリ関数を用意してクラスの利用者にはファクトリ関数経由でオブジェクトを生成するようにしてもらうようにするべきだったのです。
それに基づいて書き換えたコードは以下のようになります。これで生のポインタ経由でクラスを使うことを禁止することができます。
増えた行数は高々6行…サンプルコードは必要最小限にしたかったとはいえ、抑えるところはちゃんと抑えないといけないとあらためて思い直しました。まだまだ精進が必要なようです。
その他の記事
Other Articles
関連職種
Recruit