エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
遅延I/Oとメモリリーク - maoeのブログ
先週の土曜日にReal World Haskell読書会に行ってきた。とても有意義な読書会だったのだけど、遅延I/Oと... 先週の土曜日にReal World Haskell読書会に行ってきた。とても有意義な読書会だったのだけど、遅延I/Oとメモリリークに関して腑に落ちない点があったので書いてみる。 遅延I/Oの例 Real World Haskell 7.4.1節の注意マークのところ、邦訳版から引用すると、 上の例で、inpStrを使った一箇所(つまりprocessDataを呼んだところ)を過ぎてから、inpStrを捕まえようとすると、プログラムのメモリ効率が失われてしまいます。 という部分が気になっている。 本を持っていない方のために、わかりやすいサンプルプログラムを例に挙げる。Haskellではテキストファイルを読んでそのまま出力するプログラムをこう書くことができる。 ここで注目すべき点は、BS.readFileは遅延I/Oとなっているので、実際に読むファイルがメモリに載らない大きなものであったとしても、