場当たり的なMakefileで管理しているC/C++のコードの規模(数千行程度)がそれなりに大きくなってきた. テストがないので大きな変更がしんどい. テストがないのでバグを踏んでも何が原因かは勘とprintfデバッグ、辛い. もういろんなところでテストがまったくな…

発声練習:Intel C/C++ を用いた Google Test環境を準備するを参考にしてgoogletestのセットアップを行うシェルスクリプトを書いた． ホームディレクトリにソースを落としてきて、コンパイルした後に/usr/local/に必要なヘッダとライブラリをcpしているだけ．…

前回(g++)と前々回(gcc)のサンプルコードを使ったC++のマングリングや"C"リンケージに関するメモ． nmコマンドでサンプルコードのシンボルテーブルを覗いた後に、C++からCの関数を呼び出す場合のサンプルコードを示す. 特にリンケージ周りの説明は正確性を欠…

前回の記事で公開したMakefileでは、gccのコンパイルオプションに-Wallを付けていなかった． 極めて非人道的である． 現在はMakefileを修正してコンパイル時に-Wallを付けるようにしたが、そのままmakeを叩くとコンパイラにしっかり警告を食らった． run.c: …

CでもC++でも良いんだけど、コードが大きくなってくるとファイルの分割を考え始める． 追記(204/1/30):このままコンパイラをg++にするとコンパイルが通らなかった．また、-Wallオプションを付けないというとんでもないことをしている．その辺のことをこちら…

二十五日半狂乱、6日目(の分...orz)の記事 Cのエラーハンドリングを毎回やるのは面倒だ！ 前回も言ったが、Cではエラーハンドリングに戻り値とerrnoを用いる． それはそうと例外設計において"無視"は大罪である． だから、関数を呼び出したら戻り値は漏らさ…

二十五日半狂乱、5日目(の分)の記事 C言語における関数のエラーハンドリングには戻り値およびerrnoを使うが、自分が読んだ文法書などのサンプルコードではエラーが起こった場合の処理が、大体がperror("fopen"); exit(1);のような感じのもので、まぁ小さいサ…