D 「 . 望洋の プログラミンク道場。 好評発売中 B5 変形判 C 言語プログラミングの落とし穴 定価 2 , 200 円 柴田望洋か教示する「落とし穴」からの脱出法 柴田望洋の待望の最新作。本書は、初・中級の C プログラマが陥りやすいワナや落と し穴を数多く紹介し、その対応策を詳細に解説したものである。 落とし穴 Dr. 望洋の フグラミンク CONTENTS 標準入出力ライプラリ 第 1 話見えないエラー 第 6 話 第 2 話ポインタについて テキストデータの処理 第 7 話 第 3 話文字列とポインタ スタックオーバーフロー 第 8 話 第 4 話ヌル 第 9 話 線形リスト 第 5 話構造体 第 IO 話 2 分木 へストセレク′ 柴田望洋 ~ ~ ~ 【著】 C + + 対応 SOFTBANK 刪 K 柴田望洋氏著作既刊本 大好評発売中 ! C + + プログラマのバイブル誕生 C プログラマのための C + + 入門 B5 変形判・定価 2 , 900 円 秘伝 C 言語問答ホインタ編」「 C : 98 スーパーライプラリ」で好評を博した柴田望洋が贈る、 C + + の決定版。 C から C + + の特徴を系統的に解説しています。 C 言語書籍業界に大きな反響を呼ぶ ! ! 秘伝シリーズ 秘伝 C 言語問答ポインタ編 B5 判・定価 2 , 600 円 ポインタ編 ポインタが理解できず C に挫折した初心者から、ポインタを確実にマスターしたい上級者、明解な指導が要求 される C 言語の指導者まで、すべての C プログラマに最適の書 日本で最も広く使われている PC -9800 シリーズ用 C ライブラリ C : 98 スーバーライフラリ ーイ、ラ 5 " 2HD ディスク付 A5 判・定価 3 , 700 円 テキスト画面グラフィック画面制御・ポップアップウインドウなど 200 を超える機能を満載。 Tu 「 C + + 、 Quick C 、 MicosoftC 、 LS ℃など著名コンバイラのすべてに対応。付属ディスクには全ソースリストを収録。 新冊羆日 S SOFT ソフトバンク株式会社 BANK 出版事業部販売局 : TEL03-5642-8101 望泌第土の入門シリース・ C プロクラマのための C + + 入門 繍 S 新巧第 : ・ 9 0 こ : リース 0 物伝 C 第疆蔭ポインタ・ . の・者 田望洋か宿る究・のライフラリ第 ・ 5 2H0 フロ : ビー ( まソース設第・ 定価は税込

