Opened 4 years ago

Closed 4 years ago

#941 closed ожидаются исправления (задача сдана)

HW #3

Reported by: ushakova.alina Owned by: ushakova.alina
Component: HW #3 (Huffman) Version: 2.0
Keywords: Cc:

Description


Change History (4)

comment:1 Changed 4 years ago by ushakova.alina

Summary: #HW_03#HW 3

comment:2 Changed 4 years ago by ushakova.alina

Summary: #HW 3HW #3

comment:3 Changed 4 years ago by Дмитрий Свиридкин

Owner: changed from Дмитрий Свиридкин to ushakova.alina
Type: ожидается проверкаожидаются исправления
Version: 1.02.0

строка длиной 251 символ в CMakeLists.txt... какой ужас...

Там можно делать перенос строки:

add_executable(exe_name
   file1
   file2
   ....)
==36246== 32 bytes in 1 blocks are definitely lost in loss record 3 of 9
==36246==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==36246==    by 0x135D86: _DOCTEST_ANON_FUNC_2() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11EE40: doctest::Context::run() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11F85D: main (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246== 
==36246== 32 bytes in 1 blocks are definitely lost in loss record 4 of 9
==36246==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==36246==    by 0x136561: _DOCTEST_ANON_FUNC_4() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11EE40: doctest::Context::run() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11F85D: main (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246== 
==36246== 64 (32 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 9
==36246==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==36246==    by 0x136BD7: _DOCTEST_ANON_FUNC_6() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11EE40: doctest::Context::run() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11F85D: main (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246== 
==36246== 64 (32 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 8 of 9
==36246==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==36246==    by 0x1376BD: _DOCTEST_ANON_FUNC_8() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11EE40: doctest::Context::run() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11F85D: main (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246== 
==36246== 192 (64 direct, 128 indirect) bytes in 2 blocks are definitely lost in loss record 9 of 9
==36246==    at 0x483BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==36246==    by 0x138302: _DOCTEST_ANON_FUNC_10() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11EE40: doctest::Context::run() (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246==    by 0x11F85D: main (in /home/dmis/DATA/WORKSPACE/cpp-labs/hw_03/check/hw_03/test_hw_03)
==36246== 

Откуда взялся этот интересный стиль с дополнительными отступами перед CHECK и другими макросами?

            SUBCASE ("root") {
                CHECK(tree.getRoot());
                CHECK(!tree.getRoot()->getPrev());
    }

Не надо явно вызывать close у потоков. Вы не доверяете деструкторам?
Оба потока надо открывать в бинарном режиме.

    bool archiving = false;
    bool dearchiving = false;
    bool input_file_fl = false;
    bool output_file_fl = false;

А зачем так много да еще и публичных полей? Для типа операции достаточно одного enum.
А все остальное полями точно нет смысла делать.

    HuffmanNode* getNode(char symbol) { return pos[symbol]; }
    HuffmanNode* getRoot() { return root; }

Эти методы точно можно сделать константными.

private:
    HuffmanTree(const HuffmanTree& other);
    HuffmanTree operator=(const HuffmanTree& other);

= delete. Не ретроградствуйте.

У возвращаемых указателей константность тоже не помешает проставить, где надо.

Что ж вы так сырые указаетели любите...

 int size = 0;
 in.read((char *) &size, 4);

reinterpret_cast, sizeof


Логику с вычитыванием по одному битику надо вынести в отдельную структуру/обертку и протестировтать.

Логику с обработкой одного битика дерево тоже стоит вынести в отдельную функцию.


8 + 6.5 + 4 + 7

Last edited 4 years ago by Дмитрий Свиридкин (previous) (diff)

comment:4 Changed 4 years ago by Дмитрий Свиридкин

Resolution: задача сдана
Status: assignedclosed
Note: See TracTickets for help on using tickets.