This site has been moved to the following site.
コード断片を Gist に統一させようと試みたが分量が多いので諦めて仕切り直し。
旧サイトはこのままの状態で。
2016年11月16日水曜日
Expression templates 2
スカラとベクトル、スカラと行列については実装の目途が立ってきた。
ベクトルと行列に関しては、設計を煮詰める必要性があるようだ。
Eigen みたいにスカラもベクトルも行列もすべて行列として扱うのが合理的なんだろうな。
話は変わってテストケースを追加している際に、最適化(-O2)を有効にすると segfault で
vc14 / g++ / clang で全滅に遭遇した。
下記のようなケースが一例。
expression をコンストラクタに渡すと中でお亡くなりになっているようだった。
単純なケースでは発生しなかったので、expression が複雑になると何かが起きているようだ。
上記は ETs(Expression templates) のサンプルに頻繁に記載されているような
単純な expression クラステンプレート。
const reference から猛烈な激臭がしてくる。
と考えると、最適化の影響で一時変数が消されている可能性が高い。
行きつく先は dangling reference となる。
というわけで const reference となっている箇所をスカラと expression については
実体としてもつようにすると案の定というか必然というか問題は解消した。
※ 併せてスカラ(ラッパー)内の const reference も実体としてもつように
ベクトルと行列に関しては、設計を煮詰める必要性があるようだ。
Eigen みたいにスカラもベクトルも行列もすべて行列として扱うのが合理的なんだろうな。
話は変わってテストケースを追加している際に、最適化(-O2)を有効にすると segfault で
vc14 / g++ / clang で全滅に遭遇した。
下記のようなケースが一例。
auto exp = (va + vb) + (vc + vd); vector v(exp);
expression をコンストラクタに渡すと中でお亡くなりになっているようだった。
単純なケースでは発生しなかったので、expression が複雑になると何かが起きているようだ。
template<L, Op, R> class expression { public: expression(const L& l, const R& r) : l_(l), r_(r) {} // ... private: const L& l_; const R& e_; }
上記は ETs(Expression templates) のサンプルに頻繁に記載されているような
単純な expression クラステンプレート。
const reference から猛烈な激臭がしてくる。
expression exp_temp1 = va + vb; expression exp_temp2 = vc + vd; expression exp = exp_temp1 + exp_temp2; vector v(exp);
と考えると、最適化の影響で一時変数が消されている可能性が高い。
行きつく先は dangling reference となる。
というわけで const reference となっている箇所をスカラと expression については
実体としてもつようにすると案の定というか必然というか問題は解消した。
※ 併せてスカラ(ラッパー)内の const reference も実体としてもつように
vc14 の release build の結果. |
2016年11月13日日曜日
Expression templates
Expression templates である。
Blitz++ や Eigen を大人しく使っておけである。
が、そこはやはりさわり程度は知っておくべきなんだろう。
単純に動くだけの簡単なものを作ってみることにした。
二次元ベクトルの加算、減算、スカラー倍、除算。
スカラーの扱いで随分悩んだのと、オペレータ各種がかなりゴリ押し気味。
行列とか絡むと今は想像できない。
要修行。
追記:
寝て起きたらオペレータ周りがすっきりした。
なにやら錯乱していたようだ。
Blitz++ や Eigen を大人しく使っておけである。
が、そこはやはりさわり程度は知っておくべきなんだろう。
単純に動くだけの簡単なものを作ってみることにした。
二次元ベクトルの加算、減算、スカラー倍、除算。
スカラーの扱いで随分悩んだのと、オペレータ各種がかなりゴリ押し気味。
行列とか絡むと今は想像できない。
要修行。
追記:
寝て起きたらオペレータ周りがすっきりした。
なにやら錯乱していたようだ。
2016年11月8日火曜日
[CMake] 静的ライブラリのリンク
大抵の外部ライブラリには CMake 対応がされており、
気軽に好みのビルド環境を構築することができるようになっている。 (できるとは限らないが)
なんであれ自作アプリケーションに組み込んで利用する前には必ずお世話になるはずだ。
私もよくお世話になっているわけだが、ふと中で何をしているのかが気になった。
というわけで動作を追ってみることにした。
まとめきれないので GitHub に。
おそらく頻繁に使うケースは、ライブラリをビルドツリーの
・中に置く
・外に置く
のどちらかだと思われる。
いづれにせよ重要なのは、CMakeの時間軸概念ではないだろうか。
(1) Generate-Time
CMake で任意のプロジェクトを生成
(2) Build-Time
生成されたプロジェクトを msbuild / make などで実際にビルド
(3) Install-Time
ビルドされたものをインストール
中に置く場合は、ライブラリ/アプリともに (1) → (2) → (3) と進む(依存関係は解決済みという前提)
外に置く場合は、ライブラリ (1) → (2) → (3)、アプリ (1) → (2) → (3) と進める
時間軸の進め方に大きな違いがあるため、内部で必要となる準備も異なってくる。
所感としては、中に置くケースは一括で構築できるので便利である反面、複雑になる気がしてならない。
気軽に好みのビルド環境を構築することができるようになっている。 (できるとは限らないが)
なんであれ自作アプリケーションに組み込んで利用する前には必ずお世話になるはずだ。
私もよくお世話になっているわけだが、ふと中で何をしているのかが気になった。
というわけで動作を追ってみることにした。
まとめきれないので GitHub に。
おそらく頻繁に使うケースは、ライブラリをビルドツリーの
・中に置く
・外に置く
のどちらかだと思われる。
いづれにせよ重要なのは、CMakeの時間軸概念ではないだろうか。
(1) Generate-Time
CMake で任意のプロジェクトを生成
(2) Build-Time
生成されたプロジェクトを msbuild / make などで実際にビルド
(3) Install-Time
ビルドされたものをインストール
中に置く場合は、ライブラリ/アプリともに (1) → (2) → (3) と進む(依存関係は解決済みという前提)
外に置く場合は、ライブラリ (1) → (2) → (3)、アプリ (1) → (2) → (3) と進める
時間軸の進め方に大きな違いがあるため、内部で必要となる準備も異なってくる。
所感としては、中に置くケースは一括で構築できるので便利である反面、複雑になる気がしてならない。
登録:
投稿
(
Atom
)