補足(いいわけ?)003

#include忘れについて(2001/5/29)

5/29日付でまた正誤表が増殖してしまいました。主に、サンプルソースの中で#includeが抜けているものがあったためです。ご迷惑をおかけしました。

さて、なぜこのようなミスが発生してしまったかなのですが。

私は、この本のサンプルプログラムをGCCでコンパイルしたのですが、 GCCにはいくつかbuilt-in functionというものがありまして、それらについてはコンパイラが特別扱いをしています。頻繁に使う関数についてインライン展開するなどの意図があるのでしょう。

GCCのマニュアルより:

  -fno-builtin
    Don't recognize built-in functions that do not  be-
    gin  with  two leading underscores.  Currently, the
    functions affected include _exit, abort, abs, allo-
    ca,  cos,  exit,  fabs,  labs, memcmp, memcpy, sin,
    sqrt, strcmp, strcpy, and strlen.

それはいいのですが、built-in functionについては、 -Wallオプションで警告レベルを上げても、プロトタイプ宣言がないときに警告を発しないのです。警告を出してもらうためには、-fno-builtinオプションを付ける必要があります。

おかげで、主にexit()やstrcpy()について、適切なヘッダファイルを #includeしないリストが掲載されてしまいました。

それにしても、List1-5でctype.hが抜けているのは謎ですが... コンパイル後、原稿に移した後で触ってしまったかも。

ご迷惑をおかけしたことと、対応が遅れましたことについてお詫びいたします。 4刷で修正予定です。

「体当たり～」の方は、bcc32も通してあるのでこの問題はないはずです。

ポインタ演算を使うとき(2001/8/27)

ちょっと古い話になってしまいますが、闘わないプログラマ」の2001/8/6掲載分「手抜き」に、以下のような記述があります。

話は替わって、Cのポインタの話で、ポインタ(特にポインタ演算)は出来る限り使わないようにしましょう、って考え方があります。出来る限り配列要素の形で表現しましょう、という。
まあ、ポインタはちゃんと理解して使わないと(理解して使っても?) バグの温床になりがちだし、無理に使う必要は無いのかも知れませんが、でも、ポインタを使うと、コードが短くなって見やすくなるんじゃないか、って場合もありまして…。
たとえば、こんなの
    for (i = 0; hogehoge[i].fuga[0] != '\0'; i++)
        printf("%s\n", hogehoge[i].fuga);
と、こんなの
    for (p = hogehoge; *p->fuga != '\0'; p++)
        printf("%s\n", p->fuga);
があったら、後者の方が見通しがいいから見やすくて私は好きだなあ… と思ったりするのですけど、この例だと大して差が無いですね。ううむ、いまいち例がよくなかったか ←でも、他の例を考えるのも面倒だからこのままにしておこう ←手抜き。

