Есть ли возможность продлить жизнь объекту когда лля него выполнили delete?
Суть такая есть обьект который после удаления должен некоторое время еще пожить например визуальный обьект после удаления не сразу исчезает с экрана, а постепенно угасает и только потом реально удаляется.
Конечно можна было бы создать копию этого объекта но это приведет к потере плавности и будет заметен рывок чего хотелось бы избежать.
Какие есть идеи на этот счет?
Здравствуйте, Аноним, Вы писали:
А>Привет!
А>Есть ли возможность продлить жизнь объекту когда лля него выполнили delete? А>Суть такая есть обьект который после удаления должен некоторое время еще пожить например визуальный обьект после удаления не сразу исчезает с экрана, а постепенно угасает и только потом реально удаляется. А>Конечно можна было бы создать копию этого объекта но это приведет к потере плавности и будет заметен рывок чего хотелось бы избежать. А>Какие есть идеи на этот счет?
Дам подсказку: удалять объект не сразу, а когда его уже никто не будет видеть (не только на экране, но и в памяти).
Здравствуйте, Аноним, Вы писали:
А>Привет!
А>Есть ли возможность продлить жизнь объекту когда лля него выполнили delete? А>Суть такая есть обьект который после удаления должен некоторое время еще пожить например визуальный обьект после удаления не сразу исчезает с экрана, а постепенно угасает и только потом реально удаляется.
Очевидное решение — удалять объект именно тогда, когда он "только потом реально удаляется".
А>Конечно можна было бы создать копию этого объекта но это приведет к потере плавности и будет заметен рывок чего хотелось бы избежать.
А за счет чего потеря плавности и рывки? Сколько десятков (милли?)секунд создается копия объекта? А>Какие есть идеи на этот счет?
для начала разобраться, зачем выполнять delete для объекта, который должен еще пожить.
Здравствуйте, Аноним, Вы писали:
А>Привет!
А>Есть ли возможность продлить жизнь объекту когда лля него выполнили delete? А>Суть такая есть обьект который после удаления должен некоторое время еще пожить например визуальный обьект после удаления не сразу исчезает с экрана, а постепенно угасает и только потом реально удаляется. А>Конечно можна было бы создать копию этого объекта но это приведет к потере плавности и будет заметен рывок чего хотелось бы избежать. А>Какие есть идеи на этот счет?
Для этого не нужен сам объект. Делается его снимок, объект удаляется, вместо него вешается картинка, которая уже мирно угасает.
Здравствуйте, Аноним, Вы писали:
А>Есть ли возможность продлить жизнь объекту когда лля него выполнили delete?
Можно удалять прокси, который из деструктора запустит какой-то асинхронный смертоносный процесс объекту.
А>Суть такая есть обьект который после удаления должен некоторое время еще пожить например визуальный обьект после удаления не сразу исчезает с экрана, а постепенно угасает и только потом реально удаляется.
Послать виджету сигнал "умри медленно и печально", вместо того чтобы удалять.
И обнулить указатель на него, вычеркнуть из коллекции виджетов.
Виджет запустит таймер, по которому будет меняться... меняться... и в конце концов самоуничтожаться.
Все конкретные детали реализации зависят от фреймворка.
Я хорошо представляю, как это делать в голом WinAPI/ATL/WTL/MFC, примерно представляю — как в Qt, и могу экстраполировать опыт на всякие там VCL, GTK, etc.
Здравствуйте, Кодт, Вы писали:
К>Все конкретные детали реализации зависят от фреймворка. К>Я хорошо представляю, как это делать в голом WinAPI/ATL/WTL/MFC, примерно представляю — как в Qt, и могу экстраполировать опыт на всякие там VCL, GTK, etc.
Здравствуйте, Аноним, Вы писали:
А>Какие есть идеи на этот счет?
Лучше не копию, а прокси. То есть, ты всегда с объектом общаешься через прокси, который редеректит весь нужный интерфейс в отдельный объект -- реализацию. А когда проксю убивают, он передаёт свою реализацию в некий менеджер загробного мира, который уже и реализует посмертную жизнь объекта...
Только у теюя будет много всяких архитектурных проблем. Ну, например, если в гаснущий объект кликнут, или там отображаемый им файл поменют, то что должно произойти? А если файл удалят?
То есть вопрос упрётся в то, насколько активной может быть загробная жизнь объёкта. Если активной, и, тем более, возможно воскрешение объекта, то подход с проксей как раз хорошо будет работать. Типа пока жива "душа", ей всегда можно родить новую прокси-"тело" и вернуть объект в множество полноценных.
А если посмертная жизнь очень ограниченна, типа это просто какие-то статические данные, как-то отображаемые, то можно просто делать слепок с объекта, например с GUI-объекта можно деать просто фотку, и уже этот слепок отдавать в "загробный мир"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Аноним, Вы писали:
А>Есть ли возможность продлить жизнь объекту когда лля него выполнили delete? А>Суть такая есть обьект который после удаления должен некоторое время еще пожить например визуальный обьект после удаления не сразу исчезает с экрана, а постепенно угасает и только потом реально удаляется. А>Конечно можна было бы создать копию этого объекта но это приведет к потере плавности и будет заметен рывок чего хотелось бы избежать.
А new вы замедлить не хотите, чтобы объект плавно появлялся?
Объект прекращает свое существование после вызова delete.
Если объект визуальный, то пусть сам себя и отрисовавает исчезающим. Когда он решит, что его видимость нулевая, пусть шлет сообщение своему владельцу, чтобы тот его удалил.
Здравствуйте, lgb, Вы писали:
lgb>Если объект визуальный, то пусть сам себя и отрисовавает исчезающим. Когда он решит, что его видимость нулевая, пусть шлет сообщение своему владельцу, чтобы тот его удалил.
Зачем так сложно? можно просто отдавать такие "гаснущие2 объекты специальному владельцу, который их постепенно пригасит, а потом и разрушит...
Другое дело, что сами эти объекты могут быть замешаны в какую-то отдельную сожную структуру, ими владеющую, и тогда у тебя может не быть власти заменить убой объекта передачей его к этому "гасителю".
но тут мона замутить проксю -- самый простой путь -- shared_ptr + функция деаллокации, которая не delete зовёт, а сдаёт объект плавному разрушителю объектов...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, lgb, Вы писали:
lgb>>Если объект визуальный, то пусть сам себя и отрисовавает исчезающим. Когда он решит, что его видимость нулевая, пусть шлет сообщение своему владельцу, чтобы тот его удалил.
E>Зачем так сложно? можно просто отдавать такие "гаснущие2 объекты специальному владельцу, который их постепенно пригасит, а потом и разрушит...
E>Другое дело, что сами эти объекты могут быть замешаны в какую-то отдельную сожную структуру, ими владеющую, и тогда у тебя может не быть власти заменить убой объекта передачей его к этому "гасителю".
E>но тут мона замутить проксю -- самый простой путь -- shared_ptr + функция деаллокации, которая не delete зовёт, а сдаёт объект плавному разрушителю объектов...
На вкус и цвет все фломастеры разные.
Откуда плавный разрушитель знает, как правильно плавно разрушить отдельно взятый объект? Один может погаснуть, другой взорваться, третий упрыгать за границы экрана и т.п. По-моему, это дело самого объекта закончить свои делишки и известить об этом заинтересованные лица
Кстати, иметь операторы visual new и visual delete было бы клево
Здравствуйте, lgb, Вы писали:
lgb>Откуда плавный разрушитель знает, как правильно плавно разрушить отдельно взятый объект? Один может погаснуть, другой взорваться, третий упрыгать за границы экрана и т.п. По-моему, это дело самого объекта закончить свои делишки и известить об этом заинтересованные лица
почему обязательно объекта, а не его владельца, например, или причины, почему его начали разрушать, скажем?
lgb>Кстати, иметь операторы visual new и visual delete было бы клево
Лучше бы не надо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, lgb, Вы писали:
lgb>Кстати, иметь операторы visual new и visual delete было бы клево
Голос смолтолка шепчет у кого-то в голове.
Сперва задумайся о временнОм аспекте этих действий. Плавное создание-удаление происходит не атомарно, и что при этом должно твориться в программе?
Если действие синхронное, то программа должна тупить до завершения эффекта.
Если асинхронное, то какой статус у полуживого объекта? Он доступен, заблокирован, есть в коллекции, его нет в коллекции?
Особенно — у зарождающегося объекта. Как программа узнает, что он перешёл в стабильное состояние?
После того, как ответы будут ясно сформированы, — всё остальное делается за полчаса на коленке средствами фреймворка.
Всего-то нужно — таймер, и, для особо смелых, треды.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, lgb, Вы писали:
lgb>>Откуда плавный разрушитель знает, как правильно плавно разрушить отдельно взятый объект? Один может погаснуть, другой взорваться, третий упрыгать за границы экрана и т.п. По-моему, это дело самого объекта закончить свои делишки и известить об этом заинтересованные лица
E>почему обязательно объекта, а не его владельца, например, или причины, почему его начали разрушать, скажем?
Причина объекту может быть не очень интересна. Причину придумавает манагер объектов, к примеру.
Просто кто-то, может быть, даже такой же соседний объект может сказать: сгинь с глаз моих, причем со взрывом. И объект сгинет, как его просили, проинформировав подписчиков. И уже их дело, как распорядиться этим объектом — позвать delete, сложить в кэш на будущее и т.п.
На мой взгляд, логичнее иметь функционал объекта в самом объекте, а не аутсорсить его куда попало
Здравствуйте, Кодт, Вы писали:
lgb>>Кстати, иметь операторы visual new и visual delete было бы клево
К>После того, как ответы будут ясно сформированы, — всё остальное делается за полчаса на коленке средствами фреймворка. К>Всего-то нужно — таймер, и, для особо смелых, треды.
Здравствуйте, lgb, Вы писали:
lgb>На мой взгляд, логичнее иметь функционал объекта в самом объекте, а не аутсорсить его куда попало
Ну по-разному может быть. Может быть какое-то количество стандартных процедур, реализуемых через какой-то унифицированный интерфейс, ну там, типа "нарисуйся по маске прозрачности/яркости" или ещё как-то, скажем через определённый DC, а разрушалки там могут расстреливать, рвать на кусочки, жечь...
И потом менеджер разрушения можно целиком прибить, или ускорить, если что. А так прийдётся по объектам вылавливать что там кто делает...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Аноним, Вы писали:
А>>Какие есть идеи на этот счет? E>Лучше не копию, а прокси. То есть, ты всегда с объектом общаешься через прокси, который редеректит весь нужный интерфейс в отдельный объект -- реализацию. А когда проксю убивают, он передаёт свою реализацию в некий менеджер загробного мира, который уже и реализует посмертную жизнь объекта...
E>Только у теюя будет много всяких архитектурных проблем. Ну, например, если в гаснущий объект кликнут, или там отображаемый им файл поменют, то что должно произойти? А если файл удалят?
E>То есть вопрос упрётся в то, насколько активной может быть загробная жизнь объёкта. Если активной, и, тем более, возможно воскрешение объекта, то подход с проксей как раз хорошо будет работать. Типа пока жива "душа", ей всегда можно родить новую прокси-"тело" и вернуть объект в множество полноценных.
E>А если посмертная жизнь очень ограниченна, типа это просто какие-то статические данные, как-то отображаемые, то можно просто делать слепок с объекта, например с GUI-объекта можно деать просто фотку, и уже этот слепок отдавать в "загробный мир"
читается все это как руководство некроманта какое-то %) сходу так и не скажешь что С++
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, lgb, Вы писали:
lgb>>Кстати, иметь операторы visual new и visual delete было бы клево
К>Голос смолтолка шепчет у кого-то в голове. К>Сперва задумайся о временнОм аспекте этих действий. Плавное создание-удаление происходит не атомарно, и что при этом должно твориться в программе? К>Если действие синхронное, то программа должна тупить до завершения эффекта.
в этот момент в голове нарисовался следующий сниппет:
auto child = new Baby();
и следующие ~9 месяцев baby плавно так "рождается" %)
К>Если асинхронное, то какой статус у полуживого объекта? Он доступен, заблокирован, есть в коллекции, его нет в коллекции?
он находится в недрах host'a (хозяина) пока после инкубационного периода не разрывает хосту пузо (грудную клетку в некоторых вариантах %) и с криком вырывается наружу поедая еще живые (разбегающиеся) объекты
Здравствуйте, Аноним, Вы писали:
А>Привет!
А>Есть ли возможность продлить жизнь объекту когда лля него выполнили delete? А>Суть такая есть обьект который после удаления должен некоторое время еще пожить например визуальный обьект после удаления не сразу исчезает с экрана, а постепенно угасает и только потом реально удаляется. А>Конечно можна было бы создать копию этого объекта но это приведет к потере плавности и будет заметен рывок чего хотелось бы избежать. А>Какие есть идеи на этот счет?
Товарищ Аноним, UI надо писать не на C++, а на C#! Там объект если и удалён, то GC его не сразу соберет, и объект еще немножко поживет, постепенно угасая. Никаких рывков! Инфа 146%!
Перекуём баги на фичи!
