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

← →
art36 © (2008-03-24 18:42) [0]

Есть неудобный способ хранить записи в типизированном файле:

var
F:file of Tmytype
a: Tmytype

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

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

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

← →
Reindeer Moss Eater © (2008-03-24 18:44) [1]

xml

← →
art36 © (2008-03-24 18:45) [2]

> xml

Как?

← →
Reindeer Moss Eater © (2008-03-24 18:46) [3]

Как?
Очень легко и даже приятно.

← →
art36 © (2008-03-24 18:47) [4]

> Очень легко и даже приятно.

(( я понятия не имею как им пользоваться

← →
Reindeer Moss Eater © (2008-03-24 18:50) [5]

ну тогда оставайся на типизированных файлах.

← →
art36 © (2008-03-24 18:55) [6]

> ну тогда оставайся на типизированных файлах.

ну уж нет... у него избыточный код, есть что-нибудь еще?

← →
Семеныч (2008-03-24 19:10) [7]

Зависит от того, что Вы называете удобным и неудобным. Например, вместо записей можно использовать объекты, а файл читать в их список (потомок TObjectList) и писать из этого же списка. Тогда весь вопрос сводится к написанию 2-х простых методов списка - чтение и запись файла (формат файла: перваые 4 байта - количество элементов, далее сами элементы).

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

← →
Reindeer Moss Eater © (2008-03-24 19:14) [8]

Поиск нужного объекта в таком файле будет особенно удобен.

← →
Семеныч (2008-03-24 19:18) [9]

> Reindeer Moss Eater © (24.03.08 19:14) [8]

На всякий случай: в файлах объекты не ищут. В файлах вообще ничего не ищут. Файлы читают и пишут, а ищут - в памяти.

И при этом без разницы, что содержит файл - объекты, записи, просто числа или что угодно еще.

← →
Reindeer Moss Eater © (2008-03-24 19:20) [10]

да да конечно. и не ищут в файлах ничего и никогда.

← →
Kolan © (2008-03-24 19:22) [11]

Прочитай про сериализацию, используй объекты и сериализуй их стандартными методами&#133

← →
Reindeer Moss Eater © (2008-03-24 19:23) [12]

Будет та же хрень что и с типизированными файлами.
С точностью до миллиметра.

← →
Kolan © (2008-03-24 19:23) [13]

Кстати, а как на счет БД?

← →
Reindeer Moss Eater © (2008-03-24 19:26) [14]

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

← →
Johnmen © (2008-03-24 19:27) [15]

Да простой ClientDataSet.

← →
Семеныч (2008-03-24 19:27) [16]

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

Можете привести пример поиска в файле?

Если можете - приведите. А я Вам тут же докажу, что это поиск НЕ в файле, а в памяти.

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

← →
Reindeer Moss Eater © (2008-03-24 19:29) [17]

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

← →
Семеныч (2008-03-24 19:31) [18]

> Reindeer Moss Eater © (24.03.08 19:26) [14]

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

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

LOL?

← →
Семеныч (2008-03-24 19:33) [19]

> Reindeer Moss Eater © (24.03.08 19:29) [17]

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

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

← →
Reindeer Moss Eater © (2008-03-24 20:23) [20]

Ну поехали.

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

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

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

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

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

← →
Reindeer Moss Eater © (2008-03-24 20:34) [21]

В случае же обжектлиста появится необходимость считывать весь файл целиком в память. В случае xml дело конечно обстоит примерно так же, но:

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

← →
Reindeer Moss Eater © (2008-03-24 20:42) [22]

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

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

← →
art36 © (2008-03-24 21:28) [23]

Да, кстати.. вся проблема, в основном, при удалении элемента из типизированного файла.. приходится писать в другой файл, а потом копировать его с заменой предыдущего... флеш накопитель не взорвется?? ))

← →
Anatoly Podgoretsky © (2008-03-24 21:34) [24]

> art36 (24.03.2008 21:28:23) [23]

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

← →
DVM © (2008-03-24 21:44) [25]

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

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

← →
Семеныч (2008-03-24 22:40) [26]

> 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 и будем избавлены от необходимости освобождения памяти при удалении элементов списка (как это было бы с рекордами).

← →
art36 © (2008-03-24 22:43) [27]

Нужно заюзать! Благодарю за активность!

← →
Reindeer Moss Eater © (2008-03-24 22:45) [28]

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

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

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

← →
Reindeer Moss Eater © (2008-03-24 22:56) [29]

Нужно заюзать! Благодарю за активность!

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

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

← →
Семеныч (2008-03-25 00:44) [30]

> Reindeer Moss Eater © (24.03.08 22:45) [28]

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

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

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

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

← →
art36 © (2008-03-25 00:50) [31]

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

Да, конечно)

← →
Семеныч (2008-03-25 00:52) [32]

> art36 © (24.03.08 22:43) [27]

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

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

← →
Германн © (2008-03-25 00:55) [33]

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

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

← →
Семеныч (2008-03-25 00:57) [34]

> Reindeer Moss Eater © (24.03.08 22:56) [29]

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

← →
Семеныч (2008-03-25 01:01) [35]

> Германн © (25.03.08 00:55) [33]

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

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

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

← →
Германн © (2008-03-25 01:21) [36]

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

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

← →
Ega23 © (2008-03-25 06:46) [37]

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

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

← →
Reindeer Moss Eater © (2008-03-25 08:44) [38]

Свободная беспроблемная версионность формата. Вот что даст xml по сравнению с сериализцией объектов и типизированными файлами.
+ остальные преимущества описанные выше.

← →
Reindeer Moss Eater © (2008-03-25 08:52) [39]

тем-не-менее каким образом xml решает задачу удаления нода из середины файла без открытия файла целиком? :)

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

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

