как правильно работать с Qt, чтобы не было утечек памяти?

[Old]

Согласен, что зависит от задачи. Но таких задач очень мало

Нет. Такие задачи практически все.

[Ilia_Ivanov]

1. Покажите пример того, как вы обычно создаёте новый класс, новый объект этого класса, как вызываете метод объекта этого класса и как удаляете объект этого класса.

Чуть раньше у меня было всё просто. Выясняем необходимость в объекте. Думаем минут пятнадцать, а правда ли объект нам необходим. Идем в Visual Studio, добавляем руками хедер, не забыв указать папку Include в папке проекта. Сразу добавляем в хедер гварды через Visual Assist, чтобы не было проблем, через контекстное меню. Дописываем после гвардов пустую строку, комментарий, зачем класс нужен, включаем TApplication.h - это основной хедер приложения. В нем уже включены все контейнеры Qt и много мелочей, дефайны разные, структуры, энумы. Пишем руками заголовок класса, если нужно унаследоваться, возвращаемся назад и дописываем хедер с классом, от которого наследование. Для всех агрегатированных членов-указателей пишем forward declarations, хедеры включаем в cpp-шник нашего класса. После открывающей { пишем или не пишем Q_OBJECT, если нет, то класс не Qt-шный, просто Visual C++. Сразу пишем каркас класса - ключевые слова protected, public, дефолтный конструктор, конструктор от QObject(или QWidget) и виртуальный деструктор. Пишем в секцию public пару методов, какие нужны в первую очередь. Делаем в Visual Assist Create Implementations, снимаем ненужные галочки, получаем реализацию всех методов. Дописываем реализацию и новые методы. Так всё было, но теперь по-другому! Пришла страшная информация, что без юнит-тестов проект обречён. Понял, почему прошлые проекты не доходили до конца, и перешел на TDD(тестирование через разработку). Теперь нужно сначала написать тесты, которые покрывают функциональность класса, по методу красный-зеленый-рефакторинг. Сначала пишем тест через QTest фреймворк, добиваемся, чтобы тест не прошёл, потом пишем класс по имеющимся требованиям, попутно очень тяжело и долго думаем, как так написать, чтобы конструкция вообще заработала. Потому что если без тестов всё как-нибудь поднимется и потом упадёт, то с тестами при ошибочной архитектуре даже не взлетит.
По отлову ошибок. 50 процентов рассчитываю отловить юнит-тестами, остальное дебагом. У меня однопоточка. Я установил кешер буфера обмена windows, прилепил его desk pin-ом на самый верх стопки окон. Очень удобно, но требует серьезного сосредоточения. Идём дебаггером, подозрительные места копируем, после закрытия программы имеем список багов и глюков, исправляем их.
По поводу утечек памяти. Нужно просто грамотно писать код. Запрещено: арифметика указателей полностью, сырые массивы типа int* = new int[5], расползание указателей. Разрешены: stl и qtl, массивы с контролем границ, умные указатели, создание как инициализация. Там еще много требований, всего не перечислишь. Смысл такой - нет этих опасных мест, нет утечек памяти. Без них можно и нужно обходиться. Как в C#.

[Igors]

Так всё было, но теперь по-другому! Пришла страшная информация, что без юнит-тестов проект обречён. Понял, почему прошлые проекты не доходили до конца, и перешел на TDD(тестирование через разработку). Теперь нужно сначала написать тесты, которые покрывают функциональность класса, по методу красный-зеленый-рефакторинг. Сначала пишем тест через QTest фреймворк, добиваемся, чтобы тест не прошёл, потом пишем класс по имеющимся требованиям, попутно очень тяжело и долго думаем, как так написать, чтобы конструкция вообще заработала. Потому что если без тестов всё как-нибудь поднимется и потом упадёт, то с тестами при ошибочной архитектуре даже не взлетит

Долго, но, увы - безуспешно, я пытался выяснить в чем же прелести TDD здесь. Предложил показать преимущества этого подхода на простой студенческой задаче (парсинг obj файла). Ничего конкретного не увидел, только слова "ах как это хорошо". Жевать это все снова уже неинтересно

По поводу утечек памяти. Нужно просто грамотно писать код. Запрещено: арифметика указателей полностью, сырые массивы типа int* = new int[5], расползание указателей. Разрешены: stl и qtl, массивы с контролем границ, умные указатели, создание как инициализация. Там еще много требований, всего не перечислишь. Смысл такой - нет этих опасных мест, нет утечек памяти. Без них можно и нужно обходиться. Как в C#.

Глупость начальства повторять необязательно 

[Bepec]

По поводу этих ограничений - работал одно время с коллегой, профи в С++. Ему поставили задачу - написать программу на C#. Да да, чтобы не было утечек, чтобы сборщик всё убирал и прочее.
У него ушло 2 дня на то, чтобы в C# был отключен сборщик, появилась арифметика указателей и С# оказался максимально приближен к С++

При желании можно вообще пользоваться только безопасными методиками разработки. Вот только такие пути ведут в тупик трудноподдерживаемого кода

[Old]

Глупость начальства повторять необязательно 

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

[Bepec]

Old, затраты и сложность реализации из-за этих "обезопасностей" повышаются раз в 10-15, на мой взгляд.
Более того целый слой возможностей языка делается недоступным.
А получаем мы "отсутствие опасных мест", которые средним программистом обходятся на раз два.

Очень похоже на лечение сыпи методом ампутации. И проблема вроде решена, и сыпи на теле уже не осталось, однако сыпь (утечки) всё равно могут быть

PS не верю в прекращение использования таких мест. Тот же winapi полное нарушение всех правил. Т.е. мы и взаимодействовать не можем

[Ilia_Ivanov]

А получаем мы "отсутствие опасных мест", которые средним программистом обходятся на раз два.

Это про утечки памяти? Без целого дня копания с дебаггером ее часто не обнаружить. Я лучше буду обходить опасные места и лишаться некоторых возможностей языка, чем получу программу с такой ошибкой.

Я почти не взаимодействую с winapi. Winapi - это ад, чем меньше его будет, тем лучше. Ему не помогут никакие средства, это не повод вводить небезопасную технику работы.

[Old]

Old, затраты и сложность реализации из-за этих "обезопасностей" повышаются раз в 10-15, на мой взгляд.

Какие затраты и сложности? Вы о чем?

Более того целый слой возможностей языка делается недоступным.

Что это за слой такой?

А получаем мы "отсутствие опасных мест", которые средним программистом обходятся на раз два.

Ну конечно.
Обойти "опасное место" в программе состоящей из главного окна и диалога не велика доблесть.

PS не верю в прекращение использования таких мест. Тот же winapi полное нарушение всех правил. Т.е. мы и взаимодействовать не можем

Это никак не связано с winapi. Взаимодействуйте по полной.

[Bepec]

Затраты на "а как сделать вот тут, чтобы не использовать обычные указатели, массивы и прочее".
Слой называется - прямое управление памятью, работа с указателями и массивами.
Обходятся при правильной архитектуре спокойно.
Как вы будете взаимодействовать с WinApi, если для него нужно выделять массивы, передавать тупые указатели и работать с памятью. Т.е. весь код работы с winapi оказывается за пределами этих правил.

[Old]

Затраты на "а как сделать вот тут, чтобы не использовать обычные указатели, массивы и прочее".

Нет здесь никаких затрат. Это все известно.

Слой называется - прямое управление памятью, работа с указателями и массивами.

Он не куда не девается, а прячется за удобными обертками.

Обходятся при правильной архитектуре спокойно.

Обходятся при правильной архитектуре с кучей ограничений и кастылей.
Именно поэтому лет 20 назад придумали умные указатели, которые все это решают.

Как вы будете взаимодействовать с WinApi, если для него нужно выделять массивы, передавать тупые указатели и работать с памятью. Т.е. весь код работы с winapi оказывается за пределами этих правил.

Что за ерунда. Умные указатели никак с этим не пересекаются. А то что вы всегда выделяете массивы через new, говорит только о вашей квалификации.
C winapi можно работать совсем без new.

И кстати, а какие функции winapi требуют обязательно выделять блоки на куче? Можно мне показать хотя бы 10 таких?

[Ilia_Ivanov]

Ок, соглашаюсь и покидаю тему, не буду спорить. Всем доброго вечера.

[Bepec]

Присоединюсь, спор бессмысленен после слов

Именно поэтому лет 20 назад придумали умные указатели, которые все это решают.

.
Всё решают за нас, печаль.

[Igors]

Я почти не взаимодействую с winapi. Winapi - это ад, чем меньше его будет, тем лучше. Ему не помогут никакие средства, это не повод вводить небезопасную технику работы.

Следуя этой логике следующим в "списке неиспользуемых" должен быть Qt - ведь хотя бы те же виджеты (о ужас!) просто указатели. что совершенно НЕБЕЗОПАСНО!!! 

[Old]

Следуя этой логике следующим в "списке неиспользуемых" должен быть Qt - ведь хотя бы те же виджеты (о ужас!) просто указатели. что совершенно НЕБЕЗОПАСНО!!! 

Ну это как написать.
Цитата из вашего букваря:

Код

C++ (Qt)
    const QWidget *const p = new QWidget();
    // is equivalent to:
    const QScopedPointer<const QWidget> p(new QWidget());
 
    QWidget *const p = new QWidget();
    // is equivalent to:
    const QScopedPointer<QWidget> p(new QWidget());
 
    const QWidget *p = new QWidget();
    // is equivalent to:
    QScopedPointer<const QWidget> p(new QWidget());
 

[andron81_81]

Следуя этой логике следующим в "списке неиспользуемых" должен быть Qt - ведь хотя бы те же виджеты (о ужас!) просто указатели. что совершенно НЕБЕЗОПАСНО!!! 

Ну это как написать.
Цитата из вашего букваря:

Код

C++ (Qt)
    const QWidget *const p = new QWidget();
    // is equivalent to:
    const QScopedPointer<const QWidget> p(new QWidget());
 
    QWidget *const p = new QWidget();
    // is equivalent to:
    const QScopedPointer<QWidget> p(new QWidget());
 
    const QWidget *p = new QWidget();
    // is equivalent to:
    QScopedPointer<const QWidget> p(new QWidget());
 

понимаю, вы писали в 2015. А сейчас использование классических указателей с new , delete в 2023 не является ещё плохим тоном ?
а то я сам напрограммировал классикой , а может надо умные использовать или же в QT не считается преступной халатностью использовать классику ?