[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[b-free: 813] Re: B-Free AP の開発環境



Aki です。


 In "[b-free: 803] Re: B-Free APの開発環境" with Hidetosi Ochiai ,
 (01:37:21 AM +0900 in November 13,1997)
 - h953046b wrote.

|今日は、落合です。
|
|   ||以前、C++ で TAD クラスを作ろうとしたことがあります。
|   ||けっきょく途中やりでほかったままですが。
|   |僕は、同じ穴の狢。(ひょ〜)
|   |まあ、僕の場合は、「手も着けていない」のですが。^^;
|
|あら、そうだったんですか。

僕は、他にも、やりかけの物だらけ、、、、。
きっと、よっぽど耐えしょうがないのか、はたまた、すごく時間の使い方が下
手で、直ぐに追いつめられそれどころじゃなくなるのか、、、。うーむ。それ
にしても、ぼくって、ろくな者ではない、、、?
^^;;;;


|私の場合、作り始めたはいいけど
|設計が悪くてづまづいてしまいました。

OOP の設計は試行錯誤ばかりですね。^^


|
|   ||TAD をオブジェクト指向のライブラリにしようとすると、
|   ||文字(固定長セグメント)の扱いが非常に難しいです。
|   ||可変長セグメントはそれぞれのセグメントを
|   ||そのままクラスにすればよいのですが、
|   ||文字は「1文字 - 1オブジェクト」が良いのか
|   ||「1続きの文字列(可変長セグメントに挟まれた部分) - 1オブジェクト」
|   ||が良いのか、難しいところです。
|   ||
|   ||「1文字 - 1オブジェクト」のほうがすっきりしていて
|   ||良いのですが、どう考えても効率悪いですから、
|   ||文字列のほうが良いのかな、とも思います。
|   |
|   |これについては、2通り僕は考えていました。
|   | 1 文字列は既存の String クラスなどを使う。
|
|文字コードが TRON コードになるので、流用するにしても
|いろいろ改造が必要そうですね。

えっと、最新の STL は多バイト長文字を扱えるんじゃなかったっけ?



|   | 2 文字列も従えるTADと言う、基底クラスを作る。
|   |
|   |どちらにしろ、文字、一文字をオブジェクトにする意味はあまり無いと思
いま
|   |す。オブジェクトにすると言うことは、それに対する操作が規定できると
いう
|   |事ですから。一文字だとあまり可能な操作を思いつきません。それに、何
か文
|   |字列中で一文字を操作したいときは、すぐに、String の変換演算子が使
えると
|   |思います。
|
|TAD って「1セグメント」と「1文字」が等価ですよね。
|ある文字列の途中にセグメントを挿入しようとするとき、
|「1続きの文字列 - 1オブジェクト」だと困ってしまいます。

うーむ。

TADbase = String+TADbase

というのはどうでしょう?
他には、Stringも、TADbase(と仮にTAD の総基底クラスを呼びますが)から派生
させておくとか。
後者の場合、継承のコストが問題になるかなぁ?


|今思い付いたのですが、従来「文字列」と扱われていたところを
|BTRON ではに置き換えて考える、というのはどうでしょうか。

これは、「では文章データに置き換えて」ですね。:)

|ここでいう「文章データ」とは TAD 規格書の BNF での TAD の定義
|で使われている非終端記号のことです。
|文字列の代わりになるのは TAD ではなく
|TAD の構成要素である「文章データ」のほうが適当のように思います。
|ですから、ちょっと前に話題になっていた、
|「実身名に TAD を許す」というのも
|「実身名に文章データを許す」としてみてはどうでしょう。

えっと、これは多重継承を使うという案でしょうか?

  String → TAD, 文章データ

という事かな。
でも、それだと、何か良いことあります?

    String   → 文章データ → TAD
  図形要素 → 図形データ → TAD

の方がすっきりしていると思うのだけど。
「基底≡抽象化、継承≡特殊化、Template≡汎用化」の原則ですから。
多重継承を使うのは主に、根っこの違う二つ以上の物を組み合わせて新しい物
を作るときですよね。



|   ||あと、仮身セグメントだけではリンクが表現できません。
|   ||だから、仮身クラスは「仮身セグメント+リンクレコード」
|   ||にしなくてはなりません。
|   |これは、僕も、すごく困った。
|   |で、当時考えてたことは、
|   |
|   |ifstream >> vlink
|   |
|   |で、セグメントもレコードも、自動的に取ってくればいいじゃないかと。
|   |
|   |ofstream << vlink
|   |
|   |で、両方書き出せばいいと。と言うことで、常に同時扱い。
|   |それだけで良いんじゃないかな?
|
|仮身セグメントなしでリンクレコードがある事がありますが、
|そういうときはどうしましょう。

単に、仮身セグメントへの Pointer を Null で良いんじゃないかしら?


|あと、ファイルストリームと言っても、
|TAD 以外のレコードをどうするのか、という問題があります。
|1つのレコードを1ストリーム、複数のストリームが集まって
|1つの実身ができている、というようにしたとしても、
|リンクはどうするの?という事になるし、
|なかなかうまい事いきませんね。

これは、大変ですよね。
一つの可能性としては、ファイルのバッファリングを作り直すことです。えっ
と、C++ のファイルストリームと云っても一つのクラスではなく、いくつかの
クラスの継承関係で出来ているわけですよね?で、上記の入出力は「書式入出
力(ios)」に当たるわけです。それとは対照的に、ファイル操作を担っているの
は、class filebuf や class fstreambase とかです。この辺で、開いたファイ
ルとバッファとの接続とかやってますが、これを修正すればリンクの整合性と
か取れるように成るんじゃないのだろうか? もうほとんど、BTRON1の
ファイルマネージャを丸ごとクラス化するような感じですけど(苦笑)

# これで「実身」という物を抽象できそう。^^
# もはや、リンクレコードと仮身の順番の対応とか
# 気にしなくて良くなるしね。


|   ||せっかくだから、BTRON 専用ではなくて、どの OS でも
|   ||使えるようにしたほうが良いように思いますが、
|   ||どうなんでしょう。
|   |
|   |それは、難しいと思います。
|   |なにせ、TRON Application Databus ですから。
|   |難しいと言うより、意味がないと言った方が近いかも。
|   |
|   |# 他の OS に、TAD 表示用の環境を作ればいくらか
|   |# 意味もでるだろけど。
|
|その事を考えてのことです。
|ほかの OS 上で TAD ビュアを作るときなどに使えたら
|良いのではないのか、と思ったわけです。

なるほど。
そうすると、各クラスに表示部も作る気ですね。
さしずめ、

  constream << aTAD;

と言うところでしょうか。:)

|まあ、どう考えてもリンクは表現できませんが。

仮身の絵 ^^;;;

|
|===
|  落合秀俊   名古屋大学工学部情報工学科
|  h953046b@ice.nuie.nagoya-u.ac.jp
|