Re: Streamについて

投稿ツリー


このトピックの投稿一覧へ

なし Re: Streamについて

msg# 1.6.1.1.1.1
depth:
5
前の投稿 - 次の投稿 | 親投稿 - 子投稿.1 | 投稿日時 2010/7/26 14:05
rsinfu  新米   投稿数: 4
引用:
私はバッファリングをHandleで行い、Range対応をフリー関数で行なおうとしましたが、Portみたいなものでもいいかも知れませんね。
ただ、概念が Handle -> Port -> Range の3層に分かれてしまうため、複雑さ(初見での理解のし難さ)も増えてしまいそうなのが難点でしょうか。
また、テキストとバイナリの途中での切り替えも難しそうかもと最後にコメントされていますね。


僕も Port の複雑さは嫌いです.
Device -> Reader/Writer という名前なら理解しやすいかなぁと思いますが,根本的に多段なので面倒臭いですね.

ただ,I/O主体がバッファのコントロールを握っていると便利で,
- byLine はバッファの先頭から改行コードを探していって,見つかったところまでのスライスを返すだけで良い
- byChunk はバッファをそのまま返せば良いので,コピーがまったく発生しない
- 大きなデータはバッファリングせず,そのままデバイスに書き込める

…というような,効率面のメリットがあったりします.


引用:
正直、自分でbyLineみたいなのを真面目に作ったことがないので、バッファにどのような操作が必要なのか分かっていなかったりします。(なので私の実装ではubyte[]に読み込ませるだけです)
ところで、byLineみたいなテキストの取り扱いは、バッファが必須になるのでしょうか?


テキストのように「ちまちました」「長さ不定な」ものの読み込みにはバッファ必須だと思います.
アンバッファで行読み込みをすると,1バイトごとにシステムコール (read,recv 等) を呼び出して非効率すぎるんで….
手元にバッファがあれば,単にバッファの先頭から改行コードまでメモリを読むだけで済みます.

テキスト読み込みの Port に dchar[] バッファを持たせたいという部分へのツッコミなら,僕も変かなぁと思い始めてます.
僕にとって「テキストI/O」は文字コード変換をともなうので,バッファ内容の整合性を気にしてdchar型を付けたかったのですが,バッファリングは生の ubyte[] でやった方が柔軟で良さそうです.
必要なときに dchar へ変換するなりした方がまともだなと.
投票数:22 平均点:5.00
返信する

この投稿に返信する

題名
ゲスト名
投稿本文

  条件検索へ


メインメニュー

ログイン

ユーザー名:


パスワード:





パスワード紛失  |新規登録

Menu