補足(いいわけ?)000
「C言語 ポインタ完全制覇」が、 あの有名なLeptonさんの「 闘わないプログラマ」のページで 紹介されました。嬉しい限りです。
実際、既に「闘わないプログラマ」で見て購入してくださったという方から メイルをいただいたりもしてまして、 というか、それ以前にそもそも私のところに本の執筆依頼が来たのは 技術評論社の編集さんがLeptonさんのページからリンクを辿って 私のページを見てくださった所から始まっているわけで、 ホント、Leptonさんには足を向けては寝られませんです(_o_)
それはそれとして、Leptonさんは上記の紹介の中で、
例えば(61ページ)、
POINT
p[i]は、i[p]のように書くことも出来る.POINT
【上のポイントに関するもっと大事なポイント】
でも書くな.ってのがあって、個人的にウケました。
と書いておられます。
もちろん、私もウケを狙って書いてるわけで、 ウケたこと自体は喜ばしいことであるわけですが、 この部分、さてこういう形で良かったのかなあ、 という思いもあるわけでして。
というのも、現実問題、 いまどきp[i]のところをi[p]と書く奴なんて まずいないと思うのですよ。
私がここで言いたかったことは、むしろ C-FAQ の6.11にある、
このとんでもない交換可能性は、よくC言語について扱う文章の中で、 誇らしく思うかのように記述されているが国際難解 Cプログラムコンテスト以外では役に立たない
こちらに近いというか。
確かに、p[i]は*(p+i)のsyntax sugarであって、 加算は交換法則が成り立つから*(i+p)と同じになる、 と、ここまではいいんですが、 これがi[p]と書ける必要はないでしょう、と思うわけです。
整数型しかなかったBならともかく、Cでは、ポインタと整数は別物なんだから、 i[p]をコンパイラが拒否するのは簡単です。 ひょっとしたら、大昔はポインタと整数をごっちゃにして扱っている プログラムがあったのかも知れないし、 そういうのを救済するために「このとんでもない交換可能性」 が残されているのかも知れないけれど、 現在我々がプログラムを書くにあたって、 こんなのは役に立たない。 そういうのが、「よくC言語について扱う文章の中で、 誇らしく思うかのように記述されている」のに、 時々引っ掛かるものを感じるわけでして。
まあ、確かに、i[p]という書き方を紹介するのも、 p[i]が*(p+i)のsyntax sugarであることを印象付けるのには よい手だとは思います。だからこそ、私も書いたわけです。
でも、逆の成り立たない法則なんて世の中にいくらでもあります。 i[p]と書けることをもって、 「おお、Cの、ポインタに関する規則には一貫性があるんだなあ」 なんて感心するのは、ちょっと妙だと思うです。
というわけで、上記部分は、
POINT
p[i]は、i[p]のように書くことも出来る.POINT
【上のポイントに関するもっと大事なポイント】
でも役に立たない.
なんて書くのが良かったかなあ、なんて思ったりもするのですが...
でも、これだと語呂が悪いんですよねえ。
p.45の補足「NULLと0と'\0'と」について、 確かにこれは初心者さんがよく混乱する所なので、 ちゃんと説明しようと努力したつもりなんですが...
あらためて見てみると、初心者さんはかえって混乱してしまうような気もしますね。
最後にひとこと、
とおぼえときゃ大丈夫、というのを付け足しておくべきだったかも。
NULLの内部表現がビットパターンでゼロじゃない処理系なら、 NULLを「(void*)0」と定義するぐらいのことはしてありますよね、きっと。
あまり言い訳を書いてもしょうがないですし、 そもそもこれじゃ言い訳にもならないことは私も承知しておりますが...
正誤表に挙がっている、 クイックソートのリストのミスが どう発生したかの顛末を書きたいと思います。
普通に考えれば、文章部分はともかくとして、リスト部分は 動作テストがしてあればミスはあり得ないはずです。 当然、入稿はファイルで行なっていますし。
なのに、なぜこのようなことが起こってしまったのかといえば...
こんなことは全くもって言い訳にもなりませんね。
ご迷惑をおかけしたことを深くお詫び申し上げます。増刷時に修正予定です。
みなさんご存知の通り、K&Rには
ポインタは，他の変数のアドレスを内容とする変数であり， Cでは頻繁に使用される。
という表現があります(p.113)。
これについて、本の中では、
この説明，バイブルにケチをつけるようで何ですが， かなり問題のある表現だと思います．この説明では， まるでポインタといえば「変数」であるかのようですが， 実際には必ずしもそうではないからです．
と書いています。
でも、構成上入れなかったのですが、この文面に関しては 他にも言いたいことがあるわけでして...
ポインタは、他の変数の
--- malloc()で確保した領域へのポインタや、関数へのポインタや、NULLポインタは?
アドレスを内容とする
--- p.137に書いたように、規格では「アドレス」と限定はしていないはず。
変数であり
--- だから、右辺値としてのポインタは?
Cでは頻繁に使用される。
--- うん、ここはそうかも。
まあ、K&Rは入門書なので、 リファレンスはともかく本文の方に厳密さを求めるべきではないのでしょう。
ひとつめの「他の変数の」というのは、 たいていはそうだという意味なのだとして(そうか?)、
ふたつめの「アドレス」というのは、 たいていの処理系ではそうだという意味なのだとして、
みっつめの、「変数である」というのは...
実は私はこれで悩んだ経験ってないのですけれど、 どうも周りの人の話を聞くとここで混乱した人はかなり多いようです。
これまたLeptonさんの「 闘わないプログラマ」のページからですが、 「 C言語講義」というお話の中にも同じ意味のことが、というか、 すみません私は上記文面を書くときにこれを意識してました。
時々、検索エンジンで「C言語 ポインタ完全制覇」で検索したりするんですが (自意識過剰?)、そうして見つけた日記ページで、
なぜ、参考文献に「エキスパートCプログラミング」が挙がってないの?
という疑問がありました。
はい。確かにWeb版「配列とポインタの完全制覇」の方には、
この辺について述べた書籍では、アスキーから出版されている 「エキスパートCプログラミング」が良書かと思います。 以下の文書も、この本の影響をかなり受けています。
なんてことが書いてあるわけですし、 実際本の方も内容的にかなり影響を受けています。
なのに、なぜ参考文献リストに挙がっていないのかというと...
参考文献リストは、原稿を書く際に、 「どこかで引用したら挙げていく」という方針で作成していきました。 「エキスパートCプログラミング」は、 確かに影響は受けていますが、たまたま引用する機会がなかったので、 リストに載りませんでした。
ただ、それにしても強く影響を受けているのは確かなので、 どこかでリストに入れようと思ってはいたのですが、 入稿間際のどたばたでうやむやになってしまいました...
もうしわけありません。
「補足(いいわけ?)」の目次に戻る | ひとつ前のページ | ひとつ後のページ | 「C言語 ポインタ完全制覇」のページに戻る | トップページに戻る