Проблема с TFileStream

← →
vpbar © (2007-11-06 00:31) [40]

Юрий, я уже начинаю сомневатся в своей правоте :) Хотя и не привык слепо верить авторитетам. Просто не пойму, что тут фантастичного.
ЗЫ. Видимо пора спать, чтобы червь сомнений не мутил мой светлый разум. :)

← →
ProgRAMmer Dimonych © (2007-11-06 00:33) [41]

> vpbar © (06.11.07 00:31) [40]
> ЗЫ. Видимо пора спать, чтобы червь сомнений не мутил мой
> светлый разум. :)

Червь - не самое страшное. Вон троянцы тоже спали, а в это время троянский конь сработал. :)

← →
korneley © (2007-11-06 00:37) [42]

> vpbar © (06.11.07 00:13) [33]

> Добавить в объект указатель на список ссылок на переменные
Пусть даже имеется "внутренний", только для системы "ССП". Как отследить все перемещения/присвоения ссылок и отличить их, скажем, от арифметических операций? b := $01234567; это адрес или нет?

>А ведь их может быть и не одна, запросто
> Вот это некоторая проблема
:))) Некоторая... :))) И не единственная... :))) Кроме ошибки в коде... генетическом...

← →
vpbar © (2007-11-06 00:39) [43]

>>korneley © (06.11.07 00:37) [42]
Ндя, если присваивать переменной типа TObject число - это точно ошибка в геноме.

← →
korneley © (2007-11-06 00:49) [44]

> Ндя, если присваивать переменной типа TObject число - это
> точно ошибка в геноме.
А что мешает? В сысле не генома, а присвоения? Что хотим, то и храним в отведённых нам 32-х разрядах. Хоть четыре восьмибитных символа. Если правила позволяют - значит можно. Или ни разу не использовали TString.Objects[i] := TObject(<целое число>); ?

← →
Германн © (2007-11-06 01:06) [45]

> korneley © (06.11.07 00:49) [44]
>
>
> > Ндя, если присваивать переменной типа TObject число -
> это
> > точно ошибка в геноме.
> А что мешает? В сысле не генома, а присвоения? Что хотим,
> то и храним в отведённых нам 32-х разрядах.

Ни что не мешает, кроме защищенного режима.

← →
korneley © (2007-11-06 01:10) [46]

> Ни что не мешает, кроме защищенного режима
Не, ну своей переменной типа TObject, я могу присвоить всё, что угодно (а потом удивляться результатам), не взирая ни на что, тем более на "защищенный режим".

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

> ProgRAMmer Dimonych © (06.11.07 00:27) [38]
> Компилятор нагрузить этим делом.

> vpbar © (06.11.07 00:28) [39]
> Компилятор добавит нужную информацию.

Вы представляете себе, что это будет за компилятор? Сложность его? Скорость его? Надежность его?

И объект, хранящий адреса всех ссылок на себя - Вы представляете, насколько увеличится объем занимаемой им памяти? Понимаете, что память эту придется еще и постоянно перераспределять (количество ссылок ведь меняется)? Что это будут серьезные тормоза, что увеличится фрагментированность памяти?

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

На крайняк - пусть юзают интерфейсы, пусть пишут на джаве или под дотнетом. Программирование на уровне адресов - не для них.

← →
korneley © (2007-11-06 01:38) [48]

> Юрий Зотов © (06.11.07 01:14) [47]
Как занятно эволюционировала ветка... Начали с использования указателей на объекты, а закончили (?) рекомендациями кому и чем следует заниматься :) Да, всетаки "неблагодарное это занятие - бить красных..." (с)

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

> korneley © (06.11.07 01:38) [48]

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

← →
korneley © (2007-11-06 02:58) [50]

> Люди все разные, кому-то быть художником, кому - программистом,
> кому - певцом
Да, конечно. Но тема [0] исчерпана (до очередного неофита, наступившего туда же). Так не лучше ли завести другую ветку и в другом месте? Например, "Прочее".

← →
Германн © (2007-11-06 03:07) [51]

