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

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

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

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

А нахрена нужен интрузив обмазанный еще сверху недостатками шареда?

> ничайно вот так написать не получится:
>
> make_shared<some>(new some);

А так ты только эту малость считал проблемой неправильных аллокаций? Ну да, у шареда это проблема. Но ведь у интрузива это не проблема - у него и незачем такое запрещать по большому счёту (при этом new some запретить как раз можно без последствий, в отличие от make_shared).
Другое дело что это самая малая проблема неправильных аллокаций - которые make_shared решить не может вообще, надо отказываться как раз к данному синтаксису, если хочется запретить аллокации на стеке.
Т.е. у шареда вообещ патовая ситуация - запрещаешь одно - отваливается другое, запрещаешь другое - отваливается первое. Ндас...


#211
9:57, 23 авг. 2017

=A=L=X=
> например в иерархии владения parent-child в child сохранить ссылку на parent -
> у shared_ptr нельзя сделать это простым указателем, т.к. это создаёт сразу же
> возможность в будущем попытаться этот указатель превратить снова в shared_ptr
> при любом чихе, а это, как мы знаем, сломает нахрен программу. У intrusive_ptr
> же, как мы помним, нет этой проблемы - храни, конвертируй, не ошибайся только с
> тем чтобы лезть грязными пальцами в указатель когда объект уже удалён - та же
> проблема что и у weak_ptr, ведь если parent удаляется раньше child, то это уже
> косяк в программе для обоих случаев.
Вот тут отсутствует логика. С intrusive_ptr всё хорошо, потому что нужно всего лишь не ошибаться, а с shared_ptr плохо, потому что он даёт механизм, который исключает возможность ошибки в данной ситуации.

Теперь смотри: никто не мешает передать child'у ссылку, разыменовав shared_ptr, или сырой указатель с помощью .get(), и пользоваться ими, не конвертируя его обратно в shared_ptr. Мы получаем ту же самую подверженность ошибкам, что и у intrusive_ptr, которую ты почему-то считаешь его преимуществом. Но как видишь, этим "преимуществом" shared_ptr тоже может обладать при желании :D

А если серьёзно: у intrusive_ptr _нет_ надёжного способа конвертации из сырого (не владеющего) указателя. У shared_ptr - есть.
Твоё не ошибайся только с тем чтобы лезть грязными пальцами в указатель когда объект уже удалён - это не серьёзно.
Приписывать этот факт в пользу intrusive_ptr - уже и вовсе бред.

#212
10:00, 23 авг. 2017

Alexander K
> а с shared_ptr плохо, потому что он даёт механизм, который исключает
> возможность ошибки в данной ситуации.

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

#213
10:09, 23 авг. 2017

Alexander K

> Теперь смотри: никто не мешает передать child'у ссылку, разыменовав shared_ptr, или сырой указатель с помощью .get(), и пользоваться ими, не конвертируя его обратно в shared_ptr. Мы получаем ту же самую подверженность ошибкам, что и у intrusive_ptr

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

#214
10:10, 23 авг. 2017

=A=L=X=
> Но тогда ничто не помешает джуниору написать код вида new Object или Object
> instance - а с интрузив это становится возможным.

вот что это за бред?

1.
у нас закрыты конструкторы класса.

теперь джуниор не сможет сделать ни new Object
ни Object obj;

и это как бы вообще никак не зависит ни от шаред, ни от интрузив.


2.
у нас открыты конструкторы класса.
теперь  джун может сделать и так, и этак.
и это так же не зависит ни от шаред, ни от интрузив.

=A=L=X=
> Непонятно вообще зачем ты приводишь тогда make_shared тут как аргумент, как и
> было непонятно это когда ты говорил про "кто создаёт тот и удаляет",

дизайн вида:

smart p(new res);

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

make_shared/make_intrusive безопасны,
и в качестве бонуса способны предоставить массу дополнительных профитов.
например, инжектить методы clone/destruct/etc

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

в ситуации, когда мы не можем этого контролировать,
нам могут подсунуть все что угодно.

=A=L=X=
> Запрет чего? Пример в студию.

ну сделайте shared_from_this с закрытыми конструкторами,
а make_shared - его другом.

и все, те классы, которым нужны возможности shared_from_this
больше уже будет нельзя создать никак,
иначе чем через make_shared.

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

