delphi = pascal = языки для начинающих

← →
Плохиш © (2007-11-14 22:39) [200]

> Piter © (14.11.07 19:27) [169]
> @!!ex © (14.11.07 18:53) [154]
> А его вызываю я, когда МНЕ это нужно
>
> а что тебе мешает вызывать некий метод объекта, который
> будет делать тоже самое, что Destroy в Delphi? Можешь даже
> назвать его также.

Странно, за столько лет ни разу не приходилось вызывать деструктор явно. Может я чё не так делаю?

← →
Черный Шаман (2007-11-14 23:30) [201]

> Romkin © (14.11.07 22:28) [198]
>
>
> > Я о том, что пользователю стандартное сообщение об AV
> ничем
> > бы не помогло, он бы даже адреса памяти не запомнил чтобы
> > в службу техподдержки сообщить.
>
> А мой опыт говорит, что помогло бы. Хотя бы потому, что
> если (реально, млин!) нам звонит юзверь, и по слогам читает
> асес-виолейшен, то весь отдел ставится на уши до решения
> трамблемы. По факту.
> Кстати, сугубо рекомендую: глядишь, и скрывать ничего не
> нать будет.
> PS. Лог ведется, но сугубо параллельно, на случай, если
> упустили.

Во у вас в отделе 7 человек, а у нас два из которых только программированием и проектированием занимается 1 - Я (второй мой начальник занимается в основном маркетингом). А тот код достался в наследство, пока нет времени и ресурсов его переделать.

Баги есть довольно конкретные про которые давно известно, но по юзабилити программа уже опережает решения от такого гиганта как Microsoft.

← →
Piter © (2007-11-14 23:53) [202]

Плохиш © (14.11.07 22:39) [200]
Странно, за столько лет ни разу не приходилось вызывать деструктор явно. Может я чё не так делаю?

ах ах... Да какая разница Destroy, Free или там FreeAndNil, все они по сути вызывают деструктор - это их главная задача, просто вешаются проверки, доп. функционал и все такое.

Ты просто обязан в дельфи вызывать уничтожение объекта явно, потому что как раз в отличии от java не поддерживается сборка муссора для классов.
А может ты действительно чё не так делаешь ;)

← →
Piter © (2007-11-14 23:53) [203]

Черный Шаман (14.11.07 23:30) [201]
но по юзабилити программа уже опережает решения от такого гиганта как Microsoft

ну это стандартное дело, разработчику всегда кажется, что его программа наиболее удобная. А даже если че не так - это у пользователей руки кривые и ошибка в ДНК ;)

← →
Плохиш © (2007-11-14 23:58) [204]

> Piter © (14.11.07 23:53) [202]

А вот TObjectList как-то без моего участия вызывает деструктор. Да и владелец то же, для тех кем владеет... Или ты об чём?

← →
Черный Шаман (2007-11-15 00:09) [205]

> Piter © (14.11.07 23:53) [203]
>
> Черный Шаман (14.11.07 23:30) [201]
> но по юзабилити программа уже опережает решения от такого
> гиганта как Microsoft
>
> ну это стандартное дело, разработчику всегда кажется, что
> его программа наиболее удобная. А даже если че не так -
> это у пользователей руки кривые и ошибка в ДНК ;)

Нет на любые проблемы у наших пользователей мы реагируем очень быстро. Вот пришлось динамический балансировщик загрузки процессора потоками сканирования списка файлов написать, чтобы сканирование занимало процессор только когда он полностью свободен.

А то даже на нити с Priority = idle пользователи жаловались.

А на вот те баги с AV они даже не подозревают.

← →
iZEN © (2007-11-15 00:20) [206]

К теме: delphi = pascal = языки для начинающих?

По-моему, для начинающих язык Ruby самое то.
(Кстати, в NetBeans 6.0, которая выйдет в декабре, будет (=уже есть в бете) поддержка программирования на Ruby.)

← →
Piter © (2007-11-15 00:39) [207]

Плохиш © (14.11.07 23:58) [204]
А вот TObjectList как-то без моего участия вызывает деструктор

ты и на Java можешь написать контейнер, который будет вызывать некий метод самостоятельно при удалении из списка item"а, который приведет к уничтожению объекта. И что дальше?

← →
Плохиш © (2007-11-15 00:43) [208]

> Piter © (15.11.07 00:39) [207]

goto [74]

← →
Юрий Зотов © (2007-11-15 00:45) [209]

