Magic Pointers («красивые» указатели на функции, вызов)

[Хакер]

FuncPointer вместо имени принимает значение, которое получено от IdPntFunc, то есть, принимает непосредственно lpImportAddressesEntry.

Где ты возьмёшь адрес IAE до первого вызова LocalResolver-а?

[arthur2]

Ага, ступил Тады так:

Процедура MakeIdPnt принимает имя указателя и идентификатор.
Берем lpImportAddressesEntry из коллекции по имени и пишем в идентификатор
Если получилось, выходим.
Если не получилось, значит для этого имени ещё не вызывалась LocalResolver

В таком случае:
1. заносим в коллекцию m_UndiscoveredPointers подменный адрес -1
2. заносим в коллекцию m_DiscoveredPointers адрес идентификатора.
3. устанавливаем временный идентификатор -1

Теперь, если в Let FuncPointer идентификатор -1, то адрес пишем не на место (которое пока ещё не известно), а поверх идентификатора.

Теперь внутри LocalResolver, если мы вместо адреса функции извлекли из коллекции -1, это знак того, что в m_DiscoveredPointers лежит адрес идентификатора.
1. Берем настоящий адрес по адресу идентификатора.
2. Вписываем lpImportAddressesEntry на место идентификатора.

Всё Вроде, работает

[Хакер]

Плохо понял, но по-моему это криво и не сработает если:

• Установишь значение двух указателей сразу, а потом сделаешь два вызова.
• Установишь значение указателя в рамках одной функции, а вызов сделаешь в рамках другой.

Я могу сделать по другому, примерно как хочет BV: каждому указателю будет соответствовать своя переменная, но надо вручную вызывать BindFuncToVar.

[arthur2]

и не сработает если:
* Установишь значение двух указателей сразу, а потом сделаешь два вызова.

Да нет, работает - у каждого указателя же своя ячейка и свой идентификатор.

* Установишь значение указателя в рамках одной функции, а вызов сделаешь в рамках другой.

Не понял

Я могу сделать по другому,

Ну, я сделал для себя - потому что мне как раз надо Пусть это пока времянка.

но надо вручную вызывать BindFuncToVar.

В смысле, это что-то самописное или из кишок бейсика? Как это будет выглядеть в плане использования?

[Хакер]

Не понял

Код: Выделить всё

Sub Main
    Foo
    Bar
End Sub

Sub Foo
     FunctPointer("kai") = 123 ' Но по твоему методу.
End Sub

Sub Bar
    kai 1, 2, 3
End Sub

В смысле, это что-то самописное или из кишок бейсика? Как это будет выглядеть в плане использования?

Самописное, полагающееся на кишки VB фишки COM.

[arthur2]

Код: Выделить всё

Option Explicit
Private Declare Function kai Lib "*" (a As Long, b As Long, c As Long) As Long
Private idKai As Long
Sub Main()
    MagicPointersOnOff True
    Foo
    lalala
    Bar
    MagicPointersOnOff False
End Sub

Sub Foo()
     MakeIdPnt "kai", idKai
End Sub

Sub lalala()
    FuncPointer(idKai) = L_(AddressOf test)
End Sub

Sub Bar()
    kai 1, 2, 3
End Sub

Sub test(a As Long, b As Long, c As Long)
  MsgBox a + b + c
End Sub


Действительно, не хочет работать. Но по совершенно непонятной причини: в LocalResolver вместо имени "kai" приходит "kai " (то есть, прилип какой-то мусор). Если бы не мусор - работало бы правильно. В чём фишка?

[Хакер]

Ты переписал LocalResolver?

[arthur2]

Я вписал в него действия на случай, если адрес -1.

Теперь внутри LocalResolver, если мы вместо адреса функции извлекли из коллекции -1, это знак того, что в m_DiscoveredPointers лежит адрес идентификатора <...>

А это может как-то повлиять? Имя с прилипшим мусором - уже на входе. Или где-то используется размер LocalResolver?

[Хакер]

Как ты определил, что на конце мусор? Скинь мне в личку свой модуль с демопроектом. Только в личку.

[arthur2]

В общем, я нашел баг Прямо в твоем проекте поменял свойство на запуск с Main

Код: Выделить всё

Option Explicit
Private Declare Function kai Lib "*" (a As Long, b As Long, c As Long) As Long
Private idKai As Long
Sub Main()
    MagicPointersOnOff True
    FuncPointer("kai") = L_(AddressOf test)
    kai 1, 2, 3
    MagicPointersOnOff False
End Sub


Sub test(a As Long, b As Long, c As Long)
  MsgBox a + b + c
End Sub


В LocalResolver приходит имя с мусором, причем, с тем же самым, что и в первый раз. Выполнение доходит до строки Err.Raise 453, , "Specified pointer is not set.", но ошибка почему-то не генерируется, а после exit function бейсик умирает.

