Это все хорошие слова.
В C++ (имеется ввиду язык а не конкретный компилятор) это делается красивей и еще надежней.
Только объем работы таков, что на этом пути можно еще с год баги из дистрибутивов вытаскивать.
Вот и все. Причем первое второму не противоречит: можно перехватить присваивание в data_type, ликвидировав несметное количество багов, а потом годами высекать из кодов доступ к конкретным полям.
Которые и появились-то из-за неэффективности механизма property в сравнении с аналогичными механизмами в C++.
А с CGTShare происходит не это.
Отсутствие возможности написать CodeGen на fasm, к примеру, не имеет ни какого отношения к использованию предопределенных методов.
А говорит о том, что используемый нами сегодня механизм интерфейсом не является.
Т.е., вот такой совершенно конкретный вопрос: могу ли я написать CodeGen на fasm
Имея информацию ТОЛЬКО о интерфейсе, но НИЧЕГО не зная о версии компилятора, на котором написана среда.
Ответ -
нет. Если бы был - да, и проблем не было бы....
[size=-2]------ Добавлено в 00:07
А вот еще одна прелесть:
Это означает, что вызывающая прога (это плаг, который я делаю, скажем) резервирует память под результат TData. А модули среды заполнят поля.
Вот только мой компилятор выделит под это дело 28 байт.
А сколько заполнит
HiAsm
Гипотеза 32 - соответствует действительности
И такого несть числа....
Типа возврат
HiAsm-dll-кой нижней точки типа Array, а версии компиляторов (или даже версии
HiAsm) у проги и dll-ки разные....