3

だから私は設定ファイルを読んでいるプロジェクトをやっています。構成ファイルは、「D 1 1」、「C 2 2」などの文字列のリストにすぎません。C# で読み取り/書き込みを行ったことがないので、オンラインで調べて、ある種の表現を見つけることを期待しました。 C/C++ .eof() の。見つかりませんでした。

だから私が持っているのは...

TextReader tr = new StreamReader("/mypath");

ファイルの最後まで読むことがわかったオンラインのすべての例の中で、発生し続けた2つの例は次のとおりです。

while ((line = tr.ReadLine() != null)

また

while (tr.Peek() >= 0)

StreamReader には bool EndOfStream があることに気付きましたが、誰もそれを提案していなかったため、そのソリューションに何か問題があると思いました。結局こんな感じでやってみた…

while (!(tr as StreamReader).EndOfStream)

そしてそれはうまくいくようです。

だから私の質問は、TextReader を StreamReader としてキャストし、EndOfStream をチェックする際に問題が発生するのでしょうか?

4

6 に答える 6

5

明らかな欠点の1つは、コードがStreamReader固有になることです。だけで簡単にコードを書けるTextReaderので、そうしてみませんか？そうすれば、StringReader単体テストなどに（または同様のものを）使用する必要がある場合でも、問題は発生しません。

個人的には、常に「nullになるまで行を読み取る」アプローチを使用します。使用できるように拡張メソッドを使用することもあります。

foreach (string line in reader.EnumerateLines())
{
}

EnumerateLinesTextReaderその場合、イテレータブロックを使用する際の拡張メソッドになります。（これは、LINQなどにも簡単に使用できることを意味します。）

于 2011-11-08T08:27:31.807 に答える
3

または、を使用ReadAllLinesしてコードを簡略化することもできます。

http://msdn.microsoft.com/en-us/library/s2tte0y1.aspx

このようにして、.NETにすべてのEOF / EOL管理を任せ、コンテンツに集中します。

于 2011-11-08T08:26:23.977 に答える
1

いいえ、問題は発生しません。EndToStreamの実装を見ると、バッファにまだデータがあるかどうかをチェックするだけで、ない場合は、基になるストリームからさらにデータを読み取ることができるかどうかがわかります。

public bool EndOfStream
{
    get
    {
        if (this.stream == null)
        {
            __Error.ReaderClosed();
        }
        if (this.charPos < this.charLen)
        {
            return false;
        }
        int num = this.ReadBuffer();
        return num == 0;
    }
}

もちろん、そのようにコードをキャストすると、StreamReaderが実際のリーダーのタイプであることに依存することになります。

于 2011-11-08T08:28:34.313 に答える
0

StreamReaderは、StreamReaderがTextReaderから継承するという意味で、 TextReaderの特殊化です。したがって、問題はないはずです。:)

于 2011-11-08T08:27:19.093 に答える
0

おそらく、すべてを文字列に読み取ってから解析します: StreamReader.ReadToEnd()

using (StreamReader sr = new StreamReader(path)) 
{
  //This allows you to do one Read operation.
  string contents = sr.ReadToEnd());
}
于 2011-11-08T08:28:59.167 に答える