場合 - みる会図書館


検索対象: 月刊 C MAGAZINE 1990年5月号
102件見つかりました。

1. 月刊 C MAGAZINE 1990年5月号

変化に対して無神経だと思われる。もっと なんの役にも立たない。直感に頼るか , プ インディングをて、きるだけ遅らせたほうが 悪い場合には , 変更箇所が拡散していてど ログラム文を正しく読み込むかして , どこ よい。実力がついたら早めにバインディン こだかわらないこともある。 て、変更が必ず発生するかを探し出さなくて グしなさい。エキスパートとしての直感を はならない こういう場合にこそ抽象化とカプセル化 信用しなさい の協同作業の舞台がある。数値に名前をつ 次に , その変更をほかの部分から明確に 隠蔽する。そうしておけば変更が与える影 適と不適切の違い ければ , 変更可能な数値をコード中の 1 か 響について , コードを広範囲に渡ってスキ 所に閉じ込められる。ばかげたことて、はあ ャン ( 目や , grep て、 ) する必要がなくなる。 るが , 同じ定義を別々にコンパイルするモ 最初のガイドライン中にある次の重要フ カプセルを囲んて、いる壁が黒て、なく透明だ ジュール中にばらまくことも可能だ。幸運 レーズは、、たった唯一の〃 ったら , カプセル化は意味をなさない。 にも , そうすると正しい方法に比べてさら 変更箇所を複数にするいどれかひとつ 第 2 のガイドラインは , 「痛み ( 不便さ ) に仕事量が増えることになるが・・・ を見落としすることがて、てくる ( たとえあな を感じ始めるまて、は情報へのアクセスを制 最後の重要なフレーズは、、適切な場所〃。 たが見落とさなくても , 次に保守する人が 限する」こと。ほかの部分に与える影響を 見落とすだろう ) 。どこにも変更する箇所が 変更が局所化されていることがわかってい まったく心配しないて、 , プログラムを変更 ても , 正しい場所がどこかわからなければ ないとすれば , あなたのプログラムは環境 16 CMAGAZINE 19 5

2. 月刊 C MAGAZINE 1990年5月号

