'Type is not automatable' — не баг ли?

Вопросы программирования на Free Pascal, использования компилятора и утилит.

Модератор: Модераторы

Re: 'Type is not automatable' — не баг ли?

Сообщение Иван Шихалев » 21.11.2010 08:52:47

Sergei I. Gorelkin писал(а):и под каждый аргумент отводилось sizeof(pointer) байт

Как интересно. Я-то считал, что под него выделяется как минимум sizeof(pointer) из соображений выравнивания. Соответственно, для i386 проверял, а не надо ли сдвинуть сильнее... Сейчас получается, что надо менять обработку и для x64, поскольку под Integer или Boolean выделяется 4 байта и на x64 тоже. И у меня нет уверенности, что это правильно, и мы не столкнемся с проблемами выравнивания где-нибудь на экзотической платформе.

Sergei I. Gorelkin писал(а):Из-за этого в патч для DispInvoke придется вносить изменения

Посмотрю.

Sergei I. Gorelkin писал(а):Просто так подставлять varOleStr вместо varUnicodeString нельзя, это разные типы, нужно выделять память с помощью SysAllocateString и копировать строку туда, но это возможно только для windows...

А вот не уверен. Во-первых, лишнее выделение строки, в общем-то, ни к чему. Во-вторых, тут главное не поломать совместимость с OLE и Delphi, а для других случаев может передаваться все, что угодно. Пусть об этом программист, который будет разбирать результат, заботится.

Добавлено спустя 3 минуты 21 секунду:
И, кстати, о Delphi... Есть еще именованные параметры. Насколько я понимаю, пока в FPC на них положен большой болт... Не то, чтобы они были мне нужны, но вот для совместимости таки требуются.

Добавлено спустя 1 час 48 минут 56 секунд:
Посмотрел изменения в ComObj. В общем, не проблема копировать варианты в DispInvoke... Меня больше беспокоит вопрос выравнивания. Было бы здорово, если б кто посмотрел, как это работает в Delphi 64... Хотя и это не совсем аргумент, поскольку та все равно не рассчитана на платформы, кроме x86, а в них можно данные и по байту выравнивать, а в более общем случае — не получится.

Добавлено спустя 7 минут 38 секунд:
Насчет строк тут у меня такое соображение возникло:
Если строка передается как значение, то вопросы выделения памяти поднимать не стоит — по правилам хорошего тона вызываемая сторона не должна ничего с ней делать (хотя для OLE это и не так, но тут в чистом виде проблемы OLE — так делать нельзя, получили кучу геморроя и, несмотря на все старания, источник трудноуловимых ошибок). А вот если по ссылке... Тогда никакое копирование не подходит, ибо надо изменения вернуть в строку-параметр...

В общем, сильно заморачиваться на них не стоит.
Аватара пользователя
Иван Шихалев
энтузиаст
 
Сообщения: 1138
Зарегистрирован: 15.05.2006 11:26:13
Откуда: Екатеринбург

Re: 'Type is not automatable' — не баг ли?

Сообщение Sergei I. Gorelkin » 21.11.2010 14:37:52

Иван Шихалев писал(а):Как интересно. Я-то считал, что под него выделяется как минимум sizeof(pointer) из соображений выравнивания. Соответственно, для i386 проверял, а не надо ли сдвинуть сильнее... Сейчас получается, что надо менять обработку и для x64, поскольку под Integer или Boolean выделяется 4 байта и на x64 тоже. И у меня нет уверенности, что это правильно, и мы не столкнемся с проблемами выравнивания где-нибудь на экзотической платформе.


