Вопрос по Пользовательскому типу данных (VB6)

[Qwertiy]

Мне кажется я выложил 3 примера, и TLB фигурирует только в одном...

Ну так я как раз про StandartEXE. В нём-то нельзя, получается.

Остальное — уже пошёл оффтопик.

Удобно

[Хакер]

Ну так я как раз про StandartEXE. В нём-то нельзя, получается.

В Standard EXE нет публичных сущностей (классов, структур) и нет TLB. Он именно стандартный в том плане, что мало чем отличается от EXE, сделанного например при помощи чистого Си.

По вашему нужно было сделать так, чтобы в Standard EXE могли бы быть публичные сущности и была бы хранимая в ресурсах TLB? И чтобы тогда было два типа проекта (Standard EXE и ActiveX EXE), абсолютно ни чем друг-от-друга не отличающихся?

[Хакер]

Удобно

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

[arthur2]

нельзя, чтобы UDT, который покидает границы нашего приложения, был объявлен как приватный.

Понятно Ну а как же твоя предполагаемая CreateNewUDT, которая будет делать udt на лету, не то что приватно, вообще нигде не объявленную? это не будет нарушать данный принцип?

Это что объявленная внутри будет локальной процедурой, которую можно вызвать только из родительской процедуры?

Ага. В джаваскрипте, кажется. Хотя уже много лет не пользовался, может и путаю.

[Qwertiy]

По вашему нужно было сделать так, чтобы в Standard EXE могли бы быть публичные сущности и была бы хранимая в ресурсах TLB? И чтобы тогда было два типа проекта (Standard EXE и ActiveX EXE), абсолютно ни чем друг-от-друга не отличающихся?

Кажется, идею понял.
Я не настолько хорошо разбираюсь в VB6 и COM...

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

Несовсем так. Ты написал, что в языках того же уровня, что VB6 этого сделать нельзя. Я привёл конкретный пример, как это обойти в Си.

ты из моего жалкого примера хочешь развить целую подветвь дискуссии с обсуждением других языков и лямда-функций. Не надо этого делать.

Ok.

Я так и не понял, что там про переменные между функциями...

[Хакер]

Понятно Ну а как же твоя предполагаемая CreateNewUDT, которая будет делать udt на лету, не то что приватно, вообще нигде не объявленную? это не будет нарушать данный принцип?

Это чёрная магия в привычном для меня стиле.
Microsoft говорит, что программист не должен реализовывать IRecordInfo сам, а должен использовать встроенную (в COM) реализацию, которая берёт данные из TLB.

Иными словами, взяли ITypeInfo для UDT и попросили у COM на основе этого сгенерировать реализацию IRecordInfo. Конечно, новая уникальная реализация не генерируется, просто имеющаяся универсальная реализация обращается к ITypeInfo для получения данных о структуре структуры.

Microsoft пишет, что программисту никогда не потребуется самому реализовывать IRecordInfo, потому что можно делать так, как написано выше.

С другой стороны, Microsoft прямо не запрещает самому реализовывать IRecordInfo, и, более того, это неотъемлемая природа интерфейсов — вызывающая и вызываемая сторона абсолютно ничего не знают друг о друге и не должны полагаться на какие-то аспекты функционирования друг-друга, окромя тех, что прямо предписываются самим COM-интерфейсом.

Но конечно это будет уже урезанный функционал. Например IRecordInfo задуман так, что если у вас есть IRecordInfo для некоей UDT, то через IRecordInfo можно выйти на ITypeInfo этого типа, и на ITypeLib той TLB-шки, в которой этот тип (UDT) объявлен. Естественно, что в моём варианте с CreateDynamicUdt если кто-то получит Variant-значение, хранящее структуры, извлечёт из этого Variant-значения ссылку на IRecordInfo, а у IRecordInfo попросит вернуть ему ссылку на TLB-шку, в которой описан хранимый в варианте UDT, то будет облом, потому что такой TLB-шки вообще не существует во вселенной.

Хорошо что хотя бы IRecordInfo::GetTypeInfo позволяет вежливо донести до вызывающей стороны, что до TLB ей (вызывающей стороне) достучаться не суждено, возвращая ей (вызывающей стороне) ошибку TYPE_E_INVALIDSTATE.

[arthur2]

Насколько я понимаю, тип вариант - это ведь не чисто бейсиковская фича, а комовская? А комовские возможности варианта шире, чем в бейсике, и ли те же?

[Хакер]

Насколько я понимаю, тип вариант - это ведь не чисто бейсиковская фича, а комовская?

