CLLocationのdistanceFromLocation:の精度が低い。

低い。4桁程度だろうか。
7000mくらい離れた2地点の距離を求めると、国土地理院が公開してる測地線長の計算式で求めたものとの差が1mくらいになる。

これはまあ、ほとんどの場合は4桁もあれば十分ではある。

ただ、3地点を結んでできる三角形の面積をヘロンの公式で求めるのにこの distanceFromLocation: を使ってて困ったことが起きた。面積がNaNになることがあるのである。

調べてみると、3地点がほぼ直線上にある場合にdistanceFromLocation:で得られる長さで計算すると

  長辺の長さが他の2辺の長さの和よりも長くなってしまう

場合が生じることが判った。。。 これはマズい。三角形にならないじゃん?
先の有効桁数以下の差ではあるのでこれが起きた場合は面積ゼロとして処理する。。とかやればいいのだが、うーむ。。。

測地線長を計算するよりは distanceFromLocation:の方が精度悪いとはいえ計算速いしなー、と悩んでたのだが、あれ? もしかして CLLocationがalloc/deallocされる時間を考慮したらあんま変わらないんじゃね? と思って計測したら案の定測地線長計算する時間より CLLocaitonの alloc/distanceFromLocation:/dealloc にかかる時間の方が1.2倍くらいかかってるではないか。

つまりこういうことだ。サヨウナラ distanceFromLocation: !!!

ちなみに測地線長の計算式で求めた2点間の長さで面積を計算した場合では面積がNaNになることはなかった。ぐらっちぇ

響け! ユーフォニアム面白い

放映アニメが入れ替わる毎に、最初に期待してたアニメと段々ハマって楽しみに見るアニメとが全然違うんだけど今期面白く見てるアニメはユーフォ。これは良い花田。
人の想いはままならなくて、面倒臭くて、だからこそ面白いなあ

shared_ptrで派生クラスを保持した時のデストラクタの挙動

C++で派生クラスのオブジェクトを親クラスのポインタで保持している場合、派生クラスのデストラクタが呼ばれるためには親クラスのデストラクタを仮想関数化しなければならない。

ところで今はもう2015年。C++11もすっかり市民権を得、C++14もやってきて、生ポインタを扱ったり直接delete書いたりするのは時代遅れとなりました。
そして、 shared_ptr を使うとどうやらデストラクタを仮想関数化しなくても良いっぽいというハナシを聞いたので試してみた。

素晴らしい。

ただしどうやら格納されたオブジェクトの型のデストラクタではなく、「shared_ptrにセットした時の型」のデストラクタが呼ばれるっぽい。

まーこんな書き方はフツーしないけど、shared_ptrを使えばデストラクタの仮想関数化は全く不要!! と安易に考えると落とし穴があるかもしれない。かもしれない。

もひとつ紛らわしいのは unique_ptr は単純に従来通りのデストラクタが呼ばれるのよな。

というわけで B のオブジェクトがdeleteされる時にBのデストラクタが呼ばれることを確実に保証するためにはshared_ptrに頼るのではなく親クラスのデストラクタを仮想関数化するしかないよなー。みたいな。そんな。