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

[kambala]

часто «монстров» не бьют на куски т.к. придется передавать тонну параметров, а сохранять их в полях класса не имеет смысла

[voral]

Не. тут идёт дело о дальнейшей поддержке кода.
Пробежаться по 10 функциям и увидеть, что девятая выдаёт неверные данные - дело 5 секунд.
Пробежаться по функции в 100 строк, мониторя все переменные - бесценно, но бессмысленно.

И тем не менее это имеет смысл, только в случае если для разбивки есть еще и логическое обоснование. Бить ради приведения количества строк к какомуто взятому с потолка числу строк - не понятен профт.. Для примера (сразу отбросим вариант когда выделен код который выделен по логике. Я о тех случаях когда строка/группа строк не имеет смысла если выкинуть остальные 90. Итак имеем:
1. вариант

Код:

метод1{
строка1
строка2
.....
строка10


строка11
строка12
......

строка 100
}
//2 вариант (строки взяты из первого варианта)
метод2_1
{
строка1
...
строка10
}
.....// несколько прочих методов которые по мере разработки появились

метод2_3
{
строка21
...
строка30
}

метод2_2
{
строка11
...
строка20
}

метод1 // метод который мы порезали
{
   Метод2_1
   Метод2_2
   Метод2_3
}

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

Нет правило такое есть и оно не плохое. Просто, имхо, не надо бросаться сразу дробить по количеству строк. А 100 раз подумать: почему код такой длинный? Можно ли его уменьшить в рамках одного метода? Можно ли выделить логически самостоятельные "куски"?.....    "не более Х строк в методе" - это не серьезно.....

[Igors]

Нет правило такое есть и оно не плохое. Просто, имхо, не надо бросаться сразу дробить по количеству строк. А 100 раз подумать: почему код такой длинный? Можно ли его уменьшить в рамках одного метода? Можно ли выделить логически самостоятельные "куски"?.....    "не более Х строк в методе" - это не серьезно.....

Не имеет значения длинный/короткий, "сколько писать" и.т.п. бьется по смыслу. Пример

Код

C++ (Qt)
for (TMap::const_iterator it = tmap.begin(); it != tmap.end(); ++it)
 cout << *it << endl;
 

Должно быть выделено в метод или в утилиту, т.к. этот ф-ционал не завязан на текущий контекст.

[vregess]

На Вындоуз я пока на MSVC 2008, поэтому интересно что там за макрос такой в 2010 который Вы упоминаете?

я пользовался
_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
хочется хотя бы что то типа этого в Qt

что мешает и дальше пользоваться этим?

Я пользуюсь таким подходом: http://winfig.com/detecting-memory-leaks-in-qt-applications-with-visual-studio/
Меня пока устраивает.

[deMax]

Не. тут идёт дело о дальнейшей поддержке кода.
Пробежаться по 10 функциям и увидеть, что девятая выдаёт неверные данные - дело 5 секунд.
Пробежаться по функции в 100 строк, мониторя все переменные - бесценно, но бессмысленно.

С точки зрения тестов согласен. Хотя хватает нюансов, девятая может не пройти так как на восьмую пришлось исключение которого нет в тесте(а это исключение формирует кривые данные или портит память, а тест проходит) - если что и не работает, то дебагером быстрее ошибку найдешь, чем замыленным глазом в "чистый код" смотреть.
Гадить в структуре ради тестов, не хочется. Правда писать длинные функции тоже не получается, ИМХО - как правило, чем меньше кода(при одинаковой его чистоте), тем легче он читается.

Как грится садясь в машину ты видишь интерфейс водятла. А под капотом проще разобраться, если оно по частям, а не одним комком.

Правильно, если там 5 частей и каждая состоит из 5 подчастей. А не 5 частей, в каждой 5 подчастей, в каждой подчасти еще по 5 подчасте, ... а потом смотришь и говоришь, а вот эти нижних 25 подчастей и 5 .cpp + .h файлов теперь надо удалить и заменить одной меленькой фунцией из библиотеки тойоты. (или выкинуть в помойку ущербный бензиновый двигатель, и поставить батарейку с компьютером и 4 моторчика).

И тем не менее это имеет смысл, только в случае если для разбивки есть еще и логическое обоснование.
Нет правило такое есть и оно не плохое. Просто, имхо, не надо бросаться сразу дробить по количеству строк. А 100 раз подумать: почему код такой длинный? Можно ли его уменьшить в рамках одного метода? Можно ли выделить логически самостоятельные "куски"?.....    "не более Х строк в методе" - это не серьезно.....

Согласен полностью.
Если код больше 30 строк надо на него глянуть, возможно мы не правы и стоит доработать структуру. А возможно в данном случае все нормально. Засорять обилием мусорных функций, которые вызываются в одном месте и не могут быть использованы где то еще, только структуру засорять(я глянул на такой код недописанный, но с кучей хиадеров и кучей классов и выкинул его, написал сам, почему то и функционала больше и все соответствует ТЗ и структура проще и понятнее - правда функций больше экрана в нем все равно нет).
10К строк хиадеров для проекта с функционалом Hello World хочется просто удалить и даже не вникать во всю эту "гениальность".

p.s. Хотя если над проектом работает много людей, то есть смысл раскидать на кучу функций, чтоб каждому по маленькому кусочку который он вылижет.
p.s.s. Все гениальное просто.

[vulko]

Лучший способ избежать утечек, это заранее продумать архитектуру и правильно работать с памятью.
Т.е. ненужные объекты нужно удалять. Если есть new, должен быть delete. С QObject'ми проще, они могут удаляться сами при удалении родителя. Но эта схема не всегда применима в конкретной архитектуре приложения.

При этом крайне важно не забывать о тестировании написанного. Не откладывать проверку написанного кода на потом, а тестировать конкретные моменты работы с памятью. Особенно важно при работе со сложными контейнерами (какой-нибудь мэп из указателей на векторы в которых указатели на объекты...).

Иногда текущую память видно прямо из диспетчера задач. Но чаще приходится пользоваться профайлерами.

А самое важное не забывать эти простые правила, и будет вам счастье. В противном случае рискуете потратить кучу времени в будущем.

[Tuxford]

Не могу понять почему до сих пор в Qt не используются умные указатели. Немерено проблем можно было решить.

[Old]

Не могу понять почему до сих пор в Qt не используются умные указатели. Немерено проблем можно было решить.

Почему не используются - используются.
Есть QSharedPointer, QWeakPointer, QScopedPointer. А в Qt 5.4 наконец добавили QEnableSharedFromThis.

[Bepec]

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

[Igors]

Мб потому, что ...

Ой  Скажите лучше прямо, напр "я неск раз сталкивался - и мне не очень понравилось".  По существу шаред - это попытка "сборщика мусора", т.е. если изначально все спланировано на шаред - то необходимость в delete отпадает.

Однако беда в том что "спланировать изначально" случается редко. Гораздо чаще уже имеется обильный код, без всяких шаред и обычно писаный др программистами. А тогда попытки шариться обычно печальны т.к. получается  "гремучая смесь" из таких и сяких указателей

 

[Tuxford]

Мб потому, что умные указатели пусть чуть чуть, но замедляют работу.

Насколько? Использовал это дело в ембеддед. Никаких тормозов не было замечено. Возможно такое утверждение было верно 10 лет назад. Но сейчас?

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

Ну с этим согласен. Особенно если юзать циклические ссылки и не знать разницим межу shred_ptr и weak_ptr.

Мб потому, что это С++

А что есть Qt для С?

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

В чем это проявляется? Можна узнать?

Мб потому, что часть разработчиков их не любит

Видать это большинство предпочитает ковырятся в поисках ликов.

[Bepec]

C++ был создан с прямым управлением памятью. Умные указатели были созданы позднее для удобства.

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

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

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

[Igors]

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

О "жалкости" я ничего не говорил, это Вы уже от себя 

Для понимания удалился он или нет, ...

Все-таки полезно хоть чуть-чуть знать др языки. В той же жабе никто не будет искать "а удалился ли он?" т.к. это недостижимо. Так же Вы должны думать и здесь - да, удалится когда надо, потому что спланировано правильно.

..необходимо либо проверить листинг всех файлов где имеется данный указатель, либо посмотреть дебаггером.

Что же Вы хотите найти в листингах всех файлов? Просмотр дебаггером - ну на сам шаред указатель смотреть смысла нет, т.к. данный код (где смотрите) его же и юзает.

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

Был тут один (все рвался с туториалами), он быстро схавал идею "все шаред", но попытки применить на практике не имели успеха - только затянувшиеся разборки "почему же не работает". Насколько я помню Qt вернуло ему что-то "не шаред" - ото почалось...

[Tuxford]

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

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

[Bepec]

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