> Piter © (15.11.07 00:39) [207]

А если контейнер написан раньше, чем item и контейнеру этот метод item"а, соответственно, неизвестен, то как?

← →
Piter © (2007-11-15 01:07) [210]

Юрий Зотов © (15.11.07 0:45) [209]
А если контейнер написан раньше, чем item и контейнеру этот метод item"а, соответственно, неизвестен, то как?

а на этот вопрос вам уже отвечали - у java другая логика программирования. Если эта логика не нравится лично вам - это одно, но утверждения, что язык плох - это другое. Говорить, что lisp плохой язык потому, что на нем неудобно писать 3D-приложения бессмысленно.
В java логике по идее нет месту нетипизированным указателям, поэтому там и не предусмотрено способов и мест по уничтожения таких "нестандартных" ресурсов, такие ресурсы неприемлимы в java. В этом подходе как и в любом другом есть плюсы, а есть минусы.

← →
Черный Шаман (2007-11-15 01:22) [211]

> Юрий Зотов © (15.11.07 00:45) [209]
>
> > Piter © (15.11.07 00:39) [207]
>
> А если контейнер написан раньше, чем item и контейнеру этот
> метод item"а, соответственно, неизвестен, то как?

Определить предка с "виртуальным java-декструктором" для всех итемов. От него и наследовать все итемы.

Delphi тоже не сам писался.

← →
Канадец (2007-11-15 01:23) [212]

> Юрий Зотов © (15.11.07 00:45) [209]

IMHO ваша проблема в [166] совсем не проблема языка, а проблема "специалистов" разработавших эту систему. "Проблема не в сортирах, а в головах", как говаривал небезызвестный персонаж.

Есть набор совершенно произвольных классов, о каждом из которых известно лишь то, что он имеет метод execute. Задача стоит так, что писаны эти классы могут быть кем угодно, как угодно и когда угодно, документации на них нет, исходников тоже нет.
и

По окончании цикла - убить все экземпляры в кэше и освободить все захваченные ими ресурсы. Причем неизвестно, какие именно.

Отсюда я делаю вывод, что есть некие объекты, которые могут захватывать некие ресурсы (поправьте меня если я не прав). Ну если они их захватывают, то они ж и должны их освобождать! Где они это делают? Точнее разработчики, которые разрабатывали эту систему, где предусматривали освобождение ресурсов? Неужели в finalize? Для этих целей и существует IDisposable и вот тот интерфейс, который предоставил этим объектам метод Execute должен был и предоставить IDisposable.
Ну а сейчас уже конечно поздно пить боржоми. В рамках описанного сценария проблему, скорее всего, не решить.

← →
Юрий Зотов © (2007-11-15 01:24) [213]

> Piter © (15.11.07 01:07) [210]

> В java логике по идее нет месту нетипизированным указателям, поэтому
> там и не предусмотрено способов и мест по уничтожения
> таких "нестандартных" ресурсов, такие ресурсы неприемлимы в java.

Миш, ты бы не спорил о том, что не вполне понимаешь, а? Захваченные ресурсы - это далеко не только память. Это открытые файлы, коннекты к БД и многое другое. И все это в джаве есть, потому что без этого никуда. И никакие указатели тут вообще ни при чем.

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

← →
Юрий Зотов © (2007-11-15 01:32) [214]

> Черный Шаман (15.11.07 01:22) [211]

> Определить предка с "виртуальным java-декструктором" для всех итемов.
> От него и наследовать все итемы.

Зачем определять то, что уже и так есть? Это Object с его finalize. Который ОБЯЗАН работать.

> Канадец (15.11.07 01:23) [212]

Проблемы нет, потому что ввести в интерфейс новый метод еще не поздно (и об этом говорилось). Но на фига делать искусственные подпорки, ежели (повторюсь) существует finalize и он ОБЯЗАН работать?

Тем не менее, подпорки эти приходится делать. И только из-за глюкавости.

← →
Черный Шаман (2007-11-15 01:50) [215]

> Юрий Зотов © (15.11.07 01:32) [214]
>
> > Черный Шаман (15.11.07 01:22) [211]
>
> > Определить предка с "виртуальным java-декструктором" для
> всех итемов.
> > От него и наследовать все итемы.
>
> Зачем определять то, что уже и так есть? Это Object с его
> finalize. Который ОБЯЗАН работать.

