[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