Вот именно! Variant — COM-овская фича, и VB вынужден играть по правилам COM-а. А правила COM-а такие: в Variant можно поместить рекорд (UDT), но рекорд должен быть описан в TLB.

А комовские возможности варианта шире, чем в бейсике, и ли те же?

По спецификации (то есть только на бумаге) — шире.
На практике (ибо реализовано не всё из спецификации) — чуть шире, засчёт поддержки таких типов UI2, UI4, UI8, I8.
Но эти типы не входят в установленный Microsoft'ом список «OLE Automation»-типов. Поэтому в VB они не поддерживаются не просто так, не из-за чьей-то лени или нежелания делать их поддержку, а чтобы не создавать проблем.

[arthur2]

Возник ещё такой вопрос.

нельзя, чтобы UDT, который покидает границы нашего приложения, был объявлен как приватный.

В вариант вполне помещается приватный класс. То есть, класс, объявленный как приватный, может покидать границы нашего приложения. Почему же тогда такая дискриминация для структур?

И как именно структура помещается в вариант? видимо, как указатель? на что именно - на какой-то интерфейс (IRecordInfo)?

[burik]

В вариант вполне помещается приватный класс. То есть, класс, объявленный как приватный, может покидать границы нашего приложения. Почему же тогда такая дискриминация для структур?

По-моему, различия между классами и структурами уже описывались тут.

[Хакер]

В вариант вполне помещается приватный класс. То есть, класс, объявленный как приватный, может покидать границы нашего приложения. Почему же тогда такая дискриминация для структур?

Не могу терпеть, когда говорят «класс», а имеют в виду объект (то есть экземпляр класса).
В вариант помещается не класс. И в вариант помещается даже не экземпляр класса.
В вариант помещается ссылка на интерфейс IUnknown (или на интерфейс IDispatch, но разницы никакой) какого-то объекта (возможно — экземпляра класса, а возможно — единственного объекта в своём роде, для которого даже и класса не существует).

Есть колоссальная разница между структурой и ссылкой на объект.
Ссылка на IUnknown — это просто 4-байтный указатель. Именно 4 байтный указатель и хранится в варианте.
Структура — это структура, совокупность байтов заведомо неизвестной (отдельно взятому пользователю вариант-переменной) длины, с неизвестными полями, с неизвестными правилам копирования.

Когда есть

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

Dim a as Variant, b as Variant
a = b

и b содержит ссылку на IUnknown, единственное, что сделается при копировании ссылки: скопируется 4-байтный указатель и вызовется IUnknown::AddRef (ибо была одна ссылка, а стало две).

Когда есть

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

Dim a As Variant, b As Variant
a = b

и b содержит UDT-шку, то должно произойти копирование структур. И чтобы скопировать структуру, нужно знать кучу вещей: какой у UDT-шки размер в байтах, сколько у неё полей, какие у неё поля, и правило клонирования значения для каждого отдельного взятого поля этой структуры. То есть нужно нечто, по функциональности аналогичное тому, что в С++ называется конструктором копирования (или конструктором клонирования).

Так что, как я уже сказал, разница колоссально.
Чтобы скопировать Variant-значения подтипа VT_UNKNOWN (которое является ссылкой на объект), об объекте не нужно знать абсолютно ничего.
Чтобы скопировать Variant-значение подтипа VT_USERDEFINED (которое является хранимой UDT-шкой), об UDT нужно знать абсолютно всё.

Объекты всегда адресуются по ссылке, и всегда происходит манипуляция ссылками (указателями), которая предельно проста.
Структуры никогда не адресуются указателями (кроме случаев с ByRef-параметрами функций), и всегда происходит манипуляция непосредственно самими структурами, которая требует знания правил инициализации нового значения обрабатываемого пользовательского типа, правил уничтожения старого значения обрабатываемого пользовательского типа, правил создании копии значения обрабатываемого пользовательского типа.

___________

Почему же тогда такая дискриминация для структур?

Как видишь, это не дискриминация, а естественная необходимость, проистекающая из концептуального различия между COM-объектами и плоскими структурами.

________________

И как именно структура помещается в вариант? видимо, как указатель? на что именно - на какой-то интерфейс (IRecordInfo)?

Неужели так трудно посмотреть в MSDN?
Variant, который внешне выгдялит как вариант, хранящий UDT, изнутри выглядит так.
Первое поле VARIANT-структуры содержит идентификатор субтипа VT_USERDEFINED.
Второе поле VARIANT-структуры содержит указатель на сам хранимый UDT, то есть на блок байтов, являющихся полями UDT (подразумевается экземпляр)
Третье поле VARIANT-структуры содержит ссылку на интерфейс IRecordInfo, ответственный за UDT (подразумевается сам тип)

