Замена существующих необработанных указателей умными указателями

Question

Примечание: это может звучать глупо. У меня есть приложение, которое использует сырые указатели, и в приложении много утечек памяти.

Теперь мой вопрос: насколько легко было бы заменить существующие необработанные указатели умными указателями? И только их замена поможет уменьшить утечки памяти, вызванные не освобождая динамически распределенную память.

Чтобы объяснить немного подробнее, это приложение является устаревшим, и есть очень простые утечки памяти, когда память будет выделена и не будет освобождена в самой функции.

Я провел анализ памяти с помощью DevPartner и нашел много областей. Является ли Valgrind лучше Devpartner.

Answer 1

Использование умных указателей, безусловно, будет хорошим началом для очистки вашего приложения, но они не являются панацеей. Многие утечки памяти могут быть просто небрежностью в хорошо спроектированной программе, но, скорее всего, у вас есть серьезные проблемы с дизайном, и утечки памяти являются симптомом этого. Когда вы переключаетесь на интеллектуальные указатели, вам все равно нужно будет сделать выбор дизайна, такой как «Кому принадлежит этот объект», «Является ли владение этим объектом общим для нескольких клиентов» и «Каково ожидаемое время жизни этого объекта», чтобы выбрать правильная реализация интеллектуального указателя для данного сценария. Но это будет хороший способ начать, потому что процесс выбора правильного вида интеллектуального указателя для различных ситуаций заставит вас задуматься об этом и, вероятно, улучшит ваш дизайн.

Answer 2

Я собираюсь дать этому фирму "очень возможно".

Одна из форм утечки памяти - это когда функция выделяет память и не удаляет ее хотя бы в одном пути из функции.Какой-то видовой указатель, такой как auto_ptr, может справиться с этим очень хорошо(Примечание: auto_ptr был частью первого стандарта ISO, и в следующем он устарел, поэтому сложно дать совет относительно того, какой указатель на область применения использовать. Обратитесь к документации компилятора и библиотеки, чтобы узнать, что они поддерживают.)

Другая форма - это то, где объект распределяется, а право собственности распределяется, а это означает, что существует более одной подпрограммы, которая использует его, и нет простого способа определить, все ли с ним справились.Это хороший кандидат на shared_ptr, но вы должны проявить осторожность.Присвойте shared_ptr при создании объекта и убедитесь, что при любом другом использовании указателя используется shared_ptr.Если подпрограммы A, B и C обращаются к объекту через shared_ptr, а вы не изменили D, то когда подпрограммы A, B и C завершены, он исчезает, независимо от потребностей D.

Одна вещь, которую вы хотите избежать с помощью shared_ptr, это циклы, поскольку, если у меня есть shared_ptr до J, у J есть shared_ptr до K, а у K есть shared_ptr для I, ни один из них не являетсякогда-либо будет удален, даже если он недоступен из других мест программы.Вам нужно следить за этими ситуациями.Вы можете разбить их на weak_ptr в цикле, или удалить элемент в цикле самостоятельно, или просто жить с утечкой.

Еще одна вещь, которую следует учитывать, - это замена vector и подобных контейнеров для динамическираспределенные массивы и другие динамически распределенные структуры данных.Это дает вам много управления памятью бесплатно, хотя вы все еще можете утечь память.Если вектор становится большим, а затем становится маленьким, он не освободит дополнительную память.Обычная практика, если вам действительно нужно восстановить память, это swap когда-то большой вектор с его копией.

Короче говоря, есть много очень полезных инструментов для автоматизации большого количества памятиуправление, но они не заменяют мышление с вашей стороны.Многие проблемы можно решить, просто превратив каждый указатель в shared_ptr и каждый массив в vector, но разумное их использование даст еще большие преимущества.

Answer 3

Нет никаких сомнений в том, что умные указатели уменьшают нагрузку на программиста с проблемами с владением памятью. Поскольку вы не упомянули, является ли это устаревшим приложением или насколько легко изменить интерфейсы (это не всегда требуется, поскольку интеллектуальные указатели переходят в необработанные указатели), я бы посоветовал вам запускать ваше приложение под каким-либо инструментом, например valgrind (в Linux ) или очистить (в Unices и Windows), чтобы отследить утечки памяти.

По моему опыту, большинство утечек памяти следуют определенному шаблону (разработчик A что-то упускает, разработчик B копирует этот код и вместе с ним проблему). Таким образом, используя инструменты, вы можете решить проблемы утечки памяти, прежде чем думать об использовании интеллектуальных указателей.

И если вы начинаете разрабатывать это приложение - начните с использования умных указателей. Они сэкономят вам много времени и энергии.

Answer 4

Зависит от того, что программы сбора мусора могут иметь утечки памяти, если жесткие ссылки на объекты мешают сборщику мусора освободить его. Если вы хотите выяснить, где происходят утечки памяти, используйте профилировщик или напишите модульные тесты и имитируйте объекты.

Редактировать. Чтобы воспользоваться преимуществами интеллектуальных указателей, вам также необходимо подключить или внедрить собственный сборщик мусора, поскольку это не языковая функция.

Редактировать 2: Интеллектуальные указатели, по-видимому, реализуют подсчет ссылок, который является стратегией сбора мусора.

Answer 5

Умные указатели «документ в коде» владения объектами.Поэтому для каждого указателя вы должны преобразовать «расплывчатый документ, который был в голове некоторых программистов», в этот «точный документ в коде».Большинство вариантов просты.Это все еще оставляет много вариантов, которых нет.Кроме того, помимо владения, вам нужно беспокоиться о нарушении циклов объектных графов со слабыми указателями.Таким образом, это общее преобразование в интеллектуальные указатели не является тривиальной задачей, и если вы ошибетесь в части прерывания цикла, вы даже внесете новые утечки памяти.