[arthur2]

Мусор определил, просто поставив брейк. проект сейчас вышлю

[Хакер]

Не надо, я понял причину.

[Хакер]

Посмотри новую версию.

[arthur2]

но ошибка почему-то не генерируется,

там у тебя там пропущено on error goto 0, в исправленной тоже. Пойду поэкспериментирую

[arthur2]

Я могу сделать по другому, примерно как хочет BV: каждому указателю будет соответствовать своя переменная, но надо вручную вызывать BindFuncToVar.

Собственно, я ведь так приблизительно и сделал: мою MakeIdPnt можно было бы назвать и так. Она именно что связывает некую переменную с конкретным указателем.
Интересно, как будет снаружи выглядеть твой вариант? Ну и интересно, на какие фишки из COM он будет полагаться?

[Хакер]

на какие фишки из COM он будет полагаться?

На Variant. На то, что плоскую Variant-переменную можно превратить в переменную-указатель.

[Хакер]

Собственно, при определённой технике можно и без медленного варианта обойтись, превратив в указатели простые Long-переменные. Метом будет очень быстрым, но код будет не таким чистым для понимания. То есть там будут хардкорные (с твоей точки зрения) трюки.

[Mikle]

Я несколько раз перечитывал тему, очень интересно.
Как обстоят дела с обновлениями? В первую очередь интересует оптимизация скорости - отказ от коллекций, да и от Variant тоже бы. Что если, как вариант, сделать быстрые неизменяемые указатели? Это для COM-интерфейсов, не поддерживающих IDispatch. Не скажу, что я прям сразу сяду портировать DX через этот кирпич, слишком глубоко я уже зарылся в свой вариант порта, просто интересуюсь, и на будущее может пригодиться.

[Хакер]

Как обстоят дела с обновлениями?

Пока никак. В какую сторону обновляться-то? Разве что заменить коллекции на самописные быстрые словари. Но здесь я боюсь вот чего: чтобы добиться очень высокой скорости, мои самописные словари будут содержать достаточно много трудного для понимания кода. Это не значит, что от этого они будут медленными, наоборот, ещё более быстрыми. Но потенциальные пользователи могут испугаться больших объёмов непонятного кода.

В первую очередь интересует оптимизация скорости - отказ от коллекций, да и от Variant тоже бы.

Медленные коллекции и Variant участвуют только в изменении значения указатели и самом первом вызове через указатель. В последующих вызовах через указатель — коллекции и Variant-ы никакой роли не играют и участия не принимают.

Что если, как вариант, сделать быстрые неизменяемые указатели?

Можешь их так и воспринимать: установил один раз, а потом много раз вызываешь. Вызов будет всего-лишь на две машинных инструкции длиннее, чем вообще мог бы быть (например в Си-прграмме), да и то взамен бонус: проверка на 0. Потому что в самих вызовах никакой дополнительный код не вызывается и не выполняется: проверили на ноль и перешли ровно туда, куда сказали (а не куда-то ещё на что-то лишнее медленное).

Это для COM-интерфейсов, не поддерживающих IDispatch.

Для COM-объектов, не поддерживающих IDispatch. Собственно, можно, но непонятно, зачем. VB абсолютно наплевать на отсутствие IDispatch. Единственное, что из этого вытекает, это невозможность привести ссылку к типу Object (но при том опять же запросто можно привести к Unknown). А поддерживаемые интерфейсы нужно просто объявить в TLB и подключить её к проекту.

[Mikle]

Единственное, что из этого вытекает, это невозможность привести ссылку к типу Object (но при том опять же запросто можно привести к Unknown).

И то, и другое, приведёт к позднему связыванию? Лучше уж обернуть в обычный VB-класс.

[Хакер]

И то, и другое, приведёт к позднему связыванию?

Ни то, ни другое не приведёт к позднему связыванию. Интерфейсы в TLB — это гарантированно раннее связывание, а MagicPorinters — ну, уж как решишь заполнять указатели, то есть как вздумываешь применить универсальный кирпич.

[Mikle]

Под "и то, и другое" я подразумевал Object и Unknown:

Код: Выделить всё

Dim T As Object

Или речь о каком-то другом "Object"?

[Хакер]

Dim T As Object означает две вещи

1. Типом переменной T «actually» будет интерфейс IDispatch.
2. Всякое обращение к члену (методу, свойству и т.д.) T будет кодироваться/компилироваться по особенному (см. дальше).

Теперь о том, как кодируется обращение к члену интерфейса. Пусть есть ссылка R типа T (тип обозначает интерфейс IX) и член M.