ま 7a 方ッ加′ Vbranes YOShi masa 日 ectronic presents アイサムライプラリ 価。、格 : 23 , 0 ロ 0 円 ■製品概要本製品は、 C 言語にて旧 AM ファイル処理を実現するライプラリてす。検索は、 B ー t 「 ee アルゴリズムを採用しているため、高速検索が可能てす。 当ライフラリにて作成のテータベスファイルは、 d 日 ASE Ⅲ Q 旧 s にて参照、変更が可能で魂 顧客管理、名刺管理等の情報管理システムのアプリケーション開発にお役立てください。 ・主な特徴・ B ー t 「 ee による高速検索・ dBASE Ⅲ D 旧 s とファイル互換 ・レコード単位及びフィールド単位での入出力 ・整数型フィールドのサポート ・フィルタ機能 ・ソースコード完全公開 ・組み込みロイヤリティ無料 PC98 版 DOS/V 版 対応機種 PC 98 シリーズ及びその互換機 対応機種日本旧 M PS / 55 シリーズ 対応言語 MS-C Ve 「 . 5.10 以上 または、旧 M PC/AT 及び Ve 「 . 2.00 以上 その 1 囲 % 互換機 Quick-C Ve 「 . 1 創以上ー。対応言語 MS-C Ve 「 . 6.00 以上 Tu 「 bO C 十十 BORLAND C 十十 Ve 「 . 2.00 以上 Ⅳー d0 ーあー a ー / グラフィックウインドウライプラリ、価第 23 , 000 ー製品概要本製品は、 C 言語にてウインドウ処理を行うためのライプラリです。このライブラリを使用することによりウインドウ対応型アプリケーションを簡単に実 現致します。ウインドウ間の切り替えや移動等、マウスに完全対応していますのでマン・マシン・インターフェイスは、抜群の威力を発揮します。また、グラ フィックを使用していますので、 1 行のドット数が可変となり、 ANK フォントも自由に設定可能です。 EMS にも対応しており、大きなアプリケーションで も安心して利用てきます。 なお、サンプルプログラムとして、 ANK フォントエデイタ、タイルノヾターンエテイタ等をソースコード付きて提供していま魂 ■主な特徴・高速グラフィックウインドウ ・標準ウインドウを数種類用意 ・汎用キー入力ルーチン装備 ・倍角、斜体、強調などの文字に対応 ・ 1 6 色表示対応 ・ EMS 対応 ・マウス完全対応 ・組み込みロイヤリティ無料 ・ソースコード完全公開 PC98 版 DOS/V 版 対応機種 PC98 シリース及びその互換機 対応機種 日本旧 M PS / 55 シリーズ 対応言語 MS-C Ver. 5.10 以上 または、旧 M PC/AT 及び その 100 % 互換機 Ve 「 . 2.00 以上 QuiCk-C Ven L00 以上ー対応言語 Tu 「 bO C 十十 MS-C ー Ve 「 . 6 創以上 BORLAND C 十十 Ve 「 . 2.00 以上 lbrary ををを 123 , 000 日 通信ソフト Y-TERM 装備 ・製品概要本製品は、 C 言語にて日 S ー 232C の各種制御を行うためのライブラリです。一般的な調歩同期式だけでなく、同期式についても完全にサポートされて いますのて、 BSC 等同期式手順を使うアプリケーションにも対応できます。 また、付属している通信ソフト Y 一丁 E 日 M は、プログラム例としてだけでなく実際にパソコン通信等にもお使い頂くことがてきる機能を備えております。 ー主な特徴・調歩同期式、同期式手順ともこサポート ・拡張日 S ー 232C ホード ( PC ー 9861 K) 対応 ・半 / 全ニ重制御、八一ド / ソフトフロー制御のサポート ・実用通信ソフト Y ー TE 日 M 装備 ・組み込みロイヤリティ無料 ・ソースコード完全公開 対応機種 PC98 シリーズ及びその互換機 対応言語 MS-C Ve 「 , 5 」 0 以上 , Tu 「 bo C 十十 Ver. L00 以上 Quick-C Ve 「 . 2.00 以上 BORLAND C 十十 Ver, 2.00 以上 才 C 囂手順ー′′ 価を = 格第 46 , 000 。 通信ソフト JTRN 装備 ■製品概要本製品は、 C 言語にて JCA 手順を実現するためのライプラリてす。 ( 製品には、日 S ー 232C Lib 「 a 「 y が含まれます。 ) 対応機種 PC98 シリーズ及びその互換機 , 対応言語 MS-C Ve 「 5 」 0 以上 , Quick-C Ver. 靄以上 , Turbo C 十十 Ver. 以上田 0 日 LAND C 十十 Ver. 靄以上 全銀、手順ーるー′ ー通信ソフト ZTRN 装備 0 第 46 , 000 円 ■製品概要本製品は、 C 言語にて全銀手順を実現するためのライブラリです。 ( 製品には、日 S ー 232C L 他「 a 「 y が含まれます。 ) 対応機種 PC9 日シリーズ及ひその互換機対応言語 MS-C ver. 5 」 0 以上 , Quick-C ver. 2. 圓以上 , Tu 「 bo C + 十 Ve 「 . 以上 , BORLAND c 十十 Ve 「 . 2.00 以上 タ宿第 198 , ロ 00 円 = 》オンライン・ユーサ・サポート・システム ■製品概要ノヾソコン通信のホスト局を運営する BBS ソフトウェアてす。電子メール、電子会議、電子掲示板などの基本機能が充実しています。回線は最大 3 回線 をサポートしており、 24 時間運用が可能てす。 貴社のニーズに合わせたオンラインネットワークの構築にお役立て下さい。 ( 弊社製品情報ネットワークシステム“ Y ー NET ”は、 PC ー NE 丁 / 2 にて運営しております。 ) 対応機種 OS / 2 が動作可能な機種 対応 OS 旧 M OS/2 Ve 「 . Jl.3 以上 , 日本語 MS OS / 2 Ve 「 . 12 以上 ・弊社製品情報ネットワークシステム、。 Y ー NET ”開局中″アクセス電話番号 ( 03 ) 5350 ー 1785 USERID ・、 GUES 丁 " でどうぞ / あ求め方法弊社製品は、ノヾソコンソフト取扱店であ求めいただけますガ、 直接ご注文の際は石記まであ問い合わせください。 なあ、上記価格には消費税が含まれてありません。 び .29 吉正電子株式会社 〒 1 51 東京都渋谷区代々木 1 ー 58 ー 1 0 第一西脇ビル 電話 ( 03 ) 5371 ー 3041 ( 直通 ) く資料請求番号 179 〉

新連載 プログラミング ANS けイプラリの概要と特徴 きだあきら 第 1 回 本連載は , ANSI C のライプラリ関数の仕様 と , それにまつわるプログラミングテクニック に関して説明していくのか目的である。今回は ANS けイプラリの概要と , 利用方法の基本を 概観しそれを通して ANSI C でライプラリの 仕様か標準化されたことの意義を考える。 はじめに ANSIC が制定される以前から , C 言語は 豊富なライプラリ関数とともに提供される のが常て、あった。これはもちろん , システ ムプログラミング用言語として C を採用した UNIX オペレーティングシステムの存在があ ったからて、ある。複数の優秀なハッカーた ちが , 長年にわたり UNIX における C のプロ グラミング環境の改善へと注力した結果 , さまざまなライプラリが構築され , 痒いと ころに手が届く環境が構築されたのて、ある。 しかも C て、は , 元々の言語仕様が比較的低い レベルの機能をサポートしていたために ほかの言語て、はライプラリて、提供すること がて、きないような機能ーーたとえば可変引 数を受け取る printf など も容易に実現可 能てあったことが , 結果的にプラスに働い ているといえる。 とくに , C て、は基本的な入出力も言語に組 み込まれていない。入出力はすべてライプ ラリを呼び出すことによって行う。逆にい だけて、は何もて、きないに等しい えば に 4 ロロ、 ファイルへの入出力はもちろんのこと , 「 H e110W0r1d 」とコンソールへ表示することす ら , ライプラリなして、は不可能て、ある ( コン ソールは , stdio. h の観点から見れば , 実は 66 C MAGAZINE 1994 1 ファイルの一種て、ある ) 。 これは , C 以前に開発された大部分の手続 き型コンパイラ言語と大きく異なる点て、あ る。 PascaI, PL/I, BASIC, FORTRAN など , C の普及以前 , あるいは普及と並行し て設計された言語て、は , 入出力は言語の一 部として , 「入力文」とか「出力文」という特 別な命令文 , あるいは組み込みの関数とし て用意されている。もっとも PASCAL にお いては , 入出力の手続きは「標準手続き」な どと呼び , 建て前上は言語の一部て、はない ことになっているが , 実際には組み込みて、 処理せざるを得ない仕様て、ある。 なかて、も , BASIC は C とは対照的な思想を 持つ言語のようて、あり , 「組み込みの機能が 多いほうが偉い」という方針て、拡張に努めて いるようて、ある。 これらは , 言語機能に関する基本的な思 想の問題て、あり , 好き嫌いはあるにせよ , 絶対的にどちらが正しいというものて、はな いと思う。 C の場合には , Small is beautif ul という設計哲学が根底にあったため , 言語 に含めるのは核となる機能だけに留め , ラ イプラリて、実現て、きる機能はそちらに出す という設計になったものと思う。ただ , そ のような設計のほうが , さまざまな環境に 対して柔軟に対応可能な言語になるのはい うまて、もない。 Modula-2 や Ada など , C の 普及した後から開発された言語て、 I / O はライ プラリに出してしまうように設計されてい るのは , そのあたりの事情に配慮した結果 て、はないかと推察している。 とにかく C プログラミングは , ライプラリ の存在抜きに語ることはて、きない ライプラリは C 言語の一部て、はないとするの が , 長い間の一般的な解釈て、あったと思わ れる。そしてこの「ライプラリは言語の一部 て、はない」という考え方は , 「ライプラリは 環境に依存していてよい」という結論を導く ことになる。伝統的に C は UNIX とともに発 展してきたため , ANSI 以前の C のライプラ リは , UNIX の影響を色濃く受けたものとな っていた。当然これは UNIX 上て、 C を使う場 合は , 有利なことて、あったが , それ以外の 環境において C を使おうとした場合にやっか いな間題を引き起こしがちて、あった。 一応 UNIX の側て、は , C から呼び出せるル ーチンをシステムコールと C ライプラリのふ たつに分類していたのだが , これは UNIX の 実装上からくる区別て、あって , いうところ の C ライプラリの中にも UNIX 固有の機能に 依存するものが少なくなかったのて、ある。 だが , 「ライプラリは環境に依存する」とい う解釈の下て、は , これは非難することはて、 きない結果てある。 もちろんライプラリは C の言語仕様 , すな

