Вверх ↑
Этот топик читают: Гость
Администрация
Ответов: 15294
Рейтинг: 1518
#16: 2006-07-14 18:24:02 ЛС | профиль | цитата
Galkov, этим сейчас и занимаюсь
карма: 26
0
Ответов: 9906
Рейтинг: 351
#17: 2006-08-14 22:52:55 ЛС | профиль | цитата
Вижу на 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) А если мы решили ВТОРУЮ интерфейсную проблему, то ПОЧЕМУ бы нам не решить ТОЧНО так же и первую.

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

0
Администрация
Ответов: 15294
Рейтинг: 1518
#18: 2006-08-17 04:06:56 ЛС | профиль | цитата
Ну положим с простыми типами все ясно. Так же ясно все с типом PStream, но вот с типом скажем PBitmap или PIcon не совсем ясно. В каком виде передавать такие данные в предлогаемой структуре?
карма: 26
0
Ответов: 9906
Рейтинг: 351
#19: 2006-08-24 00:41:58 ЛС | профиль | цитата
На развернутый топик времени как-то не очень хватает
Ну хоть коротко:


В нулевом приближении принять картинку не сложнее чем 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, который имеет понятие - но там это уже класс, а не объект...
И если не подвергать сомнению исходную Аксиому...
карма: 9

0
Ответов: 2125
Рейтинг: 159
#20: 2006-08-24 12:42:07 ЛС | профиль | цитата
Galkov писал(а):
универсальность предполагаемой системы
В Windows уже есть одна универсальная система - СОМ, зачем изобретать велосипед?
карма: 1

0
Ответов: 9906
Рейтинг: 351
#21: 2006-08-24 13:44:35 ЛС | профиль | цитата
Излагай, чего нам надо сделать.
карма: 9

0
Ответов: 2125
Рейтинг: 159
#22: 2006-08-24 14:31:49 ЛС | профиль | цитата
Излагаю.
Вместо введения кучи типов (stream, array, bitmap и т.п.) можно оставить один тип object и передавать указатель на IUnknown, для чего потребуется реализовать вышеприведённые типы данных как COM-объект (унаследовав от TInterfacedObject). Компоненты, использующие подобный тип данных, должны запросить у объекта посредством QueryInterface знакомый им интерфейс (например IHiStream, IHiArray, и т.п.) и использовать его. Если нужного интерфейса нет, значит есть ошибка в схеме, например соеденены неподходящие var и data точки.
карма: 1

0
Ответов: 9906
Рейтинг: 351
#23: 2006-08-24 18:15:54 ЛС | профиль | цитата
Изложил называется....
Все равно придется буквари читать. Благо на сети у нас полно всякого валяется....
карма: 9

0
Ответов: 9906
Рейтинг: 351
#24: 2006-10-02 12:31:35 ЛС | профиль | цитата
вот чего вижу в share
function ReadData(var Data:TData; PointData:THI_Event; Def:PData):TData;
begin
if Assigned(PointData.Event) then
begin
Result.Data_type := data_null;
//Result.Next := nil;
_hi_OnEvent(PointData,Result);
end
else if(Def = nil)or( Def.data_type = data_null ) then
begin
Result := Data;
{$ifdef MT_ENABLED}
if Data.ldata <> nil then
Data := Data.ldata^
else
{$endif}
Data.data_type := data_null;
end
else Result := Def^;
end;
и представляется мне, что правильнее вот так:
    .....
    begin
Result := Data;
{$ifdef MT_ENABLED}Result.ldata := nil;
if Data.ldata = nil then Data.data_type := data_null;
if Data.data_type <> data_null then Data := Data.ldata^;
{$else}Data.data_type := data_null;{$endif}
end
else Result := Def^;
end;

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

0
Ответов: 2125
Рейтинг: 159
#25: 2006-10-02 12:38:29 ЛС | профиль | цитата
Result.ldata := nil;[/code] действительно нехватает, а вот насчёт остального: подумай, что будет, если в MT-данных где-нибудь (например вначале) появятся данные типа data_null :) и что будет с данными после них.
карма: 1

0
Ответов: 9906
Рейтинг: 351
#26: 2006-10-02 14:29:10 ЛС | профиль | цитата
Так я подумал: если dat_type=data_nul, то гарантий про ldata, вроде бы - никаких.
карма: 9

0
Ответов: 2125
Рейтинг: 159
#27: 2006-10-02 15:13:04 ЛС | профиль | цитата
А я думаю, между .data_type и .ldata никакой связи нет. Есть просто обычный список с полем связи .ldata, а что в каждом элементе списка лежит - показывает .data_type
карма: 1

0
Администрация
Ответов: 15294
Рейтинг: 1518
#28: 2006-10-02 16:08:35 ЛС | профиль | цитата
Galkov, с такой поправкой MT_Add перестанет работать правильно

[size=-2]------ Добавлено в 16:08
Да и смысл MT_Get тоже пропадет
карма: 26
0
Ответов: 9906
Рейтинг: 351
#29: 2006-10-02 19:28:45 ЛС | профиль | цитата
tsdima писал(а):
Есть просто обычный список с полем связи .ldata, а что в каждом элементе списка лежит - показывает .data_type
А мне казалось по другому: а что в каждом элементе лежит - показывает .ldata.data_type

Dilma писал(а):
с такой поправкой MT_Add перестанет работать правильно
а как правильно (у меня эти коды с незапамятных времен)
У меня такой пример: code_364
выдает:
<
2.71828
>
12
===
3.1415


Dilma писал(а):
Да и смысл MT_Get тоже пропадет
А вот мне показалось, что пропадает смысл только в одной строке MT_Get
   dt.ldata := nil;[/code]

[hr]Но меня больше интересовала возможность [b](data_type=data_nul) and (ldata<>nil)[/b]
Возможно это перестраховка....
Но ведь MT_Add от этого страхуется....
И НЕ ГАРАНТИРУЕТ не выполнения этого условия на своем выходе
карма: 9

0
файлы: 1code_364.txt [1.1KB] [386]
Администрация
Ответов: 15294
Рейтинг: 1518
#30: 2006-10-02 20:32:20 ЛС | профиль | цитата
С правками согласен.

подумай, что будет, если в MT-данных где-нибудь (например вначале) появятся данные типа data_null

Если такие данные появились, то это ошибка компонента, который смог сделать такой поток.
карма: 26
0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)