Comments 8
освобождение памяти находится после оператора return
Я собирался написать, что это дичь, и посетовать на то, что нынче, похоже, код пишут прямо в UI гитхаба, не компилируя, потому что на такое любой компилятор выругается по умолчанию, ну или хотя бы с -Wall, ведь так же?
Но, оказывается, не любой.
Правильный и надёжный вариант кода:Не правильный, и не надёжный, именно для таких случаев придуман
std::unique_ptr<char[]> buf(new char[65536]);
template< class T >
unique_ptr<T> make_unique( std::size_t size );en.cppreference.com/w/cpp/memory/unique_ptr/make_unique
Так что правильный вариант тут
auto buff = make_unique<char[]>( 65536 )
В данном варианте они эквивалентны.
Оч странное применение юник поинтера, и тем более странно называть его «правильным вариантом»
Логичнее было бы использовать std::vector или даже std::string, учитывая, что тип — char
Логичнее было бы использовать std::vector или даже std::string, учитывая, что тип — char
Это уже нужно смотреть на применяемость данного буфера, я только поправил вариант с явным выделеним памяти на такой же, но использующий возможности, предоставляемые самой STL, что явно предпочтительней, а замена на другие контейнеры — это уже другой уровень диагностик.
И строка и вектор имеют накладные расходы на внутренние структуры, а строки ещё и могут (и почти всегда включают) иметь оптимизации, например small-string optimisation. Для рассматриваемого примера это не подходит, но мы опять начинаем обсуждать нюансы.
И строка и вектор имеют накладные расходы на внутренние структуры, а строки ещё и могут (и почти всегда включают) иметь оптимизации, например small-string optimisation. Для рассматриваемого примера это не подходит, но мы опять начинаем обсуждать нюансы.
А PVS-Studio защищает от хреновых статей на Хабре?
Sign up to leave a comment.
Как PVS-Studio защищает от поспешных правок кода