[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
|