されることになる。しかし , コーディング スタイルとしては使わないほうがよいだろ うと考える。 これらの識別子が用意されている理由は , 処理系製作者が , 実装上の都合から , ュー ザには見せたくない一時的な変数や処理系 の都合て、用いるマクロ , 内部て、共通に使用 したい裏方の関数などを宣言するときに ユーザ定義の識別子とのバッティングを避 けるためと考えてよいだろう。 次に注意したいのが TabIe 1 の (C) て、あ る。これは , 端的にいえばライプラリて、定 義されている外部リンケージを持っ関数や 変数の名前と同じ名前を , ューザが外部リ ンケージを有する識別子として用いること は禁止されているということて、ある。もっ と具体的には , たとえばユーザは printf とか strcat といった名前の関数 ( や変数 ) を自前て、 使って , それに外部リンケージを与えては ならないのて、ある。ただし内部リンケージ の識別子として用いることはてきるし , マ クロ名とかタグ名 , メンバ名としてならば 用いることに支障はない ( はずだが , 後て、述 べるマクロ名の問題があるのて、 , 話はそう 単純て、はない ) 。 74 C MAGAZINE 1994 1 用いているコンパイル済みのユーザ定義ラ ューザが自分のプログラムにリンクして は留まらないことに注意してほしい あるのは , ューザが記述したソースだけに 標準ライプラリ関数を呼び出す可能性が ていたとなると , 結果は保証されなくなる。 だが , 本来の標準ライプラリ関数を期待し とを期待しているのて、あれば問題はないの 実際にユーザが定義した関数が呼ばれるこ もし関数を呼び出している側のコードが , リンクされる可能性が生じるからて、ある。 クされず , その代わりにユーザ定義関数が よっては同名の標準ライプラリ関数がリン ユーザ定義関数として定義すると , 環境に たとえば標準ライプラリ関数と同じ名前の なぜこのような規定があるかというと , イプラリの中て、呼んて、いるかもしれないし , 実は別な標準ライプラリ関数が呼んて、いる かもしれない ( これも ANSI の仕様上は許さ れる ) 。 マクロと関数の取り扱いを 同一視できるように配慮 ANSI ライプラリの規定には , もうひとつ 重要なポイントがある。それはマクロと関 数の取り扱いに関してて、ある。以下にその 一般ルールを列挙しておこう。ただし , 個 別のライプラリ関数に関して , 断わり書き があった場合はこのルールは適用されない ( 以下の文章て、は , 「関数」という用語は , 「マ クロ定義された関数」という意味て、も用いる のて、注意してほしい ) 。 ( A ) ヘッダで宣言されているライプラリ関 数は , さらに同じへッダの中で関数風 マクロ , すなわち引数を有するマクロ として定義されていてもよい ( B) ただしその場合でも引数リストなしの 関数名だけを評価することで , 通常ど おり関数のアドレスを取り出したりす ることは可能である ( C ) マクロ定義を行う場合 , とくに規定す る例外的ないくつかの関数を除けば , Table 1 予約済みの識別子に関するルール (A) どのような用途に対しても常に予約済み そのマクロを展開した結果の式で各引 数は正確に一度だけ評価される ( D ) マクロは引数をカッコで囲んだ形に展 開するので , 呼び出し時に実引数をカ ッコで囲むといった配慮は必要ない ( E ) マクロは , それと適合する戻り型を有 する関数を呼び出すことが可能な場所 であれば , どこでマクロ呼び出しを行 ってもよい。 これらの規定は , 言に要約すれば , ラ イプラリ関数をマクロとして実装してもよ いが , その場合 , それがマクロて、あること を意識してコーディングを変更する必要が ないようにしなければならないということ て、ある。 (B), (C), (D), ( E ) の規定は , の「関数と同じに見える」ために必要なルー ルて、ある。マクロて、実装すれば , 関数を呼 び出すよりも実行効率が上がる可能性があ るため , 実行効率を重視する処理系て、は , なるべくマクロにしてしまいたいところだ ろう。なお , (C) のルールにおける「例外」の 関数には ,putc や getc がある。これらの関数 て、は FILE * 型を持つ stream と呼ばれる引数 を有するが , これらの関数がマクロとして 実装されていた場合 , stream は例外的に複 数回評価されてもかまわないとされている。 アンダースコア ( ー ) で始まり , その後に英大文字あるいはもうひとつのアンダースコアが続くような識 別子のすべて 各ライプラリ定義で示されているマクロ名 ( ただし , それに関連したヘッダが取り込まれている ( include ) 場合にかきる ) (B) ファイルスコープの通常の識別子およびタグの名前空間に対して常に予約済み アンダースコアで始まる識別子のすべて (C) 外部リンケージを持つ識別子としての用途に関して常に予約済み 各ライプラリ定義で示されている , 外部リンケージのすべての識別子 (D) ファイルスコープの識別子としての用途に関して常に予約済み 各ライプラリ定義で示されている , ファイルスコープを持っそれぞれの識別子 ( ただし , それに関連した ヘッダが取り込まれている場合 , かっその識別子と同じ名前空間にかきる )

