Здравствуйте, я новичок здесь.

Прочитал книгу Шлее, но так и не понял, как правильно работать с Qt, чтобы не было утечек памяти. Долго искал какую нибудь библиотеку или макрос, как в VC++ 2010, чтобы банально проверить, вдруг что то потекло, но так и не смог найти.

Сейчас я понимаю следующее:

Чтобы не заботиться об удалении объекта, нужно сделать класс этого объекта наследником QObject. Это не совсем нормально по моему мнению, так как где то я могу банально забыть наследоваться, и компилятор мне ничего не скажет, а память потечёт.

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

В связи с этим у меня к вам просьбы:


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

т.е

class MyClass( ... наследуетесь от QObject/QWidget?...
{

   //Какой указатель на ресурс динамической памяти используете - простой или умный?
   ...

}.

MyClass::MyClass(
   //Присвоение указателю начального значения, если нужно
...
)

void MyClass::UsePointer(
   //Присвоение указателю какого либо значения
...
)

MyClass::~MyClass(
   //Как удаляете и удаляете ли вообще?
...
)


int main(argc, argv)
{

   //Как создаёте объект класса, вызываете метод UsePointer?

   return 0;
}

2. Как всё-таки контроллировать утечки памяти? Есть ли какие то встроенные макросы как в VC++2010? Может, какие то утилиты?



Заранее очень очень благодарю!

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

Вопрос звучит несколько наивно, т.к. возможность утечек в самой природе языка, как бы плата за эффективность кода, это нормально. Способ решить эту проблему "раз и навсегда" мне неизвестен. В общем случае - "я распределил, я и удаляю". Есть неск исключений, наиболее популярное "родитель удаляет детей". Отлов утечек производится инструментами - на каждой платформе своими, к Qt это отношения не имеет.

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

Книги, Шлее и др. может и неплохи, но практического опыта не заменят

Так же, как и просто в С++ - например засовыванием вывода в консоль в деструктор объекта

Qt - это framework, поэтому все правила С++, компилятора и платформы столь же применимы. Т.е. спокойно используете тот же CrtSetDbgFlag, те же методы отлова что и без всякого Qt. Если в языке нет возможности проверить валидность указателя - то ее не будет и в Qt.

Если человек знает и любит C/C++, то изучение Qt будет легким и приятным. И наоборот 

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

Чаще используйте локальные переменные на стеке, вместо new/delete. Если вы точно знаете, что объект вам нужен только в рамках работающей функции, в том числе с передачей его вглубь других функций, используйте локальные переменные функций и передавайте их по адресу. После выхода из текущей функции стек просто "очищается" и память освобождать явным образом нет необходимости.

Сокращайте размер участков кода, разбивайте код на короткие и логически ясные методы с хорошими именами - сможете избежать многих проблем заранее. В нескольких отдельных методах размером в 10-20 строк разобраться не в пример проще, чем в одном "монстре" на 100. Мыслите в терминах простых и ясных связей между компонентами программы (интерфейсов), а о конкретной реализации проще думать в рамках конкретного небольшого метода. Я думаю большинство проблем с утечками при таком подходе отпадут сами собой

Рекомендую на досуге почитать книгу Стива Макконнелла "Совершенный Код" - книга даёт хорошее понимание того, что считать хорошим кодом/стилем программирования и почему.

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

Вы неправы, deMax.

Нужно просто отделять интерфейс и функции. Интерфейс должен быть минимален - допустим задача нарисовать круг.

Интерфейс - функция drawEllipse(QPoint ) - где рисовать.

А внутри идут функции расчёта, функции рисования, функции выбора/расчёта цвета и прочее.

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

Не. тут идёт дело о дальнейшей поддержке кода.

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

Пробежаться по функции в 100 строк, мониторя все переменные - бесценно, но бессмысленно.