『 EncapsuIate it 』 COMPUTER LANGAUGE Dec. 1989 Written by P. J. PIauger 野口修男訳 / 福富寛監訳 カプセル化のすすめ す。カプセル化もシンカレです。カプセル化には , 私が思っていたほどには知ら ことをレビューしてみました。今月はそれに関連したトピックス , カプセル化で の半匠くを侮辱する覚語で ( そういう方がいらっしやるでしよう ? ) 当たり前の らよいのかわかっていません。方法さえ知らない人もいます。このコラムの読者 ン』 1990 年 4 月号 ) 。それにも関わらす実践的プログラマは , いつ抽象化を導入した にとって基礎知識を含んだシンカレなトピックでした ( 「抽象化のすすめ」『 C マガジ 先月号ではデータ抽象化の基本原理について解説しました。プログラミング作業 れていない知恵があります。かくしてレビューは続きます。 カセル化と抽象化 抽象化とカプセル化は同じ意味て、はない 抽象化を導入しながら , それをコードのあ ちこちに分散させること ( 訳注 : 散らばすこ とはカプセル化の反対 ) も可能だし , 逆に抽 象化をまったく使わずにカプセル化するこ とも可能だ。 どちらにしてもプログラムの 保守に役立っことになるのて、 , 一歩前進す 14 CMAGAZINE 19 5 しかし , このふたつをいっしょに使うこ ともよくある。変更されそうなコードを 1 モ ジュールに詰め込んて、内部構造を隠し , イ ンタフェイスを定義するのに必要な型や名 前つき定数 (named constants) を導入する ことがある。この場合は , 抽象化とカプセ ル化は相互に助け合う。 もちろん , 何から何まて、カプセル化する のは不可能て、あり , また , 行うべきことて、 もない。実行文の 1 行 1 行のすべてが関数 コールて、て、きているプログラムを想像して みよう。このようなプログラムて、は大量の 単純な関数が離れた場所にあり , おのおの の関数中にはひとつの実行文だけがあるこ とになる。 あるいは式中の 1 語 1 語すべてが関数コ ールの場合を想像してみてほしい。このケ ースて、はさらに大量の単純な関数があり , おのおのが定数値かデータオプジェクト値 をリターンすることになる。 これらふたつの場合て、は , 変更の可能性 のあるものはすべて注意深くカプセル化さ

3. 月刊 C MAGAZINE 1990年5月号

五ロ 用 応 Fig. 4 = KAN 』 1 のとき type = Fig. 1 ANK を格納 カーソル位置 ↓ ANK カ - ソル位置 ↓ 2 漢字第 1 ノヾイトの場合 第い第 2 空白 ( クリア カ - ソル位置 xx 第 1 第 2 3 漢字第 2 ノヾイトの場合 空白てクリア ( 1 ) ANK の場合 カーソル位置 ↓ 第 1 第 2 空でクリア 空白 AN K → 第 1 空白 ここへ文字を格納する ↓ 空白 AN K ー→ Fig. 2 漢字第 1 バイトを格納 Fig. 5 ctype==KANJ12&&nxtype==KANJ11 のとき 設定した漢字第レヾイト カーソル位置 x x 第 1 第一第 2 カーソル位置 xx ANK ? ? カーソル位置 2 漢字第 1 バイトの場合 x x 第 1 , 第 2 ( 1 ) ANK の場合 第巳ノヾイト用工リアもチェック 空白てクリア 第 1 第 2 → 第 1 第 1 空白 x x ここへ第 2 バイトを格納する カーソル位置 3 漢字第 2 バイトの場合 第 1 第 2 ? ? 空白でクリア x x 空白 第 1 ? ? → 第 2 ノヾイト用のエリアもチェック Fig. 3 漢字第 2 ノヾイトを格納 Fig. 6 tYPe==KNAJ12&&ctype!=KANJ12 のとき カーソル位置 第 1 第 2 空てクリア 第 2 ノヾイト用工リア 第 1 ANK ( 1 ) ANK の場合 第 1 第 2 第 2 バイト用工リア 2 漢字第 1 バイトの場合 第 1 第 1 第 2 空白 第 1 第 2 空白 ここへ第 1 バイトまたは ANK を格納する ただし . カーソルの前の文字が格納した第 1 バイトの場合を除く 設定した漢字第 1 ノヾイト カーソル位置 xx 第 1 第 2 ここへ第 2 バイトを格納する 空白でクリア 第 2 バイト用工リア 3 漢字第 2 バイトの場合 第 1 第 2 第 1 第 2 103 応用 C 言語

4. 月刊 C MAGAZINE 1990年5月号

S e c t i 0 n Ⅳ C の将来 FUTUER OF STANDARD C ヾは , スタンダード C の将来について説 明してみたいと思います。 これまて、 C がどのように使われてきたか , そして C の競争相手がどのようなものて、あっ たかということから話を始めたいと思いま す。 今や C は圧倒的な地位を誇っている面があ ります。ノンニューメリックのプログラム , そしてシステムプログラミングて、は , 圧倒 的になっています。組み込みシステムにお いても , 長年 , 重要な地位を占めてきまし た。また , 汎用のアセンプリ言語 CUniversaI assembly language") としても重要な役割 を担っています。 こうした分野て、は , C は非常に重要な地位 を占めており , 競争相手がない状態て、す。 汎用アセンプリ言語 は , 汎用のアセンプリ言語として C が 使われている場合に注目して説明し ていきます。 私は , いろいろな大きなプログラムカ℃コ ードを出力することから , C を汎用アセン プラと呼んて、います。たとえば非常にハイ レベルの言語やアプリケーションシエネレ ータなどが C を中間コードとして使ってい ます。さらに , C コードを出力する CASE ツ ールやほかの言語 , たとえば Pascal や PL/M や LISP などの言語から C へのトランスレー タが出てきています。 長年かけてこのような作業をやってきた 66 CMAGAZINE 19 5 慣習的使用 ことには理由があります。コンヒ。ュータの 多くカ℃のコンパイラをもっているというこ とも , そのひとって、す。過去数年間 , C コン パイラの技術が大幅に伸びてきていること も見逃せません。こういったことから , C コードを作成しないようなアプリケーショ ンは考えにくくなってきています。 C コンパ イラが間題を解決してきましたし , しかも 重要な点て、間題を解決してきたことが , そ の背後にあります。 こうした現象はさらに出て 将来的には , くると思います。 はアセンプリ言語の伝統的なライバ ルて、す。今日て、は , C て、は実現しにく い特別のパフォーマンス ( たとえば CPU の 特別の機能を利用するといった ) を得るた めにアセンプリ言語を使っています。 しかしながら , アセンプリ言語て、はなく C を使った場合のパフォーマンス上の問題点 は , かなり削減してきています。また , ア センプリ言語て、書いた場合の生産性の減退 , 損失についても理解が深まってきています。 ほんのちょっとした性能を引き上げるため いつもアセンプリ言語て、書くことは , それだけの意味がない場合もあります。 コンパイラの技術については , 今後も引 きつづき進歩していくと思います。アセン プリ言語よりも , コンパイラのほうて、より 優れた結果が出るのは , もう時間の問題だ と思っています。もちろんアセンプリ言語 の必要性が消えるわけて、はありませんが , アセンプリ言語が使われるのは , 小さなプ C vs ASSEMBLY LANGUAGE ログラムを書く場合て、あって , 大きなプロ グラムを書く場合のアセンプリ言語の必要 性は今後ますます減っていくて、しよう。 CvsC 十十 十十は , C にとって現在 , 最大のライ C vs ADA ことになると思います。 ますます C 十十に似た性質を C が帯びてくる 次に出てくるスタンダードを比べてみると , になると思います。現在のスタンダードと C は , より C 十十の性格を備えていくよう よう。 大半は , ここ数年間は C を使いつづけるて、し ら , 現在 , C て、プログラミングする人たちの り C 十十に傾いていくて、しよう。しかしなが す。て、すから , 先進的なプログラマは , よ そのメリットが得られないケースもありま てメリットが得られるものもありますし , ありません。もっと C 十十を使うことによっ けません。その疑間に対して単一の答えは ットが得られるかどうかを考えなければい C 十 + に新たに払う価格に見合うだけのメリ 得られないこともあります。したがって , のプログラムて、は C ほどのノヾフォーマンスが より複雑だということて、す。さらに , C 十十 ります。というのは , 勉強していくうえて、 , しかしながら , C 十十に伴う懸念材科もあ っています。 の場合は , 名前空間にいくっかの構造をも 名前空間も大きなものが得られます。 C 十十 ェクトを扱う能力を有する点て、す。また , よりも優れている点は , より大きなプロジ っている分野があります。 C 十十の場合 , C いくっかの点て , C 十十のほうが C を上回 していくことも可能て、す。 て、書いて , 少しずつ C 十十にトランスレート C からの上位互換て、あることが原因て、す。 C バルて、す。それはほとんどの場合 ,

5. 月刊 C MAGAZINE 1990年5月号

工ル・エス・アイジャパン 0 「 m 面 00 from (ompiler ma 「 5 LSI C -86 LSI C -80 今回はわかりにくいコンパイル 工ラーやコーディングミスのなか て、 , とくに多い質問を集めました。 0 Warning . function assumed printf' undefined to be int なというコン′くイ ) レエラ ーがでるのですが。 A 未宣言の関数を呼び出すとこ のエラーがてます。 printf のよう なライプラリの場合は各ライプラ リのプロトタイプ宣言がヘッダフ ァイルに入っていますのて , 必要 なヘッダファイルをインクルード (#include) してください また , ライプラリてない場合は プロトタイプ宣言が必要になりま す。同一ソース内に関数が定義さ れていても , 参照よりも下に関数 が定義されている場合はこのエラ ーになります。どうしてもこの工 ラーがうるさいという場合は , -w オプションて、エラーメッセージが てなくなります。 Q&A List 1 0 以下のソースで•Warning illegal pointer combination ( = ) ″というコンパイルエラーが でるのですが。 char * p; p = 0X8000 ; ポインタと整数間の代入また は比較を行うとこのエラーになり ます。この場合は以下のようにキ ャストします。 (char * )Ox8000; 0 ー v a ー u e 「 e q u i 「 e d (XXX)& というコン′ヾイルエラー がでるのですが。 代入て、きないものに代入演算 子または & 演算子を摘要した場合 にこのエラーになります。とくに 以下のように , 誤って配列名に & 演 算子をつけるとこのエラーになり 将来的にはこの警告ェラーのみ を出力しないように指定する -wi オ プションをサポートする予定てす。 A P A ます。 Char X gets(&x); [ 128 ] ; ② " ・ #def i ne ABC ABC) printf("hello, worldYn") : : testl. Obj test. exe lcc -0 test. exe testl. Obj getchar()) { switch (c printf(" 改行 Yn"); break: defalt: putchar(c) ; break; 0X10 : getx(n + + ) ー (getx(n) くく 8 ) : #code= 0 #data=8000 test. hex tck test -froml ib #CODE= 0 #DATA=OAOOO test. hex tck test - f 「 0 引 ib #CODE= 0 #DATA=AOOO test. hex tck test -froml ib 0 List ト①のソースの if 文の行で syntax e 「「 0 「 near tax error near ' ) ' ″とし、うコン / ヾ イルエラーがでるのですが。 A もちろんこれは # define の最 後の、、 ; 〃が不要なのて、す。 # define 文がエラー箇所の近くにあればす ぐ気づくのて、すが , ヘッダファイ ルのなかにある場合や #define は 、、 ; 〃が必要だと思い込んて、いる場 合には , なかなかまちがいに気づ かないものて、す。 0 List1—②の makefile で make をかけたら•missing after に c ″というエラーになるのです が。 lcc の行の先頭がタブてない と , このエラーになります。タブ がないと make が正しくコマンド行 を認識て、きません。ェデイタてフ ァイルをセープするとき , タブを スペースにかえるように設定して ある場合は注意が必要て、す。 0 List1- ③の switch 文の default が実行されないのですが。 A defalt のつづりが誤っていま す (default が正しい ) 。この defalt は switch 文の default< はなく , 一度も参照されないラベルになり ます。したがって本当の default の A とき何も実行されません。 0 ListI ー④のソースが正しく実 行されないのですが。 A getx(n 十十 ) と (getx(n) くく 8 ) のどちらが先に評価されるかはコ ンパイラによります ( K & R 「プログ ラミング言語 C 』参照 ) 。したがっ て getx ( n 十十 ) が先に評価されると はかぎりません。このような場合 は , 以下のように 2 行にわけて評価 の順序を明らかにします。 getx(n 十十 ) ; X x ー = getx(n) くく 8 ; 0 LSI C ー 80 で List ト⑤のコマン ドファイルを与えて knil でリンクす ると•syntax e 「「 0 になるので すが。 A ROM や RAM の先頭配置は 16 進数て、指定するのて、すが , 先頭の 文字が数字て、ないとこのエラーに なります。 List ト⑥のように修正し ます。 0 LSI C ー 80 で凵 5t1 ー⑦ ) のコマン ドファイルを与えて knil でリンクす るとエラーにはならないのですが , 正しく配置されません。 A knil て、は ROM や RAM の配置 を指定する code, data は大文字て、 ないと正しく認識しません。つづ りをまちがえても同じ結果になる のて , マップファイルを出力して 配置を確認してください 152 CMAGAZINE 19 5

6. 月刊 C MAGAZINE 1990年5月号

iO れ 5 , 0 れ d P 「 og 「 am Extensibility Obiects,Fu システムに新たなデータ型を追加する場合 構造化設計の場合に追加される関数がすべ て、あり , さらに内部の部分構造が互いに微 て含まれることになるだろう。個々の手続 妙に関連しあっている。したがってオプジ は , それぞれのトランザクション用のメソ き的な断片の総数と , 新たな関数のインプ ッドをサポートする新たなオプジェクトモ ェクト構造のケースて、は , 第 2 のコスト要因 リメントに必要なコード量は , 同じてはな はモジュールべースて比較するとかえって ジュールを , たったひとっ書くだけて、ある。 いとしても , 似たようなものだろう。オプ 厳密にいうならば , 少なくともあと 1 か所の 高くなることもあり得る。しかし場合によ ジェクト構造のインプリメンテーションて、 変更が必要て、ある。つまりその新オプジェ っては , この点はすべての変更がコードの は , システム全体のモジュール数が少ない 一部分 ( 単一のオプジェクトモジュール ) に クトへの条件参照が少なくともひとつ , シ ステムのどこかにないと , システムは新た ( したがって選択の幅も少ない ) こと , すべ 局所化されていることによって , 償われる なデータ型を正しく扱えないからて、ある ての新たな機能を 1 か所にインプリメントて、 こともある。 きること , そしてたぶん , システム内のさ トランザクション中心の構造設計に新た (Fig. 10 ) 。 オプジェクトによる構造化のアーキテク らにあと 1 か所だけを変更すればよいことな なデータ型を追加するためには , そのデー チャは , 拡張がより容易て、あるようにみえ タ型に対する有効なトランザクションごと どを考慮に入れるべきて、ある。 たったひとつのモジュールの 新たなコードの量がほば同じて、も , 変更 に , 新たなモジュールを作らなければなら る。つまり , 箇所の確定に要する時間の節減効果は , 相 ない (Fig. 9 のアミ部分 ) 。トランザクション 追加とひとつの変更て、すむのに対して , 関 当なものになるだろう。 Meyer [ 8 ] , R Wirfs モジュールのそれぞれを変更して , 追加さ 数による構造化の場合には 3 つの追加と 3 か -Brock と B. WilkersonC16] が指摘している 所を変更しなくてはならないからて、ある。 れたデータ型に対応て、きるようにしなけれ ように , 健全なオプジェクト指向設計によ しかしながら , この場合のオプジェクトモ ばならない ( Fig. 9 の斜線部分 ) 。これらのモ れば , ひとつのオプジェクトモジュールが , ジュールは複雑な ( 複数の ) モジュールの複 ジュールの本体はわずか 1 行の CASE 文て、あ 10 個から 20 個のメソッドをサポートする。 合体になるだろうし , 新たなオプジェクト り , また必要な変更も , CASE をひとつ追加 したがってオプジェクト指向の構造を構成 の内部的部分構造には , 分解の程度とレベ することて、ある。 するモジュールの数は , 同等の関数構造設 ルが ( 関数構造の場合と ) 同等て、あるならば , これとは対照的に , オプジェクト構造の Fig. 8 オプジェクト構造によるトランザクションの処理方法 X-OBJECT のろ テかと スこの シど別 Y-OBJECT F-METHOD G-METHOD H-METHOD Z-OBJ ECT F-METHOD G-METHOD H-METHOD F-METHOD G-METHOD H-METHOD 何らかの条件つき参照が行われる 30 CMAGAZINE 19 5

7. 月刊 C MAGAZINE 1990年5月号

以上の項目 , またそれに関連する事項に ついて明確なご意見 , ご要望がありました ら , C マガジン編集部「 Project Pragma C 」係まて文書てお寄せください。 プログラム編ロ ] まず連載第 1 回として , Project Pragma C の各種プログラムが対応する動作環境を定 義します (Tbl. 7 ) 。 基本的には , 以上の条件を満たすすべて のマシンに対応していく予定てすが , 実際 の使用においては , 数 M バイトの RAM ディ スクまたはハードディスクを使用するほう が効率的になるかもしれません。 CSP:C Souse Print UtiIity csp は , C 言語ソースファイルの表示 / 印刷 を行うためのユーティリテイプログラムて、 す。ソースファイルをただ表示したり , 印 刷したりするだけては , TYPE コマンドや PRINT コマンドとなんら変わりないのて , 以下のような仕様をもたせます。 * 処理対象を C 言語ソースファイルと特 定し , 語句の解析を行う * 解析結果をもとに , 語句を以下のグ ループに分類し , 差別化して表示 / 印 刷する 1 命令 , 指定子 , プリプロセッサ命令 2 句読点 , 演算子 3 定数 , 文字定数 , 文字列 4 注釈 5 そのほか * 差別化は , 画面に対してはカラーで , プリンタに対しては強調などの属性 で行う * 解析結果をもとに , スペーシング , オートインデントなどの整形処理を 施す csp は ,PragmaC のプロジェクトの一貫と してのユーティリティてすが , ANSI 規格に 準拠して作成されたほとんどのソースリス トを処理することが可能てす。 ース ース 50 CMAGAZINE 19 5 本連載を開始するにあたって , あらかじ TbI.8 csp. c のオプションスイッチ 出てきますが , ANSI 規格の宣伝記事で * AN 規格についての言及 / 引用が多数 いっさい使用しません。 もあります。また , yacc などのツールは 的とはいいがたい手法を採用する場合 方教室ではありません。よって , 正統 * 本連載はコンバイラの ( 正しい ) 作り ん。 思われる場合を除き ) 解説を行いませ が , その内容については ( とくに必要と 要素についての定義は行っていきます したものではありません。 C 言語の構成 * 本連載は C 言語の解説 / 教育を目的と め次の点をおことわりしておきます。 はありません。 本プロジェクトにおいて , 作成しなけれ ばならないプログラムの量は , ソースファ イル ( 数 100 ~ 1000 行として ) 単位で計算して 約 100 ファイル , ライプラリの個々のファイ ルを含めると約 400 ファイルとなります。単 純計算でも約 20 万行程度の作業量が必要と なってしまいますので , 予定した順番が移 動したり , 休載となってしてしまうことが あるかもしれません。このような場合には おおめに見ていただき , こ・了承ください。 また , そのような事態におちいらないため にも , 読者の皆さんのご協力をお願いいた します。 -s -v ソースファイルの空白 / タブを無効とし , 解析情報をもとにしたオートスペーシング , インテン ト / アンデントを行い , 整形した形で出力を行います プリンタに対して出力を行います すべてのエスケープシーケンス操作を抑止し , 通常の ASC 日テキスト形式で処理を行います ファイル名を標準入力から読み込みます。 このオプションが指定されると , csp はファイル名の入力を標準入力に対してリクエストし , 入 力があった場合には該当するファイルに対しての処理を行います。この動作は , プランク行が 入力されるまで繰り返されますので , 複数のファイルをつづけて処理したい場合などに有効で す。また , 大量のファイルの印刷を行いたい場合などには , ファイル名を列記したテキストフ ァイルを用意しておき , I/O リダイレクトと併用すると非常に効果的です CSP 内で行われている語甸解析情報を出力します csp の起動は ,DOS のコマンドレベルから csp C-flags] filename 次の書式て、行います。 CSP -a -S -P CSP. c 以下のようになります。 ASCII 形式てプリンタに出力する場合には , ことも可能て、す。例として , 整形を行い , これらのフラグは , 同時に複数指定する に示すものが用意されています。 また , オプションスイッチとしては , Tbl. 8 CSP CSP. C す。 ト csp. c を表示する場合には次のようにしま 例として , このプログラムのソースリス プログラムの構成 csp のプログラムは , 以下のファイルから 構成されています。 語句解析ルーチン用へッダ cctoken. h csp メインプログラムソース CSP . C C 文字タイプ判定ルーチン用ソ cctype. C C 文字タイプ判定ルーチン用へッダ cctype. h 語句解析ルーチンソー cctoken. C ス •csp. c csp. c は , csp プログラムのメインソ

