на C++

oxymoron detected

я всего лишь занимаюсь пакетированием либ + взаимодействием с русским коммунити

они бы и рады передохнуть, но ты их конкретно педалишь :)

после смерти отдохнут, пакетов еще тьма тьмущая

раз взялись, то пусть делают.

после смерти отдохнут, пакетов еще тьма тьмущая

Истинно так

вон пусть пример с vcpkg берут

Это еще что, есть даже вот такое: http://cppconf.ru/workshops/anton-polukhin * а если серьёзно, то у Павла крутой мастер класс, весьма полезный :)

А где эта конференция проходит-то? Хочу поехать, но из сайта не ясно, в каком городе.

В Питере

Окей, спасибо.

@berkus , вот гляди. Есть у тебя окно, немодальное. Цикл жизни такой: по событию создаётся , висит на экране, обрабатывает ввод какой-то, события какие-то, потом пользователь его закрывает, когда оно становится ненужным. (оно ОБЯЗАНО создаваться динамически, потому как выйдет из контекста обработки события точно) Попробуй подумать КТО должен им владеть и ГДЕ должен лежать SHARED_PTR или UNIQUE_PTR и кто его будет удалять...

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

Расскажите поподробнее про "сам контрлолирует свой время жизни"? Ну или пример кода скиньте

Расскажите поподробнее про "сам контрлолирует свой время жизни"? Ну или пример кода скиньте

http://en.cppreference.com/w/cpp/memory/shared_ptr

http://en.cppreference.com/w/cpp/memory/shared_ptr

@antoshkka может тебе в супапро, если не знаешь, как работает shared_ptr? ?

???

вообще, это очень сложный вопрос

чтобы созданный объект сам хранил рефренс на себя

Расскажите поподробнее про "сам контрлолирует свой время жизни"? Ну или пример кода скиньте

Я ж описал всё...

я это когда-то давно делал через всякие enable_shared_from_this и самоотстрел специальным методом

чтобы созданный объект сам хранил рефренс на себя

Вы про weak_ptr? Или объект хранит именно shared_ptr на самого себя, и когда надо умереть, делает shared_ptr_var.reset() ?

я делал с shared, то есть, объект создается через метод, возвращающий std::shared_ptr<T> (с приватным конструктором) и хранит внутри себя этот shared_ptr, пока ему нужно существовать вне зависимости от внешнего мира

а когда это не нужно - зовет reset, да

если внешнему миру это тоже не нужно, то все подыхает

Я ж описал всё...

кто-то сохраняет weak_ptr, сам диалог примешивает вот такую фигню в виде SharedPtrReady и когда диалог умрет, weak_ptr сможет это определить: struct SharedPtrEmptyDeletor { template<class T> void operator()(T* p) const { } }; template<typename T> struct SharedPtrReady : public std::enable_shared_from_this<T> { public: SharedPtrReady() : fake_shared_ptr_(self(), SharedPtrEmptyDeletor()) { } protected: T* self() { return static_cast<T*>(this); } private: std::shared_ptr<T> fake_shared_ptr_; };

а когда это не нужно - зовет reset, да

Вы ведь понимаете, что это лютое UB?

почему? доступ делается через один и тот же control block всегда

Запустите под санитайзерами ваш код, в тот момент, кодга this - единственный владелец shared_ptr

я не понимаю, откуда здесь может взяться UB, если класс делается через enable_shared_from_this

Вы про weak_ptr? Или объект хранит именно shared_ptr на самого себя, и когда надо умереть, делает shared_ptr_var.reset() ?

Почти по это. Оригинально был вопрос про delete this

Вы ведь понимаете, что это лютое UB?

Да нет там UB...

а в delete this что плохого?

Ничего

тоже валидное использование, если потом не дергать этот this (в т.ч. не вызывая нестатические методы)

Ну обсудили уже в supa...

@antoshkka @berkus Вообщем ситуация там такая: создано немодальное Windows окно, единственная связь с миром C++ это void* во вспомогательной структуре класса окна. Когда окно закрывается пользователем, С++ объект, ассоциированный с этим окном, должен быть уничтожен. Этот С++ объект подписывается на событие "последнегого выдоха господина пж" и убивает себя через delete this. Такова дислокация.

