Посоны, а чо там с delete this?

Да у всех крышу рвёт с него...

и?

смотри: существует сущность выше, который должен отвечать за read/write с контрактом ошибок, удобным тебе. Этот контракт ошибок логически не связан с захваченной сущностью "сетевое соединение" и владеешь ты объектом контракта

Я завязываю с разговорами на эту тему.

Лущ бы using explicit пообщупали.)

и?

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

смотри: существует сущность выше, который должен отвечать за read/write с контрактом ошибок, удобным тебе. Этот контракт ошибок логически не связан с захваченной сущностью "сетевое соединение" и владеешь ты объектом контракта

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

Всё, я замолк

смотри: существует сущность выше, который должен отвечать за read/write с контрактом ошибок, удобным тебе. Этот контракт ошибок логически не связан с захваченной сущностью "сетевое соединение" и владеешь ты объектом контракта

учи меня ещё, сенсей

учи меня ещё, сенсей

толсто же, ты спросил я ответил)

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

он всё равно связан с циклом жизни .. как ты это там умно называешь ... ща

Ну можно запретить все некорректные создания

как запретить создание на стеке? создание массива объектов на хипе?

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

толсто же, ты спросил я ответил)

а, с захваченной сущностью "сетевое соединение"

как запретить создание на стеке? создание массива объектов на хипе?

приватный конструктор

как запретить создание на стеке? создание массива объектов на хипе?

продуцирующую функцию делай и помещай в private конструктор

а, с захваченной сущностью "сетевое соединение"

у такой сущности циклом жизни управляешь не только лишь ты. внешнее управление выражается как delete this (явно или неявно)

как запретить создание на стеке? создание массива объектов на хипе?

Конструкторы все закрыть и сделать статичную производящую функцию )

у такой сущности циклом жизни управляешь не только лишь ты. внешнее управление выражается как delete this (явно или неявно)

ну и shared_ptr в обработчике СОБЫТИЙ от такой сущности, прекрасно справляется без суицида

friend?

friend?

static

friend?

struct Foo { static Foo* make_foo(); // only new private: Foo(); }

ну и shared_ptr в обработчике СОБЫТИЙ от такой сущности, прекрасно справляется без суицида

ну либо у тебя объект сдохнет с вызовом по this в стеке, либо объект может существовать в некорректном состоянии, я не вижу альтернативу

ну либо у тебя объект сдохнет с вызовом по this в стеке, либо объект может существовать в некорректном состоянии, я не вижу альтернативу

с чего ты это взял?

с чего ты это взял?

а какая альтернатива?

с вызовом по this в стеке он дохнет как раз при delete this

смотри, ты получаешь результат DISCONNECTED при проведении операции

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

а какая альтернатива?

передавать shared_ptr в хендлер

дальше он может его передать дальше или скинуть

при этом работает ДАЖЕ если несколько хендлеров параллельно вызвались

@berkus @webreh короче, можно резюмировать, если С++ объект управляет временем жизни ресурса, то здесь вопросов нет, если ресурс управляет временем жизни объекта C++, то delete this в самый раз

@berkus @webreh короче, можно резюмировать, если С++ объект управляет временем жизни ресурса, то здесь вопросов нет, если ресурс управляет временем жизни объекта C++, то delete this в самый раз

хуета, ок

закончили

передавать shared_ptr в хендлер

смотри: я получаю сигнал разрыва соединения. Мои действия?

приватный конструктор

Есть же человеческий delete

смотри: я получаю сигнал разрыва соединения. Мои действия?

пойти в лес

ну серьезно

надоело короч, надо писать код

вопрос: какая альтернатива, кроме 1) объект может существовать после разрыва соединения 2) оповещение разрыва удаляет объект

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

там полный lifecycle сетевого соединения с ssl

я не понимаю, какое третее между "объект удален оповещением" и "объект не удален оповещением"

хуета, ок

ну, это не то, что я сказал

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

так код просто реализует альтернативу "объект бывает в некорректном состоянии"

так код просто реализует альтернативу "объект бывает в некорректном состоянии"

whatever

так код просто реализует альтернативу "объект бывает в некорректном состоянии"

я посмотрю как ты реализуешь это c delete this, хотя ты обвиосли не сможешь - застопоришься на постоянных крашах от double free

