ちょっと前のことですが、購入して読みました。
で、今回は、特にこの本のレビューとかではなくて。
こういう本だと、ジャンルがジャンルだけに、「自分だったらどう書くか」という視点で読んでしまいます。
Javaプログラマ向けのCの入門書なら、「Javaでこう書くところを、Cだったらこう書く」という形になるだろうから、私が書くなら……
- 配列は、Javaなら
int[] a = new int[size];
と書くところ、Cではこう書け、とか、
int *a = malloc(sizeof(int) * 10);
- クラスはないので、データだけ固めて扱いたいなら構造体を使って、newの代わりにmalloc()使って書け、とか、
- メソッドらしきことをしたければ第1引数にオブジェクトへのポインタを持って回るようにして、あとは関数の命名規則でなんとかしろ、とか、
- 継承はないので、データメンバの追加だけをしたいのなら、構造体と共用体と列挙型のコンボを使え、とか、
- でもポリモルフィズムはあきらめろ、とか*1、
- malloc()したものはJavaと違ってfree()しなければならないからとにかく気をつけろ、とか、
- Javaと違って配列の範囲チェックとかもないからとにかく気をつけろ、とか、
- 領域破壊を起こしたときにはとにかく何がおきるかわからないからとにかく気をつけろ、とか、
――とかいう話を書いた後で、「Cでは、配列や構造体のオブジェクトをスタックやstaticに確保することができる」という話に入り、メモリ上の配置のイメージなんかを書いていくんじゃないかなあ、と思います。
いや、一般に「AプログラマのためのB言語入門」みたいな本において、「Aでこう書くところを、Bだったらこう書く」的な説明にしてしまうと、Aの流儀でBを書いてしまうからよろしくない、ということは言えると思います。「COBOLプログラマのためのJava入門」なんて本があるのかどうか知りませんが、そういう本を「Aでこう書くところを、Bだったらこう書く」的な書き方にしてしまうと悲惨なことになりそうです。
おそらくLeptonさんもそう思われたのでしょう。「JavaプログラマのためのC作法虎の巻」では、malloc()のまともな説明は「8章 ライブラリ」まで出てこないという徹底ぶりです。確かにこの本は「C作法虎の巻」ですから、こういうスタンスが正しいようにも思います。
ただ、私自身について言うと、たとえばcrowbarやDiksamのソースコードにおいて、固定長の配列なんてほとんど使っておらず、ほとんどmalloc()で確保しています。明示的なポインタ演算も使わず、常に添え字でアクセスです。私の場合、自分で書くCの流儀が、ほとんどJavaの流儀と変わらないものになっているように思います*2。
Cの書き方としては、私の方が邪道ですかね。実はいまどき世間では、Cなんか使うのはメモリがすごく限られた組み込み系とかばかりで、malloc()なんてとんでもない、とか?
以上、とりとめのない話でした。
