Войти
ФлеймФорумПрограммирование

Список модных прог в которых shared_ptr и weak_ptr и unordered_map хорошо зашли (16 стр)

Страницы: 112 13 14 15 16 17 Следующая »
#225
12:00, 23 авг. 2017

=A=L=X=
Я не тупой и _прекрасно_ представляю, как работает shared_ptr, intrusive_ptr и ещё много разных _ptr.  Очевидно, что я описывал вполне внятно претензию к подобному утверждению:

=A=L=X=
> Неверно уже из самой фразы - ведь в интрузив можно спокойно конвертировать
> обратно в смарт. Собственно только поэтому у шареда и нужны слабые ссылки в
> первую очередь, а вовсе не из-за механизма удержания. Нужен валидный метод
> хранить на объект ссылку, которой можно пользоваться без ограничений - например
> передавать дальше куда либо - child просто не сможет этого правильно сделать
> если бы не было weak_ptr. Просто не смог бы. Зачем ему ссылка, которую никуда
> нельзя передать? Это уже бред, а не ссылка. А у интрузив в первую очередь нет с
> этим никаких проблем - поэтому и нужда в weak_ptr вообще не возникает.

Ещё раз:
>поэтому и нужда в weak_ptr вообще не возникает.

Так каким образом чайлд на перента будет хранить  поинтер, если перент хранит intrusive_ptr на чайлда? Как решишь циклическую зависимость? Тебе же не нужен мерзкий weak_ptr, так как же? И чем тут поможет каст к сырому указателю? )

=A=L=X=
> Тот же typeid полетит к чертям
Который никому и не нужен в прямом виде, а dynamic cast и так прекрасно сработает.


#226
12:03, 23 авг. 2017

=A=L=X=
> У intrusive в связи с тем, что счетчик внедрен в сам объект
Дык make_shared<> тоже так делает. Надо просто запретить конструировать шаред от левой фигни, и всё.

#227
12:03, 23 авг. 2017

L
> Так как чайл на перента хранить будет поинтер, если перент хранит intrusive_ptr
> на чайлда?

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

#228
12:04, 23 авг. 2017

1 frag / 2 deaths
> Надо просто запретить конструировать шаред от левой фигни, и всё.

Выше уже обсудили почему make_shared это космическая лажа в этом вопросе.

#229
12:07, 23 авг. 2017

=A=L=X=
> А что ему запрещает то? Чайл берет и хранит указатель на парента - ноу
> проблемо.
Тем самым вызывает addref если хранит в виде intrusive_ptr и генерит потому циклическую зависимость, проблема не решена.  Или ты предлагаешь просто хранить сырой поинтер на перента и не делать addref? Ну это же тогда совсем дичь )  В одной половине проги нормальный автоматический рефкаунт, в другой надо НЕ ЗАБЫТЬ сделать release (если попользовался)! И не сделать release удалённому объекту, но узнать удалён ли _не возможно_ нормально с сырым поинтером. (upd: я скорее имел в виду addref когда поинтер на перент уже удалён)

То есть intrusive_ptr имеет _ту же_ проблему циклических ссылок (это как бы очеивдно), и не имеет стандартного решения типа weak_ptr, которое так же _очевидно_.

#230
12:11, 23 авг. 2017

=A=L=X=
> Не но костыль то еще тот!
Основной костыль заключается в том, что после неявного приведения shared_ptr<Bootstrap> к shared_ptr<Foo> в памяти хранится экземпляр shared_ptr<Bootstrap> вплоть до уничтожения последнего экземпляра shared_ptr<Foo> который на него ссылается. И действительно, если мы рассмотрим иерархию Bootstrap : public Foo, то при создании экземпляра Bootstrap виртуальная таблица не порождается, а значит при удалении этого объекта через Foo* деструктор ~Bootstrap() не должен вызываться, однако:
https://ideone.com/OaB9GB
Об этой особенности смарта я еще в 160 сообщении говорил.

#231
12:16, 23 авг. 2017

L
> Тем самым вызывает addref

Нет не вызвает.

> В одной половине проги нормальный автоматический рефкаунт, в другой надо НЕ ЗАБЫТЬ сделать release!

Зачем? Сырой указатель - когда weak_ptr, когда отношение использования, а не владения. Там где появляется отношение владения - intrusive_ptr. Всё просто.

#232
12:18, 23 авг. 2017

