[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[b-free: 1088] Re: C++と GUI+ α
/* In [b-free: 1079] Re: C++とGUI+α
Hideaki Suzuki <h1suzuki@bridgew.edu> Wrote: */
|> 前にメールに書いたものから、かなり変更しました(計画性がない...)。
|> クラス名には接頭辞'B'を付けることにしました。
|> 一応 BTRON の B です。(TAD は BTRON だけのものではない、という話も)
|
|OOP は統一された設計方法が確立されていないと言うのが実状ですものね。「じっと問題をにらんで、
|えいやぁ!」と設計を決めてみないことには、始まらない。
|一寸やって、うまく行かなかったら、問題点を究明して、Member の修正で効くならそれだけ。さもなけ
|れば、Object の割り振りから考え直さないといけない。中規模ならばやり直しも少ないでしょうが、大
|規模だと、Object の切り直しはしんどいですからねぇ。「じっと問題をにらんで、、、」の部分からな
|かなか先に行けませんよ。まあ、Guideline みたいなものは色々云われていて、結構それ通りにやれば
|うまく行きますけど、最後の部分は”感”だとおもいます。一度、Object の切り方さえ分かってしまえ
|ば、作業するだけなんだけど。
同感です。よーく考えて設計しないと、後になってかなりの変更を
余儀なくされます。が、よく考えたつもりでも実装の段階になって
足りない機能に気付いて class 階層の練り直しが何度かあります。
オブジェクト指向は、我慢強さが必要のような感じがします。
オブジェクト指向で開発するときは、1人でやるより
2〜3人で議論しながら設計していくのが良いような気がします。
1人だと、統一感のない interface でも見逃がしがちですし、
途中で投げ出すことも多いようです。
最近、作りかけでほかってあるものが多いのも、1人でやっているせいかも。
|そういうわけで、初めての TAD 処理系 class を作る落合さんはしんどいと思いますが、頑張って下さ
|い。出来てしまえば、色々な意味で、TAD 処理系の model になるでしょうからね。
今、作っている部分は Byte列の TAD から Segment に
分割する部分ですが、これは TAD の字句解析に当たると思います。
ここが完成したら、今度は Segment列の解析に当たる構文解析の
部分を考える必要がありそうですね。
|> TADStream と ByteStream の多重継承はやめました。
|> さらに、Input と Output に分けました。
|> クラス名としては、BTADInputStream,BTADOutputStream,
|> BByteInputStream,BByteOutputStream としました。
|> (我ながら、名前のセンスのなさに悲しくなります)
|
|そうですか?そんなにひどくはないと思うけど、、、。^_^;若干の希望があるとすれば、もう少し短く
|してくれると、嬉しいかな。
短い名前で良いのが思い浮ばなかったので、だらだらと長い名前にしました。
|File Input Stream => ifstream
|
|みたいな感じに。あと、C++ なので、 TADStream より TADstream の方が良い気がするけど、それはか
|なり個人的な意見なので聞き流して結構です。
C++ なので、というのかよく分からないのですが、
そういう命名の慣習とかあるのでしょうか。
|> で、file pointer は ByteStream も TADStream も
|> 内部的には持っていることになりますが、利用者が直接接っする
|> ことはないです。
|> BByteInputStream には先読みの機能を付けました。
|> BTADStream には付けていません。たしかにあっても良いかと思います。
|>
|> | TADstream >> TADSegment;
|> | TADstream << TADSegment;
|> |
|> |はあると便利でしょうね。(これは、TADSegment の実装でしょうが、、、)
|>
|> ">>"のほうは、TADStream から先読みして ID を調べておいて
|> ID に合った Segment を作っておいてそれに読み込む、
|> という感じになりますね。
|> 私は、ユーザーが自力で ID に合った Segment を作るのではなく、
|> TADStream が適切な Segment を作成してそれに読み込んで、
|> 読み込まれた Segment のポインタを返すようにしました。
なんか、日本語がおかしいですね。
Segment のポインタと言うのは Stream の中の位置、ではなく
作成された Segment の instance の メモリのポインタのことです。
|> どちらでも良いような気がします。両方あるほうが良いかな。
|
|今流の方法として、iterater class を file pointer に使うという方法もありますね。
STL のコンテナとしても使えるようにしようか、と思ったのですが、
あまり徳なことがないようなので、やりませんでした。
find は嬉しいかもしれないですが、sort できてもしょうかないですし。
|> TAD の Segment は ID だけでなく sub ID があって、
|> 同じ ID でも sub ID が異なるとまったく別物になるので
|> (文字修飾指定付箋を除く)、sub ID ごとに別クラスにしてます。
|> 全ての Segment の基底になる BSegment に sub ID と ATTR を
|> 入れてしまいました。sub ID を使わない Segment だと
|> 無駄ですが、まあいいんじゃないかな、と。
|
|僕もこのくらいの無駄は良いと思います。ID はさしずめ、private static で const の getter 関数で
|数値を得るのかな?
すこし話が飛びますが、
BSegment (のサブクラス)はあくまでデータだ、と考えると、
Segment ごとに固有のデータは private にせずに public にしても
良いのではないか、と思っているのですが、
やっぱり private にして get,set のメソッドを作るのが
一番なのでしょうか。
|これは効率の話ですが、すべての BSegment を BTRON の標準構造体 (API 用)の wrapper にするという
|方法もありますね。利点は file からの読み込みや System Call への受け渡しが楽などが挙げられま
|す。
|欠点は、API 用の構造体が pack されてやらなくてはいけないところでしょうか。<大した欠点ではな
|いか。
マシンのエンディアンを考えると、構造体をそのまま
stream に読み書きするのはやめたほうが良いのではないか、と
考えています。
それに、定義されている構造体を良く見ると、
sub ID のあるセグメントは共通部分だけですし、
複雑な構造のセグメントも構造体に入っているのは
一部だけですよ。
|> ID と sub ID を指定すると、それに合った BSegment の
|> サブクラスを作成する BSegmentMaker というクラスも
|> 作りました。
|
|これは便利ですね。:-)
これも説明の日本語がなんか変ですね。
「ID と sub ID を指定すると、その ID,sub ID の Segment を
実装したクラス(それは BSegment のサブクラス)の
instance を作成する BSegmentMaker というクラスも
作りました。」
が本当です。
プログラムする前に日本語の勉強をしたほうか良いかも。
|> 言葉で説明しても分かりにくいですね。
|> もしなんでしたら作りかけのソースを送りますよ。
|> STL 使っているのでコンパイラと環境を選びますが。
:
| よろしくお願いします。
| まあ、実行とかはしないでしょうが、試しに、BC++ 5.0J に通してみるかもしれません。
| <Syntax Error とかのため
| BC++ で通用するでしょうか?
いまのところ、私は Visual C++ 4.0 で作っています。
Code Warrior が出たらそちらにしますが。
まだ、テストできるほど実装は進んでません。
クラスごとに個別にコンパイルして、
文法チェックしているだけです。
早いところ、実際の TAD を読み書きするテストが
できるくらいまでもっていきたいです。
===
落合秀俊 名古屋大学工学部情報工学科
h953046b@ice.nuie.nagoya-u.ac.jp