期 $ に助 rary プログラミング わち各種の構文の文法やその意味する内容 い , 最終的には /usr/group という UNIX の いる。それ以外にも RationaIe によれば移植 とは独立したものて、ある。ライプラリの存 ューザ団体て、のライプラリ標準化活動を生 困難 , すなわち , 処理系製作者が特定の計 在を完全に無視して , C コンパイラのみを開 み出すことになったのて、ある。 算機環境上て、実現するのが困難な関数とか , 発するということも理屈の上て、は可能て、あ あるいは , /usr/group の標準における仕様の ANS けイプラリの特徴 る。しかし , 繰り返すが C はライプラリ抜き 定義が十分精密て、はないもの (ill-defined) は には成立しない言語なのて、ある。それなの 取り除いたと記されている。具体的に取り に , ライプラリは言語の外の存在て、あると ANSI ライプラリは /usr/group が制定した 除かれたものが何て、あるかは追求しない するこの態度は , C が UNIX 以外の環境へも 標準を base document とし , そこから発展 とにするが , 筆者の判断て、は , ANSI ライプ 広く普及していくにつれ , いろいろな問題 させた形て、制定された。 base document に ラリが目指した目標と , その特徴は以下の を生み出す原因となっていく。さらに , UN は当然オペレーティングシステムとしての 3 点に集約て、きるように思う。 IX そのものも発展を遂げた結果 , 必ずしも UNIX に依存する部分が数多くあったに違い ・移植性 , 異なる環境に対する適合性へ UNIX 間て、すら互換性を保てなくなってしま ないが , それらは標準からは取り除かれて の配慮 ・ライプラリのすべてを宣言する標準へ List ファイルモテルのテスト ッダの提供 ・マクロと関数の取り扱いを同一視でき るように配慮 以下 , 順を追って詳しく解説する。 移植性 , 異なる環境に対する 適合性への配慮 UN Ⅸからの独立 何よりも UNIX の呪縛から逃れて , それと は独立なライプラリを構築・定義した点が 大きいと思われる。たとえば , パイプ , I/O のモード制御 (ioctl) , ファイルのアクセス 許可 , プロセス制御 , ディレクトリ関係な どのライプラリは , UNIX の存在が前提にな っていた。これらのライプラリ関数は , UN IX とはまったく異なるオペレーティング環 境においては , 意味をなさない場合がある。 そのようなものを標準が取り込んて、いるわ けにはいかない ただし , この目標は意外な落とし穴を用 意しているようにも思う。たとえばファイ ルアクセスにおいて , 従来の UNIX ないしは それとコンパチビリティを持ったライプラ リ環境て、は , open/close/read/write/lseek といういわゆるバッフアなし入出力の関数 と , fopen/fclose/fread/fwrite/fseek など 1 1 : # i ncl ude く s td i 0. h> 100 3 : # de f i ne N 4 : # def i ne M 5 : # def i ne K 7 : static char buff[N]; 8 : 9 : i n t ma i n ()O i d) 10 : { F I LE S i ze_ t S ; 13 : total; S i ze ー t / * open temproary * / if ((fp ニ tmpfile()) fprintf(stderr, return 1 ; 20 : 22 : 23 : 25 : 26 : 27 : 28 : 29 : 30 : 32 : 33 : 34 : 35 : 36 : 38 : 40 : *fp; ニ NULL) { can't open work file}n") ; / * wr i te f ⅱ e * / = 0 : i く K : + + i ) for (i fwrite(buff, M, 1 , rewind(fp) ; / * read again * / f or ( t 0 t 心 = fread(buff, S total 十ニ s; printf("%3d: read = %3u, total break; 1 , N, fp); i , s, t0 ta I) ; ニ %3uYn ” / * close and remove temporary * / fclose(fp); return 0 : ANSI C Library プログラミング 67

