Открыть список
Как стать автором
Обновить

Комментарии 8

освобождение памяти находится после оператора return

Я собирался написать, что это дичь, и посетовать на то, что нынче, похоже, код пишут прямо в UI гитхаба, не компилируя, потому что на такое любой компилятор выругается по умолчанию, ну или хотя бы с -‍Wall, ведь так же?
Но, оказывается, не любой.
Ну для шланга нужно добавить -Weverything или -Wunreachable-code, а для gcc -Wunreachable-code удалили. Но странно что на -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
Это уже нужно смотреть на применяемость данного буфера, я только поправил вариант с явным выделеним памяти на такой же, но использующий возможности, предоставляемые самой STL, что явно предпочтительней, а замена на другие контейнеры — это уже другой уровень диагностик.
И строка и вектор имеют накладные расходы на внутренние структуры, а строки ещё и могут (и почти всегда включают) иметь оптимизации, например small-string optimisation. Для рассматриваемого примера это не подходит, но мы опять начинаем обсуждать нюансы.

А PVS-Studio защищает от хреновых статей на Хабре?

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