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

[MaTBeu]

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

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

Ну тогда мы все умрем.

Ей богу, если вырубать нельзя - писать не на С++, а на Perl, Ruby, Groovy и других скриптовых интерпретируемых языках. В любом случае изврат с компиляциями - это лишнее. Никто вам за такую работу не заплатит. Ни одному заказчику не нужны тонны кода, который реализует минимум функционала.
В Ruby и Groovy есть охренительная база для метапрограммирования. Там и обращение к полям/методам объекта по имени в качестве строки, и безопасный вызов метода. Проверка наличия метода у объекта и прочий синтаксический и семантический сахар.

Вы стремитесь сделать из С++ кашу, намешав туда кучу всяких фич, которые есть в других языках. Динамика и метапрограммирование, так же как и полноценное ООП - это не про С++.

[spamer]

так же как и полноценное ООП - это не про С++

Во, а можно насчет этого немного конкретнее? Сколько читал учебников, везде пишут С++ это объектно-ориентированный язык программирования (оно то так и есть)...только теперь интересно, а что в нем такого неполноценного?

[MaTBeu]

Как пример - Мультиметоды. Их нет в С++. Можно извратиться - получим схему с двойной диспетчеризацией. Если интересно - почитайте Александреску.

А вообще - Википедия вам в руки, там все про это написано. http://ru.wikipedia.org/wiki/Сравнен...ограммирования

[Utkin]

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

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

Не вижу в этом никаких проблем

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

Совсем не обязательно новая, а условная. То есть в зависимости от условий Вам может потребоваться одна структура, а может и другая. И потом это просто экономия. Вот тот же пример с генеалогическим деревом - поля в структурах обычно требуют места независимо от того нужны ли они или нет. В нашем случае, если дата смерти неизвестна (например тип еще жив), то и поле под него необязательно. В тоже время само генеалогическое дерево не настолько уж востребованная к скорости структура. Если же я хочу работать с новым полем, то добавляю его тогда, когда уже действительно пойдет работа с ним. А зачем оно статически, если даже неизвестно будет ли им кто-нибудь пользоваться? Если хотите, то упрощенным аналогом является динамический массив - он содержит лишь те элементы, которые программист посчитает нужным, причем возникают случаи когда число элементов в разное время будет различным. Аналогичная ситуация и с полями этой структуры.

[MaTBeu]

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

Совсем не обязательно новая, а условная. То есть в зависимости от условий Вам может потребоваться одна структура, а может и другая. И потом это просто экономия. Вот тот же пример с генеалогическим деревом - поля в структурах обычно требуют места независимо от того нужны ли они или нет. В нашем случае, если дата смерти неизвестна (например тип еще жив), то и поле под него необязательно. В тоже время само генеалогическое дерево не настолько уж востребованная к скорости структура. Если же я хочу работать с новым полем, то добавляю его тогда, когда уже действительно пойдет работа с ним. А зачем оно статически, если даже неизвестно будет ли им кто-нибудь пользоваться? Если хотите, то упрощенным аналогом является динамический массив - он содержит лишь те элементы, которые программист посчитает нужным, причем возникают случаи когда число элементов в разное время будет различным. Аналогичная ситуация и с полями этой структуры.

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

2TC
Хотя можно сделать полем класса stl-евский map или multimap - и добавлять к нему записи. Однако обращение будет доступно только через специальную функцию. Реализация кривая - но вам я думаю подойдет. Если у вас такое непреодолимое желание использовать С++, вместо языков, которые к этому приспособлены - дерзайте.

[Utkin]

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

Дело в том, что нельзя динамически добавлять поля к структуре на этапе выполнения.

Почему? Что в этом плохого? Единственная загвоздка все это правильно организовать. Приведите мне способ использования полиморфизма как аналога такого сякого, какого я хочу . Просто не совсем пойму как это сделать красиво.

[Smitt&Wesson]

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

Ага, может еще расстояние до звезд миллиметрами мерять?

Кстати, как ни странно, меряют. Расстояние до Солнца (звезда) измеряется именно в миллиметрах !
А насчёт твоего "почему" - язык С объектноориентированный. Незачем в сам язык вводить конструкции, которые могут никогда и никому не понадобиться. Для этого есть библиотеки и классы. Вытворяй с ними чё хочешь. Хочешь Лисп - на тебе библиотеку лисп. Хочешь Пролог - на тебе пролог!

[Utkin]

Сообщение от Smitt&Wesson

А насчёт твоего "почему" - язык С объектноориентированный.

Разве не с++? Пусть объектный, но это вроде вполне укладывается в рамки объектов. Все является объектом. Числа, переменные, объекты и т.д. Следовательно структура данных тоже объект. А следовательно никаких коллизий/препятствий не возникает. Далее у с++ есть серьезные проблемы при взаимодействии указателей и объектов - есть возможность перешагнуть через область видимости и получить данные конкретного объекта. Это вроде как считается нормой.

Незачем в сам язык вводить конструкции, которые могут никогда и никому не понадобиться.

Так можно сказать про любое средство. Я вот в Дельфи указателями не пользуюсь, так для чего они туда были включены? Исключить их оттуда немедленно. А не пользуются такими конструкциями, потому что их там нет. Вот в Лиспе есть пары, парами там и пользуются и это несмотря на наличие и других типов. Просто отмазка.

Для этого есть библиотеки и классы. Вытворяй с ними чё хочешь. Хочешь Лисп - на тебе библиотеку лисп. Хочешь Пролог - на тебе пролог!

Это и так ясно, но я имел ввиду почему?

[pu4koff]

1. Основная идея С++ - основную работу делать на этапе компиляции. Именно поэтому там шаблоны, а не Generic классы. С динамическими методами на этапе компиляции ничего не сделаешь, а, соответственно, это нарушает принципы языка.
2. Будет проблема с сохранением объектов таких классов в файл. Одним куском уже не запишешь. В файл нужно записывать какие члены есть, каких нет,... Куча проблем.
Если всё это сделать в плюсах, то получится полускриптовый язык с совершенно другой идеологией, т.е. это уже будет не С++.

[Utkin]

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

1. Основная идея С++ - основную работу делать на этапе компиляции. Именно поэтому там шаблоны, а не Generic классы. С динамическими методами на этапе компиляции ничего не сделаешь, а, соответственно, это нарушает принципы языка.

Ок, это понял.

2. Будет проблема с сохранением объектов таких классов в файл. Одним куском уже не запишешь. В файл нужно записывать какие члены есть, каких нет,... Куча проблем.

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

Если всё это сделать в плюсах, то получится полускриптовый язык с совершенно другой идеологией, т.е. это уже будет не С++.

Ну не знаю, а препроцессор чем занимается? А макросы? Он же и так по сути полускриптовый...