05/26

(1:01) 今日はプログラミングのアルバイトの進捗がとても少なかった。

 

独自実装をできるだけ標準的なもので置き換えるというテーマがあるので、先週、独自実装のキューの中身をほとんど std::deque に委譲した(deque ではカバーできない挙動があったので置き換えはせず)。

しかし、それでビルドして全体のテストを動かすと無限ループになってしまう。

困った。

 

けっこう大きなプログラムなのだが、現状ユニットテストのようなものはない。

ここで追加するという選択肢もあったが、テストを追加するというのは要求されている優先度としては後のほうだった。

 

キューのクラス自体は大きくはないのだが、ぼくはこういうときはまずデバッガで挙動を確認することにしている。

それで、まず llvm でのデバッグの仕方を調べる。

lldb というものがあるようだ。

それでデバッグをしてみたが、どうも行番号が合わなかったり挙動がおかしい。

最終的にはprintfまで使ってしまった。

 

最終的にわかったのは、使うべきでないところで deque の resize を使っていて、それでサイズが大きくなっていたということ。

元の実装では配列ベースだったので、vector の reserve にあたるメソッドがあったのだが、その引数をそのまま deque の resize に渡してしまった。

あきれてものも言えない。

 

まあ、うっかりしたのはしょうがないが、デバッガで何時間も使ってしまったのは明らかに失敗だ。

途中で休憩を取るべきだった。

そうしたら、コードをチェックするという考え方が出てきたかもしれないし、うっかりミスに気がつきやすかったかもしれない。

 

普段であれば図書館でやっているので 25分やって 5分休んでその間歩き回ったりするということがやりやすいのだが、今日は月曜で図書館が休みだったので喫茶店でプログラミングしていたのがまずかった。

もうちょっと休憩時間を厳密に取って、喫茶店でも漫画を読むなどして完全に気分転換をするよう気をつけよう。

 

ぼくは Visual Studio が長かったので、問題があったら(テストの有無にかかわらず)すぐにデバッガを使う習慣ができている。

しかし、Visual Studio が使えない状況でその行動はよくない。

なにしろ、デバッガが信用できるとは限らない。

 

いま XCode でやってみたが、やはりうまくいかなかった。

ベースが lldb なら当然かもしれないが。

しかし、gdb はもっとひどい。

 

C++ のような複雑怪奇な言語で、デバッグがまともにできるのは Visual Studio ぐらいのものだ。

そういうものが利用できない原始的環境では、デバッグに頼らない方向で考えたほうがいい。

gcc などを使っている原始的環境に慣れた人はデバッグを軽視する傾向があるが、テストとデバッグは直交した概念だ。テストがあっても、失敗したらデバッガで原因を調べるというのは普通にあるやり方だ)

 

明日の午後は家庭教師? だ。

またデータ構造などを教える。