std.stdioをstd.ioという名前にしない浅い理由はstd.stdioがstandard ioライブラリだからで、深い理由はstd.ioがどういうものであるべきか見えていないから、かな。
2011-02-26 18:22:18@Rayerd templateは静的バインドが基本だから、I/Oのように実行時に何が扱われるのかわからない場合の扱いが難しいのだと考えている。
2011-02-26 22:33:32@Rayerd 最近@rsinfuさんのBuffer生ざらしioの再設計みたいなことをローカルでやってるんですが、関連してC/C++のstreamとか見ているとテキストモードとかバッファリングとか基本ランタイムの制御ばっかりで静的に固めるものは無い(歴史が古いのもあるが)。
2011-02-27 00:53:16@Rayed 一方templateでI/Fを固めるtango(Conduit)とかBuffered!Portとか考えると、byLineみたいにひとつのことだけやるには効率いい実装が選択できる。
2011-02-27 00:57:31が、標準入力とかテキスト・バイナリ何でも入ってくるものへの処理は結局ランタイムに分岐が必要になるので、テンプレートで処理をがっちり決めると逆に扱いづらくなってしまう。
2011-02-27 00:58:13たとえばEncodingを判別してテキストを読み出すStreamを考えても、最初はバイナリでバッファリングし、Encoding判別後はchar/wcharとか型を分ける必要がある。バッファリング前提だと中途半端なバッファの受け渡しとかが面倒になる。
2011-02-27 01:00:05@Rayerd もちろんできる。がチャンクサイズのためだけに型をインスタンス化するのは逆にCoadBloatするだけ。実行時にバッファを可変することはまず無いので、コンストラクタに値を渡してやっても実行時コストは変わらない。
2011-02-27 01:03:37少なくとも読み出しに関してはBufferingし、それをbyLineとかで直に触らないと効率が上がらない。つまりRange I/Fだけだとだめ。ただこれにRange I/Fをかぶせることは出来るので、そういったWrapperを書くことになると思う。
2011-02-27 01:05:59NonBlockingとか考え始めると、Rangeになじまなくなるところは増えそうだが。Rangeは計算量がその定義なので、StreamのRange化はForwardRangeぐらいまでしか無理だと思う。(Bidiはseekが必要なのでO(1)にできないハズ)
2011-02-27 01:08:25自分としてはIOはバイナリのやり取りが効率的に出来ることが第一だと思っている。テキスト関連はそれにかぶせるFilterの領分(改行とか行バッファリングとかEncodingとか)。
2011-02-27 01:10:57ちなみにA先生のstd.stream2は、IOというよりSerializeの範疇だと思っている。その意味ではMessagePack for Dが(ry
2011-02-27 01:12:35@Rayerd 行列挙とか、やることを1つに決めるなら一番効率のよい実装(バッファリング+Sliceで行列挙)を選択できる利点はある。
2011-02-27 01:15:29@9rnsr それはpolicyですかね。あと、標準入出力やファイル、ネットワークなどなどにアクセスするためのインタフェースを統一することはできそうですかね?
2011-02-27 01:22:27@Rayerd 標準入出力は読み出し・書き込みのみのFileと考えればいい。ネットワークはコネクション確立後ならファイルと同様に扱えると(今のところ)考えている。boost.asioとかみてもstream I/Fがあるし。
2011-02-27 01:25:22@Rayerd Encoding判別のためにバイナリをチャンクに読み込む→判別後、そのデータを別のStreamに渡す必要がある。この「別のStream」は実行時に決まるので、元のバイナリから一本道にテンプレートで構成できない
2011-02-27 01:32:09なんだかここまで明らかになっていてどうしてまだstd.ioやstd.stream2が存在しないのか不思議に思えてくる。俺自身は深いところまでは理解していないけれど…
2011-02-27 01:31:23