Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Что использовать вместо RECORD?

Страницы: < 1 2 3 4 >
art36 © (2008-03-24 18:42:00)
Есть неудобный способ хранить записи в типизированном файле:

var
F:file of Tmytype
a: Tmytype

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

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

Если есть ссылку в инете дайте, пожалста!

Ega23 (2008-03-25 06:46:00) [41]

> Reindeer Moss Eater © (24.03.08 22:56) [29]
>
> Нужно заюзать! Благодарю за активность!
>
> осваивай xml. в жизни пригодится.
> а то будешь для каждой задачи изобретать свой велосипед
> на базе обжектлиста, для каждого велосипеда придумывать
> свой насос, а для каждого насоса свой воздух.
>
> ...и так всю жизнь.

Про велосипед и воздух - поржал, спасибо.
Про xml: хоть и не имею ничего против, тем-не-менее каким образом xml решает задачу удаления нода из середины файла без открытия файла целиком? :)

Германн (2008-03-25 01:21:00) [42]

> Семеныч (25.03.08 01:01) [35]

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

Семеныч (2008-03-25 01:01:00) [43]
> Германн © (25.03.08 00:55) [33]

> А то может холивар раздутый в сей ветке вообще бессмысленный?

Стопудово. Я бы взял рекорд и за час написал класс-список таких рекордов, а в этот класс ввел все нужные мне методы. После чего все вопросы с удобством отпадают сами собой.

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

Семеныч (2008-03-25 00:57:00) [44]
> Reindeer Moss Eater © (24.03.08 22:56) [29]

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

Германн (2008-03-25 00:55:00) [45]

> art36 © (25.03.08 00:50) [31]
>
>

Кстати. А вот интересно было бы привести пример записи типа Tmytype. И конкретные примеры "неудобств" работы с типизированными файлами file of Tmytype. А то может холивар раздутый в сей ветке вообще бессмысленный?

Семеныч (2008-03-25 00:52:00) [46]
> art36 © (24.03.08 22:43) [27]

Если скорость неважна, то xml для этой задачи неплох. Правда, я не уверен, что xml позволит сделать изменение записи в файле или удаление записи из него более удобными, чем это было с Record - но тут, повторюсь, все зависит от того, что Вы понимаете под словом "удобно".

А если скорость важна, то однозначно нужно использовать прямую запись участка памяти и чтение в него же. С xml будет намного медленнее.

art36 (2008-03-25 00:50:00) [47]

> Reindeer Moss Eater © [29]
>
> осваивай xml. в жизни пригодится.
> а то будешь для каждой задачи изобретать свой велосипед на базе обджектлиста...

Да, конечно)

Семеныч (2008-03-25 00:44:00) [48]
> Reindeer Moss Eater © (24.03.08 22:45) [28]

> чот я не понял.
Угу.

> был экземпляр объекта с полем-строкой длиной 100 символов.
ОК, был.

> считали его из файла, заменили значение в поле на строку длиной 200
> символов.
Это невозможно по определению. См. [18]. Все то же самое, что и с рекордами - там могут быть только ShortString. Иначе типизированный файл не катит.

> и после сериализации экземпляр занимает ровно столько же места на
> устройстве хранения?
Угу, ровно столько же. И в памяти, и на устройстве хранения.

Reindeer Moss Eater (2008-03-24 22:56:00) [49]
Нужно заюзать! Благодарю за активность!

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

...и так всю жизнь.

Reindeer Moss Eater (2008-03-24 22:45:00) [50]
Не-а, снова фигушки. Считываем найденный (по предыдущей схеме) объект, делаем seek назад, записываем объект (InstanceSize). Все то же самое, что и с рекордом (если, конечно, не программировать "в лоб").

чот я не понял.
был экземпляр объекта с полем-строкой длиной 100 символов.
считали его из файла, заменили значение в поле на строку длиной 200 символов.

и после сериализации экземпляр занимает ровно столько же места на устройстве хранения?

art36 (2008-03-24 22:43:00) [51]
Нужно заюзать! Благодарю за активность!

Семеныч (2008-03-24 22:40:00) [52]
> Reindeer Moss Eater © (24.03.08 20:42) [22]

> А что, каждый инстанс после сериализации имеет один и тот же размер?

И до, и после - один и тот же. Размер инстанса с сериализацией вообще никак не связан. Это 4 байта плюс сумма размеров полей.

