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

← →
Romkin © (2007-11-15 17:51) [320]

> А зачем передавать имена? Гораздо лучше передать объект-
> обёртку для какого-то ресурса. Причём, объект самого абстрактного
> типа, насколько возможно, например, абстрактный стрим вместо
> файла. Это увеличит гибкость класса, расширит область его
> возможного применения. Посмотрите на имеющиеся библиотеки:
> именно так очень часто и делают.Таким образом, владеть
> нужными ресурсами объекту вовсе даже не обязательно, можно
> только ссылаться.

Продолжи мысль пожалуйста.
1. Где мне взять этот объект-обертку.
2. Ну ссылаюсь я на него, дальше что?

← →
Piter © (2007-11-15 17:55) [321]

Юрий Зотов © (15.11.07 17:38) [312]
я человек крайне вежливый, поэтому не могу не отвечать на посты, прямо мне адресованные. Поэтому, если ты хочешь, чтобы я на них не отвечал, то ты их просто не пиши, ладно?

а у меня такая же фигня. Значит, мы уйдем в рекурсию? ;)

И вы лукавите, я не говорил, что не хочу чтобы вы отвечали. Я говорил, что хочу, чтобы вы отвечали более конкретно, чем констатация того, что я чего-то не знаю. Особенно в свете того, что я это знаю..

Юрий Зотов © (15.11.07 17:38) [312]
то хотя бы разберись сначала, почему бывают такие программы, что если ее запустить сто раз (каждый раз завершая), то на сто первый окажется, что ресурсы системы кончились

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

Юрий Зотов © (15.11.07 17:38) [312]
А еще разберись с тем, почему бывает невозможно удалить файл, хотя программа, которая его юзала, уже завершилась

а вот это для меня новость. Если этот файл никакая другая программа также не использует - он полюбому должен удалиться (если достаточно прав на удаление).
Windows поддерживает полную сборку мусора от завершившегося процесса, по крайней мере в идеале должна поддерживать.

Поэтому тут пример не очень, на мой взгляд.

← →
Eraser © (2007-11-15 17:56) [322]

> Игорь Шевченко © (15.11.07 17:51) [319]

> Ну и со сброкой мусора тоже самое.

не то же самое, о чем и спор на 17 страниц ))

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

← →
Порш (2007-11-15 17:56) [323]

Извините, что вмешиваюсь в вашу высоконаучную беседу, но....
Из того что я понял из работы сборщика мусора, я выделил для себя следующее (.Net):
Если я хочу сам освободить занятые объектом ресурсы, я использую Dispose(). Если не вызывать этот метод, можно прописать код освобождения в finalize(). Уж он то будет точно вызван, хоть и при закрытии приложения, а значит утечки не будет. Если он не вызыватется в процессе работы приложения, значит ему (приложению) хватает памяти и GC не вызывается.
В чем проблема-то?

← →
umbra © (2007-11-15 17:57) [324]

> "чтобы собирать мусор"

так а файлы он чего не закрывает то?

← →
Германн © (2007-11-15 17:58) [325]

> Piter © (15.11.07 17:55) [321]

> а вот это для меня новость. Если этот файл никакая другая
> программа также не использует - он полюбому должен удалиться
> (если достаточно прав на удаление).
>

Тем не менее бывает. Бывает и хуже.

← →
Юрий Зотов © (2007-11-15 17:59) [326]

> Игорь Шевченко © (15.11.07 17:51) [319]

Про уши прочитал, но на что отвечать снова не нашел. Поэтому на уши не отвечаю.

Отвечаю на твое сравнение со строками. Оно некорректно, потому что строка не юзает unmanaged-ресурсов, а речь идет именно о них.

И только о них. А не о сборке мусора. К ней вопросов как раз нет, там все нормально.

← →
Piter © (2007-11-15 18:00) [327]

Romkin © (15.11.07 17:44) [316]
О как!
Юра, помнишь, ты код с Stream приводил? Так вот: метод close ты вызывать не должен был! Нет у этого класса никаких ресурсов, которые не уберет сборщик мусора!

а что, если Close не вызвать - информация в файл не запишется, да? Как это например может быть, если не вызывать CloseHandle (или запишется частично).

← →
Eraser © (2007-11-15 18:01) [328]

> Порш (15.11.07 17:56) [323]

проблема в том, что может понадобиться явно вызвать destroy (уничтожить объект) в какой-то определенный момент N. В java такой возможности нет.
В C# - хз.

← →
Piter © (2007-11-15 18:03) [329]

Германн © (15.11.07 17:58) [325]
Тем не менее бывает. Бывает и хуже

вряд ли. Бывает, что файл использует другая программа, вот и все.

← →
Piter © (2007-11-15 18:04) [330]

