iostream実装について考察

若年寄(もう若くない) @kikairoya

kwsk RT @Cryolite: ふむ， std::istream と std::ostream の双方の役割を果たすものが1つのクラスとして表現されるべき理由はいくつか見つかったけれどより強い理由が欲しいにぇ，状態．

Akso de la Malbono @Cryolite

@kikairoya 例えば TCP に対する入出力ストリームだと，やはり入出力双方でエラー状態を共有したいですよにぇ，とか．

Akso de la Malbono @Cryolite

@kikairoya あと，単一の streambuf を入出力双方で共有する場合は streambuf の lifetime 管理がしんどくなるよにぇ，とか．ただ，「単一の streambuf を入出力双方で共有する」というのが実際的な場面でどこまで強く望まれるものなのか……．

若年寄(もう若くない) @kikairoya

@Cryolite なるほろ・・・しかしそれならios_baseから菱形継承ではなく、個別に継承させてiostreamから(i|o)streamに委譲するのが素直な気も

Akso de la Malbono @Cryolite

@kikairoya はい，それは検討しました．たとえば， iostream に istream &, ostream & への暗黙の変換を定義すれば継承と同等の使い勝手となりますが，

Akso de la Malbono @Cryolite

@kikairoya ユーザ定義の iostream を実装する者は，例えば istream, ostream のエラー状態を同期するよう気をつけねばならず，実装の負荷が高いといえます．

Akso de la Malbono @Cryolite

@kikairoya あと， tie による ostream => istream のエラー状態同期を双方向に拡張することも検討してみましたが，相互依存関係でかつ lifetime 管理が難しくなるので厳しいかな，と．

若年寄(もう若くない) @kikairoya

現状stream層で管理してるのはバッファとポインタだけでフラグは全部ios_baseでは･･･というところまで考えて、ああだから仮想継承してるのかという結論に落ち着いた

Akso de la Malbono @Cryolite

@kikairoya いや， istream / ostream の層が独自に保持している状態って gcount / pcount の値ぐらいで，あとは (例えば streambuf へのポインタなんかもすべて) basic_ios / ios_base が保持してますですよ．

Akso de la Malbono @Cryolite

basic_streambuf って controlled input sequence を [持っている|持っていない]， controlled output sequence を [持っている|持っていない] の任意の組み合わせを1つの型でやる設計なので，

zak @zakkas783

やっぱ標準ライブラリの(深い)考察っておもしろい。かつての制作動機や思考までトレースされると大興奮。

Akso de la Malbono @Cryolite

入出力各々に対して basic_streambuf を各々保持する必要ない．

普通のC++使い、銀天すばる @SubaruG

標準はしっかり考えられて作られてるから、標準より良いものを作ろうと思ったら、現状のデザインを一度崩さないと無理、ってことなのですかねー。少なくともC++では。

普通のC++使い、銀天すばる @SubaruG

ポリシーベースの入出力ライブラリとか作れそうなもんですが。

Akso de la Malbono @Cryolite

さらに，書き込み・読み込みの stream position が常に同じ場所を指すとかいう制約が置かれている場合もあるので，そういう場合には入出力双方で同一の basic_streambuf を「持つ必要がある．」 (e.g. std::filebuf)

Akso de la Malbono @Cryolite

@SubaruG Boost.Iostream で良いんではないですか？ C++ 標準の入出力インタフェイスへの後方互換も一瞬で提供できますし． http://bit.ly/ctULvk

Akso de la Malbono @Cryolite

@SubaruG 例えば， controlled [入|出]力 seq. の有無， associated seq. が入出力で分離しているかいないか，シークできるか，シークが入出力で独立か，が http://bit.ly/a9B1Du の階層では不満とかなら別ですけれど．

zak @zakkas783

IOstreamを拡張しようとした人ならわかる、Boost.Iostreamのイカレ度。

Akso de la Malbono @Cryolite

Boost.Iostreams おいしいです(^q^) QT @zakkas783: IOstreamを拡張しようとした人ならわかる、Boost.Iostreamのイカレ度。

zak @zakkas783

Hamigaki.Audioは本気ですごいと思った。>Boost.Iostream