Galkov, этим сейчас и занимаюсь

Вижу на SVN иной способ передачи данных из среды (HiAsm) в CodeGen...
Контр-соображений против универсальности не возникает
Возникают на предмет эффективности такого способа.
Понятно, что для CodeGen эффективность не самый больной вопрос, но все-таки...
Ведь в мыслях же продолжает сидеть необходимый способ обмена данными для dll-к и плагов

Чем большим количеством типов мы захотим обмениваться, тем больше и больше будет разбухать интерфейс, что не есть хорошо
Вот припоминаю тип TValue, используемый в CallDLL....
Почему не что-то похожее
Для его окончательной "универсализации" добавить к нему еще одно поле Length, и можно будет даже различить real от extended
Кстати тип получится совпадающий с виндячим COPYDATASTRUCT, т.е., почти стандарт. А может и не почти, если поле Length установить ПЕРЕД полем Value, а на поле DType отвести 4 байта (именно столько ведь и отводится, если нет атрибута packed)
И строки появится возможность передавать не только как pchar, а любые паскалевские (доработать ф-ю LoadResData из share, чтобы она возвращала не pchar, а string - не представляется проблематичным, полная аналогия с LoadResStream).
В случае data_stream в Value содержался бы PStream.Memory, а в Length - PStream.size.
Для картинок - полная аналогия с файлами (но уж не PBitmap).

Вот и обнаружил желание получать таки в CodeGen непосредственно данные, несмотря на наличие интерфейсных методов, помещающих данные в ресурс "не глядя".
Это существенно с позиций универсальности.
Пример: FASM, скажем, должен иметь право решать САМОСТОЯТЕЛЬНО, помещать данные в ресурс, или непосредственно в сегмент данных (второе-то, запросто может оказаться рациональнее).
Да и ресурс FASM может сформировать самостоятельно. Собственно, только такой вариант сегодня и просматривается, если надо подключить XP-ресурс, скажем.

---

Почему я склоняюсь к некому интерфейсному типу...
Потому что проблемный вопрос интерфейса у нас не один - для CodeGen.
Связь плага со средой - то же интерфейсный вопрос. Этот вопрос очень похож (логические корни-то те же) на совместимость приложения и dll-ки, сделанных разными компиляторами.
На заре создания проекта hiDLL, мы видели, сделанная на FPC dll-ка не очень подключается к приложению на Дельфи.
Но сказали - ну и фиг с ним, с FPC. Фактически...
Ну заработает через какое-то время FASM, и этот вопрос (к примеру, плаги на fasm-е) станет значительно более интересным.
И хотелось бы отметить, что вопрос DLL-к не очень замыкается внутри соответствующих элементов.
Во-первых, плаг - это тоже DLL-ка, и нелогично было бы делать два разных механизма, для очень похожих конструкций
Во-вторых, есть массивы и матрицы. И тут либо не разрешать этот тип для интерфейса, либо аргументы и возвращаемые значения ф-й (указатели не которые составляют структуры TMatrix и TXArray) должны быть нашего предполагаемого интерфейсного типа (а не TData)... И это будет касаться элементов уже не имеющих отношения к DLL-кам

А далее рассуждаю так:
1) Пусть существуют ДВЕ интерфейсные проблемы, и их можно решать независимо
2) Решение второй - это путь интерфейсного типа
3) Решение любой проблемы - это встряска нашей системы, сопровождаемая несовместимостью с предыдущим
4) Поэтому лучше трясти один раз, а не два...
5) А если мы решили ВТОРУЮ интерфейсную проблему, то ПОЧЕМУ бы нам не решить ТОЧНО так же и первую.

Мне кажется, это было бы рациональнее
Хотя думать о всем сразу посложнее...
Но это только если сравнивать с решением одной. А если всех
Все одно решать все придется...

Ну положим с простыми типами все ясно. Так же ясно все с типом PStream, но вот с типом скажем PBitmap или PIcon не совсем ясно. В каком виде передавать такие данные в предлогаемой структуре?

На развернутый топик времени как-то не очень хватает
Ну хоть коротко:

---

