Мастера 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

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

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

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

Семеныч (2008-03-25 12:38:00) [21]
> Reindeer Moss Eater © (25.03.08 11:57) [55]

> ГДЕ Вы увидели дорогую цену?

В стрельбе ракетой по воробьям - раз. В необходимости переписывать весь код (притом, принципиально) - два.

> Вы переписываете все

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

А вот Вы переписываете действительно все, притом принципиально. А потом все это еще и отлаживаете.

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

Блин. Ну когда Вы уже читатьначнете? См. [41]: "Еще (не написав ни одной строчки!), получили возможность использовать готовый список со всеми его методами... ".

> Поиск будет представлять все ту же итерацию по списку.

Как Вы считаете - а какой алгоритм используется в DOM при поиске по XPath?
:о)

> Если поменяется структура объекта вы перепишете алгоритм поиска.

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

> А я перепишу всего лишь литерал для xpath.

Вот это точно. При любом изменении структуры объекта Вы будете вынуждены в обязательном порядке и каждый раз переписывать XPath (с риском внести ошибку). "Всего лишь".

> Я тоже переписываю все

Это точно. Притом, с нуля и принципиально. Абсолютно новый код.

> но получаю кучу преимуществ.

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

Reindeer Moss Eater (2008-03-25 12:03:00) [22]
Вот еще из той же оперы:

xdoc.Load('c:\data.xml');
xdoc.Load(' http://server.domain.com/data.xml');
xdoc.Load('res://c:\mydll.dll/myxmlresource');

Удобно? Кто скажет нет, пусть бросит в меня камень.
:)

Reindeer Moss Eater (2008-03-25 11:57:00) [23]
ГДЕ Вы увидели дорогую цену?

Вы переписываете все и ничего кроме освобождения памяти автоматом не получаете. Поиск будет представлять все ту же итерацию по списку.
Если поменяется структура объекта вы перепишете алгоритм поиска.
А я перепишу всего лишь литерал для xpath.
Я тоже переписываю все, но получаю кучу преимуществ.

Вот это я и называю ценой.

Семеныч (2008-03-25 11:56:00) [24]
> Reindeer Moss Eater © (25.03.08 11:52) [53]

А не слишком дорогая цена?
© Reindeer Moss Eater

:o)

Reindeer Moss Eater (2008-03-25 11:52:00) [25]
Стрелять по воробъям гораздо проще и дешевле из рогатки, а не ракетой "земля -воздух".

Я стреляю и по воробьям и по мамонтам одной удобной многофункциональнойи не такой уж тяжелой рогаткой.

Reindeer Moss Eater (2008-03-25 11:50:00) [26]
Да понял я все. Не переживайте так.

Семеныч (2008-03-25 11:47:00) [27]
> Reindeer Moss Eater © (25.03.08 11:40) [50]

> TStream + TReader + TWriter

Блин. Извините, я для кого пишу? Вы [46] читали? Вдумчиво?

> пока не распробовал xml и не проникся.
> После чего благополучно забыл навсегда все эти танцы

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

Reindeer Moss Eater (2008-03-25 11:40:00) [28]
В общем скажу так. Я тоже раньше перся от подобных вещей, а так же от TStream + TReader + TWriter пока не распробовал xml и не проникся. После чего благополучно забыл навсегда все эти танцы, как страшный сон.

Семеныч (2008-03-25 11:37:00) [29]
> Reindeer Moss Eater © (25.03.08 11:30) [47]

> а не слишком дорогая цена

ГДЕ Вы увидели дорогую цену? Это как раз при переписке под XML цена будет не просто дорогая, а супердорогая. А переписка с рекордов (которые УЖЕ юзаются) на объекты - это как раз переделки самые минимальные из всех возможных. ГДЕ Вы увидели дорогую цену?

> за нехотение вызывать диспоуз?

Блин. Извините, я для кого пишу? Вы [41] читали? Вдумчиво?

Семеныч (2008-03-25 11:32:00) [30]
> нужно прописать первые 4 байта

Кстати, а можно и не прописывать - если писать в файл не весь объект, а начиная со смещения +4 (и соответственно читать).

Reindeer Moss Eater (2008-03-25 11:30:00) [31]
а не слишком дорогая цена за нехотение вызывать диспоуз?

Семеныч (2008-03-25 11:28:00) [32]
> Reindeer Moss Eater © (25.03.08 11:14) [44]

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

Нет, Вы все-таки не понимаете. Не нужно изобретать никакой своей сериализации. Не нужна никакая RTTI вообще. Кто мешает писать объект, используя BlockWrite?

