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

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

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

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

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

G>

G>return (IUnknown*)this;
G>

this указывает на грань, отличную от IID_IUnknown. Как быть?


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

G>>>>>Первый по порядку (любому).
S>>>>Первый face по любому порядку не обязан быть IUnknown фэйсом, о чем ты?
G>>>Ты и сам говорил что любой интерфейс наследуется от IUnknown и сам хотел делать приведения. Так вот предлагаю делать эти приведения внутри QueryInterface.
S>>Предлагаешь выкинуть сценарии расширения COM объектов? Мне? Я не копенгаген решать такие вопросы.
G>Я предлагаю решение для сценария, который ты сам придумал. Ведь можно и другой сценарий придумать, который будет не менее рабочий, и не менее COM.
Сценарий multiple interface navigation придумал не я. Это довольно типичный сценарий в COM уровня чуть глубже букварного. В спеке он упоминается неоднократно, даже с примерами реализации.

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

Я все жду, какой сценарий ты предпочтешь...
а) COM использует состояние в вычислении ID, значит незазорно использовать данные строки при сравнении двух строк.
б) COM не использует состояние в вычислении ID, значит сравнение строк не использует состояние.