[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 998] Re: C++ とGUI+α
大体、Hidetosi さんの仰るようで、よいと思います。
struct TADstream {
virtual Segment & readSegment() = 0;
virtual WORD writeSegment(Segment &) = 0;
};
struct TADparser {
virtual BYTE readByte() = 0;
virtual ERCD writeByte() = 0;
};
class StringSegment : public Segment {};
引数や戻り値はどうでもいいとして、こんな感じですよね? Hidetoshi さんの想像は。
<いちおう確認。
僕が昔想定していたのは次のような物です。(SPMC で検索したら見つかった。<Cyclic
の遅い会議室でよかった。^^;;;)
MyWin WinObj_Sample; // ウィンドウオブジェクト(3)
TS_IMAGE imge; // 画像セグメント(2)
fstream rec_TAD; // 実身の主TADレコード(1)
rec_TAD >> image; // 画像セグメントを捜して抽出
WinObj_Sample << image; // ウィンドウに描画
MyWin は「 Window を抽象した構造体」から派生した構造体です。派生時に必要な情報は
すべて与えてあるので(生成子中)、Instance を生成するときには引数は不要になって
います。Event Loop 処理中に呼ばれる雑多な関数も Base class で仮想で定義されてい
て、MyWin で実装されています。
TS_IMAGE は Hidetosi さんだったら、ImageSegment と銘々するだろう Segment からの
Derived class です。
Hidetosi さんと主に考え方の違った部分はその次で、僕は C++ の stream I/O を出来る
限りそのままの形で持ってきたかった部分です。まあ、とにかく、その次の行で、
fstream から ImageSegment に抽出し、その後、MyWin に表示しています。
TADparser は、そんなことで、ios を書き換えることで何とかしようと考えます。あと、
buffering は streambuf が受け持ちますが、multi-record 構造の file を扱うわけです
から、こいつも書き換えねばならないでしょう。
multi-record を、TADstream の集合として表現することも考えられますが、そうなる
と、VLINK と 仮身セグメントの組み合わせをうまく処理できそうにありません。実身を
一つの TADstream と扱うしかないと思います。とくに、仮身セグメントと Link record
とは順番で相互対応がとられているので、実身一つを一つの構造体とし、不用意な
record の入れ替えを防げれば幸いと思います。Tray との操作の協調を考えるならなおさ
らですね。
C++ の標準 stream I/O を改造するのは、作業量が大きくなるのが欠点ですけれど。
# この欠点は、致命的か?! 人手不足の状況下で、、、。(^_^;;;;
# って、個人の話に、人手不足も何もあった物ではないけど。
- Aki.
Hidetosi Ochiai wrote:
> 最近私は、BTRON1 用 C++ Frame work を作ろうかと模索中です。
> もうすぐテストが終わるので、春休み中になんとか作業を
> 進めたいな、と思ってます。
がんばって!僕も来週は四つの授業でテストです。とほほ。
# そのほか、提出しないと不可をもらうことになる宿題が一つ、、、。
> |と、だめですね。後もう一つ、考えられる障害としては、Databox があります
>
> データボックスは、システムのものを使うのをやめて、
> 新たなリソース管理の手段を考えても良いのではないでしょうか。
> どうせプログラムは作り直しになるのですから。
ふむふむ。要は、
1.Data を Process 間で共有できること。
(読み込む必要がある時のみ読み込む)
2.大きな情報を System Call に渡す手段を提供できること。
この二つが Databox の役目ですから、これだけ実現できれば何でもいいわけですもの
ね。
>
>
> なぜ BTRON1 はデータボックスをデータボックス独自のデータ構造に
> したのでしょうか。TAD の枠にはまった形で作れば
> 良かったのに、と思います。
> ついでに言えば、フォントも実行オブジェクトも TAD のセグメントにして、
> 実身のレコードには TAD しか書き込めないようにすれば良かったのですが。
>
効率の問題でしょう。より厳しく書式が決まっていれば、より早く処理できる。全体の大
きさも小さくなると。TAD は柔軟すぎて、特定用途の情報を入れて置くには自由度が大き
すぎるのではないかな? たぶん、、、。まあ、今となっては、どれほど影響しているか
しれませんが。
# いまだに、286やPDAの世界では重要事項かもしれませんよ。:)
# にしても、実時間 TAD がみたい! TACL として出るのかなぁ?
>
>
> ===
> 落合秀俊 名古屋大学工学部情報工学科
> h953046b@ice.nuie.nagoya-u.ac.jp