Кажется, вы используете инфраструктуру Vapor, и я цитирую:
Не все базовые библиотеки (Foundation) доступны в Linux еще.
blockquote >Проблема, которую вы создали над Vapor, уже получила ответ: https://github.com/vapor/vapor/issues/870
Вариант 1 .
Самый простой способ - полностью избежать new
и delete
.
Вместо:
blockquote>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
для этого случая просто скрывает тот факт, что рекурсия имеет место.
Я знаю, что есть способ устранить эту утечку памяти в C # и Java
blockquote>Java и C # являются языками сбора мусора, поэтому они не склонны к утечкам памяти часто (это почти невозможно), но когда они делают это, вы можете выдать исключение,
Есть ли способ устранить эту утечку памяти в C ++?
blockquote>в c ++ утечки памяти встречаются чаще, потому что вы вручную выделяете память каждый раз, когда создаете указатель, поэтому вы всегда будете выдавать исключение, чтобы указать, есть ли утечка памяти, где она возникает, где она и как с ней бороться ... ответ на ваш вопрос ... нет, вы не можете восстановить после утечки памяти в c ++, это язык "До металла", поэтому он настолько уязвим, если не написано правильно, но вы всегда можете вызвать исключение, когда происходит утечка памяти, вы можете указать ее и посмотреть, как это исправить.