ては非常に多彩な表現が使われているよう て、ある。 ANSIC ライプラリがロケール機能 を導入したのは , このような状況に対応て、 きるようにとの配慮からてあるらしい。何 はともあれ , 多彩な環境に柔軟に対応て、き るようにしようという姿勢は評価て、きるし , その一環としてマルチバイト文字への対応 も考慮されたのは非常に好ましいことて、あ ただし , カンマ区切りのフォーマットに 関しては , それについての情報を提供して くれるに留まり , このような形式て、自動的 に入出力してくれるライプラリ関数は用意 されていない。ライプラリ関数によるサポ ートは小数点だけて、ある。また , 小数点に しても影響を受けるのは , 実行時のライプ ラリ ( の一部 ) の関数だけて、あって , ANSIC 言語そのもの , すなわちソースの記述には 影響がおよばない点には注意が必要だ。た とえばソースの中て、浮動小数データを記す 場合には , 必ず小数点としてはピリオドを ライプラリのすべてを 用いなければならない 言する標準ヘッダの提供 なお , いくつかの名前は複数の標準ヘッダ の中て、宣言されるというルールを定めた。 マクロ , 変数 , typedef 名 ) は , 所定のヘッダ てのライプラリ関数 ( およびそれに付随する 標準ヘッダというものを明確に定め , すべ されているとはかぎらなかった。 ANSI て、は 提供されているヘッダファイルの中て、宣言 関数 ( ないしはマクロ ) がシステムによって なかったが , 必ずしもすべてのライプラリ はヘッダファイルを # include しなければなら 数のうち , いくっかの関数を用いるときに ルの関わりは曖昧て、あった。ライプラリ関 ANSI 以前は , ライプラリとヘッダファイ 引数の型チェック プロトタイプによる て、宣言されるか , あるいは定義される ( この 件については , 後て、補足する ) 。ちなみに全 標準ヘッダの名前を Fig. 4 に示しておく。 この規則が作られた背景には , ANSIC が 導入したプロトタイプの存在が大きいとい える。特定のヘッダを # include すれば , ヘッ ダの中て、ライプラリ関数のプロトタイプ宣 Fig. 2 マルチノヾイト文字の定義 2.2.1.2 Multibyte characters 2.2.1.2 マルチノヾイト文字 言が行われている。その結果 , ライプラリを 呼び出すときに , ライプラリ関数が期待し ている型と実引数の型が違う場合には , 可 能て、あれば自動的に型変換が行われる。も し自動的な型変換を施すことがて、きなかっ たり , 実引数の個数に過不足があるような 場合には , 処理系によってエラーになるか , The source character set may contain multibyte characters, used tO represent mem be 「 S Of the extended character set. The execution character set may 引 SO contain multibyte characters, which need not have the same encoding as fO 「 the source character set. For bOth character sets, the following shall hO 旧 . ・ソース文字集合は , マルチバイト文字を含んでいてもよい。マルチバイト文字とは , 拡張文 字セットの要素を表現するために用いるものである。実行文字集合もまた , マルチバイト文字を 含んでいてもよい。そして , それのコード化方法がソース文字集合と同じである必要はない。両 文字集合に関して , 以下の条件が成り立っていなければならない : * The single-byte characters defined in 目 2.2.1 shall be present. 目 2.2.1 で定義したシングルバイト文字が存在していなければならない。 * The p 「 esence, meaning, and representation Of any additional members is locale-specific. ・追加の要素の存在 , 意味 , およびその表現はロケールに固有のものである。 * A multibyte character may have a state-dependent encoding, wherein each sequence Of multibyte characters begins in an initial shift state and enters Other implementation-defined shift states when specific multibyte characters are encountered in the sequence. While in the initial shift state, all single-byte characters retain their usualinterpretation and dO not alter the shift state. The interpretation fO 「 subsequent bytes in the sequence is a function Of the cu 「 rent shift state. ・マルチバイト文字のコード化方法は状態依存であってもよい。すなわち , それぞれのマルチ バイト文字の並びは , ある「初期シフト状態」で始まり , その後に , 特定のマルチバイト文字が出 現した時点で , それとは異なる処理系定義のシフト状態に移行する。初期シフト状態では , シン グルノヾイト文字に関しては , すべて通常どおりの解釈が行われ , それらがシフト状態を変更する ことはない。文字列内での , ある文字以降のバイト列をどのように解釈するかということは , そ の時点でのシフト状態の関数となる。 * A byte with 訓 bits zero shall be interpreted as a null characte 「 independent Of shift state. ・すべてのビットがゼロである 1 バイトは , シフト状態には関わりなく空文字 ( NUL ) と解釈さ れる。 * A byte with all bits zero shall not occur in the second or subsequent bytes Of a multibyte character. マルチバイト文字の 2 バイト目あるいは 3 ノヾイト目に , すべてのビットがゼロであるよう な 1 バイトがきてはならない。 FO 「 the source character set, the following shall hO 旧 . ソース文字集合に関しては , 以下が成り立っていなければならない : * A comment, string literal, character constant, or header name shall begin and end in the initial shift state. ・コメント , 文字列定数 , 文字定数 , あるいはヘッダ名において , その開始と終了の時点で は , 初期シフト状態でなければならない。 * A comment, string literal, character constant, 0 「 header name shall consist Of a sequence Of valid multibyte characters. ・コメント文字列定数 , 文字定数 , あるいはヘッダ名に , 無効なマルチバイト文字が含まれて いてはならない。 70 C MAGAZINE 1994 1

ん Screen 1 は、入出力画面作成 / 帳票出力機能をはじめ、アプリケー ション開発に欠かすことのてきない様 々な関数を含んた多目的ライフラリて す。ん 1 の関数は、いす れも高機能でかっ操作性にも優れてお り、高度なアプリケーションの開発を 容易に行うことがてきます。しかもこ の強力なライプラリが、ライセンスフ リーて禔供されます。せひとも、 0 ん Saeen 1 をアプリケーション開発に お役立てください。 MS-C を行 70 ん′ 080 ″ RQuickBASIC/MS-BASIC/VisualBASIC/QuickC/MS-C QuickC 防豆出 C 漑 & B C 洫 / バーの OS 秋 B C ハイレゾリューションモードにも対応しました。 C 言語では、これ までの 2 S “ e を利用して作成されたプログラムが、そのままハ B S ー C プログラムについては B S ー C イレゾモードで実行可能です。 の処理系自体がハイレゾに対応している場合のみ有効です。 シリアルプリンタでもべージプリンタ並みの使い勝手が可能な、画 期的な「べージ出力機能」を実現 ! 印字位置の上下とは無関係に 任意の順序で出力が可能です。罫線専用の印字関数を用意したほか 文字修飾も簡単に行えます。ま た、印字をせずに画面上で帳票 イメージを確認できるレイアウ ト機能も装備しています。ハー ドコピーも簡単。 対応機種 : PC-PR201,NM9900,NPDL, 折れ線グラフ等も簡単に作成可能 ! (LIPSIII によ ESC/P ESC/Page, 凵 PS II LIPSIII る出力 ) シリアルプリンタでも同様に出力可能 9 3 年 0 2 月 2 8 日 当月・貨年第上・年・鋼費 第物事ー、 ) 第第無名 物月強高 人金会計 当月受上第 当月満費当月強高当月電物ー 71. 5. 引 032 卩 4. ] 0000 ・第儀 ) る . 関 第本 - 第 ー材 .48 1. 観靆輸 山出第 0 ロロロ・事儀 ) . コ . で一しー靆円 当物計】 B4 用紙での横 180 桁出力例 ( PC ー PR201 による出力 ) 各言語の統合環境に対応したヘルプファイルを用意しました。環境 内から 4 S “ e 例のリファレンスを参照可能です。また、付属の常 駐型ユーティリティによりお手持ちのエデイタ等の実行中にヘルプ ファイルを表示することも可能です。 EMS 対応 ハイレゾ対応 ライプラリを E M S 対応にしました。これにより B A S ー C の統合 環境 ()B QBX , VBDOS ) 上においても、大規模なプログラムの開発が可能に なります。また、実行形式のプログラムにおいてもライプラリを E M S 領域にロードできますので、この場合はさらに大きなプログラ ムを構築可能です。 注 ) EMS 対応のプログラムを実行する場合は、ライプラリを EMS メモリにロードする 常駐プログラム "QSLOAD. EXE" を使用します。このプログラムについては、再販ラ イセンスが付属しておりません。再販ライセンスのこ提供については、別途こ相談下 プリンタ制御 データ入力 ー第第数鋼数ー等グラフ 工ディット入力、文字・数値 データの入力、日付・時間の 入力、 1 文字の入力の 6 形態。 入力の終了条件として通常の キーや特殊キー、マウスのク リックなどから豆富に指定で きるほか、日本語 FEP と連動 した入力も可能 ( FEP のオ頁を 自動認識 ) 工ディット入力のサンカ : し 9 第川 S 凵 0 宿 ーし R 気 : 料ー E ー - 了 0 を . ー・ : し E ま上ーリを 5 第三ヨ : 日工 E 6 ・をれを、 : ーミ・に為・い ョを 会し、ーー 1 ー 1 ぐ・ 0 一 ー 3 の 0 上 S れ 工ディット入力関数を使えば、テキスト 工デイタの作成も簡単です。 ウインドウ : : 5. れ 0 1 度に 20 個までのウインドウ をオープン可能です。元の画 面の待避領域としては裏 V R A M ・ E M S ・ファイルを選 択可能。ウインドウ内の消去 ・スクロール・背景色・枠の 色等を指定可。 このようなウインドウ対応の入力画面が簡単に作成できます。 アドバイサ対応のオンラインマニュアル リハぎし . ま : 万円 ティスク その他 画面出力、マウス制御、日付・時間の計算関数、リアルタイムでの 日付・時間の表示関数、グラフィック関数 ( C 版のみ ) など 100 を超 える関数を用意しました。 価格 ( 消費橳リ ) ■ 8C 十 C 版 ■版 ■ C 版 必、要システム ・ . 本イ本 : NEC PC ・ 9800 シリー - ス ( ネ刀イ弋、 U 、 LT をド余く ) ・ MS-DOS:Vers•on 2 . 凵 ~ 5 . 0 ・ソフトウェア : く BA 引 C ん反ク ) 文寸石む言 - 言吾〉 Qu•ckBASlC V4 . 5 、 MS-BASIC V7 コ Vtsual BASIC fO 「 MS-DOS VI . 0 く C 言・言吾 . 版 . ク ) 文寸ルむ言第吾 > MS-C (Ver 4 . 0 ~ 7 . 0 ) 、 QutckC (Ver 2 . 0 ) フロッビーディスクのフォーマット、 ファイル / ディスク単位での コヒ。ー、巨大ファイルの分割コビー、ファイル名の操作 ( 抜き出し、 正当性のチェック ) 、ディスクオフラインの検出、残り容量の取得 などが可能です。 \ 35 , 000 \ 25 , 08 \ 25 , ディスクび ) 内容 ・ライプ・ラリ ・インクノレー・ドファイノレ ・アド / 、イ・サ文寸石む′、ノレプファイノレ ・ EMS 文寸応、常男主フログラム . コ - - ーーテ・イリテ。イ ・サンプノレプログラム V B 対応 対応言語として、次世代 BAS ℃の Mi “ 0 $ 0 尹⑩防 $ 田 C 7 MS-DOS を追加、さらに様々な用途で活用できます。従来の BAS 旧によるプ ログラムも、そのまま VB に移行できますので VB の快適な開発環境 での作業が可能になります。 学 Sunauesr 開発・発売元 〒 115 東京都北区赤事 1 丐 2-16 田口ビル 7F TEL 03 ー 3902-1169 ( 代 ) FAX 03 ー 3902 ー 1292 株式会社サンクエスト く資料請求番号 01 1 〉

