この記事は、emacs 用 reviewboard モードの宣伝である。 <https://github.com/ifritJP/emacs-reviewboard-front> reviewboard は、ソースコードレビューを Web 上で行ない記録するためのツール。 今は github の Pull-Request に代表されるように Web 上のソースレビューが普及しているが、 reviewboard の初版が 2007 年であることを考えると、 当時は先進的なツールだったと思う。 そんな reviewboard を emacs で操作するモードを今になって作ったので、 どれ程の人が使うかは不明だが、折角なので宣伝しておく。 機能 このモードでは、次の機能を提供する。 修正ファ

プログラムを組む際、ラッパー関数を作ることは良くある。 このラッパー関数のオーバーヘッドが気になったので簡単に調べてみた。 計測用サンプルは次の通り。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 #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 種類のラッパー関

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

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

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