Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата MyNameIsIgor @ 29.12.11, 14:29

Цитата D_KEY @ 29.12.11, 13:28

Можно поговорить об освобождении ресурсов, GC, деструкторах, финализаторах и Dispose

Ну так, можно сказать, последняя надежда на возрождение холивара.

Цитата

1. Почему в дельфи нет GC? Какие-то фундаментальные сложности? Или он всё же есть в виде каких-то библиотек/расширений?
Если нет, то как бы мог выглядеть GC в дельфи?
2. Зачем в шарпе финализаторы? На мой дилетантский взгляд они просто не нужны

Спасибо !

Цитата D_KEY @ 29.12.11, 14:38

Ну так, можно сказать, последняя надежда на возрождение холивара.

Чё, топоры точим?

Цитата MyNameIsIgor @ 29.12.11, 14:29

1. Почему в дельфи нет GC? Какие-то фундаментальные сложности? Или он всё же есть в виде каких-то библиотек/расширений?
Если нет, то как бы мог выглядеть GC в дельфи?

Хороший вопрос! Сейчас делфятники начнут что-то втирать про возможность использовать разные Менеджеры Памяти для разных модулей и т.п., но мы-то знаем, что просто "ниасилили" и тянули совместимость с Паскалем. Я еще понимаю зачем нужна совместимость с Си в С++, но с Паскалем-то зачем?.. Кодавая база на этом языке была и остается несравнимо меньше Сишной, можно было просто оставить этот хлам.

И это при том, что профессор Н.Вирт, ЕМНИП, во всех своих языках после Паскаля использовал GC...

Сообщение отредактировано: korvin - 29.12.11, 15:00

korvin, а про финализаторы что скажешь? Ты же используешь Яву?
И, по традиции, можешь немного рассказать о "функциональщине"
В часности интересно, как там решают проблемы с освобождением ресурсов.

Цитата MyNameIsIgor @ 29.12.11, 14:29

2. Зачем в шарпе финализаторы? На мой дилетантский взгляд они просто не нужны

Ну это по-моему слабо. Если я правильно понимаю, что такое финализаторы в C#, то они нужны для того, чтобы объект мог освободить все занятые собой ресурсы, ведь только класс "видит" внутреннюю структуру объекта и имеет к ней доступ. С памятью проще, поэтому ее можно отдать на откуп GC.

Кроме того обычно память не обязательно освобождать сразу после того, как объект стал недоступен (а нормальные GC так и не делают), в отличие от, например, открытого (на запись или просто монопольно) файла. Время же освобождения памяти пожалуй важно только в системах (жесткого) реального времени и, вероятно, других критичных к этому системах (я просто не знаю, где еще это важно). Хотя и на этот случай, насколько мне известно, разрабатывались (не знаю насчет реального применения) специальные GC для Java, например.

Добавлено 29.12.11, 15:07

Цитата D_KEY @ 29.12.11, 14:56

korvin, а про финализаторы что скажешь? Ты же используешь Яву?
И, по традиции, можешь немного рассказать о "функциональщине"
В часности интересно, как там решают проблемы с освобождением ресурсов.

Точно также, как и в любом другом языке с GC -- подобиями try-finally. Плюс различные сахарные формы (синтаксические или просто функции) открытия одного ресурса с автоматическим вызовом закрытия (финализатора), например:

синтаксическая форма:

(with-open-file (strem path)
  (read stream))

файл будет гарантировано закрыт при выходе из блока with-open-file

функция:

withOpenFile path { stream =>
  read stream
}

поэтому наличие общего интерфейса наподобии

interface Resource {
  open();
  close();
}

вполне полезно

Цитата korvin @ 29.12.11, 14:59

Если я правильно понимаю, что такое финализаторы в C#, то они нужны для того, чтобы объект мог освободить все занятые собой ресурсы

Проблема в том, что тебе не известно, когда и в каком контексте вызовется финализатор и вызовется ли он вообще
Так что для освобождения ресурсов его использовать очень странно - для этого используется во всех современных языках RAII(пришедший из С++).
Но в языках с GC нет деструкторов, потому используется специальные конструкции, using в C#, with в Python и try-with-resources в Java
Про финализаторы в Java могу процитировать негативные отзывы, все тех же, Эккеля("Философия Java") и Блоха("Эффективное использование Java"), которых цитировал по поводу конструкторов и finally.

Цитата korvin @ 29.12.11, 14:59

Ну это по-моему слабо.

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

Цитата korvin @ 29.12.11, 14:59

Если я правильно понимаю, что такое финализаторы в C#, то они нужны для того, чтобы объект мог освободить все занятые собой ресурсы

Для этого у них есть волшебный IDisposable А в финализаторах они имеют привычку проверять, вызывался ли метод Dispose. Если нет, то чистят. А память да, на откуп GC. Так собственно вопрос: правильно ли я понимаю, что финализатор спасает обезьянок, которые вовремя Dispose не вызвали, создавая иллюзию правильно работающей программы? Ведь по сути что получается - GC рулит память, он же вызывает финализатор, который может вызвать Dispose, который в свою очередь чистит ресурсы-не-память. Таким образом с плеч обезьянок снимается и на GC вешается управление не-памятью.