まどりつど RAFF プログラム 美味しい料理は、素材で決まります。 美味しい料理を作るときは、素材に気を使いますね。プログラム作りも同じことか言えます。 良い材料を集めれば、誰もがより良いプログラムか簡単にしかも思い通りに作れるようになります。 「まどりつど」と「日 AFF 」は K & T がお届けする、安価で使いやすいライプラリ集です。 C 言語プログラムから呼び出し 機能を最小限におさえた 可能なファイル操作ライプラリ ユーザーフレンドリーな ライプラリ 開発者はアプリケーションプログラムに「 RAFF 」をリンク することにより、ファイルを容易に操作することができます。 「まどりつど」は一部の機能を強化するよりも、 操作の一貫性を追及した設計になっています。 ファイル本体のフォーマットを 意識しなくても容易に操作可能 手軽にウインドウ ( マンマシン 「 RA 杯」では論理的なデータ定義フォーマットをサポートして インターフェース ) の構築ができる いますので、ファイルフォーマットを意識せずにプログラムの 作成が可能となります。 マウス中心のアプリケーションの開発に最適です プルダウンメニューやポップアップウインドウ ー詳細なデータ管理 一般的なファイル操作ライプラリでは 扱えるデータの単位がバイト単位だったり、 固定長データしか扱えなかったりといった制限がありました。 しかし「 RA 」では可変長データおよびピット単位での ファイル管理をサポートし、フォントファイルや 画像ファイル等のデータベース作成に力を発揮します。 ・本製品は ( 財 ) 東京都中小企業振興公社の 助成金を受けて開発いたしました。 動作環境ー ■対応機種 : SUN ワークステーション ・ OS : SUN OS Ve 「 4.1.1 以上十 X ウインドウ システム (Openwindows Ver2. O. x) 十 GUI(OPEN LOOK 準拠 XView) ・必要メモリ : 16MB 以上 ・必要ディスク容量 : 100MB 以上 標準価格 Y252 , 000 ライフポード社 「 C-WIN DOW 」リソース互換 ー動作環境 ■対応機種 : 80286 以上の CPIJ を持つ PC -98 シリーズ ■ OS : MS-DOS Ve 「 3.3 (A/B/C/D) ■必要メモリ : 640MB 以上 ■対応コンバイラ : MS C6.0 標準価格 Y19 , 800 K & K 月 0 Ⅳ edge&Techno/ogy ナレッジ・アンド・テクノロジー有限会社 〒 151 東京都渋谷区代々木 4-31 -4-704 TEL. 03-3373-7047 FAX. 03-3373-5815 担当 : 岡崎 10 : 00 ~ 12 : 00 / 13 : 00 ~ 16 : 00 ( 月 ~ 金 ) ・まどりつど、 RAFF を使用した セキュリティ関連製品も発売中 * 一般に各商品名は各社の商標または登録商標です く資料請求番号 004 〉