=A=L=X=
> Нет не вызвает.
Создание intrusive_ptr из сырого поинтера _вызывает_ addref.  Если ты хочешь создать смарт поинтер НЕ вызывая addref, то поломаешь всё к чертям, т.к. не знаешь жив объект ещё или мёртв.

#233
12:20, 23 авг. 2017

totoro

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

#234
12:21, 23 авг. 2017

L

Смотри - всё просто: Parent хранит IntrusivePtr<Child>, Child хранит Parent* и ни тот ни другой не вызывают вручную ни addRef ни release и при этом все удаляются в правильном порядке. Ты чёто в кучу намешал. Никто не хранит нигде и не должен хранить Child у которого нет живого Parent, это ошибка в программе была бы логическая, такого нельзя допускать ни с интрузив ни с шаред.

#235
12:31, 23 авг. 2017

=A=L=X=
1. Смешивание сырых и смарт поинтеров - само по себе писец.
2. Выкручиваешься за счёт знания о верхнеуровневой логике программы вместо обсуждения минимального тесткейса подверженного багам, которые решают смарт поинтерами. Нуок, засчитано.
3. Предположим логика программы в случае отношений parent-child всё разруливает (это НЕ заслуга intrusive_ptr). И вот у нас есть weak_ptr. Который  == твоему "сырому" указателю без рефкаунта. Только не сырой, умеет так же конвертироваться в smart, добавляет проверку валидности объекта когда дело касается не владеющего использования.  То есть суммарно weak_ptr уделывает сырой поинтер.

#236
12:38, 23 авг. 2017

L
> 1. Смешивание сырых и смарт поинтеров - само по себе писец.

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

Задолго до shared_ptr существовали те же COM-объекты с ref-count-ом и к ним шаблонные "холдеры" автоматически вызывающие AddRef/Release и всё это классно смешивалось и где не надо было захватывать - использовали обычный указатель, где надо было захыватывать - смарт. И всё прекрасно работало и никто не исходил пеной, что нельзя смешивать, потому что можно смешивать.

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

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

#237
12:48, 23 авг. 2017

Программу на смартах легко проверить на валидность - надо просто дать на поиск "delete", "addRef", "release" и если слова встретятся - значит надо вносить корректировки. Вот и всё, и не надо надувать слона из личных проблем убогого shared_ptr.

#238
12:58, 23 авг. 2017

=A=L=X="
> Это высказывание проистекает из-за повального распространения shared_ptr
Это высказывание проистекает из такого понятия, как "многолетний опыт разработки различнейшего софта от desktop до embedded". Что из опыта усвоил, о том и говорю и претензии такие мне не стоит предъявлять, будто бы я "ведусь на модное и делаю как дяди пишут". Свои слова я аргументирую и жду в ответ того же (не как в комментируемом предложении и последующих).

=A=L=X=
> Задолго до shared_ptr существовали те же COM-объекты с ref-count-ом и к ним
> шаблонные "холдеры" автоматически вызывающие AddRef/Release и всё это классно
> смешивалось
И существует и я ими пользуюсь как в С++ так и в C# и передаю между ними объекты, имеется свой кошерный смарт поинтер для COM, конечно же с кастом к сырому поинтеру и обратно. И это знание не мешает мне писать то, что я писал выше, ни чего не меняется. С COM просто нет другого выхода, счётчик у него встроен, при чём для каждого интерфейса внешние ссылки могут быть _отдельными_. Там своя идеология и ломать её конверсией к shared_ptr было бы крайне тупо, включая то, что имеется куча legacy кода принимающего только сырые указатели.

=A=L=X=
> убогий shared_ptr
А вот это уже смешивание необоснованных эмоций с логикой, что никогда не помогает в поисках решения.

shared_ptr НЕ убогий, это обычный смарт поинтером с вледанием объекта, weak_ptr - компаньён, не владеющий объектом, вместе они - мощная концепция, использующаяся в GC многих языков и не только в GC.  В проблеме с перентом/чайлдом intrusive ни как не выигрывает (я могу weak_ptr держать), в концепции не владещего использования intrusive вообще не может в принципе использоваться.  И намазывать на каждый свой класс intrusive перента лишь бы можно  было кастонуть к сырому поинтеру ИМХО "так себе" аргумент. Реальных профитов я не вижу.

#239
13:06, 23 авг. 2017

Ладно, щас по второму, если не третьему, кругу так пойдём, на все эти возражения я уже отвечал выше, я выхожу.

Страницы: 112 13 14 15 16 17 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.