HW #3

[Дмитрий Свиридкин]

==91094== 24 bytes in 1 blocks are definitely lost in loss record 1 of 3
==91094==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==91094==    by 0x12F5FC: HuffmanTree::construct(std::unordered_map<unsigned char, int, std::hash<unsigned char>, std::equal_to<unsigned char>, std::allocator<std::pair<unsigned char const, int> > > const&) (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x12E167: HuffmanArchiver::compress(std::istream&, std::ostream&) (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x12D054: _DOCTEST_ANON_FUNC_2() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x12876D: doctest::Context::run() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x1155F2: main (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094== 
==91094== 24 bytes in 1 blocks are definitely lost in loss record 2 of 3
==91094==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==91094==    by 0x12F685: HuffmanTree::construct(std::unordered_map<unsigned char, int, std::hash<unsigned char>, std::equal_to<unsigned char>, std::allocator<std::pair<unsigned char const, int> > > const&) (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x12E167: HuffmanArchiver::compress(std::istream&, std::ostream&) (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x12C3C4: _DOCTEST_ANON_FUNC_4() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x12876D: doctest::Context::run() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x1155F2: main (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094== 
==91094== 24 bytes in 1 blocks are definitely lost in loss record 3 of 3
==91094==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==91094==    by 0x12F685: HuffmanTree::construct(std::unordered_map<unsigned char, int, std::hash<unsigned char>, std::equal_to<unsigned char>, std::allocator<std::pair<unsigned char const, int> > > const&) (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x12E167: HuffmanArchiver::compress(std::istream&, std::ostream&) (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x12B762: _DOCTEST_ANON_FUNC_6() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x12876D: doctest::Context::run() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094==    by 0x1155F2: main (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==91094== 

[Дмитрий Свиридкин]

падение на пустом файле

статистика выводится некорректно:

файл с содержимым: "aaaaaaaaaaaaaaaa" (16 букв a). Сжатый файл: 11 байт.
Вывод статистика: 16 + 9 байт.

Файл с каждый байтом по одному разу (всего 256 байт)

Running test  normal input/00_to_ff.core
Test failed -- invalid compressed size reported: 3332 instead of 1540
Test failed -- expected compressed data to be no longer than source data, got 2048 > 256

Размер сжатых данных (без доп. данных) в принципе не может быть больше, чем размер исходных.

---

Тесты только end-to-end.

Оба потока нужно открывать в бинарном режиме.

        std::cout << "Parse arguments error:\n" << ex.what() << std::endl;
        return 0;

Как может быть 0, если ошибка?

    HuffmanTree() = default;
    void construct(const std::unordered_map<unsigned char, int32_t>& frequencyTable);

Серьезно? Вы не хотите писать конструктор, но пишете метод construct, который делает то, что должен делать конструктор?

Логику TreeWalker? надо вынести из дерева в отдельный класс, оборачивающий дерево.

Размещайте публичные поля и методы перед приватными. Кишки никому не нужны.

    void garbageCollector(HuffmanNode node);

1. Обычно методы именуются глаголами.
2. Умные указатели?
3. Деструктор?

typedef HuffmanNode_* HuffmanNode; using лучше чем typedef. У using нет проблем с пониманием того, где новое имя, а где старые тип.

---

Зачем в HuffmanArchiver? поля, если достаточно локальных переменных в методах compress/extract

    readData(in);
    huffmanTree.construct(frequencyTable);
    countSizeOfData();
    writeFrequenctTable(out);
    in.clear();
    in.seekg(0, std::ios::beg);

Сбросьте поток в начало в функции readData (ее бы переименовать в соотсветсвии с тем, что она делает)
Верните построенную таблицу частот через возвращаемое значение явно. Явное всегда лучше неявного.

    HuffmanNode firstNode = node->left, secondNode = node->right;
    if (gen() % 2) { // Theoretically speeds up the search
        std::swap(firstNode, secondNode);
    }

??? В среднем, никакого ускорения тут нет, только дополнительные накладные расходы на генератор случайных чисел.
Постройте таблицу кодов, если сильно хочется ускорить. Случайными блужданиями по дереву вы тут ничего не получите.

---

6 + 3 + 4 + 7