Он и работает. Просто стандартом не определено когда он должен вызыватся. А вызывается он только когда сборщик мусора решит очистить память. А решит он это когда погода будет хорошей и положение звёзд правильным или же приложение выжрет ВСЮ память.

Так что все правильно, он вызывается, но недерминированно по времени, что николько не противоречит официальной документации.

Хотите детерминированно - реализуйте свой метод.

Вот вы других обвиняете в ламеризме, а у самих "компилятор виноват".

← →
Канадец (2007-11-15 01:56) [216]

> Юрий Зотов © (15.11.07 01:32) [214]

> существует finalize и он ОБЯЗАН работать?

Работать в смысле освобождать ресурсы или в смысле вызываться вообще? С первым не согласен, со вторым согласен.

Кстати далеко не факт, что пример в [80] это глюк. Консоль может закрывться раньше, чем finalize у объектов вызываться. Попробуйте в файл что-нибудь записать.

← →
Piter © (2007-11-15 02:02) [217]

Юрий Зотов © (15.11.07 1:24) [213]
Миш, ты бы не спорил о том, что не вполне понимаешь, а?

а что я по вашему не вполне понимаю? Что такое указатели? Вы сами про них говорили, а теперь оказывается я не понимаю.

Юрий Зотов © (15.11.07 1:24) [213]
это далеко не только память. Это открытые файлы, коннекты к БД и многое другое

и это многое другое должно быть типизированными объектами, структурами или что-то в подобном духе. Которые будут корректно уничтожены сборщиком мусора java.

← →
Piter © (2007-11-15 02:04) [218]

Канадец (15.11.07 1:56) [216]
Консоль может закрывться раньше, чем finalize у объектов вызываться. Попробуйте в файл что-нибудь записать

кстати

← →
Юрий Зотов © (2007-11-15 02:44) [219]

> Черный Шаман (15.11.07 01:50) [215]

В [80] я привел код теста, который показывает, что finalize не вызвался ни разу за все время жизни приложения (хотя счетчик ссылок на объект обнулялся, как минимум, дважды). Как это понимать? Очевидно, так, что за все время жизни приложения GC ни разу не решил, что пора почистить память. По крайней мере, других объяснений нет.

Но возникает вопрос - а если бы объект открыл файл или коннект к БД, а код его освобождения был прописан именно в finalize (кстати, в полном соответствии с рекомендациями документации) то что, этот ресурс так и остался бы открытым? Чушь ведь.

> Канадец (15.11.07 01:56) [216]

> Работать в смысле освобождать ресурсы или в смысле
> вызываться вообще?

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

> Консоль может закрывться раньше, чем finalize у объектов вызываться.

Если в консоли второй раз появилась строка "created", значит, до этого она точно была открыта. Но строки "finalized" в ней не появилось - значит, метод finalize вызван не был, хотя счетчик ссылок на объект точно был обнулен. Но, возможно, он был вызван перед завершением программы, так решил GC? Хорошо, давайте проверим, как Вы и предложили. Вот измененный тест:
public class DisposableObject { private FileOutputStream stream; public DisposableObject() { super(); try { stream = new FileOutputStream("C:/Test.txt"); writeString("created"); } catch (IOException e) { e.printStackTrace(); } } public void writeString(String s) throws IOException { stream.write((s + "\n").getBytes()); System.out.println(s); } protected void finalize() throws Throwable { writeString("finalized"); stream.flush(); stream.close(); super.finalize(); } }
И измененная запускалка теста:
public static void main(String[] args) { DisposableObject obj = new DisposableObject(); try { obj.writeString("isWorking"); } catch (IOException e) { e.printStackTrace(); } obj = null; }
А вот результат - и в консоли, и в файле одно и то же:
created isWorking
Никаких вызовов finalize, как видим, снова не зафиксировано. Что удручает.

← →
Юрий Зотов © (2007-11-15 02:48) [220]

> Piter © (15.11.07 02:02) [217]

> а что я по вашему не вполне понимаю?

Что такое ресурсы.

> и это многое другое должно быть типизированными объектами,
> структурами или что-то в подобном духе. Которые будут корректно
> уничтожены сборщиком мусора java.

Миш, ты никак не мог лучше подтвердить мои слова о том, что ты не вполне понимаешь, что такое ресурсы. Какие объекты? Какие сборщики мусора будут тебе хэндлы закрывать? При чем тут вообще сборщик мусора?

