Есть такой большой объект-"матка", который обслуживает множество других. Эти обслуживаемые объекты выдаются по запросу. Тоесть в метод GetMyObject(int nObjectID) дается ключ, и в этом методе создаётся и возвращается new MyObject(nObjectID)
По одинаковым ID нужно выдавать один и тот же объект. Тоесть, например, хранить ссылку на него в HashMap и содавать новый только если ссылки там нет. И удалять его из HashMap и из памяти, как только освобождается последний указатель.
Проблема в том, что последний указатель — это и есть ссылка из HashMap! Как бы вызывать деструктор объекта при освобождении всех указателей, кроме последнего?
Вот такая проблема.
Здравствуйте, DILL, Вы писали:
DIL>Есть такой большой объект-"матка", который обслуживает множество других. Эти обслуживаемые объекты выдаются по запросу. Тоесть в метод GetMyObject(int nObjectID) дается ключ, и в этом методе создаётся и возвращается new MyObject(nObjectID) DIL>По одинаковым ID нужно выдавать один и тот же объект. Тоесть, например, хранить ссылку на него в HashMap и содавать новый только если ссылки там нет. И удалять его из HashMap и из памяти, как только освобождается последний указатель. DIL>Проблема в том, что последний указатель — это и есть ссылка из HashMap! Как бы вызывать деструктор объекта при освобождении всех указателей, кроме последнего? DIL>Вот такая проблема.
а если после "освобождения последнего указателя, кроме последнего" — у хранилища опять попросят этот объект, а ты все уже удалишь его... Опять создавать ? Что эти объекты столько весят, что держать в памяти не хочется ?
Здравствуйте, sadomovalex, Вы писали:
S>а если после "освобождения последнего указателя, кроме последнего" — у хранилища опять попросят этот объект, а ты все уже удалишь его... Опять создавать ? Что эти объекты столько весят, что держать в памяти не хочется ?
Ну, весят-то они немного, но их самих множет быть много. И просто хотелось бы освобождать ненужные ресурсы...
Здравствуйте, DILL, Вы писали:
DIL>Есть такой большой объект-"матка", который обслуживает множество других. Эти обслуживаемые объекты выдаются по запросу. Тоесть в метод GetMyObject(int nObjectID) дается ключ, и в этом методе создаётся и возвращается new MyObject(nObjectID) DIL>По одинаковым ID нужно выдавать один и тот же объект. Тоесть, например, хранить ссылку на него в HashMap и содавать новый только если ссылки там нет. И удалять его из HashMap и из памяти, как только освобождается последний указатель. DIL>Проблема в том, что последний указатель — это и есть ссылка из HashMap! Как бы вызывать деструктор объекта при освобождении всех указателей, кроме последнего? DIL>Вот такая проблема.
Никак, автоматического подсчета ссылок в Net нет. Только вручную.
Был такой вопрос недавно здесь
Здравствуйте, DILL, Вы писали:
DIL>Есть такой большой объект-"матка", который обслуживает множество других. Эти обслуживаемые объекты выдаются по запросу. Тоесть в метод GetMyObject(int nObjectID) дается ключ, и в этом методе создаётся и возвращается new MyObject(nObjectID) DIL>По одинаковым ID нужно выдавать один и тот же объект. Тоесть, например, хранить ссылку на него в HashMap и содавать новый только если ссылки там нет. И удалять его из HashMap и из памяти, как только освобождается последний указатель. DIL>Проблема в том, что последний указатель — это и есть ссылка из HashMap! Как бы вызывать деструктор объекта при освобождении всех указателей, кроме последнего? DIL>Вот такая проблема.
Для решения подобных задач во фрэймворке есть WeakReference. Это как бы необязательная ссылка. Если на объект существуют другие ссылки (кроме WeakReference) то GC ири запуске не удалит такой объект и WeakReference будет уназвать на него. Если же кроме WeakReference на объект не останется ссылк GC удалит этот объект и запишет в WeakReference null.
Таким образом тебе нужно хранить в хэш-таблице не прямую ссылку, а WeakReference. Все остальное сделает CLR.
... << RSDN@Home 1.1.4 beta 3 rev. 0>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, DILL, Вы писали:
DIL>Проблема в том, что последний указатель — это и есть ссылка из HashMap! Как бы DIL>вызывать деструктор объекта при освобождении всех указателей, кроме последнего? DIL>Вот такая проблема.
Я так понимаю надо хранить в хеше System.WeakReference вместо обычной ссылки на объект.
Мне не нужно знать, кто и сколько раз ссылается на мой объект, как было спрошено в указанной ветке. Мне нужно получать уведомление об освобождении предпоследней ссылки. Есть мысль организовать для этого последнюю ссылку (из HashMap), используя шаблон C++ gcroot, но нет уверенности, что получится... Есть у кого подобный опыт?
Здравствуйте, VladD2, Вы писали:
VD>Для решения подобных задач во фрэймворке есть WeakReference. Это как бы необязательная ссылка. Если на объект существуют другие ссылки (кроме WeakReference) то GC ири запуске не удалит такой объект и WeakReference будет уназвать на него. Если же кроме WeakReference на объект не останется ссылк GC удалит этот объект и запишет в WeakReference null.
VD>Таким образом тебе нужно хранить в хэш-таблице не прямую ссылку, а WeakReference. Все остальное сделает CLR.
Супер! Похоже это именно то что нужно. Побежал пробовать
Здравствуйте, DILL, Вы писали:
DIL>Здравствуйте, GlebZ, Вы писали:
GZ>>Никак, автоматического подсчета ссылок в Net нет. Только вручную. GZ>>Был такой вопрос недавно здесь
GZ>>С уважением, Gleb
DIL>Мне не нужно знать, кто и сколько раз ссылается на мой объект, как было спрошено в указанной ветке. Мне нужно получать уведомление об освобождении предпоследней ссылки. Есть мысль организовать для этого последнюю ссылку (из HashMap), используя шаблон C++ gcroot, но нет уверенности, что получится... Есть у кого подобный опыт?
Сорри, не сразу врубился в требования. Готов сам себе поставить -.
Здравствуйте, DILL, Вы писали:
DIL>Супер! Похоже это именно то что нужно. Побежал пробовать
Только учти многопоточность. А то может оказаться так что мусор соберется между тем как ты проверишь слабую-ссылку и до того как ты сделашь первую не полноценную. В общем, сначала копируй ссылку в переменню, а потом делай проверки.
... << RSDN@Home 1.1.4 beta 3 rev. 0>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Похоже это именно то что нужно. Побежал пробовать
