EndOfStream для BinaryReader - PullRequest
       5

EndOfStream для BinaryReader

11 голосов
/ 20 сентября 2010

BinaryReader не имеет свойства EndOfStream.Безопасно ли использовать следующий код для проверки достижения конца потока?

reader.BaseStream.Length>reader.BaseStream.Position

Ответы [ 6 ]

10 голосов
/ 03 ноября 2010

Самый простой способ, который я нашел, это проверить возвращаемое значение метода PeekChar () в BinaryReader.Если он возвращает -1, значит, вы достигли конца потока.

7 голосов
/ 20 сентября 2010

Это зависит. Существуют различные типы потоков, которые не реализуют свойство Length или Position, вы бы получили исключение NotSupportedException. NetworkStream например. Конечно, если вы используете такой поток, вам действительно нужно заранее знать, как часто вызывать метод BinaryReader.Read (). Так что да, все в порядке.

2 голосов
/ 20 сентября 2010

Это не будет работать в качестве общего решения, поскольку предполагается, что значение BaseStream поддерживает свойство Length.Многие Stream реализации не делают, а вместо этого выбрасывают NotSupportedException.В частности, любой базовый сетевой поток, такой как HttpRequestStream и NetworkStream

1 голос
/ 16 декабря 2013

Я заметил, что сравнение позиции с длиной не работает на StreamReader, даже если базовый BaseStream поддерживает поиск.Кажется, что StreamReader буферизует упреждающее чтение из BaseStream.Это должно быть причиной того, что StreamReader предоставляет свойство EndOfStream, что хорошо, и я бы хотел, чтобы BinaryReader сделал то же самое.

Проверка этих значений (длины и позиции) в базовом базовом потоке ведет к тому, что BinaryReader не ведет себя какStreamReader делает, то есть полагается, что BinaryReader получает только точное количество байтов из BaseStream, необходимое для выполнения вызова пользовательского метода.Предположительно, если BinaryReader на самом деле работает таким образом внутренне, именно поэтому ему не нужно предоставлять EndOfStream, но я бы очень хотел, чтобы он предоставлял такой, чтобы я знал, что конец файла правильно обрабатывается для клиентов независимо от реализации.

Конечно, читатели не являются потоками, но в отношении поведения конца файла было бы неплохо, если бы существовал общий интерфейс, позволяющий клиентам классов ввода / вывода знать, является ли А. конец файла разумной концепциейдля основного источника данных и B. когда конец файла имеет место, если A имеет смысл.

0 голосов
/ 03 января 2016

Проверьте свойство Streams CanSeek.Если это свойство возвращает true, тогда вы можете сравнить длину потока с позицией потока, чтобы определить, находитесь ли вы в конце потока.Если это свойство возвращает false, это не сработает.

Для сетевых потоков вам может понадобиться различать конец доступных байтов (клиент на другом конце еще должен написать, но еще не сделал) и поток закрывается.Свойство IsConnected для лежащего в основе соединения Tcp недостаточно надежно, чтобы знать, когда поток закрыт.Можно перечислить соединения, которые есть у компьютера, и посмотреть, входит ли в их число используемый вами поток.Это надежнее, но сложнее.Может быть лучше просто обработать IOException, когда вы не можете прочитать

0 голосов
/ 20 сентября 2010

Это то, что я всегда делал в прошлом, и никогда не видел проблем с этим. Код с его использованием находился в производственной среде более 2 лет.

...