STL の勉強をするために Visual Studio 2015 の std::map をコードレーディングした時のメモ。
_Treeにアルゴリズムの実装がある。（ヘッダーファイル xtree）- アルゴリズムは赤黒木。
_Tmap_traitsがキーを使って比較するための関数オブジェクト。_Tmap_traitsを噛ませることで実際の木の実装と，内部オブジェクトの分離を図っている。- 高速化やデバッグコードの分離のために複数のイテレーターが存在する模様。
StoneDotのいろいろ
highlight.pack.js
2016年1月4日月曜日
Visual Studio 2015 の std::map について
2015年2月20日金曜日
make_shared の弱点
make_shared の弱点
make_shared で確保されたメモリ領域は，それを参照する weak_ptr が無くならない限り解放されない
がイマイチしっくり来なかったので、自分でコード作る＋make_sharedのコードを追いかけて理解したので、
それのメモ。
以下のようなコードをメモリ使用量を監視しながらステップ実行して確かにそのようなことを起こっていることを確認出来た。
というわけで、どうしてそうなっているのかをソース追いかけてみる。 そうすると内部で、
_Ref_count_obj<_Ty> *_Rx =
new _Ref_count_obj<_Ty>(_STD forward<_Types>(_Args)...);
と内部オブジェクトを作っているようだが、事実上これが shared_ptrの中身だと思って良さそうだ。
で、実際にそのコンストラクタのコードがこんな感じ。
template<class... _Types>
_Ref_count_obj(_Types&&... _Args)
: _Ref_count_base()
{ // construct from argument list
::new ((void *)&_Storage) _Ty(_STD forward<_Types>(_Args)...);
}
つまり、placement new を使って _Ref_count_obj の中に、そのままオブジェクトを構築していることになる。
この _Ref_count_obj は _Ref_count_base を継承しているが、これが参照カウンタを持っている。
管理用のカウンタとオブジェクト本体が一緒になっているので、
オブジェクトを参照している weak_ptr と shared_ptr がなくならなければオブジェクトが開放されないというのも納得である。
make_shared の中ではメモリの確保回数を減らすためにこのような処理を行っている、ということがわかっていればそれほど難しい事ではなかった。
2014年12月1日月曜日
フーリエ変換の結果
\begin{equation}
F(k)=\dfrac{1}{\sqrt{2\pi}}\int_{-\infty}^{\infty} f(x)e^{-ikx}dx
\end{equation}
で定義されるフーリエ変換の結果を纏めておく。
f(x)=exp(-a|x|) (a>0) の時
\begin{equation}
f(x)=e^{-a\left|x\right|} (a>0)
\end{equation}
\begin{equation}
F(k)=\sqrt{\dfrac{2}{\pi}}\dfrac{a}{a^2+k^2}
\end{equation}
f(x)=exp(-a^2x^2) (a>0) の時
\begin{equation}
f(x)=e^{-a^2x^2} (a>0)
\end{equation}
\begin{equation}
F(k)=\dfrac{1}{\sqrt{2a}}e^{-\frac{k^2}{4a}}
\end{equation}
f(x)=1/(x^2+a^2) (a>0) の時
\begin{equation}
f(x)=\dfrac{1}{x^2+a^2} (a>0)
\end{equation}
\begin{equation}
F(k)=\sqrt{\dfrac{\pi}{2a^2}}e^{-a\left|k\right|}
\end{equation}