← →
Romkin © (2007-11-15 07:55) [221]

> это далеко не только память. Это открытые файлы, коннекты
> к БД и многое другоеи это многое другое должно быть типизированными
> объектами, структурами или что-то в подобном духе. Которые
> будут корректно уничтожены сборщиком мусора java.

Да, конечно. Вполне логично, что создал я объект типа файл - файл открыт, пишу-читаю. Стал объект не нужен - он уничтожился, файл закрыт. Только маленькая проблема: а когда?

← →
Evgeny V © (2007-11-15 08:17) [222]

> Юрий Зотов © (15.11.07 02:48) [220]

> Какие сборщики мусора будут тебе хэндлы закрывать? При чем
> тут вообще сборщик мусора?

Для программирования в таких средах как .NET, JAVA,BlackBox и подобных надо просто менять несколько идеологию - как , когда и зачем.... Программу за программиста все равно никто не напишет. Поэтому кое-что надо делать самому, ручками и в нужное время. А вынос освобождения например файловых ресурсов (или каких других неуправляемых ресурсов) в финализатор - это просто неверный подход в данном случае. О чем указывают все учебники по JAVA, .NET и прочие... Правило относительно простое - если есть реализация IDisposable - то и надо воспользоваться соответствующим методом для освобождения ресурса. Впрочем я повторил [212] Что касается ссылок на описание, что делает finalize то надо помнить, что это просто последний бастион,для освобождения ресурсов, которые надо было явно осбодить, но не сделали этого. Никто не гарантирует, что метод будет вызван в определенный момент. А если сборщик мусора решит, что нет необходимости на данный момент уничтожать объект и освобождать память, то вообще вопрос будет ли вызван финализатор.

Почитайте - рекомедую. Кстати и книгу на которую там ссылаются, есть ее русское издание (Философия Ява).
http://iais.kemsu.ru/odocs/javax/finally.html
"Деструкторов нет. А что вместо?
Многие программисты (особенно только что пересевшие с C++), видят замену деструкторов в виде методов finalize. Это не есть правильно. Во первых, этот метод не вызовется, пока на объект имеются ссылки. Нет гарантии, что он вызовется тогда, когда вам это нужно. Он может вообще никогда не вызваться. Есть, конечно, метод System.runFinalizersOnExit(), но он уже давно deprecated из-за возможных deadlock-ов. Как справедливо заметил Bruce Eckel в замечательной книжке Thinking in Java метод finalize стоит использовать только для того, чтобы освободить память (или другой, не очень критичный ресурс), выделенную в native методах. Для прочих же ресурсов следует добавить явный вызов метода очистки ресурсов (он может называться по-разному - close, dispose, cleanup, и т.д.), внутри конструкции finally. Внутри finally - для того, чтобы не прозевать какое-нибудь исключение. Пример типичных конструкций:
"

Поэтому надо реализовать и/или использовать IDisposable, когда надо явно освободить ресурсы(как правило методы Close,Dispose)

Кстати - кроссплатформенность, даже в урезанном виде весьма неплохая вещь, когда приходится с этим сталкиваться....

← →
Evgeny V © (2007-11-15 08:20) [223]

> Romkin © (15.11.07 07:55) [221]

Когда сам его закроешь, или если забыл, то когда решит GC, а это только ему одному известно:-)))

← →
Romkin © (2007-11-15 08:23) [224]

Вот давайте разберемся, тем более что в Юрий Зотов © (15.11.07 02:44) [219] есть код с потоком.
Вот что подразумевается, когда говорят, что о времени жизни объекта заботится не надо? Это значит, что если он не нужен - он уничтожается.
Замечательно! Возьмем stream. Фактически - мы создаем из строкового имени файла объект, представляющий его содержимое, так ведь?
И красиво было бы, если бы поток не надо было закрывать, зачем? Сам закроется, когда будет не нужен. Но обратите внимание: есть вызов close();
Зачем? Вы скажете: а я его хочу потом снова открыть и поработать. Ну и что? А почему нельзя создать новый объект потока? Почему не принять, что файл открывается при создании (а так и есть), и совершенно симметрично закрывается при уничтожении? В Delphi поток так и работает, кстати. Логично же?
Тогда при вызове метода close мы объявляем, что объект не нужен. Это - вызов логического деструктора. И если я вызываю close, то почему я не могу в этом же месте просто уничтожить объект?
Получается какая-то нелогичность: все советуют иметь метод, освобождающий ресурсы, но только не деструктор! Млин. С одной стороны - если я освободил внешние ресурсы, объект мне не нужен, с другой - избавиться я от него не могу, этим занимается сборщик мусора!
Спрашивается, а оно мне надо? Точнее, а нафига мне этот сборщик мусора? НУ насобачили нечно, заботящееся об освобождении памяти, и при этом еще мешающее мне освобождать остальные ресурсы?!
Не считайте меня идиотом: если я позаботился о закрытии потока, то об уничтожении собственно объекта я тоже позаботиться в состоянии. И мне бы подошло совмещение этих двух действий.
Почему в java я лишен возможности явно уничтожить объект, когда мне хочется?! Что за детский сад?

