Единый способ организации данных в программе

[Stilet]

А сейчас С (точнее его потомки) сколько весит?

Дружище, я имел ввиду Классический Си, тот который еще в ДОСе рулил миром.
Тот что сейчас микрососы выпхнули вообще сложно измерить, ибо к нему же нужно еще Runtime Library. вон msvcrt хотябы. Сами программы нативные на VS небольшие, но они то еще и библиотеки VC требуют. Или я не прав?

[MaTBeu]

Сообщение от Utkin

И тут вспоминаешь, едрены пассатижи! Я же дату рождения забыл! Да не вопрос, вставил команду - она добавила в твою структуру еще одно поле на этапе работы проги.

C/C++/Delphi не поддерживает динамическое добавление полей к структурам и классам. Вы можете подменять объекты посредством полиморфизма, но добавлять на этапе выполнения ничего нельзя.
Можно извратиться и сделать так, чтобы ваша программа генерировала новый код, компилировала его, собирала в dll(допустим), а потом его использовала. Но согласитесь - это ядреный отстой. Ни одна задача не стоит таких сложных схем.

Если хотите больше таких вещей - прямая вам дорога в objective-c. Там с этим попроще.

[Utkin]

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

[Stilet]

Ведь перспективно.

Так же как и обращение к полям обьекта по имени в качестве строки. т.е. имя хранится в Экзешнике. типа RTTI

[Alex Cones]

Delphi не поддерживает динамическое добавление полей к структурам и классам

А если делать поля не полями, а объектами в "списке" или массиве?

[Utkin]

Сообщение от Alex Cones

А если делать поля не полями, а объектами в "списке" или массиве?

Это понятно. Есть такой пассажир - TList. Но он свои ссылки не отслеживает. То есть если объекта не будет, TList, все равно будет на него ссылаться. А это не по-фэнь-шую.

[Alex Cones]

TList (HIGH OBJECT [CORE])
|
+-TList (LOW OBJECT [FIELD])
|  |
|  +- ПОЛЕ 
|  |
|  +- ПОЛЕ
|
+-TList (LOW OBJECT [FIELD])
|  |
|  +- ПОЛЕ 
|  |
|  +- ПОЛЕ
|
+-TList (LOW OBJECT [FIELD])
   |
   +- ПОЛЕ 
   |
   +- ПОЛЕ

Что-то вроде этого?

[evg_m]

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

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

новая функция -> новый код -> новая компиляция (Delphi не является интерпретатором) -> можно обойтись и статикой.

[Levsha100]

новая функция -> новый код -> новая компиляция (Delphi не является интерпретатором) -> можно обойтись и статикой.

Ну, а если вырубать систему нельзя?

[Vikenty]

Сообщение от Utkin

Их много, понятно для скорости. Но вот почему в С/С++ или Дельфи нет универсального способа организации, с помощью которого можно написать все что хочешь. Например, Лисповые списки или пары. Легко превращаются в массивы, деревья и всю прочую мутотень на которую только у программиста хватает его воспаленного воображения. Да, конечно обычный массив будет быстрей, но из массива во время работы программы сделать бинарное дерево, а потом обратно массив в ходе работы совсем не так просто как хотелось бы. Я бы даже сказал геморройно. Почему ? Возможно тому есть хоть какое-то внятное объяснение?

Разные языки по разному сделаны