いといった制限があるとコーディング作業 が煩雑になるからて、ある。これを実現する ためには , 標準ヘッダ間て、の相互依存関係 をなくしておく必要がある。 一方 , 「何度て、も」というのは , 直ちにメ リットが理解て、きないかもしれない だが , これまたコーディング上て、はたいへん有利 な特性て、ある。どうしてそうなのかを以下 の架空のシナリオに沿って考えてみよう。 あるユーザ定義ライプラリを設計するこ とを考えよう。以下 , 便宜上このユーザ定 義ライプラリを libl と呼ぶ。また libl は , へ ッダファイルを提供していて , それを #incl ude することて、 , ユーザ定義ライプラリに含 まれる関数のプロトタイプを宣言している ものとする。このヘッダファイルを libl. h と しよう。さらに , libl に含まれるユーザ定義 のライプラリ関数のうちには , FILE * とい う型の実引数を受け取るものがあるとしよ う。 FILE * という型を引数に受け取ろうと すると , 前もって <stdio. h> を #include して おかなければならない。ユーザ定義のヘッ ダて、は , このような標準ヘッダが宣言して いる名前への依存が生じてしまうのはある 程度は避けられない事態て、ある。もちろん , ここに示した特定のケースて、は , ポータビ リティを無視すればほかの解決手段もある が , 移植性も考慮しているものとする。 そうすると , この作業をどこて、行うべき かが問題になる。この場合 , ライプラリの 設計者としてのユーザには , ふたつの選択 が可能て、ある。ひとつはユーザ定義ライプ List Bogus #include 4 #define int double # i nc 1 ude く s td i 0. h 〉 72 C MAGAZINE 1994 1 ラリを使う側のユーザプログラムの中て、 , 必要な # include を並べて書いてもらうように するというやり方て、ある。この場合ふたっ の # include の順序が重要て、あって , #include く stdiO. h > #include ”ⅱ bl. h ” のように必ず < stdio. h > を先にしなければ ならない もうひとつのアプローチは , どうせ必ず #include しなければならないのて、あれば , そ れは libl. h の先頭て kstdio. h > を #include し てしまうというやり方て、ある。この手法を 取ると , libl を利用するユーザプログラムに とっては , libl. h を #include するに先だっ て , <stdio. h> を #include しておかなければ ならないという制約がなくなり , 余計な心 配ごとが減る。めてたしめて、たして、ある。 だから , この解決策は実際によく使われる 手法て、ある。 て、は , ューザプログラムそれ自身が libl の 内容とは無関係に , く stdi 。 . h > が提供してい る機能を使いたくなったとしたらどうだろ うか。この場合 , libl. h の中て、すて、に # inclu de されているから , ューザプログラムの中 て kstdio. h> を #include せずにおくのは , 健 全な姿勢て、はないだろう。 libl. h の中て、 < s tdio. h> を #include しているのは , libl のお 家の事情て、あって , 将来的には仕様が変更 になるかもしれないのて、ある。 やはりいちばん素直なのは , ューザプロ グラムの中て、 < stdio. h > と lib. h の両方を # in clude することて、ある。ということになる と , 結果的に <stdio. h> が二重に #include さ れることになる。しかし , このようなコー ディングの習慣はよく見かけるものて、ある。 ANSI て、も RationaIe によれば , そのような 習慣を尊重する意味て、 , 何度 #include しても よいというルールにしているらしい もし , 標準ヘッダを通常のテキストファ イルとして実装するというオーソドックス なアプローチを採用する場合には , 現 実に , ほとんどの処理系はこのようなアプ ローチを採っているはずだが あるヘ ッダを何度 # include してもよいとするには , ちょっとした配慮が必要て、ある。というの も , ヘッダの中て、何らかの定義を行ってい る場合に , マクロ定義を除いてヘッダが一 度以上 #include されると , その部分て、二重定 義のエラーになってしまうからて、ある。端 的な例としては struct/union/enum などの定 義があげられる。ちなみに , 標準ヘッダは 同じ効果を得られるかぎりどのような実装 の方法をしてもよいことになっている。た とえば , 標準ヘッダに対する # include をコン パイラのフロントエンドが「見た」瞬間に コンパイラが管理している内部的な識別子 テープルに標準ヘッダの中て、定義 , 宣言さ れるべき情報を直接展開するというような 実装をしてもいっこうにかまわないという ことになっている。 標準ヘッダの中て、二重定義を防ぐには , ANSI の RationaIe が示しているように , Li st 5 に示すような方法が考えられる ( Ration ale 4.2.1 ) 。原理は , 以下のとおりて、ある。 List 標準ヘッダの中でニ重定義を防ぐ 5 #ifndef _ERROR_H #define _ERROR_H / * body of く errno. h> * / #endif

