Здравствуйте, LaptevVV, Вы писали:
LVV>Может ли уважаемый ALL привести примеры задач, в которых без шаред_птр никак не обойтись ?
волки гоняются за зайцами по лесу. зайцы могут помереть или быть сьедеными другим волками.
указатели на зайцев, как и на волков хранятся в лесу, но волку тоже хочется иметь указатель, чтобы не искать зайца заново в каждой итерации. можно искать зайца по имени или по ближайшим координатам, но зачем когда есть shared_ptr

Здравствуйте, LaptevVV, Вы писали:

LVV>Может ли уважаемый ALL привести примеры задач, в которых без шаред_птр никак не обойтись ?

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

Здравствуйте, Igore, Вы писали:

I>Здравствуйте, Chorkov, Вы писали:

LVV>>>Может ли уважаемый ALL привести примеры задач, в которых без шаред_птр никак не обойтись ?

C>>Передача объектов DOM в плагины, или в иные языки программирования типа python.
C>>Т.е. когда мы не контролируем время жизни объектов, на стадии проектирования.
I>Так лучше не делать, в итоге стреляет когда по разному удаляется и приходят к init/deinit в С стиле. В плагины и т.д. проще голый указатель передать, как явное указание что нет владения данными.

Это если плагины не имеют права менять DOM. У меня, чаще имеют. Причем достаточно сильно.

LVV>>Может ли уважаемый ALL привести примеры задач, в которых без шаред_птр никак не обойтись ?
Pzz>Ну если у тебя разные объекты/потоки исполнения имеют одновременный доступ к одному и тому же объекту, и нет какого-то понимания, когда отпустят, shared_ptr, библиотечный или самодельный — хороший вариант.
Да, я уже понял, что это в сторону параллельных...

Здравствуйте, LaptevVV, Вы писали:

Pzz>>Ну если у тебя разные объекты/потоки исполнения имеют одновременный доступ к одному и тому же объекту, и нет какого-то понимания, когда отпустят, shared_ptr, библиотечный или самодельный — хороший вариант.
LVV>Да, я уже понял, что это в сторону параллельных...

Вовсе не обязательно. Возьмите условный make, которому нужно иметь дерево зависимостей. Какой-нибудь .h-файл может быть в зависимостях сразу у нескольких .с-файлов, ссылку на описатель этого .h-файла в дереве зависимостей можно хранить в виде shared_ptr.

Или текстовый документ. Есть понятие "абзац", есть понятие "стиль абзаца" (левая и правая граница, отступ до, отступ после, межстрочный интервал и т.д.). У объекта "абзац" вполне себе может быть shared_ptr на объект "стиль абзаца".

Здравствуйте, B0FEE664, Вы писали:

BFE>В двух разных окнах приложения отображаем (редактируем) одни и те же данные (картинку) с, например, разными фильтрами. Пользователь волен открывать и закрывать окна в произвольном порядке.
Это же классический случай для MVC.

Здравствуйте, LaptevVV, Вы писали:

LVV>Может ли уважаемый ALL привести примеры задач, в которых без шаред_птр никак не обойтись ?

Возможные, на мой взгляд, минусы:
1. Получается определённый оверхед на выделениях памяти, управляющий блок + сам объект. Не очень кэш френдли.
2. Счётчики ссылок это атомик — соответственно при большом количестве объектов тоже будут проблемы с кэшем, но это в основном актуально в геймдеве, где как раз таки может решаться в частном порядке
3. При программировании структур данных на основе шаредов можно получить циклические зависимости и объекты не будут удаляться. Надо внимательно использовать weak_ptr.

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

Здравствуйте, so5team, Вы писали:

S>Вовсе не обязательно. Возьмите условный make, которому нужно иметь дерево зависимостей. Какой-нибудь .h-файл может быть в зависимостях сразу у нескольких .с-файлов, ссылку на описатель этого .h-файла в дереве зависимостей можно хранить в виде shared_ptr.

Условному make можно построить дерево зависимостей, и не освобождать его.

S>Или текстовый документ. Есть понятие "абзац", есть понятие "стиль абзаца" (левая и правая граница, отступ до, отступ после, межстрочный интервал и т.д.). У объекта "абзац" вполне себе может быть shared_ptr на объект "стиль абзаца".

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

Здравствуйте, SaZ, Вы писали:

SaZ>Счётчики ссылок это атомик — соответственно при большом количестве объектов тоже будут проблемы с кэшем

Это один из случаев где плюсы отходят от принципа "not pay for what you don't use"

Слава богу для таких случаев есть local_shared_ptr

Здравствуйте, ArtDenis, Вы писали:

SaZ>>Счётчики ссылок это атомик — соответственно при большом количестве объектов тоже будут проблемы с кэшем

AD>Это один из случаев где плюсы отходят от принципа "not pay for what you don't use"

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

Здравствуйте, so5team, Вы писали:

SaZ>>>Счётчики ссылок это атомик — соответственно при большом количестве объектов тоже будут проблемы с кэшем
AD>>Это один из случаев где плюсы отходят от принципа "not pay for what you don't use"
S>Там же еще и счетчик слабых ссылок есть, который очень часто не нужен от слова совсем. Так что атомики не единственное такое отхождение от принципа не платить за неиспользуемое

Ну это не совсем тоже самое. Если без слабых ссылок, то это, так сказать, raii ref counter. В стандарте, конечно, такого нет. Но я раньше часто встречал такой велосипед в эпоху до цпп11.

Здравствуйте, SaZ, Вы писали:

SaZ>Ну это не совсем тоже самое.

Как посмотреть. Принципиальное отличие shared_ptr от unique_ptr в том, что shared_ptr допускает совместное владение, тогда как unique_ptr -- только эксклюзивное.

А поскольку в C++ной stdlib нет других штатных способов выразить совместное владение, то приходится прибегать к shared_ptr. Даже когда weak-ссылки не нужны в принципе.

SaZ>Но я раньше часто встречал такой велосипед в эпоху до цпп11.

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

Здравствуйте, tapatoon, Вы писали:
T>Здравствуйте, LaptevVV, Вы писали:

Мы медленно и планомерно избавились от шаред. Оказалось они не нужны. Т.е. мы никогда никуда не передаём параллельное владение. Ни наверх по стеку, ни в параллельные процессы.

Но у нас есть библиотека, где все объекты шаред. Скорее интрузивные, но без разницы. Это математика. Когда мы запускаем вычисления, создаём объекты, библиотека сама следит за тем, кто и когда это всё подчистит. И таких Кад библиотек я знаю несколько.

S_B>Но у нас есть библиотека, где все объекты шаред. Скорее интрузивные, но без разницы. Это математика. Когда мы запускаем вычисления, создаём объекты, библиотека сама следит за тем, кто и когда это всё подчистит. И таких Кад библиотек я знаю несколько.
Ссыли можете привести пару-тройку ?

Здравствуйте, LaptevVV, Вы писали:

S_B>>Но у нас есть библиотека, где все объекты шаред. Скорее интрузивные, но без разницы. Это математика. Когда мы запускаем вычисления, создаём объекты, библиотека сама следит за тем, кто и когда это всё подчистит. И таких Кад библиотек я знаю несколько.
LVV>Ссыли можете привести пару-тройку ?
c3d, OpenCascade