Естественно, этот вопрос является языковозависимым, но оператор переключения мог бы быть более оптимальным вариантом во многих случаях. Хороший C или компилятор C++ смогут генерировать таблица переходов , которая будет значительно быстрее для больших наборов случаев.
В вашем методе распаковки вы переназначаете inp новому потоку (поток deflate). Вы никогда не закрываете этот поток Deflate, но закрываете базовый файловый поток в Main (). То же самое происходит в методе сжатия.
Я думаю, что проблема в том, что базовый файловый поток закрывается до того, как финализаторы потока deflate автоматически закрывают их.
Я добавил 1 строку кода в ваш Decompress и методы сжатия: inp.Close () // в метод Decompressmehtod
outp.Close () // в метод сжатия.
лучше было бы заключить потоки в предложение using.
Вот альтернативный способ напишите свой метод Decompress (я тестировал, и он работает)
public static long Decompress(Stream inp, Stream outp)
{
byte[] buf = new byte[BUF_SIZE];
long nBytes = 0;
// Decompress the contents of the input file
using (inp = new DeflateStream(inp, CompressionMode.Decompress))
{
int len;
while ((len = inp.Read(buf, 0, buf.Length)) > 0)
{
// Write the data block to the decompressed output stream
outp.Write(buf, 0, len);
nBytes += len;
}
}
// Done
return nBytes;
}
У меня была такая же проблема с GZipStream. Поскольку у нас была сохранена исходная длина, мне пришлось переписать код, чтобы читать только количество байтов, ожидаемое в исходном файле.
Надеюсь, я скоро узнаю, что есть лучший ответ (скрестив пальцы).