Eraser © (15.11.07 18:01) [328]
проблема в том, что может понадобиться явно вызвать destroy (уничтожить объект) в какой-то определенный момент N

зачем? Не ссылайся больше на этот класс и забудь о нем.

← →
Юрий Зотов © (2007-11-15 18:05) [331]

> Piter © (15.11.07 18:00) [327]

Миш, ответь точно, коротко и прямо на прямой вопрос - что такое unmanaged ресурсы?

← →
Порш (2007-11-15 18:06) [332]

> В C# - хз.

Как только нет на обьект ссылок, сборщик его соберет, а может и не соберет, если не собрал, значит таки опять не нужно. Что за мания такая собрать за собой. Это же не смертельно.

← →
Eraser © (2007-11-15 18:07) [333]

> Piter © (15.11.07 18:04) [330]

к сожалению в данный момент rtl и система устроены так, что если "не ссылаться больше на этот класс и забыть о нём", мы получим грабли, которые подробно описал ЮЗ. не правильно это, imho.

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

> Порш (15.11.07 18:06) [332]

> Как только нет на обьект ссылок, сборщик его соберет

А файлы, которые этот объект держит открытыми, сборщик тоже закроет?
И заюзанные хэндлы объектов GDI - тоже освободит?
А открытые транзакции - тоже завершит? И коннекты к БД позакрывает?

← →
Порш (2007-11-15 18:13) [335]

> А файлы, которые этот объект держит открытыми, сборщик тоже
> закроет?
> И заюзанные хэндлы объектов GDI - тоже освободит?
> А открытые транзакции - тоже завершит? И коннекты к БД позакрывает?
>

Я же написал, это пропишем в finalize() - если даже в процессе работы сборщик и не соберет обьект и не вызовет этот метод, то при закрытии приложения - точно.

← →
Игорь Шевченко © (2007-11-15 18:14) [336]

> Отвечаю на твое сравнение со строками. Оно некорректно,
> потому что строка не юзает unmanaged-ресурсов, а речь идет
> именно о них.

Ну давайте от каждого класса будет требовать умения работать именно с такими ресурсами - а вдруг потомкам понадобится.

← →
@!!ex © (2007-11-15 18:14) [337]

> [335] Порш (15.11.07 18:13)

Это не вариант.
Уже говорили.
Если надо файл еще раз открыть? А он еще не закрыт ниразу..

← →
clickmaker © (2007-11-15 18:14) [338]

> то при закрытии приложения - точно

а чего мелочиться? Может, при шатдауне винды все скопом и закроем? )

← →
Порш (2007-11-15 18:17) [339]

> а чего мелочиться? Может, при шатдауне винды все скопом
> и закроем? )

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

> Если надо файл еще раз открыть? А он еще не закрыт ниразу.
> .

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

← →
Игорь Шевченко © (2007-11-15 18:18) [340]

И в java и в .Net файлы как-то закрываются, не так ли ? Значит и "аппарат есть". Зачем требовать наличие этот аппарата у всего, чего только можно - не понимаю.

← →
Юрий Зотов © (2007-11-15 18:19) [341]

> Порш (15.11.07 18:13) [335]

> то при закрытии приложения - точно.

Нет, не точно. finalize может быть вызван, а может быть и нет. Это уж как сборщик решит. А как он это решает - никому не ведомо. И даже дока вызова finalize тоже не гарантирует. Что мы и наблюдали на практике (см. выше).

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

← →
clickmaker © (2007-11-15 18:19) [342]

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

это вообще путаешь мягкое с теплым

← →
Черный Шаман (2007-11-15 18:19) [343]

> @!!ex © (15.11.07 18:14) [337]
>
> > [335] Порш (15.11.07 18:13)
>
> Это не вариант.
> Уже говорили.
> Если надо файл еще раз открыть? А он еще не закрыт ниразу.
> .

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

← →
Порш (2007-11-15 18:22) [344]

>
> Нет, не точно. finalize может быть вызван, а может быть
> и нет. Это уж как сборщик решит. А как он это решает - никому
> не ведомо. И даже дока вызова finalize тоже не гарантирует.
> Что мы и наблюдали на практике (см. выше).

Что приводит к вызову метода Finalize
Метод Finalize объекта может быть вызван в результате одного из следующих
четырех событий.
• Заполнение поколения 0 Это событие намного чаще остальных приводит
к вызову метода Finalize, так как является естественным следствием выделения
новых объектов во время работы кода приложения.
• Явный вызов статистического метода Collect объекта System.GC Код мо-
жет напрямую запросить сбор мусора у CLR. Хотя Microsoft настоятельно не
рекомендует так поступать, порой имеет смысл, чтобы приложение заставило
CLR выполнить сбор мусора (об этом я расскажу ниже).
• Выгрузка домена приложения CLR Выгружая домен приложения, CLR счи-
тает, что ни один объект в нем не является корнем, и вызывает метод Finalize
у каждого объекта, созданного в AppDomain. О домене приложения см. главу 20.
• Закрытие CLR Корректно завершив свою работу, процесс также пытается
корректно завершить работу- CLR. При этом CLR считает, что ни один объект
не является корнем, и вызывает метод F i n a l i z e у каждого объекта, созданного
в управляемой куче.
Рихтер