[arthur2]

Первое поле VARIANT-структуры содержит идентификатор субтипа VT_USERDEFINED.
Второе поле VARIANT-структуры содержит указатель на сам хранимый UDT, то есть на блок байтов, являющихся полями UDT (подразумевается экземпляр)
Третье поле VARIANT-структуры содержит ссылку на интерфейс IRecordInfo, ответственный за UDT (подразумевается сам тип)

хм... прикольно А если я сам заполню все эти поля и сам реализую IRecordInfo, получается, смогу впихивать в вариант любой пользовательский тип? или я чего-то недопонял?

[Хакер]

хм... прикольно А если я сам заполню все эти поля и сам реализую IRecordInfo, получается, смогу впихивать в вариант любой пользовательский тип? или я чего-то недопонял?

Именно так. IRecordInfo может вешать любую лапшу, придумывая формат (в смысле количества и типа полей) UDT-шки на ходу. На этом и основывалась идея о CreateDynamicUdt.

Собственно, можно все мои три примера, которые все требует регистрацию TLB (так или иначе), модифицировать так, чтобы хост перехватывал GetRecordInfoFromGuids, и подсовывал свою реализацию IRecordInfo для заведомо известных UUID-ов нужных типов. TLB тогда станет не нужна, но это будет хак, и могут быть последствия. Я предполагаю теоретическую возможность появления таких последствий: вариант с UDT не сможет отмаршаллиться в апартамент чужого процесса того же самого компьютера (как максимум), или в удалённый апартамент (как минимум).

Я думаю, что маршаллинг Variant-а устроен по умному, и ссылка на IRecordInfo не маршаллится как обычная ссылка, а «перезапрашивается» на удалённой стороне на основе UUID-а типа.

[arthur2]

Собственно, если наружу такую переменную передавать не предполагается, то можно об этом вообще не заморачиваться?

Я так понимаю, что когда в коде идет обращение к полю структуры внутри варианта, бейсик сначала смотрит, VT_USERDEFINED ли это, а затем по названию структуры вызывает соответствующий метод у IRecordInfo? то есть, я сам могу сообщить бейсику, что за тип у этого поля? Всё правильно?

[Хакер]

а затем по названию структуры вызывает соответствующий метод у IRecordInfo?

Почему по названию структуры?

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

Dim v as Variant
v.foo = 2

VB смотрит, что содержит v. Если это не VT_DISPATCH или VT_USERDEFINED, генерируется ошибка «Object required».
Если это VT_DISPATCH, то используется IDispatch::Invoke, чтобы выполнить присвоение свойству foo значения 2.
Если это VT_USERDEFINED, то используется IRecordInfo::PutField, чтобы присвоить полю foo значение 2.

Так делает VB, VBA, VBScript, JavaScript в рамках Script-контрола, и т.д.

_____

Кстати, рекомендую ещё прочитать вот это, чтобы проникнуться идеей о хитрости VB.

[arthur2]

Почему по названию структуры?

б-р-р... по названию поля, хотел сказать В общем, кажется, понятно, как будет работать CreateDynamicUdt

[Хакер]

В общем, кажется, понятно, как будет работать CreateDynamicUdt

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

[arthur2]

Кстати, рекомендую ещё прочитать вот это, чтобы проникнуться идеей о хитрости VB.

О!!! Как раз только-только собирался спросить, как работает тёмичевский же кирпич

[Хакер]

Опять оффтопик.
Он использует Variant-тип с субтипом VT_BYREF. Переменная притворяется ByRef-аргументом функции, хотя она при этом ею не является.
То же, что и это, только более приятно синтаксически, но с учётом медленности варианта-а.
Я не использую тёмычевские прозрачные указатели, мне нравится больше мой быстрый вариант: вместо замаппливания Variant-переменной на нужный мне адрес, я замаппливаю SafeArray-массив на нужный мне адрес. Имею при этом быстроту обычных указателей и возможность написать pointer(10), подобному тому, как я могу в сях написать pointer[10] как аналог *(pointer + 10)

Пример можно посмотреть в любом из моих последних кирпичей. Смотреть функции SaMap/SaUnmap например здесь. Возможность использовать UDT в качестве типа указателя — прилагается, и не требует объявления UDT в TLB в отличие от того же тёмычевского варианта.

[arthur2]

Во чё нашел Читаю... http://www.rsdn.ru/article/com/varsafearr.xml