← →
Evgeny V © (2007-11-15 08:38) [225]

> Romkin © (15.11.07 08:23) [224]

GC никак не знает, что вам не нужен файл уже сейчас, что его надо закрыть, разрешить им позоваться другому. Он закроет файл, когда увидит, что поток уже не используется, нет ссылок на него. Но - это будет неизвестно когда, то есть недетерминированный процесс. Надо что бы файл был свободен сразу после того, как мне он не нужен. Для чего и вызывается его метод Closeю Почему нельзя создать новый объект потока? Можно, только я ведь мог открыть файл в эксклюзивном режиме. Close не уничтожает объект, он закрывает файл. Класс уничтожиться уже GC(или нет, такое возможно). Кстати на вопросы в этом посте и тебе поможет hfphttp://iais.kemsu.ru/odocs/javax/finally.html -статья хорошая. Не все яве было и есть возможно гладко. Но возможность явного освобождние ресурсов типа файл, битмап и т.п. вещб полезная. Ибо GC не вызывается явно, даже когда мы вызываем его сами GC.Collect() - это не гарантия, что он решит, что все объекты ненужные надо освободить. Кстати - идиотом я тебя и не думал считать:-))

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

И в c# и в компонент паскаль и еще много где, где есть сборщик мусора. Кстати используя менеджер памяти дельфи, я тоже не всегда могу явно освободить блок памяти(вернуть его менеджеру не есть освободить) - ну что за детский сад:-))

← →
DiamondShark © (2007-11-15 08:58) [226]

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

Опять сакрализация "уничтожения объекта".
Объект -- это просто область памяти. Какая разница, каким образом неиспользуемая область памяти попадёт под повторное использование?

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

← →
@!!ex © (2007-11-15 08:59) [227]

> А решит он это когда погода будет хорошей и положение звёзд
> правильным или же приложение выжрет ВСЮ память.

...

> Вот вы других обвиняете в ламеризме, а у самих "компилятор
> виноват".

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

← →
Evgeny V © (2007-11-15 09:12) [228]

> @!!ex © (15.11.07 08:59) [227]

Например на дельфи 6 со стандартным менеджером памяти - в цикле очень часто выделяем блоки памяти примерно одного размера:

Getmem и через какое-то время FreeMem. Скажи мне когда совпадут звезды так, что бы освобожденный FreeMem блок памяти был сразу же возвращен системе???

> Опять сакрализация "уничтожения объекта".Объект -- это просто
> область памяти. Какая разница, каким образом неиспользуемая
> область памяти попадёт под повторное использование?Отвыкайте
> мыслить освобождение памяти и закрытие ресурсов как однозначно
> связанные операции -- и будет вам щасте.

А зачем мне вообще об этом думать? Если меня добрая Виртуальная машина избавляет от дум о памяти - пусть освободит и от дум о ресурсах!

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

Вот об этом и речь. Java как-то остановилась на середине пути: что-то освобождается (не будем упоминать о том, что это что-то - только память), а что-то - нет.
Более того, если в Delphi есть четкое место освобождения всех ресурсов, деструктор, то в java - каждый предусматривает его для себя. Один назовет Close, другой - Dispose... А тот, кто пользует, должен знать, как это называется и как вызывать, более того: обязан это сделать.
Вот Delphi:
function BigBrother.GetMeTheFile(const FileName: string): IStream; var Stream: TStream; begin Stream := TFileStream.Create(FileName, fmOpenRead); Result := TStreamAdapter.Create(Stream, soOwned); end; //Пользуем, где-то: procedure ReadFile; var Stream: IStream; begin Stream := BigBrother.GetMeTheFile("c:\a.txt"); Stream.Read(...); //Big thanks! end;
И все... Все уже давно договорено: где тут open, close, dispose?
Почему в Java так нельзя?