← →
Юрий Зотов © (2007-11-15 18:23) [345]

> Игорь Шевченко © (15.11.07 18:14) [336]

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

Не надо от каждлго класса. Надо ввести в самый базовый класс один, четко документированный виртуальный метод. Так, как это сделано в TObject.

И все проблемы. И об этом уже говорилось. Стоит быть внимательнее .

← →
Игорь Шевченко © (2007-11-15 18:26) [346]

Юрий Зотов © (15.11.07 18:23) [345]

> Не надо от каждлго класса. Надо ввести в самый базовый класс
> один, четко документированный виртуальный метод. Так, как
> это сделано в TObject.

Про TObject уже тоже говорили.
> Стоит быть внимательнее .

И все-таки я не понимаю, как же разработчики-то мучаются ? Им же надо файлы закрывать...А судя по ветке, они, файлы, могут закрыться, могут не закрыться или могут закрыться неизвестно когда...

← →
Юрий Зотов © (2007-11-15 18:27) [347]

> Черный Шаман (15.11.07 18:19) [343]

> Ничто не мешает самому написать...

Хорошее предложение. Действительно, ничто не мешает.
Только не об этом речь-то.

← →
@!!ex © (2007-11-15 18:29) [348]

> И все-таки я не понимаю, как же разработчики-то мучаются
> ? Им же надо файлы закрывать...А судя по ветке, они, файлы,
> могут закрыться, могут не закрыться или могут закрыться
> неизвестно когда...

Видимо они пользуются собственноручно написанными аналогами Close, что здесь уже обсуждалось.
И когда это не работает уже тоже обсуждалось.

Юрий Зотов © (15.11.07 18:05) [331]
Миш, ответь точно, коротко и прямо на прямой вопрос - что такое unmanaged ресурсы?

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

Любой unmanaged ресурс - это слишком низкий уровень абстракции для java, если хотите - недостаточная для кросс-платформенности абстракция.

Eraser © (15.11.07 18:07) [333]
к сожалению в данный момент rtl и система устроены так, что если "не ссылаться больше на этот класс и забыть о нём", мы получим грабли, которые подробно описал ЮЗ. не правильно это, imho

какие грабли? Приведи конкретный пример

Юрий Зотов © (15.11.07 18:11) [334]
А файлы, которые этот объект держит открытыми, сборщик тоже закроет?

Во-первых, вы применили хитрость. Речь шла не о том, что СРАЗУ соберет, речь шла о том, что соберет вообще. Хотите прямо сейчас? Пользуйтесь определенным методом. В любом случае утечки ресурсов не будет.

во-вторых, а что, разве нет? Допустим, ваш класс имеет ссылку на файл (stream). Сборщик соберет ваш класс, потом и ссылку, да и файл потом закроет. Только никто не обещает вам, что это случится прямо вот сейчас. Хотите сейчас? Решение вам сказали.

@!!ex © (15.11.07 18:14) [337]
Если надо файл еще раз открыть? А он еще не закрыт ниразу..

интересная логика. А если ты открыл файл в винде, а потом опять его хочешь открыть - и не получится, это что - проблемы винды?
Или все таки тебе надо вызвать сначала CloseHandle, а потом опять открывать? Так вот и в Java надо сначала Close, а потом открывать заново.

clickmaker © (15.11.07 18:14) [338]
а чего мелочиться? Может, при шатдауне винды все скопом и закроем? )

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

> Игорь Шевченко © (15.11.07 18:26) [346]

> Про TObject уже тоже говорили.

Извини, но пришлось повторить.
> Стоит быть внимательнее .

> как же разработчики-то мучаются ? Им же надо файлы закрывать... А
> судя по ветке, они, файлы, могут закрыться, могут не закрыться или могут
> закрыться неизвестно когда...

Кстати, я на деле с таким чудом сталкивался. Java-программа (Eclipse 3.2, JRE 1.5.10). Программа запущена под соедой, она пишет файл и нормально завершается. А файл оказывается захвачен непонятно кем. Причем не всегда.

> Piter © (15.11.07 18:32) [349]