[arthur2]

Смотреть функции SaMap/SaUnmap

Кстати, здоровский способ! Почему бы тебе не добавить его в свой топик об указателях?

[Хакер]

Потому что я хочу сделать классный кирпич, в котором вместо SaMap — какая-нибудь функция с другим более понятным называнием, а вызывать SaUnmap (про вызов которого если забыть — будт утечка памяти) будет вообще не нужно, потому что SaUnmap будет вызываться автоматически при выходе из процедуры, и в котором не нужно будет вызывать AryPtr.

[arthur2]

Кстати, а чем отличается статический массив от динамического? Я имею ввиду изнутри - SAFEARRAY. Это я к тому. что где тебе нужен указатель на одну структуру, ты объявляешь статические массивы из одного члена, а где нужно двигать указатель, объявляешь его как динамический массив и редимишь.

[ger_kar]

и в котором не нужно будет вызывать AryPtr.

Можно применить Not(Not(pArray)), это имелось ввиду? Вроде бы баг, но какой замечательный, раньше тоже приходилось по всякому извращаться, пока здесь на форуме про эту фишку не прочитал

Кстати, а чем отличается статический массив от динамического? Я имею ввиду изнутри - SAFEARRAY.

Да собственно ничем не отличается. Разница только в том, что для статического массива память распределяется сразу, массив находится на одном месте SAFEARRAY сразу указывает на это место, а переменная массива сразу содержит указатель на SAFEARRAY.

[Хакер]

Можно применить Not(Not(pArray)), это имелось ввиду?

Ни в коем случае не это. Просто сделать свойство
MapArray(тут_указывается_массив) = тут_указывается_адрес
То есть такое же модулярное свойство, каким является свойство FuncPtr в кирпиче MagicFuncPointer.

Разница только в том,

Нет, разница в другом, касательно того аспекта, какой подметил Артур.


Вы осознаёте, что это оффтопик и никак не относится к теме.

[ger_kar]

Да занесло как всегда в оффтоп
Может с этого viewtopic.php?f=1&t=43928&p=6762834#p6762790 стоит перенести в другую тему, этот мой пост снести и все дальше пойдет правильно.

[arthur2]

Вы осознаёте, что это оффтопик и никак не относится к теме

ну так давай перенесем куда-нибудь

Кстати, к теме это тоже вполне может иметь отношение:

1.Как передать эти типы в одну переменную.
2. Как определить, какого типа переменная пришла на вход функции.

В функцию можно передавать указатель на структуру (можно byref as any - с помощью твоего кирпича и переопределения функции через declare). Вторым параметром - идентификатор того, какая именно структура передана. А внутри функции можно работать со структурой как раз через указателемассив.

[Хакер]

Без особых оговорок это просто плохой дизайн.
Если нужно передавать в одну функции нечто очень разное, и чтобы функция с этим что-то дело, то значит у разных сущностей всё равно есть что-то одинаковое. Значит надо использовать ООП-подход, несколько разных классов для разных сущностей, но чтобы все классы поддерживали один и тот же интерфейс. Интерфейс бы объединял те общие моменты, присущие разным сущностям, которые позволяют разным сущностям обрабатываться одной и той же функции. Или интерфейс возможно непосредственно отождествлял бы саму одинаковую задачу, производимую над принципиально разными сущностями.

Или, ладно, к чёрту ООП. Если это разные структуры, они могли бы включать в себя идентичную подструктуру, и аргумент функции должен бы был объявяться с типом этой самой подструктуры.

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

[arthur2]

Я не думаю, что какие-либо из моих кирпичей или трюков тут нужны.

Мне просто нравится пользоваться кирпичом с функциями-указателями как способом переопределить некую функцию. Например, всегда жалел, что в обычной процедуре нельзя объявить параметр as any. А теперь - можно Что, собственно, позволяет "разным сущностям обрабатываться в одной и той же функции"

Если это разные структуры, они могли бы включать в себя идентичную подструктуру, и аргумент функции должен бы был объявяться с типом этой самой подструктуры.

А если, это разные, но конкретные структуры и вносить в них дополнительные поля просто нельзя?

Нет, разница в другом, касательно того аспекта, какой подметил Артур.

Офтоп-неофтоп, но всё-таки интересно...

[ger_kar]

А в варианте Standart EXE + TLB возможна упаковка TLB в файл ресурсов и если да, то как это все можно проделать. Саму TLB конечно засунуть в ресурсы можно как простой бинарный файл, но вот что делать с ним потом? Или такой вариант вообще не прокатит?