8. 月刊 C MAGAZINE 1990年5月号

README を参照ください 追記 csp のプログラムそのものは ( この手のも のとしては ) , 非常に単純な構成となってい ます。もし , 冗長な部分があるとしたら ANSI 規格 ( または最近の仕様 ) に適合させるため の部分て、しよう。とくにワイド文字関連の 接頭子処理は , いささか取ってつけたよう な感じがするのはいなめませんにれは規格 自体も同じだと思います ) 。 今回は , プログラムの細部についての解 説はしませんてしたが , ソースリストをた どっていただければ , ほとんど理解してい ただけると思います。姑息な手法やトリッ クなどはいっさい使用していないのて、 , 単 純な語句解析の例題となるかと思います。 実際 , このプログラムは , ひとつのユー ティリテイプログラムとしてとらえるより これらは , csp. c の冒頭て、定義されていま PC ー 9800 シリーズ ( カラーディスプレイ ) も , コンパイラのプリプロセッサやパーサ すのて、 , 画面の表示色を変更したい場合や , ーを作る前の練習課題と考えてもらったほ FM-R シリーズ ( カラーディスプレイ ) うがよいかもしれません。あと数百行程度 工スケープシーケンスの異なるマシン / プリ CSPA. EXE は , モノクロ画面用の csp 実 ( 数式処理と語句展開 ) を加えるだけて簡単 ンタを使用したい場合などには , このマク 行型プログラムファイルて、す。以下のマシ ロ定義を書き換えて再コンパイルしてくだ ンに対応します。 なプリプロセッサに仕立てあげることも可 PC ー 9800 シリーズ 能て、す。同様にシンタックスチェッカとす ( モノクロディスプレイ ) ることも可能て、しよう。 例として , 画面出力時に予約語のみを反 FM ー R シリーズ ( モノクロディスプレイ ) 次回はスタンドアローン型のプリプロセ 転表示させる場合の定義方法を Tbl. 13 に示 J ー 3100 シリーズ ッサを発表する予定て、す。 します。 IBM PS155 シリーズ ティスクの内容 そのほかのファイルの詳細については , 以下のファイルが付属ディスクに格納さ れています。 P 「 agmaC 委員会読者委員募集 YPRAGMAYREADME CSP. EXE 「プロジェクト P 「 agmaC 」は , まったく新し P 「 agmaC 制作委員会読者委員を選考さ CSPA. EXE い C コンパイラの制作を目的とするとと せていただき , 読者代表の PragmaC 制作 もに , その制作にあたって広く読者の皆 主要メンバーとして参加していただく予 CSP. C さんと協議 , 意見交換することをも目的 : 定です。 CCTOKEN . H としています。つきましてはご意見 , CCTOKEN . C 要望を文書 , または FD にて下記「プロジ : 宛先 CCTYPE. H ェクト P 「 agmaC 」係までお寄せください。 CCTYPE. C お寄せいただいたこ・意見は可能なかぎり 東京都千代田区九段南 2 ー 3 ー 26 井関ビル CSP. EXE は , カラー画面用の csp 実行型 日本ソフトバンク C マガジン編集部 P 「 agmC 制作に反映してまいります。 プログラムファイルてす。以下のマシンに 「プロジェクト PragmaC 」係 さらに , ご応募された皆さんのなかから , 対応します。 TbI. 12 動作モードに応じて以下に示す工スケープシーケンス画面出力の場合 画面出力の場合 #defi ne CRTCOLORO \ 33 [0m" #define C RTCO LO R 1 \ 33 [ 36m ' #define \ 33 [ 32E ' C RTCO LO R 2 #defi ne \ 33 [ 33m ' CRTCOLOR3 ' \ 33 [ 34m ' #defi ne CRTCOLOR4 f-r ー 印刷出力の場合 #define PRNCOLORO ” \ 33 \ ー #define PRNCOLORI #defi ne ” \ 33 \ ド PRNCOLOR2 PRNCOLOR3 #defi ne ' \ 33 \ " #define PRNCOLOR4 ' \ 33 \ " TbI. 13 画面出力時に予約語のみを反転表示させる場合の定義方法 CRTCOLORO #define CRTCOLORI #defi ne CRTCOLOR2 #define CRTCOLOR3 #define CRTCOLOR4 #define \ 33 [0m ' ' \ 33 [7m ' \ 33 [0m ' ' \ 33 [0m ' ' \ 33 [0m ' プロジェクト PragmaC 53