я посмотрю как ты реализуешь это c delete this, хотя ты обвиосли не сможешь - застопоришься на постоянных крашах от double free

я не собираюсь это делать

я не собираюсь это делать

ну я и сказал, что не сможешь

грубо говоря я считаю корректным примером примерно следующее struct some_reference_wrapper { static some_reference_wrapper * wrap(notifiable_object & ref) { return new some_reference_wrapper(ref); } void notify() & { delete this; } private: explicit some_reference_wrapper(notifiable_object & ref): ref_(ref) { ref.on_dtor(UTILS_BIND_THIS(notify)); } notifiable_object & ref_; };

вроде же Джерри там главный. Но Зайцев там тоже важный ?

ну ты как бы пинай, чтобы либы пакетили. Ещё пусть пилят плагин

там работы жесть сколько. просто пусть пакетят либы

грубо говоря я считаю корректным примером примерно следующее struct some_reference_wrapper { static some_reference_wrapper * wrap(notifiable_object & ref) { return new some_reference_wrapper(ref); } void notify() & { delete this; } private: explicit some_reference_wrapper(notifiable_object & ref): ref_(ref) { ref.on_dtor(UTILS_BIND_THIS(notify)); } notifiable_object & ref_; };

да пожалуйста, теперь реализуй на этом как-нибудь асинхронную https сессию

после пары double free обсудим еще раз

ну ты как бы пинай, чтобы либы пакетили. Ещё пусть пилят плагин

Пинаем, пинаем ?

Нахера delete this?

Не нужно же. И так вызывается деструктор.

Нахера delete this?

лучше заменить на эксплицитный вызов деструктора в конструкторе

лучше заменить на эксплицитный вызов деструктора в конструкторе

мсье знает толк

после пары double free обсудим еще раз

чсх я уже написал)

а, стоп, все норм

чсх я уже написал)

не знаю что такое чсх, но давай ссылку

что самое характерное

я думал в примере есть double free

у меня нет примеров кода с double free, я все указатели врапаю всегда

delete запрещено конвенцией кроме реализации just-another-smart-ptr

должно быть жутко эффективно, но мы не об этом

хтппс сессия

ERROR: S client not available

внешнее владение, или как там у вас это называется

у меня будет в этой модели сокет-суицидник, который всегда за оберткой

хотя это неудобно, да

наверное, обертка-сессия хранит сокет-суицидник с приватным деструктором и вызывает disconnect сокета в своем деструкторе наверное, сокет-суицидник хранит ссылку на сессию и оповещает сессию перед самоуничтожением

принципиально можно без delete this, она просто грохнет его через unique_ptr

disconnect() сокета это асинхронная операция, которая заканчивается ... когда-то

тогда у сокета не ссылка, а указатель на сессию

принципиально можно без delete this, она просто грохнет его через unique_ptr

нельзя, только delete this, только хардкор

нельзя, только delete this, только хардкор

ну в моем астральном мире это одно и то же

технически delete this там будет после последней операции

оповещение произошедшего disconnect

хорошо, а как ты определишь что операция была последняя?

тахионный ответ ;)

я оповещаю сессию, если она от меня не детачнулась раньше

ну вот ты вызвал сокету дисконнект, и он уже дисконнектнулся, но тут вдруг SSL такой А ЗАКРЫТЬ СЕКЬЮРНОЕ СОЕДИ

у меня взаимные оповещения о смерти между сессией и сокетом-суицидником

логика "что делать при операциях с нуллптр вместо сокета" остается сессии

сессия никому никогда не дает указатель внутренний на сокета-суицидника

логика "что делать при операциях с нуллптр вместо сокета" остается сессии

ясно-понятно, то есть во ВСЁМ коде у тебя еще и проверка shared_ptr на нулл, да?

у меня нет ни одного shared_ptr

только обычные указатели

проверка на null в деструкторах

проверка на null в сессии при операциях

мультитрединг идет в лес

что ж, я составил представление о твоей (говно)архитектуре, спасибо

она хотя бы быстрая

она говняная

даже в plain c постоянно приходится иметь дело с рефкаунтерами

она говняная

зато быстрая

даже в plain c постоянно приходится иметь дело с рефкаунтерами

рефкаунтеры вообще не при делах!

так и shared_ptr быстрая

если не дергать рефкаунтер без нужны