тоже валидное использование, если потом не дергать этот this (в т.ч. не вызывая нестатические методы)

Это не этот кейс? (не читал весь тред) Before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that refers to the storage location where the object will be or was located may be used but only in limited ways. [...] If the object will be or was of a class type with a non-trivial destructor, and the pointer is used as the operand of a delete-expression, the program has undefined behavior.

@antoshkka @berkus Вообщем ситуация там такая: создано немодальное Windows окно, единственная связь с миром C++ это void* во вспомогательной структуре класса окна. Когда окно закрывается пользователем, С++ объект, ассоциированный с этим окном, должен быть уничтожен. Этот С++ объект подписывается на событие "последнегого выдоха господина пж" и убивает себя через delete this. Такова дислокация.

если сделать фиктивный shared_ptr с пустым делитором как мембер в этом C++ объекте, отнаследоваться от enabled_shared_from_this, то это даст возможность клиентам оставлять у себя weak_ptr и контролировать жив или нет этот объект С++, связанный с окном

@antoshkka @berkus Вообщем ситуация там такая: создано немодальное Windows окно, единственная связь с миром C++ это void* во вспомогательной структуре класса окна. Когда окно закрывается пользователем, С++ объект, ассоциированный с этим окном, должен быть уничтожен. Этот С++ объект подписывается на событие "последнегого выдоха господина пж" и убивает себя через delete this. Такова дислокация.

А держать shared_ptr в обработчике события нельзя?

Это не этот кейс? (не читал весь тред) Before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any pointer that refers to the storage location where the object will be or was located may be used but only in limited ways. [...] If the object will be or was of a class type with a non-trivial destructor, and the pointer is used as the operand of a delete-expression, the program has undefined behavior.

Похоже что тот

А держать shared_ptr в обработчике события нельзя?

по сути это call_back функция, вызываемая потрохами windows

А держать shared_ptr в обработчике события нельзя?

Нельзя, объект выйдет из скопа обработчика и удалится.

А держать shared_ptr в обработчике события нельзя?

Ты что, никогда Windows-приложения не писал? :-)

Ты что, никогда Windows-приложения не писал? :-)

Ну, Ильюха, много людей Windows даже в глаза не видели

Ок, со стороны shared_ptr подлянки в виде бесконечной рекурсии не будет void shared_ptr::reset() noexcept; Effects: Equivalent to shared_ptr().swap(*this).

Ты что, никогда Windows-приложения не писал? :-)

Дык Qt же. Там это не так убого реашается, ибо можно shared_ptr держать в коллбеке, и если владелец колбека будет уничтожен, вузовется деструктор shared_ptr и ресурс не утечёт

Дык Qt же. Там это не так убого реашается, ибо можно shared_ptr держать в коллбеке, и если владелец колбека будет уничтожен, вузовется деструктор shared_ptr и ресурс не утечёт

Ну, в Qt это решается именно УБОГО. Но по-другому.

Дык Qt же. Там это не так убого реашается, ибо можно shared_ptr держать в коллбеке, и если владелец колбека будет уничтожен, вузовется деструктор shared_ptr и ресурс не утечёт

Кто тебе сказал, что shared_ptr держится в callback?

Блин, давайте к истокам.

Нельзя, объект выйдет из скопа обработчика и удалится.

unordered_map<Handle, shared_ptr<MyClass> > open_windows_to_kill_without_holding_sp_in_this; Такая конструкция поможет избежать вызова delete this?

Был вопрос, про то, что такое delete this и валиден ли такой код. Было отвечено, что 0) код валиден 1) при этом надо соблюдать некоторые условия https://isocpp.org/wiki/faq/freestore-mgmt#delete-this 2) этот подход применяется во многих фреймворках. Собственно, и всё. Далее пошёл необоснованный хай, что это плохо, это некрасиво, и т.д.

Хай обоснован тем, что в мире с исключениями ручное управление памятью и ресурсами есть зло

