HW_02

[Daniil Lyubaev]

Пока реализован только алгоритм сжатия-расжатия и он вроде даже работает! Тестов пока нет. Эксепшены не везде расставлены, проверки на "битый" файл при распаковке тоже пока нет. Еще код плохо выглядит, но я пока не знаю, как его аккуратно переписать :(

[Святослав Власов]

Часть тестов прошла, а другая часть попадала, потому как разархивированный файл не совпадал с исходным.
Еще попадали тесты, которые передают аргументы в другом порядке
Еще упал тест на пустой файл

Тебе не нужно передавать компаратор для нод в std::priority_queue, если у тебя определен оператор <

Зачем в huffman_archiver держать указатель на huff_tree? Почему не по значению или хотя бы unique_ptr? Чтобы оставить лишнюю возможность на мемори-лик?

istream_iterator нужны, для использования в алгоритмах, чтобы упростить код и повысить читаемость. То, как ты их используешь, скорее понижает читаемость.

outp.write((char*)&source_len_, 8);

Что за куча магических констант? Во-первых есть CHAR_BIT (​http://www.cplusplus.com/reference/climits/), а во вторых sizeof

outp.write((char*)&source_len_, 8)

А если я соберу это под 32-битную архитектуру, то что будет?

В get_node_binary_info/craft_nodes ты достаточно сложным и неочевидным способом пытаешься сереализовать/десериализовать дерево (кстати, лучше для этого использовать названия serialize/deserialize). Попробуй вместо этого просто записывать байты в дереве "слоями", в том порядке в каком они будут появляться при обходе дерева в ширину.
Например, для такого вот дерева

     d
    /  \
   a    f
       / \
      e   b
     /     \
    c       g

кодировка будет "daf00ebc00g". Отсутствие потомка у узла кодируется нулем.

Хранить биты в виде строки -- это очень плохая затея. Можно что-то более разумное придумать, тот же std::vector<bool>.

Потоки нет смысла руками закрывать в конце функции -- они закроются сами в деструкторе.

Пока что 4/15

[Daniil Lyubaev]

Много поправил, но сериализацию/десериализацию пока не правил -- после правок все падало, пока оставил как есть. Суть там такая: я храню два бита на вершину, первый бит указывает, есть ли эта вершина, второй указывает, конечная ли это вершина (то есть лист). Если биты 11 -- значит после этого идет символ, который лежит в листе. Это сохраняет память, потому что легче передать один бит, нежели передавать 8 бит для символа-нуля.

[Святослав Власов]

Прошло уже больше тестов, но всё равно часть тестов падает на сравнении сжатого и распакованного файла (например, тест на файл из трех байт: 0x01, 0x01, 0x00), другая часть падает на декомпрессии (почему-то программа ругается на ей же сжатый файл, что он wrong, ошибка проявляется, к примеру, на файле состоящем из одного нуля), и почти во всех тестах неправильно репортятся размеры (разница в 1 байт).

В конструкторе huff_tree можно заюзать unique_ptr и избавиться от необходимости освобождать память в catch

В деструкторе потоки тоже нет смысла закрывать руками -- их деструкторы и без того вызовутся, а в них они сами закроются.

Нестандартные аргументы программа так и не научилась парсить :(

Твои тесты проверяют только функцоинальность сжатия и распаковки целиком. Это плохо. Юнит-тесты должны проверять каждую функцию и каждый класс по отдельности. Для проверки каждого метода должен быть свой тест-кейз.

8/1/5

[Daniil Lyubaev]

Починил архивацию\деархивацию и аргументы.
Пока не получилось в конструкторе huff_tree использовать unique_ptr -- оно ведь удаляется после того, как я ноды пытаюсь сделать. Постараюсь что-нибудь придумать и еще запилить тесты.

[Святослав Власов]

Тесты на сжатие-распаковку перестали падать.
Но размер по прежнему репортится неправильно и несжимаемые данные (случайные или все байты от 0x00 до 0xff) дают размер сжатых данных на 1 байт больше, чем размер исходных)
Переставленные местами аргументы тоже не работают
Тесты по прежнему не юнит.

12/2/8