Цитата D_KEY @ 29.12.11, 15:07

Проблема в том, что тебе не известно, когда и в каком контексте вызовется финализатор и вызовется ли он вообще

А, т.е. я неправильно понял. Финализатор выполняется перед освобождением памяти объекта? Ну тогда его видимо можно использовать для освобождения каких-то ресурсов, время освобождения которых также не важно. Хотя я и не скажу, что это могут быть за ресурсы. И еще смущает "неизвестно ... вызовется ли он вообще", т.е. может и не вызваться? Если не сложно, процитируй краткое определение/описание финализаторов.

В Python'е используется управление памятью на основе счетчиков ссылок, поэтому объект разрушается сразу, как только на него исчезает последняя ссылка. Кроме того в питоне объект может иметь деструктор (специальный метод __del__), поэтому для этого языка тоже возможно нормальное использование RAII. Ссылки правда там пропадают только при выходе из функции, поэтому гибкость хуже, чем в C++. С другой стороны, если объект оказывается включен в циклическую структуру, он может быть вычищен сборщиком мусора. Правда наличие деструктора может помешать в таком случае удалить объект.
Собственно, ничто не мешает программировать на питоне без использования finally.

Цитата amk @ 29.12.11, 15:24

В Python'е используется управление памятью на основе счетчиков ссылок

Точно? Или всё же GC?

Цитата amk @ 29.12.11, 15:24

в питоне объект может иметь деструктор (специальный метод __del__), поэтому для этого языка тоже возможно нормальное использование RAII

Я думал, что RAII работает с помощью блока with...

Сообщение отредактировано: MyNameIsIgor - 29.12.11, 15:30

Цитата korvin @ 29.12.11, 15:14

А, т.е. я неправильно понял. Финализатор выполняется перед освобождением памяти объекта?

Ну фактически так. Его дергает GC

Цитата

И еще смущает "неизвестно ... вызовется ли он вообще", т.е. может и не вызваться?

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

Цитата

Если не сложно, процитируй краткое определение/описание финализаторов.

Ну так гугл ж
А так - метод, который дергается GC перед освобождением памяти, выделенной под объект.

Добавлено 29.12.11, 15:36

Цитата amk @ 29.12.11, 15:24

В Python'е используется управление памятью на основе счетчиков ссылок, поэтому объект разрушается сразу, как только на него исчезает последняя ссылка. Кроме того в питоне объект может иметь деструктор (специальный метод __del__), поэтому для этого языка тоже возможно нормальное использование RAII. Ссылки правда там пропадают только при выходе из функции, поэтому гибкость хуже, чем в C++. С другой стороны, если объект оказывается включен в циклическую структуру, он может быть вычищен сборщиком мусора. Правда наличие деструктора может помешать в таком случае удалить объект.
Собственно, ничто не мешает программировать на питоне без использования finally.

В питоне работает подсчет ссылок + опциональный GC, который чистит циклы.

Цитата

garbage collection
The process of freeing memory when it is not used anymore. Python performs garbage collection via reference counting and a cyclic garbage collector that is able to detect and break reference cycles.

А для RAII там "менеджеры контекста" и with.

Добавлено 29.12.11, 15:38

Цитата korvin @ 29.12.11, 14:59

Точно также, как и в любом другом языке с GC -- подобиями try-finally. Плюс различные сахарные формы (синтаксические или просто функции) открытия одного ресурса с автоматическим вызовом закрытия (финализатора), например

А, ну тоже RAII

Цитата MyNameIsIgor @ 29.12.11, 14:29

1. Почему в дельфи нет GC? Какие-то фундаментальные сложности? Или он всё же есть в виде каких-то библиотек/расширений?
Если нет, то как бы мог выглядеть GC в дельфи?

См. Delphi Prism.

Цитата MyNameIsIgor @ 29.12.11, 14:29

2. Зачем в шарпе финализаторы? На мой дилетантский взгляд они просто не нужны

Чтобы освобождать ресурсы, время использования которых не критично. И да, зачастую вызывают Dispose(), т.к. лучше поздно, чем никогда

Цитата MyNameIsIgor @ 29.12.11, 15:13

Просто основной шмат говнеца заготовлен

У тебя его всегда в избытке заготовлено.

Цитата IL_Agent @ 29.12.11, 15:43

Чтобы освобождать ресурсы, время использования которых не критично

А можно пример таких ресурсов?

Цитата IL_Agent @ 29.12.11, 15:43

У тебя его всегда в избытке заготовлено.

Даже не знаю... Это комплимент?

Цитата IL_Agent @ 29.12.11, 15:43

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

Это что за ресурсы такие?

Цитата

И да, зачастую вызывают Dispose(), т.к. лучше поздно, чем никогда

А разве это не бага?

Цитата MyNameIsIgor @ 29.12.11, 15:44

А можно пример таких ресурсов?

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

Цитата MyNameIsIgor @ 29.12.11, 15:44

Даже не знаю... Это комплимент?

Ну ты сам решай