Установка размера динамического

[Ins]

чего у меня, к счастью, не произойдёт

Похвальная самоуверенность. Я бы даже готов был с тобой поспорить, ну да не мне это нужно. Ты подложил себе бомбу замедленного действия И она рано или поздно рванет. Мое дело только предупредить

[Selestis]

Это не самоуверенность, а вытекающее из организации процесса правило: имеющиеся объекты-хранилища не будут получать никаких дополнительных свойств, пока они не понадобятся, а когда они понадобятся, они так же обязаны появиться и в файлах настроек (чего ради собсно и делалось изменение структуры класса), это не должна быть такая уж архи-универсальная вещь и используется далеко не для всего что у меня в программе...
А всё-таки насчет массивов, так просто не отделаться?) Впрочем, при желании всё необходимое с ними я сумею запихнуть в типизированные массивы классов с потомками, просто хотелось бы окончательно узнать..

[Ins]

Попробуй к любому типу динмассива привести для передачи в SetLength, т.к. есть подозрение (проверить пока негде) что SetLength все равно опирается на внутренние записи динмассива, а не на то, переменную какого типа ей передали. Это был плохой совет, который ты сам попросил. Хороший совет - это пересмотри модель, у тебя типичный быдлокод

[Selestis]

Ну, спасибо за совет, но пожалуй я всё-таки сделаю по-своему. Хотя не вижу никакого "быдлокода" в том, чтобы использовать достаточные простые вещи взамен многофункционального, но избыточного и, к слову, не сильно простого в описании(смотрел примеры к статье) RTTI...
В любом случае спасибо за помощь, всем плюсую.

[Ins]

Объясняю в чем быдлокод... Это простые вещи, которые не все понимают, но с опытом все приходит. Простой принцип черного ящика. Клиентский код (использующий возможности какого-либо класса) НЕ ДОЛЖЕН опираться на аспекты его реализации, а должен опираться только на открытый (документированный, если угодно) интерфейс. Реализация может меняться со временем в зависимости от различных обстоятельств - что-то нужно модернизировать, добавить, убрать, оптимизировать. Все это НЕ ДОЛЖНО приводить к неработоспособности и необходимости изменять клиентский код. Придерживаясь этого принципа, однажды написанный клиентский код будет работать что бы ты там не намудрил в реализации. Если же этого принципа не придерживаться, ты постоянно должен будешь в уме держать аспекты реализации, помнить их при написании кода. Мало того что придется заниматься распределенной модернизацией (поменяли тут - вынуждены менять и там), так еще и стоит на секунду забыть - придется проводить кучу времени в отладке. Вот и все - проще некуда, просто перед тем как писать код, нужно его продумать с точки зрения инкапсуляции - разделения интерфейса и реализации

[Selestis]

В том-то и дело, что у меня интерфейс и реализация достаточно сильно разделены, но если вдруг придёт в голову новая мысль по улучшению, разве даже с RTTI не придётся менять поля классов и переделывать реализацию? Только загрузка/сохранение останется неизменным, ибо оно забито в интерфейс. Но чем это отличается от моего способа, кроме того, что я просто в рдном файле допишу строчку сродни добавленному свойству класса?

[Ins]

Не разделены. Если код завязан на порядке следования полей, их размере и смещении, то код 100% завязан на реализации. Соответственно на эту реализацию нельзя даже дышать! Принесут мне такой код на ревью - сразу в корзину даже не вникая в суть. RTTI - это не панацея, это просто один из способой отвязаться от реализации. Заключается этот способ в том, что ты не закладываешь в клиентский код жестко последовательность, размер, наличие параметров, ты закладывашь в код возможность ему самому определить это, а значит - он будет работать что бы ни случилось. Я уже сказал в чем отличие - тебе не нужно ПОМНИТЬ о твоих аспектах реализации, а значит - не нужно применять метод стрельбы дробью при модернизации (термин по Фаулеру) и в случае если забудешь - ловить баги. Это сегодня тебе кажется что нужно не забыть дописать одну строчку. Чуть позже тебе нужно будет круто перелопачивать весь код. Говорю, это бомба замедленного действия, пока не рванет - можно и не знать об опасности

Что будет, если я:
1. Поменяю поля местами?
2. Добавлю новое поле, что приведет к изменению адресов других полей (да-да, даже если добавлю в конец, к полям же применяются правила выравнивания, а изменение размеров экземпляр может на выравнивание повлиять)
3. Захочу реализовать в классе интерфейс? Ведь интерфейсные VMT тоже хранятся в объекте и сместят все поля

[Selestis]

Всё-таки я не совсем вас понимаю. Вот смотрите, вы говорите, что

Если код завязан на порядке следования полей, их размере и смещении, то код 100% завязан на реализации.

Как сказать... Безусловно, в какой-то мере это так, но реализация загрузки (что, собственно говоря, - единственное, что от всей моей системы требуется) отделена от реализации основных задач.
Рассмотрим пример с добавлением нового поля:
- добавляем поле в код класса (присутствует в обоих подходах)
- добавляем описание поля с файл структуры (только в моем подходе. не так уж и тружно)
- делаем реализацию процесса, использующего данное поле класса, не зависящую от вышеописанной загрузки.
Если разница только в том, чтобы не забыть 2-й пункт, то не совсем понятны преимущества... Конечно, в больших проектах, скажем библиотеках для других программистов, это полезно, ибо им не приходится париться, но я-то пишу для себя и не волнуюсь о ком-либо, кто будет в моих данных копаться(код-то другим недоступен, значит, реализацию "новых" полей, добавленных в файлах, они всё равно ведь не сделают, у меня нет такой задачи).
Просто вы достаточно убежденно рассуждаете на тему, и хотелось всё-таки понять почему, но пока, увы, я не могу)

[Ins]

Я отредактировал пост выше, добавил пару вопросов. Попробуй на них ответить

PS: ко мне можно на "ты"

[Selestis]

Попытаюсь ответить:
1) Во-первых, смысл мне менять поля в моей собственной проге? Предположим, что я всё же задумал сие дело: тут тот самый минус - что то же самое придется делать в файле настройки. Но всё равно смысла в затее я что-то не вижу, хотя, как знать...
2) Хмм.. Хороший вопрос. Вообще-то, по правде говоря, я был уверен, что выравнивание компенсируется дельфой или чем-то ещё, я просто не смогу обратиться к адресу, отданному под выравнивание... Видимо я ошибался)
3) Никогда не работал с интерфейсами, поэтому единственное, что я могу сказать по этому пункту, это то, что такого я делать никак не планировал =)

P.S.
Сейчас пытаюсь проверить насчет выравнивания, получая адреса полей объекта... Что-то никак не могу поймать сей случай... Не трудно выложить примерчик с этим?
Мой код пока примерно таков:

type
TObj = class
   a,b,c: array[1..5] of byte;
   d: single;
   e,f: array[1..5] of byte;
end;

var Obj: TObj;

begin
Obj:=TObj.Create;
writeln('5 byte: ',cardinal(@Obj.a));
writeln('5 byte: ',cardinal(@Obj.b));
writeln('5 byte: ',cardinal(@Obj.c));
writeln('4 byte: ',cardinal(@Obj.d));
writeln('5 byte: ',cardinal(@Obj.e));
writeln('5 byte: ',cardinal(@Obj.f));
readln;
end.

Пока что всё совпадает...