[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1003] Re: C++ と GUI+α
/* In [b-free: 998] Re: C++ と GUI+α
Hideaki Suzuki <h1suzuki@bridgew.edu> Wrote: */
|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 さんの想像は。
|<いちおう確認。
TADStream は そんな感じですが、TADParser は違いますね。
(やっぱり言葉で書かずに形式的に書いたほうが良かったかな)
TADParser は byte列から segment を切り出す class で、
読み書き対象の ByteStream に readBytes() writeBytes() が
実装されている、というしくみです。
図にしてみました。
+----------------+
| TADStream |
+----------------+
|readSegment()=0 |
|writeSegment()=0|
+-----+----------+
+--------------+ |
+---+ ByteStream | A
| +--------------+ |
| |readBytes()=0 | |
| |writeBytes()=0| +-------------+
| +------+-------+ | |
| | | |
| A | |
| | | |
| +----------|---------+ |
| | | | |
| +-+----------+---+ +-+---+--------+
+------+------+ |RealObjectStream| | TrayStream |
| TADParser | +----------------+ +--------------+
+-------------+ |readSegment() | |readSegment() |
|readSegment()| |writeSegment() | |writeSegment()|
+------+------+ |readBytes() | |readBytes() |
| |writeBytes() | |writeBytes() |
| +------<>--------+ +-----<>-------+
| | |
+---------------+-------------------+
図注: 'A' は継承を表しています。また、線の端に '<>' があるのは
集約(contain)を表し、両端になにも付いていない線は関連を表します。
RealObjectStream と TrayStream はTADStream と ByteStream の両方を
継承していますが、ByteStream は抽象class であり、java で言う
interface のようなものと考えてください。
RealObjectStream は読み書きの処理をほとんど TADParser に
任せてしまいますが、link だけは自前で処理します。
TrayStream は segment ごとに区切って送られてきた場合は
自前で処理しますが、区切られていない文章レコード・図形レコードの
場合は TADParser を利用します。
|Hidetosi さんと主に考え方の違った部分はその次で、僕は C++ の stream I/O を出来る
|限りそのままの形で持ってきたかった部分です。まあ、とにかく、その次の行で、
私も最初は C++ 標準の stream を使うのを考えていたのですが、
link を考えるとどうしても上手くいかないので、諦めました。
|multi-record を、TADstream の集合として表現することも考えられますが、そうなる
|と、VLINK と 仮身セグメントの組み合わせをうまく処理できそうにありません。実身を
|一つの TADstream と扱うしかないと思います。とくに、仮身セグメントと Link record
|とは順番で相互対応がとられているので、実身一つを一つの構造体とし、不用意な
|record の入れ替えを防げれば幸いと思います。Tray との操作の協調を考えるならなおさ
|らですね。
私はこう割り切りました。
「1つの実身には TADレコードは1つで link は TADと同時に扱う。
他のレコードのサポートはしない」
普通はこれで足りますよね。特殊なことをしたい場合は
API を直接いじくってもらいます。
|> データボックスは、システムのものを使うのをやめて、
|> 新たなリソース管理の手段を考えても良いのではないでしょうか。
|> どうせプログラムは作り直しになるのですから。
|
|ふむふむ。要は、
|
| 1.Data を Process 間で共有できること。
| (読み込む必要がある時のみ読み込む)
| 2.大きな情報を System Call に渡す手段を提供できること。
|
|この二つが Databox の役目ですから、これだけ実現できれば何でもいいわけですもの
|ね。
標準の物と独自の物のどっちが作るのが簡単かは分からないですが、
新たに作ったほうが使いやすくなるでしょうね。
|> なぜ BTRON1 はデータボックスをデータボックス独自のデータ構造に
|> したのでしょうか。TAD の枠にはまった形で作れば
|> 良かったのに、と思います。
|> ついでに言えば、フォントも実行オブジェクトも TAD のセグメントにして、
|> 実身のレコードには TAD しか書き込めないようにすれば良かったのですが。
|>
|効率の問題でしょう。より厳しく書式が決まっていれば、より早く処理できる。全体の大
|きさも小さくなると。TAD は柔軟すぎて、特定用途の情報を入れて置くには自由度が大き
|すぎるのではないかな? たぶん、、、。まあ、今となっては、どれほど影響しているか
|しれませんが。
いやいや、今のデータ構造をそのまま「データボックスセグメント」
として TAD に取り込むだけです。
こうした上で、ファイル I/O の単位をbyte列にせずに
segment単位でしか読み書きできないようにすれば、
プログラムも簡単になるし、
link を別レコードに分離しなくても済むだろう、と
思うのです。
===
落合秀俊 名古屋大学工学部情報工学科
h953046b@ice.nuie.nagoya-u.ac.jp