「C言語ポインタ完全制覇」では、「3-3-5 ポインタ演算なんか使うのはやめてしまおう」なんて章もあったりするわけで、私は、Leptonさんおっしゃるところの「ポインタ(特にポインタ演算)は出来る限り使わないようにしましょう、って考え方」を強硬に主張する一人であるわけですが (^^;

# 2001 8/31補足
# 「ポインタ(特にポインタ演算)は出来る限り使わないようにしましょう」
# と書くと、例えば木構造を作るときに、ポインタを使わずにでっかい配列で
# たくさん要素を確保して、添字をポインタ代わりにするようなのを奨励する
# かのように思われそうですね (^^;
# もちろん私もそんなのを勧めはしません。私の主張は、生のポインタ演算
# なんかやめてしまって、添字演算子というシンタックスシュガーを使うように
# しよう、ということです。

そんな私は、やっぱり上記の例だったら、文句なしに添字を使います。「先頭の文字が'\0'になるまでループする」という条件ですから、 [0]が登場するのは理に適っていると思うのですが、どうでしょうか。

特にこの例に関して言えば、Cの、「間接参照演算子が前置である」という欠点をもろにひっかぶってるように見えます。「*p->fuga」は、

「pの指す先にある構造体のメンバfugaの指すものをたぐり寄せる」

ことを意味するわけで、人間もコンパイラも

p, ->, fuga, *

という順序で解釈するはずです。なのに、*が前置であるせいで左から順に読めないわけです。

私なら、こういうのを書かなければならないのなら、せめて

*(p->fuga)

のように余計な括弧を付けます。これなら、「左から順に読めない」ことを読み手に明確に意思表示できるからです。

でも、どっちみち

*((*(p->fuga[0].hoge->piyo))->hehe)

あたりまでくると読みにくいんですけどね。

*がらみでこんなソースを書くことは、少なくとも私はまずありませんが、やむなく「ポインタのキャスト」を行なう時にキャスト演算子が前置であることに頭を抱えることはちょくちょくあります。

で、「ポインタ演算を使った方がすっきり書ける例」としては、ひとつには、「ポインタ完全制覇」の中でも触れている

たとえば、「巨大なcharの配列に、いろんな型のデータが無理やり突っ込んであって、その中から何バイト目のデータを取り出したい」という場合、ポインタ演算を使った方が(まだ)読みやすい

という場合があるわけですが、他の例として、こんなのはどうでしょうか。

設定ファイルなど、一定の書式に従ったテキストファイルを読みこむ。

そのファイルの書式は、「行頭の空白は無視する」ことになっている (インデントして見やすくするため)。

こういう場合なら、以下のようにポインタ演算を使った方が良いかもしれません。

  char buf[1024];
  char *line;
  ･･･
  /* 行頭の空白を無視する */
  for (line = buf; isspace(line); line++)
      ;

  /* 以後は、lineが配列であるかのように使える */

これをポインタ演算なしで書こうとすると、以下のように別途ループカウンタを導入しなければなりません。

  char buf[1024];
  char *line;
  int  i;
  ･･･
  /* 行頭の空白を無視する */
  for (i = 0; isspace(buf[i]); i++)
      ;
  line = &buf[i];

  /* 以後は、lineが配列であるかのように使える */

これはこれで別に問題ないような気もしますが... この程度のことでローカル変数をひとつ増やすのは嫌だというのもわかります。

結局、配列を「まともな配列」として使う限りにおいてポインタ演算は不要だが、「まともな配列ではできない裏技的な使い方」をする場合には、ポインタ演算を使ったほうがすっきり書けることがある、ということのような気がします。

Javaのホワイトペーパー

http://java.sun.com/docs/overviews/java/java-overview-1.html

では、「Instead of pointer arithmetic, Java has true arrays.」つまり、「Javaにはポインタ演算なんていい加減でアブない機能の代わりに、ちゃんとした本当の配列があるんだぜい。すごいだろ」(意訳)と誇らしげに書いてあるわけですが、こういう「まともな配列」では、「ポインタlineを適切な場所に向けてやって、以後lineをまるで bufの部分配列であるかのように使う」というような器用な操作は出来ません。

Cの「配列とポインタの妙な交換性」のおかげでこういう妙な技が使えるわけで、これはこれで柔軟で良いと思います。「分かって使う」という限定条件がつきますが。

そういう技を使う場合には、ポインタ演算が便利な場合もある、ということなのではないかと。

それから余談ですが、Leptonさんのページには、他にこんな記述もあります。

この「strcat」でつなげて行くやりかた、ってよく見受けられるんですけど、こういうコーディングする人の考え方、っていったいなんなんでしょう。分かりづらいし、メンテナンスしづらいし、冗長だし、「sprintf」でも使った方がずっと便利だと思うんですけどね。
あ、でも、噂で聞いたことがありますけど、「printf」系の関数は遅いから一切使用禁止ってコーディング規則の会社がある、って聞いたことがありますけど、もしかしてその類?

「単に知らない」に一票。

こういうことは、K西さんの入門書には書いてありませんでした。「C言語体当たり学習徹底入門」にはもちろん書いてありますが:-p。

で、知らないことは要るときに調べればよいのですが、たいていの人にとって、printf()と言えば「画面表示の関数」だと思います。 K&Rのリファレンスを見ても、sprintf()は「B1.2 書式付き出力」の項に入れられています。

それでは、やはりstring.hの関数群を先に見付けてしまうでしょうし、それでとりあえず動作するプログラムが書けるなら、「これでいいや」になっちゃうプログラマが大勢いるわけでしょう。

暇なときに、ライブラリのリファレンスをぼーっと眺めるとか、そういうことが重要なんでしょうね。ま、私の場合、バグが取れずに鬱になっている時の現実逃避のネタとして眺めることの方が多かったりするわけですが(^^;。

あとは、「printf()の本当の機能は何なのか」をちょっとじっくり考えてみるとか。

「画面に数値を表示する」ためには、数値の文字列表現を作らなければならないはずだ。
そういえば、%dみたいなもののことを、 K&Rでは「変換仕様」と呼んでるな。この「変換」とは、数値を文字列に変換するってことか。
数値を文字列に変換するのは結構ややこしい。だとすると、printf()のソースは、その大半が各種の「文字列に変換する機能」で占められているはずだ。
数値などを文字列に変換するという用途は、画面表示に限らず存在するはずだ。
ということは、ライブラリの設計者としては、せっかく作ったややこしい文字列変換機能を画面表示だけに限るのはばからしいと考えるはずだ。
よって、printf()の文字列変換機能だけを使える関数があってもよさそうなものだ。

と、こういう思考の経路を辿れば、すぐに sprintf()に行き着くんじゃないかと思うんですが、どうでしょうか。

まあ、それ以前に、職場にsprintf()を教えてくれる先輩がひとりもいないってのはちょっと悲しい気がしますけど。

「補足(いいわけ?)」の目次に戻る | ひとつ前のページ | ひとつ後のページ | 「C言語ポインタ完全制覇」のページに戻る | トップページに戻る