имеем:

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

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

← →
Reindeer Moss Eater © (2008-03-25 08:55) [40]

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

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

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

← →
Семеныч (2008-03-25 10:46) [41]

> Reindeer Moss Eater © (25.03.08 08:55) [40]

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

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

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

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

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

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

← →
Семеныч (2008-03-25 10:58) [42]

> Reindeer Moss Eater © (25.03.08 08:52) [39]

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

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

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

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

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

← →
Ega23 © (2008-03-25 11:06) [43]

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

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

← →
Reindeer Moss Eater © (2008-03-25 11:14) [44]

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

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

← →
DVM © (2008-03-25 11:26) [45]

Все таки XML он предназначен больше для обмена данными, нежели их хранения. Хранение обладает кошмарной избыточностью - на 1 байт полезных данных 9 и более байт мусора всякого. Использовать XML в качестве базы данных нерационально.

← →
Семеныч (2008-03-25 11:28) [46]

> Reindeer Moss Eater © (25.03.08 11:14) [44]

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

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

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

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

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

← →
Reindeer Moss Eater © (2008-03-25 11:30) [47]

а не слишком дорогая цена за нехотение вызывать диспоуз?

← →
Семеныч (2008-03-25 11:32) [48]

> нужно прописать первые 4 байта

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

← →
Семеныч (2008-03-25 11:37) [49]

> Reindeer Moss Eater © (25.03.08 11:30) [47]

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

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

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

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

← →
Reindeer Moss Eater © (2008-03-25 11:40) [50]

В общем скажу так. Я тоже раньше перся от подобных вещей, а так же от TStream + TReader + TWriter пока не распробовал xml и не проникся. После чего благополучно забыл навсегда все эти танцы, как страшный сон.

← →
Семеныч (2008-03-25 11:47) [51]

> Reindeer Moss Eater © (25.03.08 11:40) [50]

> TStream + TReader + TWriter

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

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

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

← →
Reindeer Moss Eater © (2008-03-25 11:50) [52]

Да понял я все. Не переживайте так.

← →
Reindeer Moss Eater © (2008-03-25 11:52) [53]

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

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

← →
Семеныч (2008-03-25 11:56) [54]

> Reindeer Moss Eater © (25.03.08 11:52) [53]

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

:o)

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

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

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

Вот еще из той же оперы:

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

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

← →
Семеныч (2008-03-25 12:38) [57]

> Reindeer Moss Eater © (25.03.08 11:57) [55]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

← →
Семеныч (2008-03-25 12:42) [58]

> Reindeer Moss Eater © (25.03.08 12:03) [56]

> Удобно?

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

Ой да ладно.
Мне по барабану какой алгоритм поиска использует оракл. И в этом кайф.
Я лишь пишу запрос.
То же самое происходит в случае XPath.
Переписывать в моем случае надо не больше чем в вашем случае.
То что используемый мной механизм является ракетой, не повышает стоимость её использования для меня.
Для меня все удешевляется и унифицируется.
Никаких проблем при изменении структуры xpath вообще не вносит.
Старый код читает старые данные и не портит новые.
Новый код читает старые данные и не портит старые.

Если оно не нужно - то и нафиг сдалось.

Все верно.
А если нужно, то у меня уже все есть, а вы прикручиваете новый код к своим классам.

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

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

Ага?

> [61] Reindeer Moss Eater © (25.03.08 12:51)

а ты думал, зря в апишных структурах столько Reserved1, Reserved2.. ? o)

а ты думал, зря в апишных структурах столько Reserved1, Reserved2.. ? o)

Ну тут вообще без проблем.
Побольше свойств - shortstring с именами reserved и золотой ключик у них в кармане;

:)

← →
Семеныч (2008-03-25 16:59) [64]

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

Это - логика.

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

Что ж, это их право. Но это - не логика. Это - религия. Вера.

Логика перед верой бессильна. Поэтому - let it be.

стоимость вертолета в моем случае - добавить в юзез
msxml2_tlb.pas

← →
Семеныч (2008-03-25 17:41) [66]

Самолет - хорошо.
Вертолет - хорошо.
А олени- лучше!

:)

Между тем единственное дельное замечание по теме [25] все дружно проигнорировали.

Кстати, xml в плане "скорострельности" и "экономичности" - полное дерьмо

шортстринги офигенно экономичны.

и куча экземпляров класса в обжектлисте это тоже образец экономичности.

>MsGuns © (25.03.08 21:05) [68]
>Между тем единственное дельное замечание по теме [25] все дружно проигнорировали.

Пардон, [15] конечно

Между тем единственное дельное замечание по теме [25] все дружно проигнорировали.

Кстати, xml в плане "скорострельности" и "экономичности" - полное дерьмо

Кстати, единственное дельное замечание само активно использует "полное дерьмо"

← →
Семеныч (2008-03-25 22:35) [73]

> Reindeer Moss Eater © (25.03.08 21:59) [70]

Согласен. Дерево элементов DOM, безусловно, намного экономичнее. А метровая DLL - так это и вовсе пустяк.

LOL

эта метровая длл по жизни в винде есть.
/* кому сегодня сдалась вообще эта пресловутая экономичность? кроме разумеется действительно важной экономии времени */

ps лол без причины признак ....

сначала ради сомнительных выгод извращаются над объектами, ограничивась полями из shortstring, потом загоняют всех их в обжект лист, после чего, поняв, что xml-то реально облегчает жизнь девелопера, тыкают в меня последней соломинкой "неэкономичности" DOM.
пипец просто.

← →
Семеныч (2008-03-25 22:53) [76]

> пипец просто.

Снова согласен. Снова LOL.

sqlite

Что использовать вместо RECORD? Найти похожие ветки