→プロクラミング道場 Dr. 望洋の LiSt 1 クモードて、は不可能て、ある。このように gp oint の返すパレット番号によって判別て、きる のて、ある。 : 98 スーノヾーライプラリ』 のグラフィック 誌面の量的な制約のため , あまり詳しい 解説がて、きないことに対するいい訳 ? と いうわけて、はないが , 拙著℃ : 98 スーパー ライプラリ』中のソースファイルを , 付録 ディスクに収録することにした。収録した ソースは , Fig. 4 のファイルて、ある。ここて、 サポートされるライプラリ ( 関数・マクロ ) box boxf は , TabIe 3 のとおりだ。 circle circlef C ー 86 Ve 「 . 3.30C e Ⅲ pse 試食版用ライプラリ ellipsef gcircle ℃ : 98 スーパーライプラリ』は , 発表当 cls gcolor 初に存在した処理系て、ある LSI C ー 86 Ver. gget 3.2 試食版やの LSI C ー 86 Ver. 3.3 には対応 gGRBset init, _ginit している。しかし , 本誌の 1993 年 11 月号付 録ディスクにも収録された , LSIC-86Ver. gline 3.30C 試食版には対応していない。そこて、 , paint' gpaint2 palette, gpaletts Ver. 3.30C 試食版に対応させて新たに作成 point したライプラリファイルなどを特別に収録 gpset put することにした。 g 「 0 付録ディスクを参照していただきた い screen gte 「 m VleW 募集 isganalog line 本連載て、は , 読者からの質問にお答えし , また希望に応じてプログラムの添削も行う。 ( 1 ) 氏名・住所・電話番号 下記必要事項を明記のうえ , フロッヒ。ーデ ②匿名希望の有無 / ペンネーム イスクにて応募していただきたい ( 短い質問 ( 3 ) 質問・相談事項 ( なるべく具体的に ) て、あれば , 書面のみて、可 ) 。 宛先 なお , 応募いただいたフロッヒ。ーディス 〒 108 東京都中央区日本橋浜町 3 ー 42 ー 3 クは返却て、きないことや , 個人的な質問に ソフトバンクスクウェア はいっさいお答えて、きないことをあらかじ ソフトバンク ( 株 ) 出版事業部 めご了承されたい C マガジン編集部 どんな小さな疑問点てもけっこうなのて、 , 「 Dr. 望洋のプログラミング道場』係 気後れせずに , 応募していただきたい ( ただ 上参考文献 し , 特殊な題材よりも , 一般性の高い題材 を優先的に取り上げることを , あらかじめ [ 1 ] 平林雅英 , 「 ANSI C 言語辞典』 , 技術 -Ghires) Gana log 引 se { gc 引 or ( 0. 0. 7 , GC4096P16 ) ; gpset(), 0 , 8 ) : GanaIog : (gpoint(0, の gpset(0,0, の : --GanaIog) gc010r(), 0 , 7 , GC8P8) : 00 ーれ 0 ー 0 リ 0 リ 0 1 ー 0 し 8 8 8 8 00 0 リ / * ハイレゾでは常に 1 6 色使用可 * / Fig. 4 付録ティスクに収録したソースファイル ASSEMBL. H GRAPH ℃ . H BSGRINIT ℃ BSGRLINE ℃ BSGRPHXX ℃ BSGRPLTS ℃ BSGRSCRN ℃ Table 3 付録ティスクに収録したライプラリのサポート関数・マクロ 関数・マクロ 内容 矩形枠を描画 矩形 ( 塗りつふし ) を描画 円枠を描画 円 ( 塗りつぶし ) を描画 楕円枠を描画 楕円 ( 塗りつぶし ) を描画 円を描画 画面を消去 バレットモードなどの設定 描画情報の格納 カラーノヾレットの設定 初期化 日本語文字の描画 直線の描画 塗りつぶし カラーパレットの設定 表示色の取得 点の描画 描画情報の返却 描画画面の移動 画面モードの設定 終了処理 表示領域の設定 拡張グラフィックモードの判別 直線の描画 評論社 , 1989 [ 2 ] アスキー出版局テクライト編 , 「新版 PC ー 9800 シリーズテクニカルデータブッ ク』 , アスキー , 1990 [ 3 ] アスキー出版局第二書籍編集部編 , rp C ー H98m0de170 テクニカルデータブッ ク』 , アスキー , 1990 [ 4 ] 柴田望洋 , ℃ : 98 スーパーライプラ リ』 , ソフトバンク , 1992 BSGRANI 6. C BSGRCRCL ℃ BSGRPAIN ℃ BSGRPALT. C BSGRPSET. C BSGRPUTG ℃ ご了承願いたい ) 。 しばた・ばうよう ( 工学博士・国立特殊教育総合研究所 ) Dr. 望洋のプログラミング道場 139