9. 月刊 C MAGAZINE 1990年5月号

イロ入 putc ー機能要約ストリームに 1 文字出力 ( マクロ定義 ) #include く stdio . h 〉 ■用法 putc (), stream) ; ■引数 intc 書かれる文字 : ファイル構造体へのポインタ FILE * stream ー戻り値 int . 書き出した文字 ・エラー int EOF ■注意 EOF がエラーによるものかどうか調べるには , fe 「 ror を使用 fwrite ■機能要約データ ( 指定バイト長 ) を特定数だけストリームに書き込む #include く stdio . h 〉 ■用法 fwrite ( buffer, size, count, stream ) ; ■弓ー数 const void * buffer : データを格納している場所へのポインタ Size t Size : データ項目ひとつ当たりのバイト数 Size t : 書き出す項目の最大個数 FILE * stream : ファイル構造体へのポインタ ー戻り値 size t : 実際に書かれた全データ項目の個数 ( バイト数ではない ) ・エラー size t : 戻り値が count より小さくなる ー注意 stream のファイルポインタは実際に書いたバイト数だけ進む。 st 「 eam が テキストモードでオープンされている場合は , 復帰 ( CR ) を復帰 / 改行 ( CR / (F) で置き換えるが , この置き換えによる戻り値への影響はない。工ラ ーが発生した場合 , アクセス位置インジケータの値は参照できなくなる fputc ・機能要約ストリームに 1 文字出力する #include く stdio . h 〉 ■用法 fputc( c, stream ) ; ■引数 int c : 出力する文字 FILE *stream : ファイル構造体へのポインタ ー戻り値 int c : 出力した文字自身 ・エラー : 工ラーか EOF ( という値 ) かを判定するためには , fer 「 or int EOF を使用する ■注意 fput, fputchar は putc, putchar と似ているが , マクロ定義ではなく関数で ある getc ・機能要約ストリームから 1 文字読み込む #include く stdio . h 〉 用法 getc ( stream ) ; ■引数 FILE *stream : ファイル構造体へのポインタ ■戻り値 int : 読み込まれた文字 : ファイルの終わり int EOF ・エラー int EOF ・注意工ラーかファイルの終わりかを判定するには , ferro 「関数または feof 関数 を使用する。 getc は関数ではなくマクロとして定義されている rewind ・機肯皀要約ストリームのファイルポインタをファイルの先頭に移動する #include く stdio . h 〉 ・用法 rewind( stream ) ; ・引数 FILE *stream : ファイル構造体へのポインタ ・戻り値 void ■工ラーなし ■注意 fseek( stream, OL, SEEK SET ) とほば同じ ( EOF やエラ ーのインジケー タをクリアする。戻り値がない ) fgetc ー機能要約ストリームから 1 文字読み込む #include く stdio . h 〉 ー用法 fgetc ( stream ) ; ・引数 FILE *stream : ファイル構造体へのポインタ ー戻り値 int : 読み込んだ文字自身 : ファイルの終わり int EOF ■工ラー int EOF : 工ラーかファイルの終わりかを判定するためには , feof または fe or を使用 ■注意 fgetc, fgetchar は getc, getchar と似ているが , マクロ定義ではなく関数 である setbuf ー機能要約ストリームのバッフアを変更する #include く stdio . h 〉 ー用法 setbuf ( stream, buffer ) ; ■引数 FILE * stream : ファイル構造体へのポインタ : ユーザが割り当てたバッファ ( NULL の場合にはバッ char * buffer ファ化しない ) ■戻り値 void ■工ラーなし ■注意 stderr と stdaux はデフォルトではバッフアがないが , これによりバッファ 化が可能 C プログラマのためのランタイムライプラリ入門 85

