Способ восстановить утечку памяти из динамического выделения в C ++?

Кажется, вы используете инфраструктуру Vapor, и я цитирую:

Не все базовые библиотеки (Foundation) доступны в Linux еще.

blockquote >

Проблема, которую вы создали над Vapor, уже получила ответ: https://github.com/vapor/vapor/issues/870

0
задан user4581301 25 March 2019 в 03:59
поделиться

2 ответа

Вариант 1 .

Самый простой способ - полностью избежать new и delete.

Вместо:

b = new int;
b = new int; 
delete b;

Запись:

std::unique_ptr<int> b;
...
b = std::make_unique<int>();
b = std::make_unique<int>(); 

Когда b перезаписывается или выходит из области видимости, он освобождает память , Нет delete требуется или даже разрешено. Обратите внимание, что это похоже на сборщик мусора Java, но в большинстве случаев достаточно хорошо.

Вариант 2.

Другой способ - использовать дополнительный сборщик мусора , но это решение не рекомендуется. Во-первых, сборщик мусора является консервативным, то есть существует вероятность утечки памяти, несмотря на сборщик мусора. Во-вторых, эти решения имеют тенденцию усугублять существующие проблемы, поскольку утечки памяти не будут замечены и устранены при появлении. Лечение утечек памяти через год после введения на несколько порядков сложнее, чем лечение через час после введения.

ПРИМЕЧАНИЕ : Использование unique_ptr не так безопасно, как в языках с сборкой мусора, таких как C #, Java и Python. Он терпит неудачу, когда нет четкой модели владения и когда существует круговое владение. Если элемент a имеет unique_ptr - b, а b имеет unique_ptr - a, то они никогда не будут освобождены. Они никогда не будут освобождены, поскольку unique_ptr освобождает объект в деструкторе, но никто не вызовет деструктор ни a, ни b. Если никто не вызывает деструктор, то unique_ptr никогда не удалит объект и никогда не вызовет деструктор другого объекта.

ПРИМЕЧАНИЕ 2 : Иногда вместо unique_ptr следует использовать std::shared_ptr, но это не решает проблему циклических ссылок. Это только решает проблему нескольких владельцев одного объекта.

ПРИМЕЧАНИЕ 3 : Эти интеллектуальные указатели не снижают вероятность переполнения стека из-за глубокой рекурсии в деструкторах. Это может произойти при рекурсивном уничтожении длинных связанных списков или в несбалансированных бинарных деревьях. Использование unique_ptr для этого случая просто скрывает тот факт, что рекурсия имеет место.

0
ответ дан Michael Veksler 25 March 2019 в 03:59
поделиться

Я знаю, что есть способ устранить эту утечку памяти в C # и Java

Java и C # являются языками сбора мусора, поэтому они не склонны к утечкам памяти часто (это почти невозможно), но когда они делают это, вы можете выдать исключение,

Есть ли способ устранить эту утечку памяти в C ++?

в c ++ утечки памяти встречаются чаще, потому что вы вручную выделяете память каждый раз, когда создаете указатель, поэтому вы всегда будете выдавать исключение, чтобы указать, есть ли утечка памяти, где она возникает, где она и как с ней бороться ... ответ на ваш вопрос ... нет, вы не можете восстановить после утечки памяти в c ++, это язык "До металла", поэтому он настолько уязвим, если не написано правильно, но вы всегда можете вызвать исключение, когда происходит утечка памяти, вы можете указать ее и посмотреть, как это исправить.

0
ответ дан Prinzeono Key 25 March 2019 в 03:59
поделиться
Другие вопросы по тегам:

Похожие вопросы: