Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2006-07-06 00:07:47 ЛС | профиль | цитата
Это все хорошие слова.
В C++ (имеется ввиду язык а не конкретный компилятор) это делается красивей и еще надежней.
Только объем работы таков, что на этом пути можно еще с год баги из дистрибутивов вытаскивать.
Вот и все. Причем первое второму не противоречит: можно перехватить присваивание в data_type, ликвидировав несметное количество багов, а потом годами высекать из кодов доступ к конкретным полям.
Которые и появились-то из-за неэффективности механизма property в сравнении с аналогичными механизмами в C++.


А с CGTShare происходит не это.
Отсутствие возможности написать CodeGen на fasm, к примеру, не имеет ни какого отношения к использованию предопределенных методов.
А говорит о том, что используемый нами сегодня механизм интерфейсом не является.

Т.е., вот такой совершенно конкретный вопрос: могу ли я написать CodeGen на fasm
Имея информацию ТОЛЬКО о интерфейсе, но НИЧЕГО не зная о версии компилятора, на котором написана среда.
Ответ - нет. Если бы был - да, и проблем не было бы....

[size=-2]------ Добавлено в 00:07

А вот еще одна прелесть:
unit hihiPlugs;
...........
TParam = record
Handle:cardinal;
Desktop:function(Index:smallint):TData;
end;
Это означает, что вызывающая прога (это плаг, который я делаю, скажем) резервирует память под результат TData. А модули среды заполнят поля. Вот только мой компилятор выделит под это дело 28 байт.
А сколько заполнит HiAsm
Гипотеза 32 - соответствует действительности

И такого несть числа....
Типа возврат HiAsm-dll-кой нижней точки типа Array, а версии компиляторов (или даже версии HiAsm) у проги и dll-ки разные....
карма: 9

0