Самоуничтожение класса.
Есть класс - сервер сообщений. Т.е. ему унифицированным способом передаётся некое сообщение и он выполняет некие действия. Одно из сообщений - это уничтожение класса. Но сообщение имеет определённый вид. Т.е. нельзя просто взять и уничтожить класс из вне с помощью delete. Потому как внутри класса может реализовыватся очередь задач. Класс должен принять такое сообщение и самоуничтожится.
Пока не идет речь о статическом создании объектов класса. Предположим, что любой объект класса создается динамически.
Собственно возможно ли вызывать деструктор класса из внутреннего метода данного класса? Грубо говоря, можно ли делать delete this? Какие косяки при этом возникают? Косяк со статическим созданием пока опустим.
Пока не идет речь о статическом создании объектов класса. Предположим, что любой объект класса создается динамически.
Собственно возможно ли вызывать деструктор класса из внутреннего метода данного класса? Грубо говоря, можно ли делать delete this? Какие косяки при этом возникают? Косяк со статическим созданием пока опустим.
Цитата: Gigahard
Есть класс - сервер сообщений. Т.е. ему унифицированным способом передаётся некое сообщение и он выполняет некие действия. Одно из сообщений - это уничтожение класса. Но сообщение имеет определённый вид. Т.е. нельзя просто взять и уничтожить класс из вне с помощью delete. Потому как внутри класса может реализовыватся очередь задач. Класс должен принять такое сообщение и самоуничтожится.
Пока не идет речь о статическом создании объектов класса. Предположим, что любой объект класса создается динамически.
Собственно возможно ли вызывать деструктор класса из внутреннего метода данного класса? Грубо говоря, можно ли делать delete this? Какие косяки при этом возникают? Косяк со статическим созданием пока опустим.
Пока не идет речь о статическом создании объектов класса. Предположим, что любой объект класса создается динамически.
Собственно возможно ли вызывать деструктор класса из внутреннего метода данного класса? Грубо говоря, можно ли делать delete this? Какие косяки при этом возникают? Косяк со статическим созданием пока опустим.
Опишите в общем виде структуру ваших классов - по приведенному описанию сказать что либо конкретное тяжело. В общем случае - почему просто не вызвать деструктор при получении сообщения?
Вот собственно в этом и вопрос. Может глупый конечно... Класс может вызывать собственный деструктор? Или это возможно только извне?
Класс может вызывать свой деструктор. Но, следует подумать - куда после этого передается управление... И есстественно позабртиться, чтоб никто не работал с деинициализированым объектом класса.
Действительно, класс может вызвать собственный деструктор. Однако мне это кажется нелогичным. Ведь объект класса создается внешней стороной, так? Тогда логично возложить на эту (или иную) внешнюю сторону и уничтожение объекта.
И потом. После динамического уничтожения объекта класса в высшей степени рекомендуется обнулить указатель, с которым этот объект был ассоциирован, иначе существует (потенциальный) риск обращения по этому указателю к уже несуществующему объекту. Но каким образом обнулится этот указатель? Это может сделать только внешняя сторона, которая работала с этим указателем. Так вот путь она и вызывает delete.
Однако в вашем случае, как вы утверждаете, delete извне вызывать нельзя. Тогда можно создать хитрый класс по типу одиночки (пусть это будет одной из вариаций паттерна проектирования "Синглтон"), и там работать со статическими методами (например, T* instance() и void destroy(T*&)), тогда вызывающая сторона при необходимости уничтожения объекта вызовет функцию destroy(T*&) с передачей ей указателя на объект, а эта функция уже сама уничтожит и объект, и ассоциированный с ним указатель обнулит. То есть, поскольку функции instance и destroy связаны с этим классом, будет выходить так, что класс "сам создает свой объект" и "сам уничтожает свой объект".
И потом. После динамического уничтожения объекта класса в высшей степени рекомендуется обнулить указатель, с которым этот объект был ассоциирован, иначе существует (потенциальный) риск обращения по этому указателю к уже несуществующему объекту. Но каким образом обнулится этот указатель? Это может сделать только внешняя сторона, которая работала с этим указателем. Так вот путь она и вызывает delete.
Однако в вашем случае, как вы утверждаете, delete извне вызывать нельзя. Тогда можно создать хитрый класс по типу одиночки (пусть это будет одной из вариаций паттерна проектирования "Синглтон"), и там работать со статическими методами (например, T* instance() и void destroy(T*&)), тогда вызывающая сторона при необходимости уничтожения объекта вызовет функцию destroy(T*&) с передачей ей указателя на объект, а эта функция уже сама уничтожит и объект, и ассоциированный с ним указатель обнулит. То есть, поскольку функции instance и destroy связаны с этим классом, будет выходить так, что класс "сам создает свой объект" и "сам уничтожает свой объект".
Цитата: deninok
Действительно, класс может вызвать собственный деструктор. Однако мне это кажется нелогичным. Ведь объект класса создается внешней стороной, так? Тогда логично возложить на эту (или иную) внешнюю сторону и уничтожение объекта.
И потом. После динамического уничтожения объекта класса в высшей степени рекомендуется обнулить указатель, с которым этот объект был ассоциирован, иначе существует (потенциальный) риск обращения по этому указателю к уже несуществующему объекту. Но каким образом обнулится этот указатель? Это может сделать только внешняя сторона, которая работала с этим указателем. Так вот путь она и вызывает delete.
Хотя, конечно, можно создать хитрый класс по типу одиночки (пусть это будет одной из вариаций паттерна проектирования "Синглтон"), и там работать со статическими методами (например, T* instance() и void destroy(T*&)), тогда вызывающая сторона при необходимости уничтожения объекта вызовет функцию destroy(T*&) с передачей ей указателя на объект, а эта функция уже сама уничтожит и объект, и ассоциированный с ним указатель обнулит. То есть, поскольку функции instance и destroy связаны с этим классом, будет выходить так, что класс "сам создает свой объект" и "сам уничтожает свой объект".
И потом. После динамического уничтожения объекта класса в высшей степени рекомендуется обнулить указатель, с которым этот объект был ассоциирован, иначе существует (потенциальный) риск обращения по этому указателю к уже несуществующему объекту. Но каким образом обнулится этот указатель? Это может сделать только внешняя сторона, которая работала с этим указателем. Так вот путь она и вызывает delete.
Хотя, конечно, можно создать хитрый класс по типу одиночки (пусть это будет одной из вариаций паттерна проектирования "Синглтон"), и там работать со статическими методами (например, T* instance() и void destroy(T*&)), тогда вызывающая сторона при необходимости уничтожения объекта вызовет функцию destroy(T*&) с передачей ей указателя на объект, а эта функция уже сама уничтожит и объект, и ассоциированный с ним указатель обнулит. То есть, поскольку функции instance и destroy связаны с этим классом, будет выходить так, что класс "сам создает свой объект" и "сам уничтожает свой объект".
что подобное COM объекта надо реализовать (со счетчиком обращений), и обертки к нему CComPtr (где автоматом этот счетчик увеличивается и уменьшается)
А что если просто написать класс-обертку, что-то вроде умного указателя, который либо предоставляет доступ к методам-членам, либо возвращает ошибку если объект самоуничтожился(или был уничтожен оберткой)?
Самое простое и, возможно, самое правильное решение - вообще не уничтожать объект.
Зачем его уничтожать? Чтоб потом создавать вновь?
Если надо, то можно просто "выключать"/"включать" объект без уничтожения. На этом, кстати, можно организовать пул объектов.
Зачем его уничтожать? Чтоб потом создавать вновь?
Если надо, то можно просто "выключать"/"включать" объект без уничтожения. На этом, кстати, можно организовать пул объектов.
Цитата: Green
Самое простое и, возможно, самое правильное решение - вообще не уничтожать объект.
Зачем его уничтожать? Чтоб потом создавать вновь?
Если надо, то можно просто "выключать"/"включать" объект без уничтожения. На этом, кстати, можно организовать пул объектов.
Зачем его уничтожать? Чтоб потом создавать вновь?
Если надо, то можно просто "выключать"/"включать" объект без уничтожения. На этом, кстати, можно организовать пул объектов.
Без общего описания данной конкретной задачи - тут вобще трудно решить о чем идет речь. Если это объект который создается сервером сообщений - то по идее создатель и должен очищать в данном случае память. Вопрос надо это делать или нет - зависит от того как объект создается и как выделяются ресурсы. Если речь идет о самом сервере - то о пять же без четкого описания задачи тема превращается в гадание на кофейной гуще. А попробуй то а попробуй то -
"-...Ребе все куры здохли!
-Жаль а у меня еще так много идей было...
" (с) юмор из Жмеринки :)
http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.15
As long as you're careful, it's OK for an object to commit suicide (delete this).
Here's how I define "careful":
1. You must be absolutely 100% positive sure that this object was allocated via new (not by new[], nor by placement new, nor a local object on the stack, nor a global, nor a member of another object; but by plain ordinary new).
2. You must be absolutely 100% positive sure that your member function will be the last member function invoked on this object.
3. You must be absolutely 100% positive sure that the rest of your member function (after the delete this line) doesn't touch any piece of this object (including calling any other member functions or touching any data members).
4. You must be absolutely 100% positive sure that no one even touches the this pointer itself after the delete this line. In other words, you must not examine it, compare it with another pointer, compare it with NULL, print it, cast it, do anything with it.
Naturally the usual caveats apply in cases where your this pointer is a pointer to a base class when you don't have a virtual destructor.
As long as you're careful, it's OK for an object to commit suicide (delete this).
Here's how I define "careful":
1. You must be absolutely 100% positive sure that this object was allocated via new (not by new[], nor by placement new, nor a local object on the stack, nor a global, nor a member of another object; but by plain ordinary new).
2. You must be absolutely 100% positive sure that your member function will be the last member function invoked on this object.
3. You must be absolutely 100% positive sure that the rest of your member function (after the delete this line) doesn't touch any piece of this object (including calling any other member functions or touching any data members).
4. You must be absolutely 100% positive sure that no one even touches the this pointer itself after the delete this line. In other words, you must not examine it, compare it with another pointer, compare it with NULL, print it, cast it, do anything with it.
Naturally the usual caveats apply in cases where your this pointer is a pointer to a base class when you don't have a virtual destructor.