C 言語のラッパー関数オーバーヘッド

プログラムを組む際、ラッパー関数を作ることは良くある。 このラッパー関数のオーバーヘッドが気になったので簡単に調べてみた。 計測用サンプルは次の通り。 #include<stdio.h> typedef void (func_t)( int val1, int val2 ); void func( int val1, int val2 ) { printf( "%d %d", val1, val2 ); } void wrapper0( int val1, int val2 ) { func( val1, val2 ); } void wrapper1( func_t * pFunc, int val1, int val2 ) { pFunc( val1, val2 ); } void wrapper2( int val1, int val2, func_t * pFunc ) { pFunc( val1, val2 ); } main() { wrapper0( 0, 1 ); wrapper1( func, 0, 1 ); wrapper2( 0, 1, func ); } 関数 func() をコールする 3 種類のラッパー関数 wrapper0, wrapper1, wrapper2 を用意した。 それぞれのラッパー関数は次

C 言語の可変長引数 (va_list) 処理のオーバーヘッド

以前 C 言語の関数ポインタによる関数コールのオーバーヘッドがどの程度なのか調べたが、 今回は可変長引数(va_list)処理のオーバーヘッドについて調べてみた。 結果 初めに結果から書くと、 可変長引数(va_list)処理のオーバーヘッドは、めちゃめちゃ掛る。 また、引数の数に応じて時間が増加する。 所感 今回の実験によって、 va_list 処理には当初の想定を遥かに越えたオーバーヘッドが かかることが分った。 個人的には、コン

如何なる開発手法、プログラム言語を用いても、日本の全てのソフトウェアプロジェクトは必ず技術的負債になる

「日本の全てのソフトウェアプロジェクトは必ず技術的負債になる」というタイトルですが、 次の条件を満す場合に限ります。 「プロジェクトに関わるソフトウェアエンジニアの大半が技術に無関心」 動機 このネタは、次の記事を読んで個人的に思うことがあったのをきっかけに 書いています。 オブジェクト指向プログラミング – 1兆ドル規模の大失敗 <https://okuranagaimo.blogspot.com/2019/07/1.html> 大企業の技術系インターンシップに参加した <https://blog.browniealice.net/post/internship2019winter/> ソフト開発で世界と闘った及川卓也氏が見た

emacs26.2 で矢印(→)等の一部のフォントが半角表示されるようになった

emacs のバージョンを 26.2 に変えたことで、 色々と細かいところの使い勝手が変っている。 その中で、 → 等の一部のフォントが半角表示されるようになったのが 微妙にストレスだったのでちょっと追ってみた。 原因 原因、と言うよりは起因と言った方が良いかもしれないが、 → 等の一部のフォントが半角表示されるようになったのは、 フォントに "DejaVu Sans Mono" を使用していることに起因していた。 これを "Bitstream Vera Sans Mono" に変更することで、現象が治った。 全く同じ環

stream は rewind/seek できる?

これは seekable な stream と none_seekable な stream の使い分けに関する記事です。 使い分けが十分出来ている人は読まなくても大丈夫です。 皆さんは bitstream という単語をご存知でしょうか? AV (Audio&Visual) が好きな人や、 それらの業界に関係のある人ならそこそこ聞く単語だと思いますが、 一般的にはあまり馴染の無い単語でしょうか。 馴染の無い人の為に身近な HDD レコーダを例に挙げて説明すると、 HDD レコーダはデジタル放送の電波に乗っているデータをそのまま記録していますが、 この