Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, samius, Вы писали:

S>>Для того что бы узнать, указывают ли pXXX и pYYY на интерфейсы одного COM объекта, по спеке нужно у pXXX и pYYY вызвать QI(IID_IUnknown, &tmp) и сравнить вернувшиеся указатели.
S>>Вопрос, существует ли способ реализовать QI БЕЗ ИСПОЛЬЗОВАНИЯ СОСТОЯНИЯ корректным образом (в соответствии со спекой), что бы он в случе различных pXXX и pYYY вернул одинаковый результат?
G>Да сортируешь все интерфейсы по значению GIUD, выбираешь первый, приводишь всегда к нему. Где тут состояние? Любое честное или неочень изменение объекта не нарушит данное поведение.
Где предлагаешь хранить коллекцию интерфейсов, если не в состоянии?

G>Можно добавить еще одну "грань" к которой приводить. И снова любое честное и неочень изменение состояния не нарушит поведение, специфицированное COM.
Где хранить указатель на грань?

S>>Так вот, QI(IID_IUnknown) должна возвращать указатель на IUnknown грань. В нетривиальных случаях, когда объект имеет multiple interface, результат QI(IID_IUnknown) должен где-то хранитсья.
G>Это будет еще одна грань напрмиер.
Так где будем хранить указатель?

S>>Подозреваю что в состоянии, а никак не в константе.
G>Ниугадал.
покажи код

S>>И QI должна будет взять указатель из состояния и вернуть его. И ты называешь это независимостью от состояния? Я ничего не попутал?
G>Никто ниоткуда ниче не должен брать. Это работает на уровне реализации наследования в языке и никакое состояние руками создавать не надо. А в .NET вообще есть interface map, там проблем таких в принципе нет.
Реализация наследования в каком-то языке не покрывает сценарии использования СOM. В дотнет тем более.

G>Вообще странно что ты не можешь придумать как сделать множественное наследование интерфейсов, которое работает только через this. Эта задача уже многократно реализована.
Демагогия детектед.
Не по адресу — спеку COM писал не я.
Не вовремя — спеку писали очень давно и уже успели налабать толпу кода, так что предложение запоздало.
Не в кассу — разработчики COM знали про множественное наследование, просто они COM разрабатывали не под языки со множественным наследованием и предполагали сценарии реюза объектов отличные от множественного наследования и composition/delegation, в том числе cross-language сценарии реюза и расширения.


S>>>>QI не является детерминированной в общем случае.
G>>>Для IUnknown — является. Этого достаточно.
S>>Этого недостаточно что бы считать QI независящей от состояния даже в случае IUnknown.
G>А что тогда считать "независимостью от состояния"? Тогда любой из твоих ранее приведенных примеров идентичности зависит от состояния.
G>Независимость от состояния обозначает ровно одно — результат функции не меняется при любом (честно или нет) изменении состояния объекта.
Об этом не очень спортивно говорить, когда ты берешь состояние и возвращаешь его в качестве результата.

G>В COM всегда можно сделать реализацию identity, которая при любом изменении состояния, не нарушающим целостность объекта, не будет зависеть от состояния.
Что бы оперировать такими аргументами, ты должен согласиться с ними сперва. Ты же мне говорил что "опираться на состояние" не по правилам вычисления identity.

G>>>>>Если нужна реализация, то пусть возвращается всегда первый face.
S>>>>Я не понял, что такое первый face, откуда он берется, и почему он должен быть именно IUnknown гранью.
G>>>Первый по порядку (любому).
S>>Первый face по любому порядку не обязан быть IUnknown фэйсом, о чем ты?
G>Ты и сам говорил что любой интерфейс наследуется от IUnknown и сам хотел делать приведения. Так вот предлагаю делать эти приведения внутри QueryInterface.
Предлагаешь выкинуть сценарии расширения COM объектов? Мне? Я не копенгаген решать такие вопросы.
И вообще, QI придумали именно для того, что бы обрулить сценарии расширения и реюза. Он такой именно поэтому. И идентичность в COM определена через QI именно для этих целей. В своем маленьком объекте, не предназначенном для расширения, ты можешь так и сделать. Но мы говорим об идентичности в COM, а не идентичности COM объекта написанного на C++ и не предполагающего расширение.