Есть ли будущее у DELPHI?

Цитата D_KEY @ 19.11.12, 06:30

Другие объекты в своих деструкторах(а деструкторы локальных объектов вызываются автоматически). А если объект шарится между несколькими другими объектами, то используют подсчет ссылок, это дает некоторый оверхед по сравнению с использованием ссылок в случае GC, но зато не требует этого самого GC, позволяет точно сказать, когда будет уничтожен объект(в т.ч. и когда будут освобождены ресурсы - память, файлы, etc.).

А что с циклическими ссылками? И опять же, это не про Делфи.

Сообщение отредактировано: korvin - 19.11.12, 06:43

Цитата korvin @ 19.11.12, 06:43

А что с циклическими ссылками?

Их нет А вообще, есть слабые счётчики...

Цитата korvin @ 19.11.12, 06:43

А что с циклическими ссылками? И опять же, это не про Делфи.

Они очень редки. Разруливаются руками через слабые ссылки. Как, собственно, weak в objective-C, если знаешь такой
Для поиска неправильных циклов есть специальные тулзы. От обычных поисковиков утечек вроде valgrind до специальных режимов сборщиков мусора.

Добавлено 19.11.12, 07:09
Но в С++ не так много "голой" динамической памяти. А та, что есть обычно внутри объектов, контейнрах и т.д., которые создаются уже локально, а не в динамической памяти.

Цитата D_KEY @ 19.11.12, 07:04

Для поиска неправильных циклов есть специальные тулзы. От обычных поисковиков утечек вроде valgrind до специальных режимов сборщиков мусора.

Только си, только хардкор!

Цитата Астарот @ 19.11.12, 07:43

Только си, только хардкор!

Пфф, какой же это хардкор? Вот машкод на перфокартах -- это да...

Цитата Астарот @ 19.11.12, 07:43

Цитата D_KEY @ 19.11.12, 07:04

Для поиска неправильных циклов есть специальные тулзы. От обычных поисковиков утечек вроде valgrind до специальных режимов сборщиков мусора.

Только си, только хардкор!

По сути-то есть что сказать? Это делается раз в тысячелетие. Ну или если бага по утечке нашлась

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

Собственно, в языках с GC так же периодически следят за утечками и начинают расставлять всяческие WeakReference/SoftReference

Добавлено 19.11.12, 08:22

Цитата Астарот @ 19.11.12, 08:08

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

Можно подумать что-либо спасает от других багов
А GC от утечек не спасает

Цитата Астарот @ 19.11.12, 08:08

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

Ну если их не фиксить, то как не банально бы это звучало, но да не спасают

Цитата D_KEY @ 19.11.12, 08:08

А GC от утечек не спасает

Ну, с точки зрения семантики языка именно от утечек то спасает, но да, там свои приколы и слабые ссылки всё равно нужны.

Цитата MyNameIsIgor @ 19.11.12, 08:33

Ну, с точки зрения семантики языка именно от утечек то спасает

С точки зрения семантики языков с GC памяти, как ресурса, вообще не существует, как правило Или я ошибаюсь?
Вот от чего GC спасает точно, так это от висячих ссылок. Ну и от ручной работы с памятью
Но вот обязательный сборщик в императивных языках кажется мне "баловством". Вот в функциональщине/логических языках GC требуется для того, чтобы не гадить в семантику языка.
Хотя... Я вот что-то подумал. Не избавляет ли ленивость Haskell'я от циклических ссылок? И нельзя ли там обойтись подсчетом ссылок? korvin, что скажешь?

Добавлено 19.11.12, 09:05

Цитата D_KEY @ 19.11.12, 09:04

Не избавляет ли ленивость Haskell'я от циклических ссылок?

Хотя не, глупость подумал...

Цитата D_KEY @ 19.11.12, 09:04

С точки зрения семантики языков с GC памяти, как ресурса, вообще не существует, как правило Или я ошибаюсь?

Допустим, что не ошибаешься, ну и что? Утечки памяти при использовании GC возможны только в случае ошибки в архитектуре и/или реализации GC.

Цитата D_KEY @ 19.11.12, 09:04

Не избавляет ли ленивость Haskell'я от циклических ссылок? И нельзя ли там обойтись подсчетом ссылок? korvin, что скажешь?

от циклических ссылок, насколько я понимаю, избавляет тотальная иммутабельность.

Цитата D_KEY @ 19.11.12, 09:04

Но вот обязательный сборщик в императивных языках кажется мне "баловством".

Почему? Разве императивный подход как-то обязывает управлять освобождением памятью вручную?

Цитата korvin @ 19.11.12, 09:28

Утечки памяти при использовании GC возможны только в случае ошибки в архитектуре и/или реализации GC.

да вот нет, утечки памяти возможны и при ошибках в прикладном коде. Банально сохраняем ссылки на локальный объект в глобальном листе и забывает удалять эти ссылки, вот те банальная утечка. В .NET есть частный (но очень распространенный) случай: локальный объект подписывается на событие, которое генерит глобальный. А отписаться - забывает.

Добавлено 19.11.12, 09:38
Так что D_KEY правильно сказал, GC спасает только от висячих ссылок, но не от мемликов.

Сообщение отредактировано: jack128 - 19.11.12, 09:38