> korneley © (06.11.07 02:58) [50]
>
>
> > Люди все разные, кому-то быть художником, кому - программистом,
>
> > кому - певцом
> Да, конечно. Но тема [0] исчерпана (до очередного неофита,
> наступившего туда же). Так не лучше ли завести другую ветку
> и в другом месте? Например, "Прочее".
>

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

← →
korneley © (2007-11-06 03:12) [52]

> Но, имхо, кроме тебя в сей ветке этот вопрос никого не
> интересует

Дык, понятно, четвертый час пошел... :)

← →
homm © (2007-11-06 06:50) [53]

> [19] ProgRAMmer Dimonych © (05.11.07 23:47)
> Кажется, понял. Тогда получается, что, действительно, без
> присвоения указателю FFile:=nil будет глючить. Так вроде?

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

И это, TFileStream вообще не причем. ([2])

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

> [34] ProgRAMmer Dimonych © (06.11.07 00:14)
> > Ну тогда ссылки считать, и не освобождать пока все ссылки
> > не обнулятся.
>
> В COM, кажется, так делается?

В КОЛ тоже так-же. Чесно говоря всю жизнь думал, что и в VCL так-же. Счас поискал подобное, не нашел. Кашмар… Может плохо искал?

← →
Anatoly Podgoretsky © (2007-11-06 07:51) [55]

> Юрий Зотов (06.11.2007 00:24:36) [36]

Тем более если ее не существует.

← →
vpbar © (2007-11-06 09:33) [56]

>>homm © (06.11.07 07:01) [54]
Неее. В KOL не совсем так. Ну не мог Кладов исправить компилятор и заставить вести его подчет ссылок на объект.

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

> vpbar © (06.11.07 09:33) [56]

Подсчет ссылок на объект сделать, кстати, можно. И сделано (в той же джаве, скажем). И в Delphi это есть (интерфейсная модель).

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

← →
vpbar © (2007-11-06 09:43) [58]

> >>Юрий Зотов © (06.11.07 01:14) [47]

>
> > Вы представляете себе, что это будет за компилятор? Сложность
>
> > его? Скорость его? Надежность его?

Да. Не сложнее существующих. Такой же простой как, например компилятор Делфи. Скорость не сильно пострадает. Надеженость, конечно зависит от сложности, но не так прямо.

> > И объект, хранящий адреса всех ссылок на себя - Вы представляете,
>
> > насколько увеличится объем занимаемой им памяти? Понимаете,
>
> > что память эту придется еще и постоянно перераспределять
>
> > (количество ссылок ведь меняется)? Что это будут серьезные
>
> > тормоза, что увеличится фрагментированность памяти?

Представляю. А сколько может быть максимально ссылок? Ну штук десяток. Больше редко. Так что скажем 320 бит в среднем на объект хватит и перераспределять необязательно. На 64х разрядной платформе поболее будет, но там все побольше.

> > И главное - а зачем ве это?

В данной ветке, просто как пример что альтернатива может быть. А вообще действительно это мало кому нужно. Ибо пошли другим путем. Ссылки считают.

← →
homm © (2007-11-06 09:43) [59]

> [56] vpbar © (06.11.07 09:33)
> В KOL не совсем так.

Не совсем так как в COM, но так, как в [34] написано. О добавлении ссылок, конечно сам программист должен заботится.

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

>>Юрий Зотов © (06.11.07 09:42) [57]
Нда. Надо сохранить ветку как доказательство моих авторских прав на идею :)

← →
vpbar © (2007-11-06 09:54) [61]

> homm © (06.11.07 09:43) [59]

Вы о чем? Я не увидел в /34/ ничего такого.
В КОЛ просто делается в free
if @ Self <> nil then RefDec;
Да объект не удалится пока fRefCount>0
Но увеличение ссылок возложено на программиста, ему нужно RefInc самому вызывать. Или вы какойто другой механизм в КОЛ имеете ввиду?

← →
homm © (2007-11-06 09:59) [62]

> [61] vpbar © (06.11.07 09:54)
> Я не увидел в /34/ ничего такого.

Сори, в [29].

Ну тогда ссылки считать, и не освобождать пока все ссылки не обнулятся.

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

> vpbar © (06.11.07 09:43) [58]