Третий раз пишу (вдумайтесь уже, наконец-то) - раз человек сейчас УЖЕ использует типизированный файл рекордов, значит эти рекорды ЗАВЕДОМО не содержат никаких указателей. Тогда, переделав рекорд в объект, мы и этот объект можем писать ТАК ЖЕ, как до этого писали record (BlockWrite + InstanceSize).

Вся разница состоит в одной простенькой дополнительной строчке: после чтения объекта из файла нужно прописать первые 4 байта в нем ссылкой на заведомо известный класс:
PPointer(Obj)^ := Pointer(TObjClass);

И все. И не нужны здесь никакие RTTI и никакие самопальные сериализации, понимаете? Весь фокус в том, что данные не содержат указателей.

DVM (2008-03-25 11:26:00) [33]
Все таки XML он предназначен больше для обмена данными, нежели их хранения. Хранение обладает кошмарной избыточностью - на 1 байт полезных данных 9 и более байт мусора всякого. Использовать XML в качестве базы данных нерационально.

Reindeer Moss Eater (2008-03-25 11:14:00) [34]
Кроме всего прочего, с объектами вы будете вынуждены перегружать их ненужной RTTI (паблишед свойства) либо все же придется изобретать свою сериализацию паблик свойств.

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

Ega23 (2008-03-25 11:06:00) [35]

> Кстати, а что мы поимеем после капитальной работы по переписыванию
> кода под xml по сравнению со списком record'ов или объектов?
>

Но преимущества-таки тоже есть:
1. читабельность (возможность подправить руками)
2. Уже упомянутый XPath

Семеныч (2008-03-25 10:58:00) [36]
> Reindeer Moss Eater © (25.03.08 08:52) [39]

> весь фукнкционал уже реализован добрым дядей в виде savetofile.

В случае record'ов или объектов весь функционал тоже уже реализован в виде Write или WriteBlock.

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

Кстати, а что мы поимеем после капитальной работы по переписыванию кода под xml по сравнению со списком record'ов или объектов?

а). Объем переписывания - гораздо больше (соответственно, вероятность налепить ошибок и длительность отладки тоже будут гораздо больше).
б). Функциональные преимущества - никаких.
в). Функциональные недостатки - тормоза.

Семеныч (2008-03-25 10:46:00) [37]
> Reindeer Moss Eater © (25.03.08 08:55) [40]

> все строковый поля в типе будут короткими строками.

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

> ничего, кроме возможности не делать Dispose.

Не только. Еще (не написав ни одной строчки!), получили возможность использовать готовый список со всеми его методами - добавить, вставить, удалить, найти, переместить, сортировать и т.п. В случае record'ов пришлось бы брать TList и допиливать все эти методы вручную, а так - все готовое. Для законченности осталось ввести в список 2 очень простых метода: SaveToFile и LoadFromFile (причем код в них практически такой же, как и при работе с reacord'ами - то есть, лишнего кодирования опять нет).

> что мы дополнительно получили от переписывния кода?

Во-первых, переписывание минимально, а объем кодирования даже меньше, чем при использовании record'ов (за счет готового списка). Во-вторых, раз автор хочет удобства, то избежать переписывания совсем, естественно, не получится (и вот тут оно как раз минимальное). В третьих, дополнительно мы получили то самое удобство работы со списком, которого и хотелось.

Reindeer Moss Eater (2008-03-25 08:55:00) [38]
Это невозможно по определению. См. [18]. Все то же самое, что и с рекордами - там могут быть только ShortString. Иначе типизированный файл не катит.

А! Понял. то есть все строковый поля в типе будут короткими строками.

Итого:
что мы дополнительно получили от переписывния кода? :
-ничего, кроме возможности не делать Dispose.

Reindeer Moss Eater (2008-03-25 08:52:00) [39]
тем-не-менее каким образом xml решает задачу удаления нода из середины файла без открытия файла целиком? :)

не решает. я говорил.
только весь фукнкционал уже реализован добрым дядей в виде savetofile.
примерно то же самое имеем при обжектлисте, но там поиск никакой, а в xml нам дан xpath. если же рекорды просто заменять сериализованными объектами, то вообще приплыли. перезапись нужно изобретать самому (это про воздух).

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

имеем:

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

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

Reindeer Moss Eater (2008-03-25 08:44:00) [40]
Свободная беспроблемная версионность формата. Вот что даст xml по сравнению с сериализцией объектов и типизированными файлами.
+ остальные преимущества описанные выше.

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

Наверх

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