=A=L=X=
> Лол, я же запретил конструктор и не смогу создать поэтому его на стеке -
> экземпляр объекта я могу получить только из его кишок из метода smart< MyObject
> > MyObject::Create, потому что все конструкторы приватны.
> С интрузив мне на это пофигу - ему достаточно только указателя на объект, а вот
> с make_shared не сможет с этим работать вообще. Вообще.

не осилил этот поток сознания.
вы таки пришли к осознанию профита:

smart<MyObject> MyObject::Create
или нет?
потому что этот тот же самый make_smart, если что.

=A=L=X=
> То есть ты пытаешься рассказывать о глобальном недостатке шаред так как будто
> бы это его преимущество, лол.

то есть я пытаюсь рассказать о глобальном недостатке любого смарта.
об ущербности дизайна:

smart<some>(ptr)
который не безопасен ни для одного из них.

и о том, какие профиты несет в себе безопасный,
и надежный make_smart

#215
10:21, 23 авг. 2017

=A=L=X=
> А нахрена нужен интрузив обмазанный еще сверху недостатками шареда?

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

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

=A=L=X=
> Но ведь у интрузива это не проблема - у него и незачем такое запрещать
у интрузива здесь ровно точно такая же проблема - можно скормить все что угодно.
например адрес объекта на стеке.

=A=L=X=
> при этом new some запретить как раз можно без последствий, в отличие от
> make_shared).
не распрасил этот поток сознания.

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

=A=L=X=
> Т.е. у шареда вообещ патовая ситуация - запрещаешь одно - отваливается другое,
> запрещаешь другое - отваливается первое. Ндас...
приведите пример хотя бы одного такого случая.

=A=L=X=
> может только замаскировать проблему, если объекты удаляются не в
> запланированном порядке, то скорее всего возникла проблема.

1.
это что за домыслы из области говнокода?

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

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

3.
вы сейчас начинаете вести себя необъективно.
как священный воен.
который готов отстаивать даже открытую дыру в безопасности
классической модели интрузива.

#216
10:24, 23 авг. 2017

Kartonagnick
> и это как бы вообще никак не зависит ни от шаред, ни от интрузив.

Слушай ну мне реально совершенно неинтересно спорить с человеком который до сих пор не понял, что make_shared требует наличия у объекта публичных конструкторов. Просто требует, он так сделан.
Т.е. ты не сможешь им воспользоваться в идиоме когда ты прячешь от джуниоров альтернативные способы конструирования объекта, такие как в стеке или в new. Надо откатываться как раз к shared_ptr( ptr ) с пенальти по аллокациям и раскрытием того, что ты собирался закрыть.
А интрузиву сокрытие конструкторов совершенно не мешает. Если ты до сих пор этого не понял, то я не вижу смысла диспут с тобой поддерживать, это просто трата времени.

#217
10:30, 23 авг. 2017

=A=L=X=
> Неверно уже из самой фразы - ведь в интрузив можно спокойно конвертировать
> обратно в смарт.
Нельзя сырой указатель спокойно конвертировать обратно в intrusive_ptr, ибо нет никакой возможности проверить, что он валиден.

> Собственно только поэтому у шареда и нужны слабые ссылки в первую очередь, а
> вовсе не из-за механизма удержания.
weak_ptr существует, чтобы решить проблему циклических ссылок (которым, кстати, intrusive_ptr тоже подвержен, но при этом не имеет способа решения этой проблемы), а также чтобы иметь возможность хранить не владеющий указатель, при этом с проверкой его валидности.

#218
10:35, 23 авг. 2017

Короче приведу код описывающий проблему, наверное без этого так и не станет понятно:

// Прячем от джуниоров все способы создания объекта кроме через smart:

class MyObject
{
  // спрятали конструкторы в private или protected
public:
  static smart<MyObject> Create( params... )
  {
    return smart<MyObject>( new MyObject( params... ) ); // make_shared тут бессилен
  }
};
Внутри объекта new работает, снаружи нет и создать нельзя никак кроме как MyObject::Create.
Вот это - правильная инкапсуляция создания объекта, запрещающяа всё что не в кассу. А make_shared тут инвалид.
#219
10:38, 23 авг. 2017

Alexander K
> weak_ptr существует, чтобы решить проблему циклических ссылок
...потому что он не может её решить другим способом - а у интрузив есть всегда валидная возможность правильно сконвертить указатель. в неправильной программе может случится облом, но в правильной, где объекты удаляются правильно, чему способствуют смарты - всё будет в порядке. а вот у шареда никогда порядка при такой конверсии не будет - она всегда завалит программу.
как продебажить прогу с интрузив я уже описал.

