Что лучше?
Почему бы не вызывать деструкторы и чистить память сразу, когда стало известно, что ссылок на данный объект уже нет?

Здравствуйте, astral_marine, Вы писали:

_>Что лучше?
_>Почему бы не вызывать деструкторы и чистить память сразу, когда стало известно, что ссылок на данный объект уже нет?
Патамушта кольцевые ссылки...

Здравствуйте, CreatorCray, Вы писали:
CC>Патамушта кольцевые ссылки...

Это единственный аргумент?
А разве счетчик ссылок не способен разрушать кольцевые ссылки? (теоретически)
Что такое есть в сборщике мусора, что нельзя добавить к счетчику ссылок что бы последний мог разрушать кольцевые ссылки?

astral_marine wrote:
> CC>Патамушта кольцевые ссылки...
> Это единственный аргумент?
Да. Это гвоздь в крышку гроба.

> А разве счетчик ссылок не способен разрушать кольцевые ссылки?
> (теоретически)
Нет. Необходимо вручную ломать циклы: с помощью слабых ссылок или явно
удаляя ссылки.

> Что такое есть в сборщике мусора, что нельзя добавить к счетчику ссылок
> что бы последний мог разрушать кольцевые ссылки?
Сборщик умеет обходить по графу объектов.

Детекторы кольцевых ссылок тоже по сути работают как GC.

Дальше можно смотреть сюда: http://www.memorymanagement.org/

Здравствуйте, astral_marine, Вы писали:

_>Здравствуйте, CreatorCray, Вы писали:
CC>>Патамушта кольцевые ссылки...

_>Это единственный аргумент?
_>А разве счетчик ссылок не способен разрушать кольцевые ссылки? (теоретически)
_>Что такое есть в сборщике мусора, что нельзя добавить к счетчику ссылок что бы последний мог разрушать кольцевые ссылки?
Как ты себе это представляешь?

Здравствуйте, CreatorCray, Вы писали:

_>>Что такое есть в сборщике мусора, что нельзя добавить к счетчику ссылок что бы последний мог разрушать кольцевые ссылки?
CC>Как ты себе это представляешь?

Пусть в каждом объекте есть инфа о всех указателях на другие объекты и количество ссылок других объектов на этот объект.
Необходимо взять один объект и пройтись по всем связям, если окажется, что найдены все ссылки на объекты и эта группа объектов не связана с другим, то ее можно спокойно удалять.

Здравствуйте, astral_marine, Вы писали:

_>Пусть в каждом объекте есть инфа о всех указателях на другие объекты и количество ссылок других объектов на этот объект.
_>Необходимо взять один объект и пройтись по всем связям, если окажется, что найдены все ссылки на объекты и эта группа объектов не связана с другим, то ее можно спокойно удалять.

В догонку:
"Concurrent Cycle Collection in Reference Counted Systems"
http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf
(Только что нашел, еще не читал)

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, astral_marine, Вы писали:

_>>Что лучше?
_>>Почему бы не вызывать деструкторы и чистить память сразу, когда стало известно, что ссылок на данный объект уже нет?
CC>Патамушта кольцевые ссылки...

Кольцевые ссылки — это результат плохого дизайна. Подробности здесь.

Здравствуйте, koder.spb.ru, Вы писали:

KSR>Кольцевые ссылки — это результат плохого дизайна. Подробности здесь.
Плохого или нет, но это вносит ограничения на использование.

Здравствуйте, astral_marine, Вы писали:

_>>>Что такое есть в сборщике мусора, что нельзя добавить к счетчику ссылок что бы последний мог разрушать кольцевые ссылки?
CC>>Как ты себе это представляешь?
_>Пусть в каждом объекте есть инфа о всех указателях на другие объекты и количество ссылок других объектов на этот объект.
_>Необходимо взять один объект и пройтись по всем связям, если окажется, что найдены все ссылки на объекты и эта группа объектов не связана с другим, то ее можно спокойно удалять.
Т.е. добавляем избыточность и делаем потом по сути почти то же что и GC

Здравствуйте, CreatorCray, Вы писали:
CC>Т.е. добавляем избыточность и делаем потом по сути почти то же что и GC

Да. Но объекты будут находится в памяти только в том случае, если они нужны.
Выходит RC лучше GC?

Здравствуйте, astral_marine, Вы писали:

_>Здравствуйте, CreatorCray, Вы писали:
CC>>Т.е. добавляем избыточность и делаем потом по сути почти то же что и GC

_>Да. Но объекты будут находится в памяти только в том случае, если они нужны.
_>Выходит RC лучше GC?
По тому, когда именно прибиваются ставшие ненужными объекты — да. Гораздо лучше.

Здравствуйте, CreatorCray, Вы писали:
_>>Выходит RC лучше GC?
CC>По тому, когда именно прибиваются ставшие ненужными объекты — да. Гораздо лучше.

Почему же тогда в .NET и в Java выбран GC, а не RC?
Многие жалуются, что GC работает непредсказуемо и приводит к черезмерному использованию памяти.

Здравствуйте, astral_marine, Вы писали:

_>Здравствуйте, CreatorCray, Вы писали:
_>>>Выходит RC лучше GC?
CC>>По тому, когда именно прибиваются ставшие ненужными объекты — да. Гораздо лучше.

_>Почему же тогда в .NET и в Java выбран GC, а не RC?
_>Многие жалуются, что GC работает непредсказуемо и приводит к черезмерному использованию памяти.

Вопрос не по адресу. Мое ИМХО что GC не серебряная пуля ни разу. На нем разрабатывать быстрее, да. Надо меньше думать и писать. Но за это приходится платить бОльшим потреблением ресурсов и вышеописанными проблемами.

Здравствуйте, astral_marine, Вы писали:

_>Почему же тогда в .NET и в Java выбран GC, а не RC?
_>Многие жалуются, что GC работает непредсказуемо и приводит к черезмерному использованию памяти.

Потому что в США память дешевле программистов

Здравствуйте, astral_marine, Вы писали:

_>Что лучше?
_>Почему бы не вызывать деструкторы и чистить память сразу, когда стало известно, что ссылок на данный объект уже нет?

Ну иногда этот момент трудно угадать, а иногда это банально ненужно. Типа на разрушение всех этих объектов может потратиться слишком много ресурсов...

ИМХО в C++ можно писать так, что в каких-то местах продумывать архитектуру, в том числе и схему владения, а в каких-то не продумывать, потому что не нужна, а писать всё на неком

Автор: Erop
Дата: 29.08.07

аналоге GC

Автор: Erop
Дата: 30.08.07

Вот и будет тебе счастье.

Ну а в яве там и шарпе так сделали для того, ИМХО, чтобы было дешевле прогать на этих языках всякие менеджеры компонент