Как сделать приложения Qt GUI на C ++ без утечек памяти
Я не смог создать приложение с графическим интерфейсом Qt, в котором не было бы более 1K «точно потерянных» байтов в valgrind. Я экспериментировал с этим, создавая минимальные приложения, которые просто показывают один QWidget, расширяющий QMainWindow; это просто создает объект QApplication, не показывая его или не выполняя его или оба, но они всегда просачиваются.
Пытаясь выяснить это, я прочитал, что это потому, что в X11 или glibc есть ошибки, или потому что valgrind дает ложные срабатывания. И в одной ветке форума казалось, что создание объекта QApplication в главной функции и возвращение функции exec () объекта, как это делается в руководствах, является «упрощенным» способом создания GUI (и не обязательно хорошим). возможно?)
Вывод valgrind действительно упоминает libX11 и libglibc, а также libfontconfig. Остальные потери памяти, 5 записей потерь, происходят при ??? in libQtCore.so в течение QLibrary::setFileNameAndVersion,
Если есть более подходящий способ создания приложений с графическим интерфейсом, который предотвращает даже то, что происходит, что это?
И если какой-либо из выводов valgrind является просто шумом, как мне создать файл подавления, который подавляет правильные вещи?
РЕДАКТИРОВАТЬ: Спасибо за комментарии и ответы!
Я не беспокоюсь о нескольких потерянных килобайтах самих себя, но мне будет легче обнаружить утечки памяти, если мне не придется фильтровать несколько экранов ошибок, но обычно я могу получить «ОК» от valgrind. И если я собираюсь подавить предупреждения, я бы лучше знал, что они, верно?
Интересно посмотреть, как могут быть приняты утечки!
Решение
Для крупномасштабных многопоточных библиотек, таких как QT, wxWidgets, X11 и т. Д., Нередко настраиваются объекты одноэлементного типа, которые инициализируются один раз при запуске процесса, а затем не предпринимают попыток очистить распределение, когда процесс останавливается.
Я могу заверить вас, что что-нибудь «просочилось» из такой функции, как QLibrary::setFileNameAndVersion() был оставлен так намеренно. Биты памяти, оставленные X11 / glibc / fontConfig, вероятно, также не являются ошибками.
Это может рассматриваться как плохая практика кодирования или этикет, но это также может значительно упростить определенные типы задач. В наши дни операционные системы предлагают очень надежную гарантию для очистки любой памяти или ресурсов, оставленных открытым процессом, когда он завершен (изящно или принудительно), и если очень вероятно, что рассматриваемое распределение потребуется в течение срока действия приложения. в том числе процедуры завершения работы — и могут подходить различные базовые компоненты QT — тогда производительность может быть благом, если библиотека настроит некоторые выделения памяти, как только она будет загружена / инициализирована, и позволит им сохраняться неограниченное время. Среди прочего, это позволяет присутствовать в памяти для использования любыми другими деструкторами C ++, которые могут ссылаться на эту память.
Так как эти распределения устанавливаются только один раз и из одной точки в коде, нет риска значимым утечка памяти. Это просто память, которая принадлежит процессу и, таким образом, очищается, когда процесс закрывается операционной системой.
Вывод: если утечки памяти нет в вашем коде, и она, кажется, не становится значительно больше со временем (и значительным в наши дни, считайте мегабайты), и / или явно происходит из исходного кода установки инициализации, который вызывается только один раз в вашем приложении, тогда не беспокойтесь об этом. Это, вероятно, намеренно.
Другие решения
Одним из способов проверить это может быть запуск вашего кода в цикле и изменение количества итераций. Если разница между allocs и frees не зависит от количества итераций, вы, вероятно, будете в безопасности.