UML-костыль, если уж начистоту.   

мне с моей низкой колокольни кажется, что шаблоны вполне подменяют метаклассы 

в любом случае это не то

  
почему бы не сделать в С++ полноценный RTTI с возможностью динамической загрузки и использования классов?
это же не трудно   
в итоге получили бы Spring для C++

Добавлено через 2 минуты и 49 секунд

это два ортогональных понятия

Это сообщение отредактировал(а) MAKCim - 4.6.2008, 12:32

как минимум - это два подхода к метапрограммированию. разве нет?

+1


Нет. Метаклассы дельфи к метапрограммированию не имеют отношения. Метапрограммирование - программирование на стадии компиляции, грубо говоря.

раз уж на то пошло, это создание программы, которая создает другие программы   

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


чем представим класс? идентификатором, методами и данными
остается эту информацию упорядочить и структурировать в бинарном формате скомпилированных классов
единственная сложность - это статические поля
в текущих версиях компиляторов С++ статические поля представлены глобальными переменными

Согласен. Метаклассы к этому не имеют отношение - это к RTTI.


По-моему, просто добавить информацию в type_info - это раз. И создать глобальный маппинг: "имя класса" -> type_info. Насчёт статических полей - не понял, в чём проблема?  Просто FieldInfo будет хранить для статических полей - адрес, для нестатических - оффсет. Но вообще для нормальной реализации всего этого, по-моему, необходимо взаимодействие с компилером  Нет, можно конечно генерить некую инфу о классе иными способами (moc? ) - но это всё-таки не то  

Любитель, 


смотри как я это вижу
есть класс

он компилируется в бинарное представление (описывает идентификатор, методы и данные)
для поддержки фабрики классов реализуется класс rtti со статическим методом load_class(), получающий имя класса в качестве параметра
load_class() находит скомпилированный класс, распаковывает его (парсит), создает объект type_info, его представляющий и помещает его в список объектов (например, хэшированный по имени класса)
реализация type_info дополняется методом создания экземпляра класса (возвращает void *)
т. е выходной код будет примерно таким

так вот, что касается статических полей
как получить доступ к variable из object?
если каждый объект Class будет хранить адрес variable, то общий размер таких объектов увеличится на sizeof(void*)
а это семантически неправильно
поэтому я бы расширил С++ концепцией атрибутов (или анотация), т. е метаинформацией о классе
что-то наподобие этого

при этом, в случае, если  Class реализует атрибут dynamic, то каждый объект этого класса будет содержать адреса всех статических переменных класса (если такие есть)

Это уже требует поддержки со стороный копилеры (речь про стандартный type_info?).


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


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

в Делфи каждый класс представляет собой объект, потому статические объекты, по идее, относятся к объекту-классу и поедания памяти не происходит.
В С++, как я понимаю, с РТТИ будет сложно, т.к. класс как структура не хранится в памяти(я прав?), а в процессе компиляции конструкторы преобразуется аллокаторы, методы - в вызовы с передачей параметров.

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

Хотите печатать быстро поступите на курсы машинисток.      А для программирования это самый последний требующийся скилл.  

Кстати, реального кскорения даже при наборе вы не получите хотя бы из-за того, что надо нажимать еще и Shift.
Я лично уже давно не пишу end руками. Их за меня вставляет Delphi 2006. ;)
И вообще, все эти вроде бы мусорные слова типа then при просмотре кода очень сильно помогают.
Если менять синтаксис, то я бы сделал в конструкции case закрытие не через end, а через endcase, лишний end если case стоит в середине процедуры иногда создает путаницу.

Что касается надежности и быстроты набора Си, то все время сэкономленное при наборе 
сишного кода съедается компиляцией.
Почему-то господа сишники стыдливо молчат, что проект в несколько тысяч строк в том же Билдере на самом современном процессоре будет собираться полминуты.
Так же стыдливо молчат про проваливающиеся case, про отсутствие родного контроля выхода за границы массива. И еще я громко заявляю, что в Си++ нет цикла for. То что есть, это while с переставленными в другие места начальным значением и приращением счетчика.
Не кажется ли, что приращение на 1, нужное в 99,9% случаев компилятор мог бы и сам ставить.

  Не нужно путать полный ребилд и билд. Если нет лишних инклудов, то при рабочем билде компилятся 1-2 cpp шника +линковка. Это происходит не дольше чем в делфи. Ребилд ол делается очень редко, например при изменении настроек компиляции. В этом нет большой нужны.
  

  В С++ ахренительный цикл for, такой обалденный, что делфи нервно курит в сторонке. Невероятно удобный, логичный и функциональный. С таким фором ничего другого не нужно. 

какой ужас, Shift нужно нажимать, слепой метод набора рулед  


в С++ и Delphi под массивом понимают несколько разные вещи, ты-бы еще Си-шный массив сравнил с массивами в Руби  
только вся фишка в том, что в С++ есть аналог массива Delphi - vector(там проверяется выход за  границу массива, и ее даже можно отключить), а вот в Delphi нет аналога Сишного массива  

компилятор тут не причем
это libstdc++.so


ну смотри


что компилятор будет генерировать в месте присваивания variable?
на сегодняшний день статические переменные реализуются через обычные глобальные переменные
но variable на момент компиляции не будет определена (класс загружается динамически)