Причины утечки памяти и способы борьбы с ними

[Bepec]

оффтоп: и потом образуется по привычке
typedef int fint;
typedef std::string textstring;
typedef bool variable;

PS проекты после этого нечитабельные на 200%

PPS хотел добавить пример такого кода, но вспомнил что подписывал бумажку :/

[Akon]

Old: Спасибо. Типичная реализация, удобная для автора либы, но может оказаться неудобной для пользователя, поскольку навязывается смарт-поинтер.

Код:

NonQObject* createObject()
{
    NonQObject* result = new NonQObject;
    try {
        functionThatCanThrowException();  // может сделать, throw std::runtime_error(), например
    }
    catch(....) {
        delete result;
        throw;
    }
    return result;
}

void foo()
{
    QScopedPointer<NonQObject> localObject = createObject();
    // do something 
}

В функции foo для локального объекта вы вынуждены были бы использовать QSharedPointer, что избыточно/снижает читабельность кода.

[Old]

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

Не навязывает. Просто все поинтеры в программе должны быть смарт. Они для этого и сделаны.

В функции foo для локального объекта вы вынуждены были бы использовать QSharedPointer, что избыточно/снижает читабельность кода.

Это не избыточно и тем более не снижает читабельность. Но это как я уже написал, если все поинтеры в программе смарт. А к этому нужно стремиться и по возможности использовать.

А вот ваш костылец заметно длинней и такие чудеса нужно вставлять везде, где может возникнуть исключение. Вот она избыточность и нечитаемость.

И это только создание объекта, а если мы проследим все костыли и исправления в программе, что бы его корректно удалять, то лишних строк будет еще больше. А с shared_ptr ничего менять не придется.

[Igors]

А вот ваш костылец заметно длинней и такие чудеса нужно вставлять везде, где может возникнуть исключение. Вот она избыточность и нечитаемость.

Я гораздо чаще действую как Akon и "костылем" это не считаю - ведь и Вам придется потратиться на обработку исключения, только в др, месте. И как Вы туда подадите данные исключения/восстановления - хз. А тут все под рукой.

А вот такой вопросик. Есть много "shared", но мне часто нужно знать не просто "удален или нет" а "кто его держит" - есть ли такая возможность?. А в Qt не знаю даже как посмотреть "а сколько ссылок" 

[Old]

Я гораздо чаще действую как Akon и "костылем" это не считаю

Вы знаете, а я не удивлен.

ведь и Вам придется потратиться на обработку исключения, только в др, месте. И как Вы туда подадите данные исключения/восстановления - хз. А тут все под рукой.

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

А вот такой вопросик. Есть много "shared", но мне часто нужно знать не просто "удален или нет" а "кто его держит" - есть ли такая возможность?

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

А в Qt не знаю даже как посмотреть "а сколько ссылок" 

Зачем вам эта бесполезная информация?

[Igors]

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

Необязательно, часто можно и не испускать вторичное а вернуть NULL. Да и пример слишком прост - если понадобится напр установить флаг/переменную (хоть код ошибки), то лучше сделать это по месту и потом вторичное throw типа "на свободу с чистой совестью".

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

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

[Old]

Необязательно, часто можно и не испускать вторичное а вернуть NULL.

Это вы дальше с Akon уже обсуждайте.

вот смотрю - ресурс жив, а я рассчитывал на его удаление/выгрузку.

Где смотрите, в отладчике?

Вероятно др объект его держит, но вот какой?

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

[Akon]

Не навязывает. Просто все поинтеры в программе должны быть смарт.  Они для этого и сделаны.

Я согласен, что когда все поинтеры в вашей программе смарт и программа задумана под это - это хорошо. Не навязывает - это значит смарт поинтера просто нет, и пользователь сам решит: использовать голый указатель или тут же обернуть его своим смартом. Рассмотрите такой пример:

Код:

QList<QSharedPointer<NonQObject> >

В данном случае sizeof(QSharedPointer<NonQObject>) > sizeof(void*), что вызовет инстанцирование QList с менее эффективной реализацией по сравнению с голым указателем. Вы автор библиотеки и не знаете, как будет использоваться объект. Фактически, вы навязали QSharedPointer и менее эффективный QList, последнее запросто может не понравиться пользователю.

Это не избыточно и тем более не снижает читабельность.

Ну как вам сказать... тогда зачем scoped pointer нужен вообще?

А вот ваш костылец заметно длинней и такие чудеса нужно вставлять везде, где может возникнуть исключение. Вот она избыточность и нечитаемость.

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

И это только создание объекта, а если мы проследим все костыли и исправления в программе, что бы его корректно удалять, то лишних строк будет еще больше. А с shared_ptr ничего менять не придется.

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

[Old]

если на стыке (библиотека - программа) интерфейс в смартах, то это может быть не всегда удобно! Мне просто было интересно ваше мнение.

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

[kambala]

2Old: можешь посоветовать хороший материал по умным указателям? максимум, что я использовал — это QPointer.

[Old]

2Old: можешь посоветовать хороший материал по умным указателям? максимум, что я использовал — это QPointer.

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

[Akon]

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

[Old]

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

Как и все у нас.
Идеальных контейнеров тоже не существует и мы вынуждены все время выбирать чем пожертвовать что бы что-то получить. Все имеет свою цены и смарты в том числе.
И для меня они дают значительно больше, чем забирают. )

[kambala]

2Old: можешь посоветовать хороший материал по умным указателям? максимум, что я использовал — это QPointer.

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

так может уж лучше тогда тему-статью-туториал? думаю не мне одному будет интересно.

[Akon]

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