• Если тип R отличен от типа Object, пусть даже IX=IDispatch, тогда обращение R.M кодируется как обращение IX::M по типу раннего связывания. Всегда.
• Если тип R — это Object, тогда за IX всегда принимается IDispatch, а обращение R.M кодируется как пара обращений IX::GetIDsOfNames и затем IX::Invoke. Вернее, как у нас IX всегда = IDispatch, как пара обращений IDispatch::GetIDsOfNames и затем IDispatch::Invoke. Эти два вызова также всегда делаются по механизму раннего связывания. Но условно эти два вызова этих двух методов объявляются (провозглашаются) обращением к одному члену — к члену M. И вот этот сложный вызов, реализованный как два других вызова, называется вызовом по типу позднего связывания.

Давай будут такие обозначения:

• EB — early-bounding — ранее связывание.
• LB — late-bounding — позднее связывание.

Так вот один EB-вызов метода IFoo::M — это просто вызов M в привычном смысле слова.
А один LB-вызов метода IBar::M — это пара вызовов — EB-вызов IDispatch::GetIDsOfNames и EB-вызов IDispatch::Invoke.

То есть раннее и позднее связывания — не два брата, а просто позднее связывание — надстройка над ранним связыванием.
И у нас позднее связывание зиждется на двух вещах: на задокументированном механизме, которым можно пользоваться и вручную, и на волшебном типе Object, который заставляет любое обращение к методу превращать в пару вызовов к другим методам, но за кулисами, скрытно от нас.

Надеюсь, теперь понятно.

Если объект по своей конституции не поддерживает IDispatch, то LB поюзать не получится, но EB — сколько влезет.
Если объект поддерживает IDispatch, то LB поюзать получится всегда, даже если нет TLB с описанием IDispatch, потому что VB сам хорошо знает его описание, и даже если в TLB в описании CoClass-а в списке поддерживаемых интерфейсом по какой-то загадочной причине решили не упоминать IDispatch, потому что IUnknown::QueryInterface не занимается такой глупостью, как проверка TLB, которой, вообще говоря, может не быть и не просто так должно быть.

Пользоваться самим механизмом позднего связывания можно двумя путями:

• Вручную: объявлять ссылку как IDispatch и самому вызывать IDispatch::Invoke, указывая DISPID нужного метода.
• Автоматически: объявлять ссылку как Object и просто вызывать нужный метод (и этот вызов автоматом превратится в первый («ручной») вариант).

Надеюсь, ососал суть момента со всех сторон.

Собственно, всё несколько сложнее, вернее всё несколько шире, но VB для типа Object ничего из этого (неупомянутого) не используется. А неупомянуты следующие вариации, которые всё ещё позднее связывание, но уже не в точности такое, какое используется в VB: (а) можно не получать DISPID при каждом вызове, а заранее хранить его константой, вшитой в код, и (б) можно не вызывать по DISPID-у через Invoke, а вызывать с помощью обычного вызово, получая у IDispatch не значение DISPID-а, а ссылку на ITypeInfo, а от ITypeInfo через AddressOfMember. Но это экзотика. Могу написать всё, можешь почитать то, что написано у tyomitch'а.

[ger_kar]

Аболдеть! Классная статейка, Хакеру просто огромный респект.
После прочтения темы даже на старый добрый VB взглянул совершенно по другому.
То что раньше делалось через всякие извращения, теперь тоже самое можно сделать не только
просто а еще и действительно изящно.
Я как раз занимаюсь малой автоматизацией, причем по большей части в VBA, теперь и в этих проектах
можно организовать полноценный и безгеморойный вызов Callback, что есть очень кстати.
Это все равно, что прямая широкая дорога через лес напрямую, вместо петляющей окольной дороги.

[Хакер]

Аболдеть! Классная статейка, Хакеру просто огромный респект.

Статейка-то что, кирпич нужно смотреть (и использовать, по возможности).

[ger_kar]

Ну конечно буду использовать. Но и топик для меня открыл много нового и интересного.
Теперь я знаю принцип и реализацию этого принципа (кирпич), а это намного больше,
чем просто кирпич
Еще раз огромное спасибо.

[arthur2]

Пытаюсь разобраться в коде. Почему вот здесь:

Код: Выделить всё

        For i = 1 To m_DiscoveredPointers.Count
            PutMem4 m_DiscoveredPointers(i), 0
        Next i


а не PutMem4 m_DiscoveredPointers(i)+Offs_EbImportFunc, 0?

[Хакер]

Я щас сам не могу понять. Несколько подзабылись подробности того, как оно там всё внутри устроена (с точностью до порядка следования полей), а кроме моей головы этой информации вообще нет нигде. Придётся заново разбираться.

Так вот.
Либо по смещению 0 что-то хранится, но я забыл что, и сейчас не смог найти ни одного обращения по этому смещению.
Либо это просто баг от моих кривых рук. Но чтобы точно сказать, нужно посидеть в отладчике и вспомнить подробности.

[arthur2]

Либо по смещению 0 что-то хранится

Если так, то тогда последнее поле не затирается.

[Хакер]

Ну скорее всего это баг, да. Но надо убедиться.