В нулевом приближении принять картинку не сложнее чем Stream. Их ресурсов же мы получаем (точнее даже не мы сами, а винда нам это дает) блок данных для битмэпа... Вроде бы это известный для винды тип: hBitmap. Насколько я понимаю, на все 100 совпадает с bmp-файлом. То же самое и про иконку ...

---

А вот если присмотреться по-внимательней, то у нас оказываются данные с разными характеристиками и требующими, соответственно, разного подхода. Аналогичное есть в других языка ВУ: в Дельфи - просто переменная и var-переменная, в CPP - простые переменные и ссылочные... У нас строки, real, integer - аналогичны простым переменным. А stream, array, bitmap - ссылочным. И реализуем мы это, передавая так называемый интерфейс. А именно, необходим указатель на объект и список указателей на методы - и вытворяй все чего дозволено, на здоровье.
В array это сделано явно, а для bitmap и stream - просто считается, что адреса методов известны на этапе компиляции, но смысл остается тот же...

Предположим, что универсальность предполагаемой системы (теперь буду называть это Интерфейсом с большой буквы) взаимодействия приложения-DLL-ки, или HiAsm-плаг - является для меня самой непреложной Аксиомой.
Т.е., я не должен напрягаться, на каком языке писать DLL-ку или плаг. Хоть на FPC, хоть на FASM, хоть на супер-пупер-компиллере (о котором мы сегодня и не знаем, к примеру)

И тут-то мы и смекаем, что отмеченный выше интерфейсный тип совсем не полная панацея
И, чтобы соблюсти требуемую универсальность, следует исключить из интерфейса наши "ссылочные" типы. А это очень досадно...
Другой путь - сделать универсальным И передачу "интерфейса" (с маленькой буквы)
Какие там вопросы...
1) ну, грубо говоря, не все знают, что такое указатель на метод объекта (скажем в CPP я про такое не слышал). Хоть и ничего военного, но разумней передавать просто адреса ф-й с дополнительным первым аргументом (как любят называть в Дельфях - Sender), ну и плюс сам этот Sender
2) типы аргументов и результата должны быть либо общеизвестны, либо нашего гипотетически интерфейсного типа
3) регистровое соглашение, видимо, следует принять за stdcall

Ну и переписать использование Stream и Bitmap незаметно для пользователя (без изменения внешней функциональности). Т.е., сделать их использование аналогичным Array

Вот такая тяжелая стезя....
Если хочется, чтобы можно было написать DLL-ку, с нижней точкой Stream - на CPP, который понятия не имеет о Дельфячем PStream. Да и FPC, который имеет понятие - но там это уже класс, а не объект...
И если не подвергать сомнению исходную Аксиому...

В Windows уже есть одна универсальная система - СОМ, зачем изобретать велосипед?

Излагай, чего нам надо сделать.

Излагаю.
Вместо введения кучи типов (stream, array, bitmap и т.п.) можно оставить один тип object и передавать указатель на IUnknown, для чего потребуется реализовать вышеприведённые типы данных как COM-объект (унаследовав от TInterfacedObject). Компоненты, использующие подобный тип данных, должны запросить у объекта посредством QueryInterface знакомый им интерфейс (например IHiStream, IHiArray, и т.п.) и использовать его. Если нужного интерфейса нет, значит есть ошибка в схеме, например соеденены неподходящие var и data точки.

Изложил называется....
Все равно придется буквари читать. Благо на сети у нас полно всякого валяется....

вот чего вижу в share
и представляется мне, что правильнее вот так:

[size=-2]------ Добавлено в 12:31
Dilma, не могу аттач удалить из поста

Так я подумал: если dat_type=data_nul, то гарантий про ldata, вроде бы - никаких.

А я думаю, между .data_type и .ldata никакой связи нет. Есть просто обычный список с полем связи .ldata, а что в каждом элементе списка лежит - показывает .data_type

Galkov, с такой поправкой MT_Add перестанет работать правильно

[size=-2]------ Добавлено в 16:08
Да и смысл MT_Get тоже пропадет

А мне казалось по другому: а что в каждом элементе лежит - показывает .ldata.data_type

а как правильно (у меня эти коды с незапамятных времен)
У меня такой пример: code_364
выдает:

А вот мне показалось, что пропадает смысл только в одной строке MT_Get

С правками согласен.


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