> Скорость не сильно пострадает.
Ой ли?
Пусть имеем a := b; // Обе переменные - ссылки на объект.
Если не учитывать ссылки, то это одна команда MOVE. А если учитывать, то к этой команде надо еще добавить внесение новой ссылки в список ссылок в самом объекте. А если емкость списка исчерпана, то еще и перераспределить память под него.

И так почти при каждом чихе, потому что операция ОЧЕНЬ частая. Итого можно прогнозировать замедление на один-два порядка. То есть, от 10 до 100 раз.

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

> А сколько может быть максимально ссылок?
Сколько угодно. Максимально - сколько хватит памяти.

> Ну штук десяток. Больше редко.
И как поступать разработчикам Вашего компилятора? Сколько памяти отводить под список ссылок? Отвести N байт и надеяться на "авось, больше не потребуется"? Глупо. Менять емкость списка динамически? Тогда на каждом чихе пойдет перераспределение памяти - а это серьезные тормоза и серьезная фрагментация памяти.

>Так что скажем 320 бит в среднем на объект хватит
Размер объекта TFont - 40 байт. При Вашем подходе он становится 360 байт. Разница в 9 раз. Примерно такая же картина и по другим объектам. Итого можно прогнозировать увеличение расхода памяти в 5-10 раз.

> и перераспределять необязательно.
Вот это мило. А как? Отвести под список 320 байт и молиться Богу, чтобы не появилась 11-я ссылка? Класная программа получится.

← →
homm © (2007-11-06 10:20) [64]

> [63] Юрий Зотов © (06.11.07 10:10)
> >Так что скажем 320 бит в среднем на объект хватит
> Размер объекта TFont - 40 байт. При Вашем подходе он становится
> 360 байт.

При его подходе он становится 80 байт или 640 бит. Хотя конечно ы целом с вами сагласен, нафиг это не нужно.
С другой стороны удивляет, почему не был опрганизован элементврный подсчет ссылок, как в KOL. Это же очень удобно.

MyBitmap := TBitmap.Create; Component1.Bitmap := MyBitmap; MyBitmap.Free; function TComponent.SetBitmap(aBitmap: TBitmap); begin fBitmap.Free; fBitmap := aBitmap; fBitmap.RefInc; end; function TComponent.Destroy(); begin fBitmap.Free; end;

← →
homm © (2007-11-06 10:21) [65]

> fBitmap.RefInc;

if fBitmap <> nil fBitmap.RefInc;

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

> homm © (06.11.07 10:20) [64]

1. Верно, спутал. Всего лишь вдвое, оказывается. :o)

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

Поэтому насчет удобства: кому как, а мне удобнее другое - когда я сам рулю программой так, как мне это надо, и никто мне не мешает это делать.

← →
homm © (2007-11-06 10:40) [67]

> [66] Юрий Зотов © (06.11.07 10:33)

Я говорю о подсчете ссылок как таковом, не с точки зрания сабжа. Посмотрите, на пример, там [64] Вы сами рулите кодом. После того, как Вы вызвали MyBitmap.Free; для вас он уже уничтожен (как бы ни было на самом деле) и пользоваться им не должны. А для компонента TComponent он существует, и если бы не вызывать MyBitmap.Free; он будет существовать для обоих кусков кода, помоему все просто и логично, и не нужно беспокоиться о том, что кто-то уничтожит объект. Нужен на каком-то участке — добавил ссылку, не нужен больше — Free, и пофиг, уничтожился ли объект на самом деле, главное что твоей ссылки на него больше нет, как только других ссылок тоже не окажется, уничтожится.

← →
vpbar © (2007-11-06 10:57) [68]

>>Юрий Зотов © (06.11.07 10:10) [63]

> Ой ли?

- так вы про скорость работы?
А я понял из этого
> Вы представляете себе, что это будет за компилятор? Сложность
> его? Скорость его?

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

> как поступать разработчикам Вашего компилятора?

Примерно так же как поступили разработчики TList. Посмотрите его реализацию. Память там перераспределяетя не на каждый чих.

>
> >Так что скажем 320 бит в среднем на объект хватит
> Размер объекта TFont - 40 байт. При Вашем подходе он становится
> 360 байт. Разница в 9 раз. Примерно такая же картина и по
> другим объектам. Итого можно прогнозировать увеличение расхода
> памяти в 5-10 раз.
>

