Я не знаю, почему они это делают, но в целом это не очень хороший пример - например, вместо этого они используют явные вызовы Close
(не в блоке finally) вместо FileStream
использования оператора using
, а также предположения, что один вызов Read
прочитает весь файл. Черт, даже чтение всего файла в буфер - плохая идея - было бы лучше скопировать порцию за раз прямо в DeflateStream
.
Эти вещи наводят меня на мысль о том, что не стоит беспокоиться об этом конкретном нечетном бите кода (дополнительные 100 байт) в этом примере. Конечно, не рассматривайте это как "лучшую практику".
Примеры MSDN, как правило, лучше, чем это, хотя есть много других странных примеров.
РЕДАКТИРОВАТЬ: Перечитав код и ответ CodeMelt, ему действительно нужны дополнительные 100 байтов - но только потому, что ReadAllBytesFromStream реализован так плохо. Вот лучшая реализация, которая всегда просит поток заполнить оставшуюся часть буфера:
public static int ReadAllBytesFromStream(Stream stream, byte[] buffer)
{
int offset = 0;
int bytesRead;
while ((bytesRead = stream.Read(buffer, offset,
buffer.Length-offset)) > 0)
{
offset += bytesRead;
}
return offset;
}
(Обратите внимание, что для offset
и totalCount
не было необходимости, поскольку они всегда имели одинаковое значение.)