> Romkin © (15.11.07 09:30) [229]

> Вот об этом и речь. Java как-то остановилась на середине
> пути: что-то освобождается (не будем упоминать о том, что
> это что-то - только память), а что-то - нет.

Согласен, я не говорю, что лучше, а что хуже. Мне в последнее время все больше нравится GC, а не явное освобождение памяти. А насчет ресурсов типа файл - то как бы тыт решил эту проблему в виртуальной машине? Я думал о таком же, когда начла, но честно говоря не придумал.

Про

> И все... Все уже давно договорено: где тут open, close,
> dispose?
> Почему в Java так нельзя?

Ты используешь один вариант, но ведь есть и Assign в паскале. И в JAVA есть не один вариант и класс для открытия файла.
В JAVA тоже все договорено. Только под другую иделогоию. И не только в JAVA, а там где есть сборщики мусора. Скажем так, тебе нравится детерминированный подход. А мне в некоторых случаях стал нарвится подход с подскакзой,что-то делается за меня. Но о чем-то я все равно обязан помнить. Без этого пока никак. Но ведь и ты пользуешься подсказчиками в виде ObjectInspector и т.п и визульными редакторами и прочим. Удобно просто. Что-то можно в JAVA. что-то нельзя, так же и для других языков. Для меня GC -это просто помощник:-) Но есть вещи, которые еще делаю в дельфи и не жалею кстати, что в дельфи. Так же ка и не жалею, что делаю задачи на C# Выбор инструмента - это задача, ресурсы и скорость выполнения задачи, начальство и мои предпочтения:-)

Давай скажем так - дело не в JAVA для тебя, дело в сборщике мусора, он ебе не нравится. А это не один язык, а много разных. А сборщик мусора - ну это дело предпочтений отчасти.

pasha_golub © (14.11.07 19:00) [157]

> 2ИШ
> То что отлаживать с excption"ами иногда муторно, я согласен.
> Но зато, получили Exception, тут же выкинуло нас в код,
> жмакаем Ctrl+Alt+S и имеем стек откуда шо пришло. А в ином
> случае, пришлось бы по F7 спускаться самим.

Ты не до конца понял - в случае, который я привел, Exception возбуждается при вполне корректной ситуации, то есть, он служит чем-то вроде условного перехода. Только среда об этом не знает и каждый раз "нас выкинуло в код", который нам совершенно неинтересен.
Тебе бы понравилось, если бы ты вызывал какую-то подпрограмму, а внутри ее по if-у стояла бы точка останова и каждый раз среда бы там останавливалась ?
Вот и мне не нравится.

> Romkin © (15.11.07 09:30) [229]

И еще, если бы был язык со сборщиком мусора, но в котором были деструкторы, которые надо вызывать явно. Но в деструторе на самом деле только закрывались бы дескрипторы файлов, битмапов и т.п - если это объект такого типа. А в другом случае на самом длеле ничего бы не делалось, все оставалось бы И ты например об этом не знаешь (так сказать эмуляция дельфи не для .NET) Тебя такое устроило бы? То есть что тебе точно не нравится? Непривычная методика работы или ты против того, что память где-то некоторое время болтается? C файлами - ну я например не знаю как автоматом освободить гарантированно файл.... Не додумали они тут LOL

Romkin © (14.11.07 21:58) [188]

> А зачем? Просто налагай штраф за try/except, если не обосновано.

Проще немцев импортировать

Evgeny V © (15.11.07 10:00) [232]

> И еще, если бы был язык со сборщиком мусора, но в котором
> были деструкторы, которые надо вызывать явно. Но в деструторе
> на самом деле только закрывались бы дескрипторы файлов,
> битмапов и т.п - если это объект такого типа. А в другом
> случае на самом длеле ничего бы не делалось, все оставалось
> бы И ты например об этом не знаешь (так сказать эмуляция
> дельфи не для .NET) Тебя такое устроило бы?