Эээ. откуда лишние 360-40 = 320 Байт?? Я предлагал 320 Бит т.е. 40 Байт. Да в два раза больше. Но опять же можно оптимизировать.

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

Пока в пределах 32х ссылок не надо перераспределять. Для 33 выделить очередной блок памяти

> homm © (06.11.07 10:40) [67]

Тут ничего нового, так оно в той же джаве, например, и работает. Плюс там никаких Free вообще нет, а счетчик ссылок рулится их явных присвоением, их явной очисткой и областями их видимости (как длинные строки и динамические массивы в Delphi).

Ну да ладно, вернемся к Delphi (или KOL). Пусть работает подсчет ссылок и мы имеем вот что:
type TMyObject = ... FRef: TObject; procedure Method1; procedure Method2; end; procedure TMyObject.Method1; begin FRef := TSomeObject.Create(...); ... // Что-то делаем if SomeCondition then FRef.Free; end; procedure TMyObject.Method2; begin ... // Вопрос на засыпку - как мне в этом месте кода узнать, ... // существует ли объект, на который ссылается поле FRef, ... // или он уже уничтожен? Конечно, учитывая, что в других ... // местах программы тоже могут ссылки на этот же объект end;

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

if not SomeCondition then ???

> [72] Юрий Зотов © (06.11.07 11:05)

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

Вариант1:
procedure TMyObject.Method1; if SomeCondition then FreeAndNil(FRef); end;

Вариант2:
procedure TMyObject.Method1; if SomeCondition then begin FRef.Free; SC := TRUE; end; end;

> [73] homm © (06.11.07 11:09)
> Вариант2:
> procedure TMyObject.Method1;
> if SomeCondition then begin
> FRef.Free;
> SC := TRUE;
> end;
> end;

Правильнее так:
procedure TMyObject.Method1; SC := SomeCondition; if SC then FRef.Free; end

>>Юрий Зотов © (06.11.07 11:02) [70]
Конечно. Собственно хотел тоже предложить Ибо думаю, Вы согласитесь, что непреодолимых технических трудностей нет. Есть недостатки самой технологии.
>>Юрий, ну Вы же понимаете что этот пример никакого отношения не имеет к подсчету ссылок, решается точно так-же, как и сабжевая проблема.
Вообще то имеет. Если бы был действительно подсчет ссылок, то вопрос был бы лишен смыла. Ибо объект существует пока на него хоть кто-нибудь ссылается. Если мы можем обратиться к объекту через ссылку( она не равна nil) то он существует.
Т.е. вопрос можно ли обратиться к объект через какую нить ссылку решается проверкой не равна ли эта ссылка nil.
Если стоит вопрос сущеcтвеует ли объект вообще. То тут только глобальные флаги выставлять при его дестрое, по-моему.

> homm © (06.11.07 11:09) [73]

В том-то и дело, что имеет. Если посчет ссылок работает, то ЛЮБОЙ вызов Free - это не уничтожение объекта, а всего лишь ЗАПРОС на его уничтожение. И этот запрос не дает никаких гарантий, что объект действительно будет уничтожен именно сейчас, а не через полчаса, другим запросом.

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

И Ваши что первый, что второй вариант на этот вопрос тоже не отвечают. Потому что ни FRef=nil, ни SC=TRUE не дают никаких гарантий. Эти условия лишь говорят о том, что метод Free был вызван, и все. А был ли объект при этом уничтожен, или нет (потому что где-то на него висят другие ссылки) - на ЭТОТ вопрос ответа нет.

И быть не может, понимаете?

> [76] Юрий Зотов © (06.11.07 11:21)
> И Ваши что первый, что второй вариант на этот вопрос тоже
> не отвечают. Потому что ни FRef=nil, ни SC=TRUE не дают
> никаких гарантий. Эти условия лишь говорят о том, что метод
> Free был вызван, и все. А был ли объект при этом уничтожен,
> или нет (потому что где-то на него висят другие ссылки)
> - на ЭТОТ вопрос ответа нет.

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

> [75] vpbar © (06.11.07 11:19)
> Вообще то имеет.

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

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

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

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