10. 月刊 C MAGAZINE 1990年5月号

れている。 の複雑さに圧倒されてしまう しょにするものをまちがえると , 絡み合い かを簡単にチェックしたい。しかし , いっ タの値と同意語 ) や機能のうち , どれがない ステートとは , 現在の値を意味する。デー とめにし , ステート ( 訳注 : オプジェクトの 関連するコードとデータすべてをひとま ■完全性 (completeness) が増え , 保守にとまどう ものどうしが何らかの依存関係をもっこと ) の結合 (coupling, 訳注 : 本来 , 関連の薄い め方をひとつまちがえれば , モジュール間 い部分をはっきりさせたい。しかし , まと プログラム中て、相互関連の強い部分と弱 ードキュメント化 (documentation) すぎるとパフォーマンスは劣化する 変更から保護したい。しかし , 「壁」を作り プログラムコードを将来起こるて、あろう ■隔離 (insulation) てみる。 ける 3 つの目的の長所と短所を簡単にまとめ とにかわりはない。以下にカプセル化にお 短所になってしまう危険をはらんて、いるこ 要度は異なるが , 一歩まちがえれば長所が 象化とカプセル化とて、は , それぞれ 3 つの重 の目的は同様に重要て、ある。もちろん , 抽 が , カプセル化においても前号て、挙げた 3 っ 前号て、は「抽象化の目的」を 3 っ挙げた ことが明確に理解て、きるだろう。 けては完璧なプログラムへの道につながら このことからも , カプセル化それ自体だ それどころか必ず事態を悪化させる。 らないし , 読みやすくもならない。 るだけて、 , プログラムの保守が容易にもな グラムのサイズと実行時間が急激に増大す このようなとんて、もない方法て、は , プロ の可能性と直感 以上のようなゴールを念頭に置き , ガイ ドラインのいくつか見てみよう。 第一のガイドラインは , 軟にて、きるものを発見することて、ある。可 ントのうち , そのプログラムをもっとも柔 ドすることがて、きる上述のいくっかのポイ ログラムがそれを使う際の名前とをバイン プログラマとしての仕事は , ある値とプ 値を変更したい場合さえある。 変数 ) に変更し , プログラムの実行時にその と考えたものをデータオプジェクト ( 訳注 : じてプロンプトが変更て、きるとよい。定数 プログラムは , 実行される地域の言語に応 場合もある。また , ョーロッパて、使われる の開始時に特定のパラメータを指定したい れることを承知しているはず。プログラム (critters, 訳注 : 定数 ) がしょっちゅう変更さ いたい場合もある。誰て、もこの生き物 プログラム中の各、、定数〃に #define を使 のキーワード変更をしないことが確実だか C の標準化委員会 ) て、は , 今後 5 年間ほどは C なぜならば , X3J11 委員会 ( 訳注 : ANSI #define IF KEYWORD if キーワードを再定義する必要はない コストがかかる。たとえば C て、以下のような けるようなことはしない。どんな保険にも があるク。起こりそうもない事態に保険をか 最初の重要なフレーズは、、変更の可能性 れている。そのひとつひとつ見ていこう。 この文章には多くの重要なフレーズが含ま を唯一の適切な場所に絞れ」 「変更の可能性があるのならば , 変史箇所 能なかぎりこのバインドを遅らせるように 奨励しているのが , 有名な最遅バインディ ング (latest binding) の考え方だ。これを用 いると , プログラムがもっとも柔軟になる。 しかし , ある一定のポイント以降にはバイ ンディングを遅らせないよう , 注意が必要 だ。そのポイントとは , 考えられる範囲て、 もっとも遅く , かつ意味のあるものて、ある。 このポイントを越えると柔軟性の向上より , パフォーマンスや可読性を失うほうが大き くなってしまう。 バインドのタイミングを決定するスキル の修得は , プログラマにとってもっとも難 しいことて、あるのは認めよう ( 十分な情報も いつ値をバインドするか決定て、き るのがプログラマだ , というのを聞いた とがあるが ) 。初心者て、あればとりあえずバ 訳注 . パインディングについて 一般的なオプジェクト指向プログラミ ングて、は , 名前 ( 変数名など ) に記憶領 域を割り付けること。バインディング は動的なオペレーションて、あり , 静的 オペレーションの宣言に相当する。 int abc は ( 静的な ) 宣言て、あり , malloc を使うのは ( 動的な ) バインディングて、 こて、筆者が述べてい ある。しかし , るバインド , またはバインディングは , 名前と値の結びつけを指す。このよう なバインディングには , #define 変数の初期値 プログラム起動時のパラメータ指定 プログラム実行中の変更 などが考えられる。そしてこの例ては , 下のほうが上のほうに比べて , バイン ディングが遅いと考えられている。 Programming on Purpose 15