unordered_map<Handle, shared_ptr<MyClass> > open_windows_to_kill_without_holding_sp_in_this; Такая конструкция поможет избежать вызова delete this?

А ЗАЧЕМ его избегать?

Господа, а можно ли как-то эту порнографию редуцировать, не используя препроцессор? struct width_visitor: public boost::static_visitor<std::size_t> { template<class T> std::size_t operator() (const image<T>& i) const { return i.width(); } }; struct height_visitor: public boost::static_visitor<std::size_t> { template<class T> std::size_t operator() (const image<T>& i) const { return i.height(); } }; struct depth_visitor: public boost::static_visitor<std::size_t> { template<class T> std::size_t operator() (const image<T>& i) const { return i.depth(); } };

Хай обоснован тем, что в мире с исключениями ручное управление памятью и ресурсами есть зло

Это другой совершенно вопрос.

Господа, а можно ли как-то эту порнографию редуцировать, не используя препроцессор? struct width_visitor: public boost::static_visitor<std::size_t> { template<class T> std::size_t operator() (const image<T>& i) const { return i.width(); } }; struct height_visitor: public boost::static_visitor<std::size_t> { template<class T> std::size_t operator() (const image<T>& i) const { return i.height(); } }; struct depth_visitor: public boost::static_visitor<std::size_t> { template<class T> std::size_t operator() (const image<T>& i) const { return i.depth(); } };

http://en.cppreference.com/w/cpp/utility/variant/visit

http://en.cppreference.com/w/cpp/utility/variant/visit