Совершенно верно, я упустил это из виду и, починив i386, сломал x64 :( Буду исправлять.

Иван Шихалев писал(а):А вот не уверен. Во-первых, лишнее выделение строки, в общем-то, ни к чему. Во-вторых, тут главное не поломать совместимость с OLE и Delphi, а для других случаев может передаваться все, что угодно. Пусть об этом программист, который будет разбирать результат, заботится.


Так это OLE знает только об OLEString (WideString), память для которых выделяется совершенно определенным способом. Т.е. в Линуксе-то все нормально, потому что UnicodeString и WideString - одно и то же. А в винде, при передаче по ссылке или если вызываемая сторона решит изменить значение - все грохнется.
Вариантов, по сути, два: либо все преобразуем в varOleStr (будет код с {$ifdef windows}, и, так сказать, совместимость с дельфи), либо не преобразуем ничего.

Иван Шихалев писал(а):И, кстати, о Delphi... Есть еще именованные параметры. Насколько я понимаю, пока в FPC на них положен большой болт... Не то, чтобы они были мне нужны, но вот для совместимости таки требуются.

Они вроде поддерживаются, но только для IDispatch, не для Variant dispatch (там их просто некуда воткнуть). В Дельфи тоже так. Работает или не по факту - нужно проверять.

Иван Шихалев писал(а): вот если по ссылке... Тогда никакое копирование не подходит, ибо надо изменения вернуть в строку-параметр...

Посмотри comobj.pp, там как раз сначала все byref AnsiString преобразуются в WideString, а потом обратно.
Аватара пользователя
Sergei I. Gorelkin
энтузиаст
 
Сообщения: 1406
Зарегистрирован: 24.07.2005 14:40:41
Откуда: Зеленоград

Re: 'Type is not automatable' — не баг ли?

Сообщение Иван Шихалев » 21.11.2010 14:52:18

Sergei I. Gorelkin писал(а):В Дельфи тоже так.

Тогда и фиг с ним. Тем более, что в DispInvoke и так непонятно, как с ними работать. А обойтись без них вполне можно.

Sergei I. Gorelkin писал(а):Посмотри comobj.pp, там как раз сначала все byref AnsiString преобразуются в WideString, а потом обратно.

Вот уж чего точно не надо. В Ruby, ради стыковки с которым я и полез в это дело, WideString работать не будет. Преобразовывать туда, потом обратно... Нафиг-нафиг.
Аватара пользователя
Иван Шихалев
энтузиаст
 
Сообщения: 1138
Зарегистрирован: 15.05.2006 11:26:13
Откуда: Екатеринбург

Re: 'Type is not automatable' — не баг ли?

Сообщение Sergei I. Gorelkin » 21.11.2010 15:50:05

Иван Шихалев писал(а):Вот уж чего точно не надо. В Ruby, ради стыковки с которым я и полез в это дело, WideString работать не будет. Преобразовывать туда, потом обратно... Нафиг-нафиг.


Внутри я поддерживаю идею ничего не преобразовывать, но ведь рано или поздно кто-нибудь заявит о "несовместимости с Дельфи".

А в каком виде нужны строки для Ruby? Ведь едва ли он просто так понимает AnsiString/UnicodeString...
Аватара пользователя
Sergei I. Gorelkin
энтузиаст
 
Сообщения: 1406
Зарегистрирован: 24.07.2005 14:40:41
Откуда: Зеленоград

Re: 'Type is not automatable' — не баг ли?

Сообщение Иван Шихалев » 21.11.2010 16:40:27

Sergei I. Gorelkin писал(а):А в каком виде нужны строки для Ruby?

PChar. Может содержать UTF-8. Правда, я не уверен насчет новых версий под Windows, но в unix'ах в новых версиях просто уже не может, а должен содержать UTF-8. Что и логично.

Добавлено спустя 2 минуты 36 секунд:
Там функции API не предполагают модификации строки — строка или возвращается или принимается, но не одновременно.

Добавлено спустя 1 минуту 41 секунду:
Sergei I. Gorelkin писал(а):но ведь рано или поздно кто-нибудь заявит о "несовместимости с Дельфи".

Вот пусть тогда сам этот кто-нибудь возится с IFDEF'ами, поскольку тянуть в unix'ы WideString — это форменное издевательство.
Аватара пользователя
Иван Шихалев
энтузиаст
 
Сообщения: 1138
Зарегистрирован: 15.05.2006 11:26:13
Откуда: Екатеринбург

Re: 'Type is not automatable' — не баг ли?

Сообщение Sergei I. Gorelkin » 21.11.2010 22:39:32

В ревизии 16394 починил выравнивание параметров еще раз. Теперь должно быть всем хорошо... ну по крайней мере i386 и x86_64, которые я в состоянии протестировать...
Аватара пользователя
Sergei I. Gorelkin
энтузиаст
 
Сообщения: 1406
Зарегистрирован: 24.07.2005 14:40:41
Откуда: Зеленоград

Re: 'Type is not automatable' — не баг ли?

Сообщение Иван Шихалев » 25.11.2010 20:54:57

Sergei I. Gorelkin писал(а):Из-за этого в патч для DispInvoke придется вносить изменения, аналогичные тем, что внесены в winunits-base/src/comobj.pp ревизии 16388.

Внес.
Аватара пользователя
Иван Шихалев
энтузиаст
 
Сообщения: 1138
Зарегистрирован: 15.05.2006 11:26:13
Откуда: Екатеринбург

Re: 'Type is not automatable' — не баг ли?

Сообщение Sergei I. Gorelkin » 28.11.2010 00:10:47

Закоммитил в ревизии 16458 с небольшими изменениями. Спасибо за патч!
Изменения такие:
- для вызова метода без аргументов, сначала вызывать GetProperty, и только в случае, если вернет false - DoFunction.
- перед вызовом SetProperty проверяется факт отсутствия result и число аргументов, равное 1.

UnicodeString пока решили считать самим собой (т.е. типа varUString) на всех платформах. Во всяком случае в Windows должно быть так, в не-Windows, возможно, что переиграется на varOleStr.
Аватара пользователя
Sergei I. Gorelkin
энтузиаст
 
Сообщения: 1406
Зарегистрирован: 24.07.2005 14:40:41
Откуда: Зеленоград

Re: 'Type is not automatable' — не баг ли?

Сообщение Иван Шихалев » 28.11.2010 11:42:40

Преобразование варианта в строку не знает ничего об varUString. См. #0018083, патчик я там приложил.

Добавлено спустя 1 минуту 53 секунды:
Хотя, пожалуй, поторопился — надо и в другие типы преобразования поправить...

Добавлено спустя 5 часов 10 минут 43 секунды:
Дополнил патч для прочих типов, которые преобразуются из строк.
Аватара пользователя
Иван Шихалев
энтузиаст
 
Сообщения: 1138
Зарегистрирован: 15.05.2006 11:26:13
Откуда: Екатеринбург

Пред.

Вернуться в Free Pascal Compiler

Кто сейчас на конференции

Сейчас этот форум просматривают: Google [Bot] и гости: 2

Рейтинг@Mail.ru