大きい (TabIe 14 ) て、すが , もともと小さな プログラムなのて、標準ライプラリのサイズ が大きく影響しただけだと思われます。 のように BC3 と MS ー C7 はいろいろな面て、共 通点の多いコンパイラといえます。 しかし , コンパイラを動作させるマシン のメモリ環境が大きく異なります。双方の コンパイラともにプロテクトメモリを活用 してコンパイルを行いますが , BC3 は VCP I のメモリ環境て、もコンパイルが可能てす が , MS-C7 は DPMI を要求します。 Windo ws 上て、開発を行うなら問題はないのてす が , DOS 上て、は 386MAX のような DPMI サ ーバを必要とします。 PC ー 9801 用にはこれまて DPMI をサポート したメモリ管理ソフトは存在しなかったの て、 , MS ー C7 には I ・ O データ機器製の Memo rySe Ⅳ er が標準て、ついてきます。したがっ て , MS ー C7 の動作の安定性にはこの Memo ry Server が大きく関与することになり , 実 績がない Memory Server に若干の不安を感 じます。 また , MS ー C7 付属のデバッガ Code View Ver. 4.0 は Turbo Debugger に比べて動作 が遅く , 仮想 86 モードての動作がない など , 随分見劣りがします。今回の XMEM クラスライプラリのような低レベルの動作 を行うソフトウェアの開発はデバッガを駆 使する必要があり , デバッガのて、きはプロ グラム開発効率に大きく影響するため改善 を期待したいところてす。 MS ー C7 に付属のマニュアルは非常によく て、きており , ℃十十 TutoriaIJ の一冊など は , 筆者が知るかぎりてはもっとも優れた C 十十の入門書だと思います。 BC3 のマニュ アルに℃十十 Tutorial 』がなくなって残 念に思っていたところだけに , 非常にあり TabIe 12 マシン環境 マシン HDD メモリ バッファ 特集 M 0S メモリ活用蠡 PC-9801RL Cx486DLC 20MHz ICM INTER- 180WS 本体 1 .6M バイト十内部増設 RAM 4M バイト buffe 「 s : 30 がたいマニュアルだと感じました ほかのマニュアルも TC Language Refere nce 』と「 C 十十 Language Refarence 』が分冊 されて , それぞれを別に説明しているため , わかりやすさが増す構成になっています。 以上のことと MS ー C7 の高度のオプティマ イズとその信頼性の高さとを考え合わせる と , BC3 にするか MS-C7 にするかは難しい 選択になります。まだ , それぞれのコンパ イラの表面しかみていないのて、 , 正確な評 価はここて、はて、きません。しかし , しいて 選択すれば , 低レベルの小さなプログラム 開発には BC3 を , 大きなアプリケーション開 発には MS ー C7 を , といえるのてはないて、し 躡クラスライプラリ ようか。 な方法てのメモリアクセス , 64K バイト以上 また , 高レベルのものては , もっと簡易 構などがあります。 変更関数や XMEM メモリエリアのロック機 ものとして XMEM メモリエリアのサイズの 低レベルな関数として加える必要がある まだ不備が目立ちます。 したが全体的には短時間て作成したため , XMEM は設計にはずいぶん時間を割きま の巨大配列の確保などサポートしたいとこ ろてす。さらにそのほかのメモリへの対応 も行いたいところてす。そのような希望が あるとき C 十十のクラスライプラリの本領が 発揮されます。 XMEM クラスからのインへ リタンスにより , このような要求は元のプ ログラムソースの変更を行わずに達成てき ます。たとえばコンべンショナルメモリの サポートなどは前章て解説した内容を理解 されている方なら 1 時間ほどて作成てきるて、 しよう。 ぜひ皆さんも XMEM クラスライプラリを 拡張して使ってみてください 最後になりましたが , XMEM クラスライ プラリのテストを行っていただいた ZOB S tation BBS の hiro, kitoh 氏にこの場を借り てお礼申し上げます。 参考文献 OURNALJ , October, ' 91 Herbert Gintis, 「 Xalloc 」 TDr. Dobb' s J BORLAND C 十十 3.0 USER' S GUIDE GUIDE BORLAND C 十十 3.0 PRXJRAMMER' S M S-C/C 十十 Programing Guide MS-C/C 十十 C 十十 Language Reference MS-C/C 十十 Tutorial manual TabIe 13 XMEM. cpp 十 TESTI ℃ pp をオプションなしでコンパイルしてリンクするまでの時間 TabIe 14 TESTI . EXE のファイルサイズ コンバイラ MS-C7 BC3 時間 21 秒 20 秒 コンバイラ MS-C7 B C3 特集 ファイルサイズ 9701 バイト 8000 バイト MS-DOS メモリ活用技法 81
3 側面 Method : 洳 ta 加 P 砿い 工ージェントの寿命よりは長い寿命を持つ ( たとえば , オプジェクト指向データベース の中に住むオプジェクトは , すべてパーシ ステントな ( = 永続性を持つ ) クラスのイン スタンスて、ある ) 。 並行処理性という項目は , 制御の流れに マルチスレッド (multiple threads) があった 場合の , そのクラスのセマンティクスを表 す。その場合 , まず , シーケンシャルなク ラスとは , そのクラスのセマンティクスが シングルスレッドの場合にしか保証されな という意味て、ある。 ガード付きのクラスとは , そのセマンテ イクスがマルチスレッドが存在しても保証 されるが , ただしアクテイプなエージェン トのすべてが協力して , 完全な相互排他性 〔資源利用の衝突や , 実行の論理的な文脈を 外れた不正な書き換え等が起こらないこと〕 という意 を実現していなければならない , 味て、ある。 同期型のクラスとは , マルチスレッドが 存在してもそのセマンティクスは保証され るが , 〔外部工ージェントて、なく〕クラスの インスタンス自身が相互排他性の確保を担 当しなければならない , という意味て、ある。 有限ステートマシンの項目は , クラスの 動的なセマンティクスを理解しやすくする ための , ひとつまたは複数のステート遷移 図を置く場所て、ある。クラスのメソッドは , TabIe 3 に示す操作仕様を用いて , さらに分 かりやすく解説してもよい。ただし , 開発 の初期段階や , あまり厳密性を必要としな い開発て、は , 操作の名前を書くだけて、十分 て、ある。また , これらの操作仕様の代わり に , 使用する言語のコード片を記入しても Table 3 の中て、 , まず操作の責任任務と は , その操作のセマンティクスを定義し , その操作の役割 , 目的 , および基本的な振 る舞いを書き表す。 操作の種類とは , たとえばその操作がコ ンストラクタて、あるとか , デストラクタて、 44 C MAGAZINE 1993 1 ある , 変更子 ( mod ⅲ er ) て、ある , セレクタ (selector) て、ある , 補助的関数て、ある , とい った区別のことて、ある。操作の種類は , そ の操作の役割に関するデベロッパの考えを 示すだけて、ある。以前はわれわれは , この 項目をく操作のカテゴリ > と称していた。種 類という用語に変えたのは , 言葉の意味と してよりふさわしいからて、ある。 操作のアクセスタイプとは , その操作が 属するクラスに対しての相対的なアクセス 制限のことて、ある。 操作の性格は , 言語に固有て、ある。たと えば , virtual, static, before, after, con st といったによって決まっている性格 、に 1 ロロ をここに書く。 結果のタイプは , その操作の返し値があ る場合に書く。そのタイプは , そのクラス が使っているクラスを表すものて、なければ ならない〔内蔵タイプも含め〕。またこのタ イプの記述を言語に固有の修飾子て、もって 修飾してもよい。たとえば , const のリファ レンス , といった修飾て、ある。 形式引数の欄には , そのメソッドの形式 引数のリストを書く。このシグネチャは , 言語に固有の書き方て、書いてもよい 例外の欄には , そのメソッドから起きう る ( そして throw される ) , あるいはそのメソ ッドが捕捉しうる , 例外状況を書く。 前提条件 , セマンティクス , および実行 後条件の項目により , そのメソッドの形式 的な ( フォーマルな ) 意味を表現する。これ らの意味は , TabIe 3 に指定する形式のどれ かを用いて記述する。 時間的複雑さの項目は , その操作の実行 に要する時間を表す式て、ある。その式て、 , 実時間 , 平均時間 , ワーストケースの時間 , などを表す。 メモリ利用の複雑さの項目は , そのメソ ッドが呼び出された場合に消費されるメモ リの , 絶対量または相対量を表す式て、ある。 並行性の欄には , 制御の流れにマルチス レッドが存在した場合の , そのメソッドの セマンティクスを書く。そこに , シーケン シャルな操作と書いた場合は , そのセマン ティクスがシングルスレッドの場合にしか 保証されない , という意味て、ある。ガード 付き操作と書くと , セマンティクスはマル チスレッドが存在しても保証されるが , た だしそのためには , すべてのアクテイプな 工ージェントが協力して , 相互的排他性を 実現していなければならない という意味 て、ある。同期型の操作 , と書けば , それは , マルチスレッドが存在してもセマンティク スは保証されるが , そのためには操作自身 が相互的排他性を確実に実現しなければな という意味て、ある。 らない , 操作の , 並行性に関するセマンティクス は , クラスのそれと整合していなければな たとえば , シーケンシャルなクラ らない ノンシーケンシャルな操作があるこ スに とは , 許されない。 クラスの関係の仕様 クラス図の中に描かれる関係線の一つひ とつに対しても , その意味を分かりやすく するための仕様を記入て、きる。その記入項 目を TabIe 4 に示す。関係の仕様は , 関係線 の描き方自体にも表現されてはいるが , 完 全なものて、はない。これらの記入項目の一 部は , 特定の種類の関係にのみ適用される ものて、ある。 クラスの仕様と関係の仕様は , どちらも , 背後にある〔単一の〕論理モデルに対する 視界を表しているものなのて、 , お互いが整 合していなければならない たとえば , クラス A の仕様として , クラス B が上位クラスだと書かれていたら , それに 対応する継承関係の仕様て、は , A がその関係 のソース , B がターゲットになっていなけれ ばならない クラス仕様から関係の仕様を参照したり , あるいはその逆もて、きるツールを作っても よい
ておくと , 各カテゴリから一々 using 関係の 線を引く手間が省けるのて、 , クラス図を相 当シンプルにて、きる。 クラス図の中の個々のクラスに対して , その意味を理解しやすくするために , クラ スの仕様というものを書く。クラスの仕様 の項目を , Table 2 に示す。クラスのフレー バによっては , これらの一部だけを用いる。 ツール類は , これら以外の仕様項目を便 宜のために提供してもよい ( たとえば , 参考 資科やクラスの上位クラスの列挙など ) 。さ らに , 使用する言語の表現力が十分に豊か ならば , その言語のコード断片を使ってク ラス仕様の一部を表現してもよい。たとえ ば , C 十十のヘッダファイルは , これらのク ラス仕様の情報の多くを表現しうる。 クラスの仕様は , そのクラスに関係のあ るすべての情報の代表て、ある , と見なす〔 = 実際に書かれているものだけがすべての情 報て、はない〕。その情報への特定の視界を表 すために , 区画を用いてもよい。たとえば それは , 特定の図のコンテキストにとって 重要な , 一部の属性やメソッドを記入する 区画て、ある。 クラスの責任任務 (responsibility) という 項目には , そのクラスの概念 , 何を抽象し ているのかを書く。つまり , そのクラスの 役割 , 目的 , 基本的な振る舞いて、ある。以 前はわれわれは , 、、ドキュメンテーション ( 説明文 ) 〃というより一般的な用語を , この よりふさわしい しかしく責任任 用語て、あると思える。 的指向の方法て、あるため , り , われわれの方法 ( プーチ法 ) もまさに目 務〉という言葉のほうが , 目的が明確て、あ 項目名として用いていた。 固有て、あり , ふつうはキーや属性の名前を 性格 (qualification) という項目は言語に こに書く。 TabIe 2 クラスの仕様 名前 責任任務 性格 アクセスタイプ 濃度 バラメータ基本形 メタクラス 上位クラス メンバ メモリ利用の複雑さ ノヾーシスタンス ( 永続性 ) 並行処理性 有限ステートマシン Table 3 クラスの仕様 名前 責任任務 種類 アクセスタイプ 性格 結果のタイプ 形式引数 例外 前提条件 セマンティクス 実行後条件 時間的複雑さ メモリ利用の複雑さ 並行性 識別子 テキスト テキスト クラス名のリスト クラス名 ノヾラメータリスト 濃度 エキスポートまたはローカル シーケンシャルかガード付きか同期型か 過渡的か永続的か 式 has のリストと操作演算の宣言 ステート遷移図 識別子 テキスト テキスト public, protected, テキスト タイプ 引数宣言のリスト 例外宣言のリスト 式 式 private, または実装化 テキスト , コード , PDL , またはオプジェクト図 テキスト , コード , PDL , またはオプジェクト図 テキスト , コード , PDL , またはオプジェクト図 シーケンシャル , ガード付き , または同期型 アクセスタイプは , そのクラスが属する クラスカテゴリに相対的な , アクセス制限 を書く。 クラスの濃度は , クラスの許されるイン スタンス数て、あり , それは Fig. 7 の記号を使 って表現する。 パラメータの基本形は , パラメタライズ ドクラス ( テンプレートクラス ) とインスタ ンスとして生成されたクラスにのみ適用さ れる。パラメタライズドクラスの場合は , 形式引数のリストをここに書く。インスタ ンスとして生成されたクラスに関しては , そのインスタンスの生成源て、あるクラスの 形式引数に対応する実引数をここに書く。 メタクラスの項目には , クラスのクラス 〔そのクラスを定義しているクラス (CLOS な ど ) 〕を書く。この関係を表すラベルを設け てもよい 上位クラスの欄には , このクラスの直接 ェクト ) は , それらのオプジェクトを作った 的なオプジェクト ( パーシステントなオプジ つの関数の 1 回の実行時間〕に等しい。永続 らを作ったエージェントの寿命〔例 : ひと 的なオプジェクトて、あり , その寿命はそれ ンスの寿命を示す。いちばん多いのは過渡 永続性の欄て、は , そのクラスのインスタ て、ある。 べてのインスタンスのメモリ消費量の合計 メモリ利用の複雑さとは , その中に含むす スティング〕がある場合は , あるクラスの 群居的階層性〔物理的実装的な has 関係のネ リの相対量あるいは絶対量を表す式を書く。 スのひとつのインスタンスが消費するメモ メモリ利用の複雑さの欄には , そのクラ ( たとえばアクセスタイプ ) を設けてもよい ャ〔引数リストなど〕やその他の修飾記号 を設けてもよい。メソッド用にはシグネチ ラベルやその他の修飾記号 ( たとえば濃度 ) 属する属性とメソッドを書く。属性用に メンバの欄には , そのクラスに直接的に ルを設けてもよい の継承源を書く。そういう関係を表すラベ プーチ法の表記法 ( 前編 ) 43
踏み入れる何年も前て、す。 だったと思います。それ以前は FORTRAN はいわば山を動かすのに成功しました。オ プジェクトを使うことによって , 非常に小 さらにその後 , 私たちは DSC1000 という やアセンプラを使っていたわけて、すが , そ 製品を開発しました。これは , 映画やテレ さい限られたマシンアドレス空間の中て、 , の場合 , リアルタイム埋め込み型アプリケ ビのサウンドトラックを編集する製品て、す。 ーションを書くことになり , 割り込みべク 信じられない機能が実現したのて、す。 当初はアナログオーディオ技術を扱う仕様 タを把握して , かなりハードウェアレベル 私たちが作ったサウンドトラック編集シ て、したが , デジタルオーディオ技術が普及 に近づかなければなりませんて、した。 ステムは実に画期的て、 , 時代を大幅に先取 とは するにつれて , デジタルオーディオ技術に いえ , アセンフラ言語て、プログラミングし りしていました。オーディオパッチベイを ていても , 私は常にオプジェクト指向スタ カラーグラフィカル表示し , 完全に自動レ も対応させました。 イアウトて、きました。それほど技術面に詳 こうしてしばらくは順調に進みましたが , イルを忘れませんて、した。なにしろ MIT て、 しくなくても , サウンド編集業界人なら , 1981 年の不景気て、大きな壁にぶつかりまし 7 年間この分野の研究をしていたわけて、すか どこて、切ってどこに挿入するかを座ったま た。この不景気て、は , 娯楽産業がとくに打 ま指示てきました。すべてがグラフィカル 撃を被ったんて、す。そこて、私たちは , それ M ぼでの人工知能の研究のことですか ? まて、のビジネスから手を引き , 投資者から Steiger ええ。私は , MIT て、カール・ヒュ かっリアルタイムて、 , 極めて自動化されて ーウィット教授が指揮していた Actor プロジ 会社を買い戻し , 第 3 のビジネスプランに取 おり , PDP ー 11 上て、なんと 48K バイトのメモ リて、稼働しました。オプジェクト技法を使 りかかりました。つまり , デジタルオーデ ェクトの初期段階に関わっていました。実 のところ私が「 Actor 」と命名したんて、す。 イオ技術をテレコミュニケーションの音声 処理に応用する計画てした。これが起死回 ある日 , みんなて、集まって , この技術をな 生のホームランとなり , 1990 年にはついに んと呼ばうかと頭をひねっていたとき , 「実 株式を公開するまて、に至りました。 にアクテイプだから , Actor ( アクター ) と呼 んてはどうだろう ? 」と提案したところ , そ どの製品もかなりハードウェアに依存 の名前がそのまま残ったのて、す。 1974 年に しているようですね。 は , 「極めてアクテイプなオプジェクト指向 Steiger 確かに既成のハードウェアも使い プログラムを直接実行するためのマシン設 ましたし , さまざまなプロジェクトて、独自 計」をテーマにして修士論文を書きました。 のハードウェアを数多く開発しました。し 私はほかにもたくさんのアプリケーション かし , ソフトウェアにも大きく依存してい をオプジェクト指向スタイルて、書き , 大学 るんて、すよ。私は , 1986 年に退社するまて、 院を出る頃には , この考え方がすっかり身 うことによって , 非常に密度が高く多機能 の DSC 在籍中 , ソフトウェアとシステムエ なプログラムを作り出せたのて、す。 FORT 体に染みついていました。そして「これこそ ンジニアリングの責任の大半を負っていま RAN や手続き型言語て、は到底不可能てし 将来のトレンドだ。再利用可能て、しかもわ した。 DSC の製品はどれも極めてソフトウ かりやすい形を構築する正しいやり方に違 ェア主導て、したね。 た。 いない」と強く確信していました。それが事 C に移行してからは , どうやってオプジ 私たちは , 1978 年に会社を設立して間も なく , ソフトウェアにオプジェクト指向技 夫だったことはご存じのとおりて、す。ただ , ェクト指向プログラミングを実現したので プログラミングの考え方を変えるのには長 術を取り入れました。そして , 最初のプロ すか ? い時間がかかりました。オプジェクト間て、 グラムをすて、にオプジェクト指向スタイル Steiger 命名規則を含め , プログラミング 規約を組み立てました。まず構造体を定義 メッセージをやりとりするコツをつかむの て、書きました。 ただ , 当時はそうしたスタ し , その構造体をもとにしてクラスを定義 イルをサポートした言語はありませんて、し に苦労する人も大勢いました。 します。構造体は , ヒープ領域を割り当て , Smalltalk との レファレンスによって受け渡しを行います。 では , どんな言語で書いたのですか ? 出会い こうして作ったクラスをもとにしてオーガ Steiger 初めは PDP ー 11 アセンプラて、す。 ナイザ関数を定義します。さらに , クラス その後 C に移行しましたが , 部分的には相変 に関数を登録する方法 , ランタイムてメッ わらずアセンプラて、書かなければなりませ ご自身で , やや時代を先取りしすぎて セージ送る方法も整えました。て、すから , んて、した。 PDP ー 11 に代わる C コンパイラが いると感じたことはありませんか ? たとえば , 待ち行列のための構造体を定義 発売されたのは , 確か 1979 年か 80 年あたり Steiger まあ , ありますね。て、も , 私たち 0 巻頭インタビュー 27
れる。単にゞほどほどによい〃標準て、よい のだ。て、も , 我々技術者にとっては , この 教訓を理解するのがなかなか難しい 私が学生時代に大学へ持っていった RoyaI のポータブルタイプライタは , 19 世紀の古 典的な機械式タイプライタと比べてもほん の些細な相違しかなかった ( そう , 1960 年代 になっても機械式タイプライタがまだ作ら れていたのだ ) 。そのキーポードと現在の一 般的なコンピュータキーポードを比較する と , いくつかのノヾンクチュエーションキー ( 訳注 : 英数字以外の文字用のキー ) の位置 が少なくとも違っていたはずだ。いま思い 出してみると , 当時の典型的な IBM タイプ ライタのキーボード配列と本当によく似て 現在のタイプライタキーポードの使い勝 手が安定していることに関しては , IBM に 感謝しなければならないだろう。この会社 は , ほかの企業より、、ほどほどによい いうことをよく理解していたようだ。そし て , 第一級の設計者による製品のリリース も何度か行われた。その結果 , 当然のごと くオフィス機器市場を長い間圧倒してきた。 IBM の Selectric キーポ、一ドの影響は , コン ピュータによるワードプロセッシングが普 通になった現在て、も残っている。 キーボードは不滅 て、も , 早合点してはいけない , 問題もあ ったのだ。 1970 年代後半に最初のホビイス ト用 ( 個人向け ) キーポードが登場したとき を思い出してみよう。その当時はハードウ ェアコストを抑えることが重要だったのて、 , いろいろ野蛮な〃手段が使われた。たと えば , プラスキー ( 十 ) の代わりにイコール サインキー ( = ) をシフトすれば , ゲートを 1 個か 2 個節約て、きる。実際にそうした設計 者もいたにんなことは本当はどちらて、もい いのだ。 Christopher CoIumbus だってイン ドを探すつもりだったのに , アメリカ大陸 に行き当たってしまったのだから ) 。 ニコンビュータのべンダも同じような ものだった。彼らの予算は膨大だったが , 実用的な感覚はそれほどて、もなかった。な にせ , 我々が想像もしないようなさまざま な場所にバックスラッシュキー ( \ ) を隠し たのだから。これは , 初期の UNIX 関係者に は困ったことだった。 もっともほかのユー ザにとっても , よく使うコントロールキー や ALT キーを探し回らなければならなかっ たのて、 , 同じことだ。 シフトキーの追加以外に , ASCII に対応す るために数文字が新たに導入された。それ らは SeIectric ゴルフポールタイプライタに は含まれない文字て、ある。これらの文字は すべて , キリストを思弄したさまよえるユ ダヤ人と同様に , 安定した居住地 ( キーの位 置 ) を持てない運命にあるのだ。キリストの 降臨まて , 彼らに安住の地は見つからない 10 年ほど前に IBM が攻撃を再開した。ビ ッグプルー ( IBM ) が PC て、も市場を支配し , 事実上の標準さえ確立て、きることを知らし めた。そうなると , ほとんどのキーボード が PC と似たものになってきた。その結果 , 私の指も再びくつろいだ気分になれた。新 しいファンクションキーや矢印キーの場所 さえ , 指が覚え始めた。 PC のキーポードは 完璧な標準て、はなかったが , 、、ほどほどによ いクものだった。 そうすると IBM は次に , 拡張 AT キーポー ドを導入した。このキーボ、一ドはいくつか のキーを , 何か , とるに足らない理由て、置 き換えただけのものとしか思えない。そし て次に AppIe が Macintosh を出してきて , ビ ッグプルーを盲目的にまねたものてない とを証明した。さらに Sun がワークステーシ ョン市場を PC とは分離し , 支配力を強め た。ワークスラーションには単なる PC の場 合とは異なり , もっと真剣なニーズがある のを知らされた。ても , それは , もう一度 タッチタイピングに戻っても安全だろうと 思い始めた頃だったのだ programming 聞町咄 私は , ここて、単にタイヒ。ストたちの声だ けを代弁しているのて、はない。コンピュー タがしゃべったり聞いたりすることの必要 性を強く信じている人たちてさえも , キー ポードが使われ続けると思っている。だか ら , アプリケーションて、ホストと対話をす るためには , キーポードがどうしても必要 なのて、ある ( マウスなどのポイント & クリッ クだけて、 , すべてを表現て、きるわけて、はな い ) 。つまり , タイピング技術がポータブル になるほど , そしてタイプすることが日常 的になるほど , より多くのコンヒ。ュータが 日々の暮らしにスムーズに入り込むように なるのだ。人々に対してコンピュータが脅 威て、あるかぎり , 本当の意味て、の一般化は 理だ。 メタキーの存在 我々プログラマにとって , とくに重要な アプリケーションはテキストエデイタて、あ る。以前のコラムて、テキストエデイタに関 する一般的な不満を説明 ( 本誌 1991 年 11 月 号 fText Editors 』参照 ) した。普通我々は , 工ディットしているテキストの変化のよう すを心理的にモデル化している。そして , テキストが期待どおりに ( つまり , 心理的な モデルと同じように ) 変化していることを確 認するためにスクリーンディスプレイを使 う。その確認に必要なものがスクリーンデ イスプレイから視覚的に得られれば , それ は有用なフィードバックといえる。スクリ ーン上 ( あるいは用紙上 ) て、変化を示すなん らかのマークさえ得られれば , 実現方法は どのようなものて、もよい しかし , そのようなマークを生成するこ と以上を望むと難しくなってくる。すべて のキーストロークが表示 ( あるいは印字 ) 可 能な文字を生成するとは限らないのて , テ キストを直接生成せずに何らかの指示を表 すメタキー〃としての扱いが必要になっ Programming on Purpose てくる。そうすると , メタキーストローク 31
- プロ久ラミング道場 , Dr. 望洋の 根元さんの質間て、ある。『通常の配列を動的 にアクセスする方法は理解て、きるのだが , 次のような構造体 struct record { COde name [ 20 ] ; Char や , 文字列 ( 文字の配列 ) char name [ 20 ] ; の配列を動的に確保したうえて、の , ポイン タを利用したアクセスの方法がわからない』 とのことて、ある。 根元さんが理解されているというプログ ラムを推定するに , List 3 のようなものて、あ ると思われる。しかし , 根元さんは , この プログラムを作成したり , 表面上の意味を 理解することはて、きるが , 本質を理解され ているとは思えない メモリの動的確保 ま iList 3 と比較して見ていただきたいの が , List 4 のプログラムて、ある。これらのプ ログラムの実行結果を Fig. 5 に , メモリの確 保・解放部の対比を Fig. 6 に示す。 Fig. 6 からもわかるように , List 3 と Lis t 4 の違いは , call 。 c の第 1 引数が SIZE ( 実質 的には整数値 10 ) て、あるか , 1 て、あるかとい うことだけて、ある。どこにも「、、単なるク整 数を確保せよ』とかド配列ク整数を確保せ よ』といった指定はない こて , 以下の点をしつかりと押さえて いただきたい C 言語では , 厳密な意味での、、配列 ' ' を 動的に確保することはできない。 c 訓 0 c, m 訓 oc などで確保するのは , 何の属 性も持たない単なるメモリの塊りであ る calloc や malloc は , 指定されたとおりの大 きさのメモリの塊りを確保するのて、あり , とくに配列〃を確保するのて、はないのて、 ある。 このことは , Fig. 7 からもわかるだろう。 網掛け部が , 動的に確保したメモリてあり , 整数 1 個を確保・解放するプログラム Li st 〇〇〇〇〇 く stdio. h> 1 : #include く stdlib. h> 2 : # i ncl ude 3 : 4 : int main(void) int 7 : = calloc(), sizeof(int)); 8 : ニ NULL) 9 : pu ts ( " メモリの確保に失敗しました " ) ; 10 : 引 se { ニ 10 0 : printf("*p ニ %d}n" 13 : free(p) ; return ( 0 ) ; 0 ー / * 確保 * / P / * 解放 * / Fig. 5 List 3 と List 4 の実行結果 ( a ) List 3 の実行結果 0 2 3 4 5 ( b ) List 4 の実行結果 100 9 8 7 6 1 Fig. 6 List 3 と List 4 の対比 (a) List 3 ポインタの宣言 i nt メモリの確保 p = calloc(SlZE, sizeof(int) ) ; メモリの解放 free(p) ; (b) List 4 i nt p = calloc(l , sizeof(int)) ; free(p) ; 7 メモリの動的確保 Fig. (a) List 3 ( 配列 ) (b) List 4 ( 1 個 ) pCO] p[2] pC3] pC4] pC5] pC6] p[7] p[8] pC9] Dr. 望洋のプログラミング道場 129
として実用的なパターンそれ自身が一種の 言語を構成することになる。その結果 , タ ッチタイピストとして覚えなければならな ことがさらにひとつ増える。 タイプライタの場合 , 使われるメタキー はごく限られている。つまり , 語と語の間 隔を空けるためのスペースノヾー , 新しい行 を開始するためのリターンキー , タブスト ップまてスキップするためのタブキー , そ して前の文字に上書きするためのバックス べースキーなどだ 0 また , ひとつのキーの 意味を切り換えるためのシフトやシフトロ ックキーもある ( ョーロッパのタイプライタ には "dead キーケもあり , アクセントマー クを文字に上書きするのに使われる ) 。 これらのキーが文書をフォーマットする ための言語を構成するわけだが , これは一 世紀以上もの間タイピストに親しまれてき こに修正キーや修正液を加えれば , フルセットのエディットコマンドが得られ た。覚えるべきことはそれほど多くないが , 際しばしば発生した。 デイタには見向きもしない ということが 長く使い続けてオフィス文書を山のように その結果 , モードを持たないエデイタが ある。また , 複数のエデイタを覚えるにし 作成するのには 0 ほどほどによいク ても , 特殊な機能についてはほとんど , あ ものだ プログラマに好まれるようになり , 普通の るいはまったく覚えようとしない , った。 タイピストが入力しそうもないキーストロ ークが使われ始めた。そういったキースト こうなると , テキストをどれ 反応もある。 ッチタイピストの限界 ロークのそれぞれになんらかの意味を結び だけ速く流暢にタイプしたとしていエデ ィット作業は未知の海域を航海するような つけるわけだが , その意味を暗示て、きるニ コンビュータの出現により , このすべて ーモニック的な結びつけならなおけっこう ものとなり , 効率が悪くなる。 が変わった。初期のコンビュータて、さえも , 私の場合は確信的な後者だ。不思議な方 だ。コントロールキーと ALT キーのそれぞ 法をマスターしてしまった人たちの結末を ( 多くの場合 ) 1 文字のコマンドによる、文 れと一般のキーあるいはその両方と一般 見る機会があまりにも多かった。彼らは知 字と行の削除がサポートされていた。にの のキー , というように 3 種類の組み合わせが 得られる。さらにシフトキーも使えば組み 識の取得に多くの時間やものを投資しすぎ 単純なコマンド群は , その後もっと複雑な てしまったのて、 , 新しいものについては何 メタ言語に置き換えられた。当初のエディ 合わせは 2 倍になる。そうなると限界がない ットコマンドは表示可能な文字て構成され のと同じだ。 ひとつ覚えようとしなかったよー方 , 私は ていた。そのため , 工デイタにはモードが いろいろなシステムを使って仕事をしてい しかし , タッチタイヒ。ストはそのような 必要だった。つまり , テキストの入力 ( 入力 世界に住むことはて、きない。指が記憶て、き る。そのため引 1 種類のエデイタて長い時間 モード ) と , すてに入力したものの変更 ( 工 る操作には限界があるのだから。しかも , タイプすることはなく , また特殊なコマン ディットモードまたは変更モード ) をなんら その操作がエデイタごとに違っているとし ドを使った編集よりも , いくつかの単純な かの方法て、切り換えなければならなかった。 コマンドを使った素早い編集のほうを好ん たら , ひどく困った状況になる。そういう 状況に陥ったときの一般的な反応として , このようなエデイタがエディットモード時 ている。 にテキスト入力をしてしまうと , いろいろ 覚えたエデイタにしがみつきにそのエディ こラいった問題は , WIMP インタフェイ 奇妙なことが発生する可能性があるし , 実 タがどんなに時代遅れになってもほかの工 スて、解決てきるはずだった (WIMP は windo 32 C MAGAZINE 1 3 1
' 93 年 1 月号特別付録 ( 5 〃 1 .2M バイト 8 セク 効に使うツールが同梱されてます。 して管理し , 階層ごとに表示 , 消去 , 移動 タ / トラック MS-DOS フォーマット ) には , などがて、きる C プログラマのためのウインド DOS 5. x 専用メモリ操作 次のプログラムが収録されています。ご使 ウライプラリて、す。ビットユニオンの協力 「 XBLJFF 」 用にあたっては , 自動解凍圧縮ファイルの を得て試食版を収録しました。試食版は , 解凍方法など , さらに詳しい説明を収録し 作成てきるウインドウの数が 10 個まて , ス MS-DOS 5.0 (NEC) CONFIG. SYS て、 D た付録ディスクの README をご一読くださ モールモデルのみの対応 , グラフィックを OS=HIGH とすると BUFFERS=5 以上て、 描写 , 登録する関数およびマウスを使う関 い。 README はテキストファイル形式て、 BUFFERS はメインメモリに確保されてし す。本誌付録ディスク収録の READ. ME 参照 数が使えないなどの制限はありますが , あ まうそうてす。そこ <BUFFERS を一時休 る程度のプログラムなら作れるて、しよう。 止させ , 新たに UMB に BUFFERS を確保す ユーティリティ、 MS-DOS の TYPE コマン ド , あるいはご使用のエデイタ , ワープロ る XBUFF が作られたそうてす。今回の特集 高速再起動「 HSB 」 ソフトて、読むことがて、きます。 てもふれていることから著作権者 (K-CRA FT 氏 ) の協力を得て収録しました。 メモリマップ表示 HSB (High Speed Boot controller, 著 「 ZMAP 」 本誌掲載プログラム 作権者 : Masao 氏 ) とは , ' 92 年 12 月号フリー 本誌特集て、紹介している MS-DOS 下のメ ソフトウェア最新レポートて、紹介した , M モリマップ情報を表示するためのプログラ S ー DOS が起動している状態からメモリディ : MS-DOS メモリ活用技法 TOKUSYU スク接続などの初期検査項目を省略してハ : 実践アルゴリズム戦略 ム , , ZMAP (Zobplus memory MAP) て、す。 STRATE ZMAP は , VMAP ( c. mos 氏作 : ' 92 年 10 ードディスクやフロッピーディスクから高 : 実践 C プログラミング入門 STEPC 月号付録ディスク収録 ) や MS(K-CRAFT 速て再起動するプログラムて、す。ドキュメ : 新 MS-DOS 入門 M SDOS 氏作 ) を参考にして作成されたそうて、すが , ントには「早いと言っても , 再起動先が MS : C 十十入門講座 Try The C 十十 TRYCPP より多くの情報を表示てきるよう機能拡張 ー DOS て、あれば CONFIG. SYS/AUTOEXE : 恥ずかしながらドジりました DOJI されています。とくに , XMS ドライバに X C. BAT の再実行が発生するのて、所詮限度が ESSENCE : プログラミングの工ッセンス MZ (XMs driver ZobpIus : ' 92 年 11 月号付 あります」と書いてありますが , 実際に試し : プログラミング道場 BOH YO 日 録ディスク収録 ) を使用している場合 , より てみるとその早さに驚きます。 : C 言語雑学講座 CZATU 詳しい XMS 情報 (EMB 関連 ) を表示て、きま : X68k 活用講座 X68K マウスで楽しく即興音楽 す。 : ワンポイントプログラミング OPPK 「 nakimaus 」 : 16 ビット C/UNIX C から 32BITC 拡張メモリアクセス : 第 2 種情報処理技術者試験に ' 92 年 12 月号フリーソフトウェア最新レポ JOUHOU クラスライプラリ「 XMEM 」 ートて、紹介した nakimaus( 著作権者 : mau : あつばれご意見番 APPARE 本誌特集て、解説している各種拡張メモリ 氏 / 葵館 ) て、す。「マウスだって泣きたい夜は : C マガ電脳クラブ PUZZLE あるから・・・・・」というコンセプトて、発作的に をアクセスするための C 十十用クラスライプ : 迷走プログラミング N IWA 作られたそうて、すが , 難しいことは考えず ラリ XMEM て、す 0XMEM は XMEM クラス INFO : インフォメーション にマウスをグリグリ動かして即興音楽をお を基本クラスとしそこから継承される EM READ. ME 参照 S メモリを扱う EMS クラスと XMS の EMB メ 楽しみください ユーティリティ モリを扱う XMS クラスを用意しています 環境改善「 DOS GH 」 ' 92 年 5 月号「新 MS ー DOS プログラミング が , C 十十の機能を生かしコンべンショナル メモリやバンクメモリにも簡単に拡張てき 入門」て紹介した READ. ME 参照ューティリ る仕様となっています。使用方法などの詳 DOSHIGH は , MS-DOS 3.3(NEC) の環 ティ ( テキストファイルを画面上て、読むプロ しい内容は本誌特集をご覧ください 境において , MSDOS. SYS の常駐部を HM グラム ) の実行ファイル ( README. EXE ) を A 領域に移動させるものて、す。今回の特集て、 README と同じルートディレクトリに収録 「 Classic Window 」 ふれていることから著作権者 ( Mr. N 。氏 ) の しました。付録ディスクをセットしたドラ 試食版 協力を得て収録しました。収録した DOSH イプにカレントを移し README て READ 「 Classic Window 」はウインドウを階層化 12. EXE には DOSHIGH 以外にもメモリを有 ME ファイルが画面に表示されます。 ディスク内容のお知らせ 179
ln 川 a ⅱ行町ⅱ計 Ma れ門 システム・ワノ Power C Ver. 2. OJ Power Ctrace りません。 アセンプラウインドウ こういった場合には , アセンプ について リ言語レベルて、データのサイズや 型変換の様子を監視することて、 , アセンプラウインドウには , ア ソースプログラムがどのように解 センプリ言語の命令 , レジスタの 釈されていたか理解て、きます。暗 値 , スタックトップ部分の内容が 黙の型変換や , メモリモデルによ 表示されます。 るポインタのサイズの違いの認識 このウインドウは , 以下に示す には , 威力を発揮するて、しよう。 ような場合に使用されます。 ・ C 言語の文に対応したアセンプリ コーティング誤りの 言語を見るとき 検出 ・ライプラリ関数をトレースする 入力ミスにより , 意味が異なっ てしまう場合があります。 ・アセンプリ言語て、記述された関 よくある例としては , 比較演算 数をデバッグするとき 子、、 〃を記述しなくてはならな 通常 , アセンプラウインドウが いところを代入演算子、、 = 〃にして 利用されるのは , おもにアセンプ しまうものがあります。この場合 リ言語て、記述された関数をデバッ は , 文法的には間題がないため , グする場合て、すが , ここて、は C 言語 工ラーとならず発見が困難て、す。 て、記述されたプログラムて、の利用 Fig. 1 は ,List 1 のプログラムを について説明していきます。 power Ctrace のアセンプラウイン 関数呼び出し時の ドウて、見たものて、す。 Fig. 2 は , L 引数の確認 ist 1 のプログラムの 11 行目の比較 演算子を 関数呼び出しの際に , 引数や戻 if (y = x) { 値の型に関して問題が発生するこ のように代入演算子に取り換えた とがあります。 場合のものて、す。 プロトタイプ宣言がなく , 関数 誤って代入演算子を使用してし 呼び出しが前方参照形式の場合に まっても , プログラマに「比較を は , コンパイラは関数呼び出し部 しているつもりてある」という思 分の情報のみて、コードを生成する い込みがある間は , なかなか気づ ため , 呼び出される関数とのイン かないものてす。 タフェイスの整合性がとれなくな アセンプリ言語に変換された命 ります。 令を見れば , 全然異なったコード この問題は , ソースプログラム として現れるため , そういった思 をながめているだけてはなかなか い込みも一発て、吹き飛んてしまう 発見て、きない厄介なもののひとつ てしよう。なお , Fig. 1 , Fig. 2 て、 てす。もちろん大部分のものは , は見やすさを考慮して , / r ーオプシ プロトタイプ宣言を行い , 警告ス ョン ( 変数をレジスタに割り当てな イッチをオンにすれば検出されま い ) を付加してコンパイルしてあり すが , それて、も検出てきなかった ます (Fig. 3 ) 。 ものについては , どうしようもあ 比較演算子、、 = ″を使用したプログラム ( SAMPLE. C ) く stdio. h 〉 1 : #include 2 : 3 : void main( void ) char *strl 5 : *str2 char 6 : char 7 : *sptr ; int 8 : 9 : i nt 10 : 11 : sptr = strl ・ 12 : 13 : else { 14 : sptr = str2 15 : puts( sptr ) 17 : return 19 : } List 1 ” VariabIe Y is 1 t0 variable X. ” VariabIe Y is not equal tO variable X. Fig. 1 List 1 のトレース画面表示 ( アセンプラウインドウ ) 8284 8290 ax 0004 cx 0027 sp 8284 si 009C cs 52C4 es 52b4 00 dO il sl 8286 0004 bx 0170 dx fff6 bp 8284 di 0 圓 0 ds 543 ss 54ee 加 al PO c0 8288 0027 828a 0000 w dx, C0a + bp] 000a disp cs: 0021 8b560a 828C 0001 w dx, [ 08 + bp ] 8284 0024 3b5608 828e 0002 off 0828e 002e 0027 7505 8290 829C w [ 06 + bp] , ax 5480 cs: 0029 894606 SS 8292 0171 5d16e 002C eb06 圓 34 8294 52fd w ax, [ 04 + bp ] 0002 cs: 002e 8b4604 cont 8296 圓 01 w [ 06 + bp] , ax 0031 894606 8298 0170 cs: 0034 90 mov cmp Jne ITIOV Jmp mov nop 置き換えた場合の List 1 のトレース画面表示 8284 8290 ax 0 圓 4 cx 0027 sp 8284 si 009C cs 52C4 es 52b4 00 d0 il sl 8286 0004 bx 0170 dx fff6 bp 8284 di 0 圓 0 ds 54ee ss 54ee z0 al PO c0 8288 0027 828a 0000 w dx, [ 08 + bp ] 0008 disp cs: 0021 8b5608 mov 828C 0001 響 C0a + bp] , dx 8284 0024 89560a mov 828e 0 圓 2 off 0828C dx, dx 0027 85d2 test 8290 829C 54 0 0030 0029 7405 SS Je 8292 0171 w [ 06 + bp ] , ax 5d16C cs: 002b 894606 mov 8294 52fd 0001 0036 cont 002e eb06 Jmp 8296 0001 w ax, [ 04 + bp ] cs: 0030 8 604 mov 8298 0170 w [ 06 + bp ] , ax 0033 894606 mov 829a 04C5 cs : 0036 90 nop Fig. 3 コンノヾイラによる変数の割り当て [ 02 十 bp] strl [ 04 十 bp ] str2 [ 06 + bp ] SPtr [ 08 十 bp ] [Oa + bpJ アドレス 0021 の時点で ax には [ 02 十 bp ] が格納されている lnformation from Compiler Makers 171
特集 M 0S メモリ活用蠡 PSP と呼ばれる 256 バイトのエリアを確保 、、 Z クのときは最終メモリプロックを示し ・ SlZe . します。この MCB の PSP セグメントアド メモリプロックのサイズをパラグラフ単 ます。 位 ( 16 バイト ) て、示します。 レスは , プロセス終了時においてメモリ ・ ownerPSP 次に位置する MCB のセグメントアドレス 解放を行うために利用されます。また環 このメモリプロックを使用するオーナー は , 「 MCB セグメントアドレス十 size 十 1 」て、 プロセス PSP (Program Segment Prefix) 境変数のメモリプロックにおいて , どの 求めることがて、きます (Fig. 3 ) 。 プロセスの環境変数かを判断するのに使 の先頭セグメントが設定されます。プロ MCB は 16 バイトの大きさて、すが , DOS3 セスが起動するとき DOS は実行に必要な われます。 例 : zmap cuexo 具体的な表示を理解していただくために A>zmap く option>@ 例をいくっか紹介しますのて , 参考にし オプション指定に / は必要あ 表示 てください りません。また連続して指定て、きます。 実行例 1 (Fig. B) オプションスイッチー覧を TabIe A に示 環境は Fig. A のとおりて、す。 表示シンポルは Table B のとおりてす。 します。 Table B 表示シンボル Conventional memo & UMB & HMA memo XMS 項目 XMS ドライバの内部リビジョン Driver internal revi メモリプロックの開始アドレスをセグメント単位で Addr 30n 表示 H MA の使用オーナー名 HMA used FFFFh : 0012h の内容を表示してし、砌みで , 設定さ メモリプロックのオーナーセグメント PSP 1 010 : 0000 の表示のときはメモリプロックの開始 れていない場合は表示しないか , 無意味な文字列を表 オフセット 1645 ー A000 の表示のときはメモリプロックの終了 A20Line の状態 A20 line . ON アドレス 以下の表示は XMS ドライバが XMZ のときのみ表示される。 XMZ の拡張 A 円 メモリプロックのサイズをバイト単位で表示 Size にはこのような情報を取得する機能が存在する owner/pa 「 amete 「 オーナー名 / コマンドラインのノヾラメータ HMA 取得時にアプリケーションが要求した HMA サ HMA Use size テパイスドライバのとき , テパイス名を表示 device イズを表示 プロックテパイスの際は , テノヾイスドライバが HMA 最低使用要求サイズ HMA Min size 扱うドライフ数を 1 文字目に表示 EMB の最大八ンドル数 EMB Max handles プログラムかフックする割り込みナンバ Hooked vector 項目 EMB ハンドル Handle フリーエリア く free> EMB プロックの開始アドレス PARA 単位 (1 6 バイト ) Base config. sys が使用するメモリプロック く config> E M B プロックのロックカウント数 Loc ks く shell> command.com EMB プロックのサイズ K バイト単位 Size 環境変数工リア <env. > u sed/free EMB プロックの使用状態 ニ x( + y) く buffers> BUFFERS フリー EMB プロックの最大サイズ K バイト単位 Max free block size x このメモリプロックを占める BUFFER 数 (XMZC なくても表示 ) DOS3 では十 y その他の BUFFER 数 フリー EMB の総サイズ K バイト単位 TOtal free size DOS5 では y は , 未使用の BUFFERS 数 (XMZC なくても表示 ) く files> FILES EMB の総サイズ K バイト単位 EMB TOtal size x このメモリプロックを占める日 LES 数 十 y その他の日 LES 数 CON 日 G. SYS 内のみ表示 VCPI FCBS く fcbs> VC 円の管理する最終アドレス PhysicaI max x 同時にオープンできる FCB 数 address y x 以上の FCB をオープンしようとしたとき , フリー VC 日メモリサイズ , ページ ( 1 ページ : 4K バイ Free VCPI memory クローズしてはならないファイル数 ト ) LASTDRIVE く lastdn.' > CRO レジスタの内容 X . CRO (CPU Register x 最終割り付け可能ドライプ名 0 ) STACKS く stacks> テパッグレジスタの内容 Debug register x スタック数 論理ページと物理ページの対応 Logical paging y 各スタックのサイズバイト 異なるアドレスが割り当てられているべージには Add ress キャラクタテパイス く characte 「一 * が先頭につく device> BANK プロックテパイス <block-device> 存在するバンク番号 I/O Bank No. EMS バンク数と総サイズ K バイト単位 Total Bank Number EMS の存在する開始セグメント Page F 「 ame マッピングされている物理ページ数とセグメントア BMS Mappable pages ドレス 項目 項目 BMS プロック八ンドル Handle EMM 八ンドル Handle BMS プロックのバンク数 Banks 使用ページ数 Pages BMS プロックサイズ K バイト単位 Size 使用ページの合計サイズ K バイト単位 Size EMMJ\ ン・ル フリ—BMS バンク数とサイズ K バイト単位 Name Unallocated Bank EMS メモーフ丿ーベーシサイ K ノ BMS 総バンク数とサイズ K バイト単位 Total Bank Number EMS メモー、ページとサズ KJX Total 特集 MS-DOS メモリ活用技法 53