Поэтому: поехали, но несколько не так, как Вы полагаете:

> Reindeer Moss Eater © (24.03.08 20:23) [20]

> запись порции данных в типизированный файл: один вызов.
> запись сериализированного объекта в файл: один вызов.
> чтение аналогично.

Согласен.

> поиск записи по значению в поле (поиск объекта по значению
> поля/свойства):
> последовательно читаем и сравниваем. снова никаких преимуществ.

Согласен.

> позиционирование на запись с номером N:
> В случае типизированного файла: да
> В случае с объектами - в цикле делаем считывание N раз. Уже минус.

Если программировать "в лоб", используя "обычную" сериализацию - то да. А если объявить файл, как file of byte, то фигушки: Seek(N * InstanseSize) сразу позиционирует куда надо. И получаем то же самое, что и для рекорда.

> изменение найденного элемента:
> типизированный файл: считываем запись, меняем поля, делаем seek назад,
> записываем рекорд.
> объекты: снова облом. все что позади изменяемого объекта, необходимо
> считать и записать по новой после измененного объекта.

Не-а, снова фигушки. Считываем найденный (по предыдущей схеме) объект, делаем seek назад, записываем объект (InstanceSize). Все то же самое, что и с рекордом (если, конечно, не программировать "в лоб").

> Итого:
> Жить стало лучше?
> Нет, жить стало просто веселей.

Лучше. Например, потому что теперь мы можем использовать уже готовый ObjectList и будем избавлены от необходимости освобождения памяти при удалении элементов списка (как это было бы с рекордами).

DVM (2008-03-24 21:44:00) [53]

> art36 © (24.03.08 21:28) [23]
> Да, кстати.. вся проблема, в основном, при удалении элемента
> из типизированного файла..

Можно просто помечать элемент как удаленный.

Anatoly Podgoretsky (2008-03-24 21:34:00) [54]
> art36 (24.03.2008 21:28:23) [23]

Второй файл лишний.

art36 (2008-03-24 21:28:00) [55]
Да, кстати.. вся проблема, в основном, при удалении элемента из типизированного файла.. приходится писать в другой файл, а потом копировать его с заменой предыдущего... флеш накопитель не взорвется?? ))

Reindeer Moss Eater (2008-03-24 20:42:00) [56]
Если раньше было достаточно переписать кусок размером SizeOf(рекорд), то это означает, что указателей пресловутый рекорд не содержит - и тогда с переходом на объекты будет достаточно переписать кусок размером InstanceSize.

А что, каждый инстанс после сериализации имеет один и тот же размер?

Reindeer Moss Eater (2008-03-24 20:34:00) [57]
В случае же обжектлиста появится необходимость считывать весь файл целиком в память. В случае xml дело конечно обстоит примерно так же, но:

- имеем sql-подобный механизм поиска
- не имеем гемора с верисонностью структуры.
- имеем простую возможность визуализации данных в различных форматах (html,txt,rtf etc)
... и так далее

Reindeer Moss Eater (2008-03-24 20:23:00) [58]
Ну поехали.

запись порции данных в типизированный файл: один вызов.
запись сериализированного объекта в файл: один вызов.
чтение аналогично.

поиск записи по значению в поле (поиск объекта по значению поля/свойства):
последовательно читаем и сравниваем. снова никаких преимуществ.

позиционирование на запись с номером N:
В случае типизированного файла: да
В случае с объектами - в цикле делаем считывание N раз. Уже минус.

изменение найденного элемента:
типизированный файл:
считываем запись, меняем поля, делаем seek назад, записываем рекорд.
объекты:
снова облом. все что позади изменяемого объекта, необходимо считать и записать по новой после измененного объекта.

Итого:
Жить стало лучше?
Нет, жить стало просто веселей.

Семеныч (2008-03-24 19:33:00) [59]
> Reindeer Moss Eater © (24.03.08 19:29) [17]

> Семеныч, вы предлагаете заменить шило на мыло. Причем с гребанием
> новых граблей.

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

Семеныч (2008-03-24 19:31:00) [60]
> Reindeer Moss Eater © (24.03.08 19:26) [14]

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

Если раньше было достаточно переписать кусок размером SizeOf(рекорд), то это означает, что указателей пресловутый рекорд не содержит - и тогда с переходом на объекты будет достаточно переписать кусок размером InstanceSize.

LOL?

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »