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

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

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

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

Естественно, это возможно только в случае, когда объект имеет чёткий жизненный цикл.

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

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

закрытие окна - это операция которую осуществляет "кто-то", вон он пусть и удаляет

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

у тебя тоже в аппе есть буккипинг этих самых окон

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

WM_NCDESTROY

ее нет, указатель на C++ в мембере WNDCLASS-а операционной системы

давай остановимся и обсудим вот что, мы сейчас говорим про архитектурный подход общий или про конкретные костыли конкретной системы? это важно

давай остановимся и обсудим вот что, мы сейчас говорим про архитектурный подход общий или про конкретные костыли конкретной системы? это важно

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

ну тут я думаю легко можно договориться - это ОГРАНИЧЕННОЕ (as in, DUMB) архитектурное решение

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

сколько можно это обсасывать???

В разделе про синглтоны

Господа, а можно ли как-то эту порнографию редуцировать, не используя препроцессор? 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(); } };

подключайся, фабрики по сжиганию делетеров зис простаивают

я плохо понимаю, почему тебе не нравится delete this но устраивают остальные варианты суицида. вот тебе пример: у тебя есть какой-то пул сетевых соединений, что должно делать соединение если оно разорвано?

ты пропустил ссылку на beast http session от меня выше, там всё есть

у тебя тоже в аппе есть буккипинг этих самых окон

Блин, парни, вы что никогда на винде приложения не писали? НЕТ буккипинга никакого!

ты пропустил ссылку на beast http session от меня выше, там всё есть

вот такое упрощение тебе пойдет? #include <iostream> #include "boost/variant.hpp" template<typename F> class visitor : boost::static_visitor<size_t> { public: explicit visitor(F&& f) : f(std::forward<F>(f)){ } template<typename T> auto operator()(T& o) const { return f(o); } private: F f; }; template<typename T> struct image { size_t width() const {return 100;} size_t height() const {return 200;} size_t depth() const {return 300;} }; int main() { boost::variant<image<int>, image<double>> v; v = image<int>{}; boost::apply_visitor(visitor{[](auto&& o){ std::cout << o.width(); return o.width(); }}, v); }

Ну там тот же самый delete this, только делегированный smapt pointer-у...

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

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

Вот, а случай с окном как раз характерен тем, что ССЫЛОК НА ОКНО НИГДЕ НЕ ДОЛЖНО БЫТЬ.

delete this вызывается когда объект никогда никому не важен

Вот, а случай с окном как раз характерен тем, что ССЫЛОК НА ОКНО НИГДЕ НЕ ДОЛЖНО БЫТЬ.

ты понимаешь что ты внешнее (управляемое) поведение заталкиваешь внутрь класса?

ты понимаешь что ты внешнее (управляемое) поведение заталкиваешь внутрь класса?

например, *установленным* сетевым соединением ты на самом деле не владеешь

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

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

а если я объект создал не через new?

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

Меня даже больше бесит, что вы так все взъелись на это дело... Я вообще не понимаю, с чего... Ну, удаляет объект сам себя, ну делов-то...

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

Беркус, ты удивишься, в оконных приложения ТОЖЕ ЕСТЬ АРХИТЕКТУРА!

Беркус, ты удивишься, в оконных приложения ТОЖЕ ЕСТЬ АРХИТЕКТУРА!

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

я тебя поражу - ОКОННЫЕ ПРИЛОЖЕНИЯ есть НЕ ТОЛЬКО В ВИНДЕ

Так и надо, например, читая bincrafter я осознаю, что главный там Зайцев :)

да ладно, в гуе все нахуячено индусами, сотка инфа

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

да ладно, в гуе все нахуячено индусами, сотка инфа

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

операции проводятся над сетевым соединением

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

не удаляется