да пример с файлом тыщу раз приводили.. открываем файл в режиме OF_SHARE_EXCLUSIVE или же подсоединяемся к named pipe"у с лимитом подключений = 1, в деструкторе закрываем хэндл файл.
чем не пример.. если последовательно создать/якобы_уничтожить пару таких объектов, то при создании второго, с большой вероятностью, вылезет ошибка доступа.

Юрий Зотов © (15.11.07 18:19) [341]
Поэтому может получиться, что объект успешно сборщиком подметен - после чего освободить заюзанные этим объектом ресурсы стало уже некому. И повисли они, родимые

серьезно? Давайте рассмотрим, например, файлы.

Вы создали экземпляр Stream, поработали с ним и забили на него.
По вашим словам, настанет время и сборщиком мусора объект будет подметен, соответственно будет и подметен используемый экземпляр stream... И... Повисли? Вы хотите сказать, что после этого файл будет продолжаться оставаться заблокированным с точки зрения windows?

← →
Порш (2007-11-15 18:45) [353]

> Piter © (15.11.07 18:42) [352]
> Юрий Зотов © (15.11.07 18:19) [341]
> Поэтому может получиться, что объект успешно сборщиком подметен
> - после чего освободить заюзанные этим объектом ресурсы
> стало уже некому. И повисли они, родимые
>
> серьезно? Давайте рассмотрим, например, файлы.
>
> Вы создали экземпляр Stream, поработали с ним и забили на
> него.
> По вашим словам, настанет время и сборщиком мусора объект
> будет подметен, соответственно будет и подметен используемый
> экземпляр stream... И... Повисли? Вы хотите сказать, что
> после этого файл будет продолжаться оставаться заблокированным
> с точки зрения windows?

Если объект уничтожен сборщиком мусора, то finalize этого обьекта вызван 100%. Если не был вызван close или в finalize не освободили ресурс, то кто виноват ясно.

← →
Порш (2007-11-15 18:46) [354]

> Если объект уничтожен сборщиком мусора, то finalize этого
> обьекта вызван 100%. Если не был вызван close или в finalize
> не освободили ресурс, то кто виноват ясно.

Даже не так, если в finalize не оперделен для этого обьекта, то он и не вызывается.

только я бы хотел услышать комментарии от Юрия, он говорит что "повиснет ресурс"

> [353] Порш (15.11.07 18:45)
> Если объект уничтожен сборщиком мусора, то finalize этого
> обьекта вызван 100%. Если не был вызван close или в finalize
> не освободили ресурс, то кто виноват ясно.

Это вы о C#? А здесь, главным образом, обсуждают Java. По поводу finalize в Java см. выше.

кстати, также очень бы хотелось услышать комментарии на это:

Юрий Зотов © (15.11.07 17:38) [312]
А еще разберись с тем, почему бывает невозможно удалить файл, хотя программа, которая его юзала, уже завершилась

как я понимаю, Юрий говорит о том, что файл уже больше ни одной программой не используется, а удалить его нельзя. Я такого не встречал. Очень хочу комментарий, когда это возможно и почему.

> [352] Piter © (15.11.07 18:42)
> Юрий Зотов © (15.11.07 18:19) [341]
> Поэтому может получиться, что объект успешно сборщиком подметен
> - после чего освободить заюзанные этим объектом ресурсы
> стало уже некому. И повисли они, родимые
>
> серьезно? Давайте рассмотрим, например, файлы.
>
> Вы создали экземпляр Stream, поработали с ним и забили на
> него.
> По вашим словам, настанет время и сборщиком мусора объект
> будет подметен, соответственно будет и подметен используемый
> экземпляр stream... И... Повисли? Вы хотите сказать, что
> после этого файл будет продолжаться оставаться заблокированным
> с точки зрения windows?

Псевдокод.

someClass = new SomeClass (path);
someClass.Read...
someClass.Write...

// вот тут, если не закрыть файл path, открытый для эксклюзивного доступа
// случится хрень
someClass = new SomeClass (path);
someClass.Read...
someClass.Write...

// А когда он освободится -- бог его знает.

Джо © (15.11.07 18:50) [358]

интересно. Только я описал алгоритм действий и в конце задал вопрос. На вопрос отвечено не было, зато зачем-то приведен некий пример, говорящий о том, что сборщик мусора НЕ МОМЕНТАЛЬНО очищает мусор, даже если ссылку на него никто не использует. По-моему, с этим тут никто даже спорить не пытался.

Джо, а давай такой пример рассмотрим, на Delphi:

someClass := TFileStrean.Create... someClass.Read... someClass.Write... // вот тут, если не закрыть файл, открытый для эксклюзивного доступа // случится хрень someClass = TFileStream.Create someClass.Read... someClass.Write...

здесь тебя почему-то не удивляет, что случится хрень? А вот с Java удивляет! К чему бы это?

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