Проблема с TFileStream

← →
Palladin © (2007-11-06 11:43) [80]

> homm © (06.11.07 11:26) [77]

Да тот же самый TFileStream, если я освобождаю объект, я точно знаю что handle закрыт и уж никак не ожидаю, что он закроется через пол часа...

← →
vpbar © (2007-11-06 11:44) [81]

> homm © (06.11.07 11:31) [78]
> Ты путаешь подсчет ссылок и автоматический подсчет ссылок

Нда. Просто я когда говорю "подсчет ссылок" имею ввиду автоматический. Но вообщем согласен.

← →
Palladin © (2007-11-06 11:46) [82]

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

← →
vpbar © (2007-11-06 11:50) [83]

>>Palladin © (06.11.07 11:43) [80]
В системах со сборкой мусора (автоматическим потсчетом ссылок) будет другая логика. Удаление объекта отдельно, а закрытие отдельно. И проблем не будет.
Если несколько ссылок на TFileStream и вы освободили одну. Остальные продалжают ссылаться и для них TFileStream должен быть валидным. Поэтому закрывать handle нуждно после освобождения всех ссылок. Хотя с другой стороны если вы вызвав TFileStream.free ожидаете что закрытия хендла то такой подход приведет к ошибке. Вообщем фигня получается.
Это наверно тот случай когда моё предложение сохранять все ссылки в объекте имеет какю-то пользу.

← →
homm © (2007-11-06 11:54) [84]

> [80] Palladin © (06.11.07 11:43)

Вполне логично предположить, что если Вы не передавали созданный TFileStream в чужой код, то он уничтожится непосредственно после Free.
Допустим такую логику:

FS := TFileStream.Create("C:\file"); R := TReader.Create; R.Stream := FS; R.ReadValue(value); FS.Free; // здесь мы не знаем, уничтжен ли FS R.Free; // но здесь то точно знаем, что ему кранты. DeleteFile("C:\file");

Согласен, нужно придерживатся каких-то еше правил, но помему это не слишком обременительно. С другой стороны, с точки зрения VCL этот пример вообще не коректен, т.к. я освободил FS до R?

← →
Юрий Зотов © (2007-11-06 12:06) [85]

> homm © (06.11.07 11:26) [77]

> А для чего это может понадобиться, точно знать что объект убит?

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

Если в Method2 я просто напишу FRef.Free, то либо все пройдет нормально (объект еще существует), либо получим AV (объект уже был уничтожен и адрес, хранящийся в FRef стал недействительным). Результат совершенно непредсказуем - а самое печальное в том, что перед вызовом FRef.Free у меня нет возможности как-то проверить валидность ссылки FRef.

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

В то же время, когда никакого подсчета ссылок нет и програмой я рулю сам (как в Delphi), то за валидностью ссылок я сам и слежу. И есть полная гарантия, что после вызова Free объект действительно уничтожен. Все просто, все однозначно и никаких проблем.

← →
homm © (2007-11-06 12:16) [86]

> [85] Юрий Зотов © (06.11.07 12:06)
> Если в Method2 я просто напишу FRef.Free, то либо все пройдет
> нормально (объект еще существует), либо получим AV (объект
> уже был уничтожен и адрес, хранящийся в FRef стал недействительным).

[73] Вариант1.

Не понимаю, как вы узнаетет, существует ли объект в приведенном Вами примере, если подсчета ссылок нет.

> но не дали способа узнать результат этого запроса.

Обычно этого и не требуется. На пример с TFileStream и хэндлом я ответил.

> homm © (06.11.07 12:16) [86]

Если подсчета ссылок нет, то FreeAndNil решает все проблемы. После этого вызова объект ТОЧНО уничтожен и об этом ОДНОЗНАЧНО сигнализирует FRef=nil.

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

> homm © (06.11.07 12:19) [87]
> Обычно этого и не требуется.

"Обычно" - это не "всегда". И если все же потребовалось, то как быть?

Пример такого "потребовалось" был приведен. Вопрос был задан. Ответа получено не было. Его и не могло быть получено. Потому что его нет.

==============

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

Примерно как автомобиль, который дает водителю возможность крутить руль, но КОГДА начать поворачивать - решает сам. Обычно он решает правильно, но "обычно" - это не "всегда"...

> korneley (06.11.2007 01:38:48) [48]

> Начали с использования указателей на объекты, а закончили (?)

Не гони лошадей

Проблема с TFileStream Найти похожие ветки