У меня нет дженерик лямбд :(

Хай обоснован тем, что в мире с исключениями ручное управление памятью и ресурсами есть зло

ну в контексте WINAPI я не имею право выпустить ниодного исключения, находясь в обработчике Windows события, к тому же delete this будет последнее, что мир запомнит об этом объекте

Господа, а можно ли как-то эту порнографию редуцировать, не используя препроцессор? struct width_visitor: public boost::static_visitor<std::size_t> { template<class T> std::size_t operator() (const image<T>& i) const { return i.width(); } }; struct height_visitor: public boost::static_visitor<std::size_t> { template<class T> std::size_t operator() (const image<T>& i) const { return i.height(); } }; struct depth_visitor: public boost::static_visitor<std::size_t> { template<class T> std::size_t operator() (const image<T>& i) const { return i.depth(); } };

Мало информации о роде порнографии, но Ванга спрашивает, может удастся использовать ссылки на методы?

Мало информации о роде порнографии, но Ванга спрашивает, может удастся использовать ссылки на методы?

Ну я не представляю существует ли такая синтаксическая конструкция как ссылка на метод неинстанцированного шаблона. &image<???>::width

А в какой момент ты собираешься создавать объекты типа depth_visitor, например?

Всё, как завещали нам авторы бубсов: boost::apply_visitor(width_visitor{}, x);

вот в этот момент нельзя взять адрес метода?

ммм... нет. ведь я не знаю какой именно тип хранится в варианте

Расскажите поподробнее про "сам контрлолирует свой время жизни"? Ну или пример кода скиньте

https://github.com/boostorg/beast/blob/develop/example/advanced/server-flex/advanced_server_flex.cpp#L278

@MasterZiv ^ вот твой кейс про окно

ERROR: S client not available

@berkus , вот гляди. Есть у тебя окно, немодальное. Цикл жизни такой: по событию создаётся , висит на экране, обрабатывает ввод какой-то, события какие-то, потом пользователь его закрывает, когда оно становится ненужным. (оно ОБЯЗАНО создаваться динамически, потому как выйдет из контекста обработки события точно) Попробуй подумать КТО должен им владеть и ГДЕ должен лежать SHARED_PTR или UNIQUE_PTR и кто его будет удалять...

выше почитай

https://github.com/boostorg/beast/blob/develop/example/advanced/server-flex/advanced_server_flex.cpp#L278

Это как раз нормально - там shared_ptr держится колбеком, а не в this. В случае шибки выполнится коллбек, завершится, а потом вызовется деструктор shared_ptr (уже не из метода класса)

Это как раз нормально - там shared_ptr держится колбеком, а не в this. В случае шибки выполнится коллбек, завершится, а потом вызовется деструктор shared_ptr (уже не из метода класса)

именно так

Это как раз нормально - там shared_ptr держится колбеком, а не в this. В случае шибки выполнится коллбек, завершится, а потом вызовется деструктор shared_ptr (уже не из метода класса)

Так беркус вроде привел пример, как нормально реализовывать кейс с окном

Так беркус вроде привел пример, как нормально реализовывать кейс с окном

а где? я, похоже, пропустил

а где? я, похоже, пропустил

7 постов вверх

То, что Антон процитировал

7 постов вверх

я не понял как это применимо к "оконной" проблеме, описанной выше

я не понял как это применимо к "оконной" проблеме, описанной выше

Я сам не смотрел код beast, но походу там "объект сам управляет временем своей жизни" без delete this

я не понял как это применимо к "оконной" проблеме, описанной выше

Ну идея в том, что delete this можно заменить на агрегацию в данном классе shared_ptr на самого себя, и когда надо вызвать удаление уже через него...

Ну, можно и так.

Я сам не смотрел код beast, но походу там "объект сам управляет временем своей жизни" без delete this

Схематично код, создающий немодальное окно, выглядит так: auto wnd = std::make_unique<MyWindow>(); if( wnd->Create(... ) ) { wnd->Show (); wnd.reset(); }

Разницы практически ноль. Ну да, при создании объекта его память защищена по RAII...

Ну идея в том, что delete this можно заменить на агрегацию в данном классе shared_ptr на самого себя, и когда надо вызвать удаление уже через него...

как я писал выше через фиктивный shared_ptr?

Ну почему фиктивный только ?

Ну почему фиктивный только ?

покажи полный пример, нифига не пойму о чем вы говорите

Вопрос-то был НЕ В ЭТОМ, а в том, что люди считают delete this невалидным с точки зрения С++, а это не так.

откуда возьмется shared_ptr и кем он будет кипится?

ойнекогда

Вопрос-то был НЕ В ЭТОМ, а в том, что люди считают delete this невалидным с точки зрения С++, а это не так.

люди так не считают.

не надо перевирать. Люди считают delete this невалидным в случае, который я кидал выше

люди так не считают.

в @supapro парень именно так и думал, когда задавал вопрос. а это уже дальше разговор перешл из разряда "неправильно в с++" до "неправильно в дизайне"

delete this - это как goto. Лучше не использовать, но если знаешь что и зачем - то пожалуйста

Вопрос-то был НЕ В ЭТОМ, а в том, что люди считают delete this невалидным с точки зрения С++, а это не так.

Я до сих пор это подозреваю... но доказать не могу :)

в @supapro парень именно так и думал, когда задавал вопрос. а это уже дальше разговор перешл из разряда "неправильно в с++" до "неправильно в дизайне"

тогда прошу прощения - не видел той дикуссии

Схематично код, создающий немодальное окно, выглядит так: auto wnd = std::make_unique<MyWindow>(); if( wnd->Create(... ) ) { wnd->Show (); wnd.reset(); }

@berkus @antoshkka ребята, вот пример, при закрытии окна пользователем объект MyWindow должен уйти в мир иной.

Вопрос-то был НЕ В ЭТОМ, а в том, что люди считают delete this невалидным с точки зрения С++, а это не так.

а при delete this вызывается только деструктор или память осводобится тоже?

а при delete this вызывается только деструктор или память осводобится тоже?

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

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

хм, тогда например в этом случае не будет утечки? X *x = new X; x->custom_delete(); а в custom_delete происходит delete this. x и this необязательно же должны совпадать

хм, тогда например в этом случае не будет утечки? X *x = new X; x->custom_delete(); а в custom_delete происходит delete this. x и this необязательно же должны совпадать

Не будет. x и this в этом случае обязаны совпадать по определению this — это в точности указатель на объект, у которого вызван метод.