Посмотри внимательно на отрывок, что я привел: меня устраивает и такое :)
В идеале в java меня устроило бы наличие интерфейса, экспонирование которого объектом говорило бы виртуальной машине (ей, а не вызывающей стороне!) о том, что нужно дернуть метод этого интерфейса, как только и сразу на него перестанут ссылаться. Все.
Другими словами, пусть есть предопределенный интерфейс IDispose (sic!) с одним методом Close. И есть следующий контракт: если объект владеет ресурсами, которые надо освобождать сразу, он обязан экспонировать этот интерфейс, и в реализации Close должен быть код их освобождения. Система (VM, но никак не вызывающая сторона!) обязуется, в случае, если у объекта экспонируется этот интерфейс, вызвать его метод Close как можно быстрее после момента, когда на объект перестали ссылаться.
Неужели это сложно? При этом тот, кто будет использовать этот объект, может вообще не догадываться о наличии у него IDispose, это забота системы.

> Romkin © (15.11.07 10:34) [234]

О! То, что нужно. И нужно было сделать. Сразу. Тем более, что делается элементарно.

> Romkin © (15.11.07 10:34) [234]

> Неужели это сложно?

Не знаю, наверное да... Вопрос, который мог бы решаться по разному.
А зачем удалять объект из памяти (уже не нужный), если он никому не мешает? Проще наверное удалить сразу кучу объетов, тем более память освобождаем страницами, блоками... и т.п. Связано думавю с оптимизацией работы GC. Отсюда наверное и ноги растут того, что объект не нужен, но как бы есть в памяти(что наблюдаем и у компиляторов дельфи, с++ при обращении к их менеджерам памяти). А удаление(закрытие) дескрипторов файлов -ну так оно такое же по сути как и в дельфи. Так в чем разница? Правила оформления. И более толстая прослойка между ОС и приложением. Но правила меняются от платформы к платформе. А вот идея GC мне в общем нравится. В BlackBox например как ты и хочешь нет IDIsposable для пользователя. Там правда и нет явного удаления объекта(там и идеология ООП несколько другая). А вот файл надо закрывать все равно ручками и последовательный порт. На мой взгляд проблема в определении того, что объект уже не нужен. Это не делается сразу. А потому повторноиспользуемые ресурсы могут не стать такими, если на некоторое время "подвиснут" в системе.
Резюме - или мы сами дергаем интерфейсы когда нам надо, или приходится мириться с недетерминированостью процесса удаления объекта. Некоторое разрастание используемой памяти считается злом небольшим, а потому явно можно не удалять ресурсы связанные с памятью. А вот файлы - это повторно используемый ресурс, который может быть нужен прямо сейчас, а потому мы должны как можно быстрее его освободить(ручной метод).

А что выбирать и когда - зависит от задачи, требований начальства, денег, времени и собственных предпочтений:-)
PS:
Я в общем не ставил задачу убедить кого-либо, что JAVA - это супер.
Я только хотел сказать, что в JAVA полагаться на вызов finlize нельзя. И если этого не знать, то конечно можно долго ругать систему, язык и прочее:-)

> А зачем мне вообще об этом думать? Если меня добрая Виртуальная
> машина избавляет от дум о памяти - пусть освободит и от
> дум о ресурсах!

С чего вдруг такая маниловщина?

Evgeny V © (15.11.07 11:09) [237] Да, все правильно. Есть ли на объект ссылки - определяет сборщик мусора, когда набредает на этот объект. Ничего не имею против, эта идеология вполне имеет право на жизнь.
Но почему не выделена "каста" объектов, которые должны освобождать внешние ресурсы как можно быстрее - вот в чем вопрос.
Причем препятствий особых и нет: в [234] я ни слова не сказал об освобождении памяти, я говорил о дергании метода, а не о наличии деструктора.
Во-первых, много таких объектов не будет, во-вторых, они, как правило, "медленные" (это не память, на памяти уже дворник сидит!). Так что особо мешает подшивать для таких вот объектов отслеживание ссылок по месту? Когда ссылки исчезли - дергаем Close, ну а дальше по ситуации: можно пометить объект как неиспользуемый, чтобы когда на него набредет GC, он его особо не терзал, а можно и не делать ничего :)

← →
Однокамушкин (2007-11-15 11:38) [240]

> Так что особо мешает подшивать для таких вот объектов отслеживание
> ссылок по месту? Когда ссылки исчезли - дергаем Close,

Мешает то, что счётчик ссылок работает только для простых типов вроде string-ов, а когда есть циклические ссылки двух объектов друг на друга и больше никаких, счётчик ссылок не поможет, тут нужен более сложный алгоритм определения того, что на объекты нет доступных извне ссылок - тот самый алгоритм, который и реализует GC

delphi = pascal = языки для начинающих Найти похожие ветки