#220
11:35, 23 авг. 2017

=A=L=X=
> Так опять же, weak_ptr решает проблему, которая у intrusive_ptr просто
> отсутствует - например в иерархии владения parent-child в child сохранить
> ссылку на parent - у shared_ptr нельзя сделать это простым указателем, т.к. это
> создаёт сразу же возможность в будущем попытаться этот указатель превратить
> снова в shared_ptr при любом чихе, а это, как мы знаем, сломает нахрен
> программу.
"Нахрен" надо выкидивать программы у которых перенты смарт поинтерами хранятся а чайлды сырыми - это прям дичь.

*Lain*
> Переименуйте уже тред в "я бросил" и бросьте его уже наконец. Уже же сто раз
> это с разных сторон обсудили. А так то вы похожи на аутистов, все время
> повторяющих одно и тоже.
Как раз дурная практика "потрындеть" в треде и остаться при своём мнении. Каждый, кто ошибался, так и не поумнеет в итоге. Разбираться всегда в проблеме надо так, чтоб вопросов вообще не возникало, всё было понятно до конца. Для человека, вледаеющего логическим мышлением этого достаточно, чтоб остановиться спорить и всё осознать. Иначе зачем вообще всё начинать.

#221
11:38, 23 авг. 2017

=A=L=X=
> make_shared требует наличия у объекта публичных конструкторов.
Это ограничение легко обходится, думаю лучше будет если я об этом скажу, нежели это хамло Kartonagnik
https://ideone.com/SQhakC

#222
11:43, 23 авг. 2017

Кот Зловред
> https://github.com/alembic/alembic

L
> "Нахрен" надо выкидивать программы у которых перенты смарт поинтерами хранятся
если shared_ptr`ом, то да надо выкидывать.

например, вот эту программу:
>https://github.com/alembic/alembic/blob/d75360416b1b20df85c4f58195d0898695ceb525/lib/Alembic/AbcCoreOgawa/OrImpl.h#L100

Alembic::Util::shared_ptr< OrImpl > m_parent;

#223
11:48, 23 авг. 2017

Adler
Вырезал из контекста половину предложения, добавил не внятный пример кода и доволен. Какой молодец.

Если ты не понял, я объясню:
Товарищ =A=L=X= заявляет, что weak_ptr говно и фиксит баги корявого shared_ptr. Однако, проблема циклических ссылок имеется точно такая же и у intrusive_ptr! И, как я понял, человек предлагает, например, parent-ов хранить смарт поинтерами, child-ов сырыми. Типа это "фишка такая" - можно кастовать "безболезненно" (почему-то, и что это решает???) к сырому поинтеру.  Что в сумме чушь полнейшая ибо не решает проблему циклической зависимости в принципе и вводит неконсистентность в код.

#224
11:56, 23 авг. 2017

totoro
> Это ограничение легко обходится

Не но костыль то еще тот! Тот же typeid полетит к чертям при таком "легко обходится". Не не не, не надо такого, Дэвид Блейн.

L
> почему-то, и что это решает???)

Блин, ну 10 страниц уже это обсуждаем - в shared_ptr следующий код вызывает UB:

object *ptr = new object();
shared_ptr sh1( ptr ); // ok, "захват" произошёл
shared_ptr sh2( ptr ); // UB!!! програ крашнется.
Так устроен shared_ptr - это его врождённый недостаток, проблема порождённая тем что он универсален и способен "захватить" любой объект. Захват порождает структуру со счётчиком ссылок, но из указателя на объект её невозможно восстановить - захват должен проиходить 1 и только 1 раз, дальше ссылка должна передаваться только посредством копирования из смартов в смарты же.
У intrusive в связи с тем, что счетчик внедрен в сам объект такой код не вызывает никаких проблем - всё правильно разруливается. Возможна безопасная конверсия из смарта в обычный указатель и обратно. Вот поэтому то weak_ptr главным образом становится не нужен - достаточно обычного указателя.
P.S.
Ну и еще, кстати, у shared исходя из вышеописанного или сам он содержит 2 указателя - на объект и на счётчик ссылок, или он содержит только 1 указатель на служебную структуру из счётчика ссылок на указателя на объект. Первое раздувает ссылку до двух указателей, второе делает 2 разыменования указателей вместо одного при каждом обращении к объекту. Интрузив тут опять на коне.

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

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