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

[Old]

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

Вот не умею я нормально писать. Давайте лучше это обсуждать в этой теме, например.
На самом деле, начать ими пользоваться очень легко с запуском нового проекта: просто берете и начинаете везде вместо обычных указателей использовать shared_ptr (не допуская циклических ссылок).

Писал, писал... какая то фигня получается... Лучше будем обсуждать конкретные моменты.

[Old]

если бы не было распространенных реализаций, вы бы сделали свою.

Так и делал... В середине 90-х, шаблонов у меня в компиляторе еще не было (BC 3.1), и в каждый класс, у которого хотелось иметь такой функционал, подмешивал класс со счетчиком и методами attach/detach.

[Igors]

Или вы хотели бы что бы он в боевом коде всех сохранял?

И это тоже бы хотел. Пример: N разнотипных объектов использует шареный ресурс, напр картинку. Все хорошо, как только все N будут удалены - и ресурс будет удален/выгружен. Но вот пользователь выбрал из меню "отключить картинки" - что делать? Как мне найти всех пользователей ресурса и сказать им "освобождай"?

А так да - экономит delete, удобно отдать в асинхронный вызов, и.т.п. с этим никто не спорит. Но каких-то больших результатов от "умности указателей" ожидать не стоит.

[Old]

Но вот пользователь выбрал из меню "отключить картинки" - что делать? Как мне найти всех пользователей ресурса и сказать им "освобождай"?

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

А так да - экономит delete, удобно отдать в асинхронный вызов, и.т.п. с этим никто не спорит.

Это одни из простейшитх задач, которые он ришает.

Но каких-то больших результатов от "умности указателей" ожидать не стоит.

Так никто и не ждет. Это просто указатель.

[Akon]

И это тоже бы хотел. Пример: N разнотипных объектов использует шареный ресурс, напр картинку. Все хорошо, как только все N будут удалены - и ресурс будет удален/выгружен. Но вот пользователь выбрал из меню "отключить картинки" - что делать? Как мне найти всех пользователей ресурса и сказать им "освобождай"?

Это действительно никак не связано с смартами. Используйте контейнер со смартами под каждый ресурс. Отключили картинки - очистили контейнер.

[Igors]

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

Это действительно никак не связано с смартами.

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

этот редиска на первом скачке расколется

И придется возвращаться к тем самым attach/detach 

Используйте контейнер со смартами под каждый ресурс. Отключили картинки - очистили контейнер.

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

[Johnik]

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

Использовать текучие указатели в паре с умными.

[Bepec]

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

Это инструмент. Можно использовать эффективно и в нужной программе, а можно "микроскопом гвозди забивать".

[Old]

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

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

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

Посылайте сигнал/event всем объекта, при получении которого они забудут ресурс. Как только они все это сделают, ресурс разрушится.

[Old]

В остальных случаях лучше простые.

Тут нужно уточнять, кому лучше. Вам? Ну хорошо. Для меня простые указатели хуже.

Это инструмент. Можно использовать эффективно и в нужной программе, а можно "микроскопом гвозди забивать".

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

[Bepec]

Я привёл пример - попробуйте скрестить библиотеку с простыми указателями и библиотеку с умными. И не простую динамическую dll, а полноценную библиотеку с взаимодействием.

PS это хорошо когда все и вся использует умные. Если что-то использует простые, вся схема рушится

[Old]

PS это хорошо когда все и вся использует умные. Если что-то использует простые, вся схема рушится

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

[Igors]

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

Так я же и не возражаю, а просто привожу пример как "умность" оказывается очень короткой. И таких примеров много

Посылайте сигнал/event всем объекта, при получении которого они забудут ресурс. Как только они все это сделают, ресурс разрушится.

А каким "всем"? Откуда я их возьму/узнаю? И что послать? Нужно делать какой-то интерфейс понимаемый многими объектами  Да и в событийной схеме это проблемно.

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

[Old]

просто привожу пример как "умность" оказывается очень короткой. И таких примеров много

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

А каким "всем"? Откуда я их возьму/узнаю?

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

Да и в событийной схеме это проблемно.

В событийной схеме послать событие проблемно? Что то вы с ней не то делаете.

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

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

[Igors]

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

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

В событийной схеме послать событие проблемно? Что то вы с ней не то делаете.

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

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

Это интересно обсудить, может создадим тему?