Я конечно понимаю что dynamic_cast это не то что нужно использовать для COM интерфейсов, что правильно использовать QueryInterface и т.п. Но все таки, могу ли я использовать dynamic_cast хотя бы для того, что бы узнать, может это мне известная реализация COM интерфейса, хотя бы для оптимизации по скорости работы с этим интерфейсом. Допустим что реализация не имеет своего UUID, поэтому QueryInterface не подходит.
Здравствуйте, sergey_shandar, Вы писали:
_>Я конечно понимаю что dynamic_cast это не то что нужно использовать для COM интерфейсов, что правильно использовать QueryInterface и т.п. Но все таки, могу ли я использовать dynamic_cast хотя бы для того, что бы узнать, может это мне известная реализация COM интерфейса, хотя бы для оптимизации по скорости работы с этим интерфейсом.
Никто не может запретить тебе использовать dynamic_cast. Но в СОМе стратегия — QueryInterface.
НО... я не совсем в курсе, как реализуется по стандарту dynamic_cast, но скорее всего на сравнении vtable для нужных типов. Но в таком случае прокси DLL или серверная DLL, поскольку она базируется на своих данных, будет давать несовместимые vtable.
_>Допустим что реализация не имеет своего UUID, поэтому QueryInterface не подходит.
Интерфейсу без разницы есть ли у его реализации UUID или нет. Точно так же и клиенту нет необходимости знать КАКИМ объектом ЭТОТ интерфейс реализован.
Если тебя интересует определение своих реализаций, то делай приватный интерфейс и запрашивай его.
Здравствуйте, Vi2, Вы писали:
Vi2>Здравствуйте, sergey_shandar, Вы писали:
_>>Я конечно понимаю что dynamic_cast это не то что нужно использовать для COM интерфейсов, что правильно использовать QueryInterface и т.п. Но все таки, могу ли я использовать dynamic_cast хотя бы для того, что бы узнать, может это мне известная реализация COM интерфейса, хотя бы для оптимизации по скорости работы с этим интерфейсом.
Vi2>Никто не может запретить тебе использовать dynamic_cast.
Может. Смотри ниже.
Vi2>НО... я не совсем в курсе, как реализуется по стандарту dynamic_cast, но скорее всего на сравнении vtable для нужных типов. Но в таком случае прокси DLL или серверная DLL, поскольку она базируется на своих данных, будет давать несовместимые vtable.
По крайней мере proxy/stub dll создает объект который валиться по exception (хотя не факт что должен валиться, повезло видимо). Но, мне хотя бы узнать что, это мой объект (т.е. я его создал в этом адресном простанстве) или это какой то объкт сгенерированный с помощью proxy/stub dll? Если у меня будет средство отвечающее на этот вопрос, то я сам дальше уже буду думать, то ли dynamic_cast попробовать, то ли QueryInterface. Т.е., такой ленивый QueryInterface получаеться.
_>>Допустим что реализация не имеет своего UUID, поэтому QueryInterface не подходит.
Vi2>Интерфейсу без разницы есть ли у его реализации UUID или нет. Точно так же и клиенту нет необходимости знать КАКИМ объектом ЭТОТ интерфейс реализован.
QueryInterface не без разницы В это и проблема.
Vi2>Если тебя интересует определение своих реализаций, то делай приватный интерфейс и запрашивай его.
Вот этого как раз и хотелось избежать. Я понимаю что это решение. Но не нравиться оно мне. Слишком много этих приватных интерфейсов получиться.
Простите за настойчивость, я понимаю что проблема на самом деле решаемая. Но все таки. Можно ли определить — это proxy/stub dll сделала объект, или нет?
Здравствуйте, sergey_shandar, Вы писали:
_>Можно ли определить — это proxy/stub dll сделала объект, или нет?
Т.е. был ли маршаллинг или нет? Есть масса способов это сделать. Дело в том, что прокси объекта реализует дополнительные интерфейсы, которые не поддерживает исходный объект. Навскидку, например, IMultiQI, IClientSecurity. Может еще какие есть. Также, в частности, и так можно ИНФО: Как получить Cx из Ix*
_>>Я конечно понимаю что dynamic_cast это не то что нужно использовать для COM интерфейсов, что правильно использовать QueryInterface и т.п. Но все таки, могу ли я использовать dynamic_cast хотя бы для того, что бы узнать, может это мне известная реализация COM интерфейса, хотя бы для оптимизации по скорости работы с этим интерфейсом.
Vi2>Никто не может запретить тебе использовать dynamic_cast. Но в СОМе стратегия — QueryInterface.
Vi2>НО... я не совсем в курсе, как реализуется по стандарту dynamic_cast, но скорее всего на сравнении vtable для нужных типов. Но в таком случае прокси DLL или серверная DLL, поскольку она базируется на своих данных, будет давать несовместимые vtable.
dynamic_cast базируется на RTTI по этому код если там будет прокси — то просто упадёт.
Здравствуйте, Tom, Вы писали:
Tom>dynamic_cast базируется на RTTI по этому код если там будет прокси — то просто упадёт.
RTTI может быть реализована многими способами, в частности, и с падением (точно также как и debug/release выделение памяти). Это уже какие руки кривые у компиляторщиков, а им это, скорее всего, и отдано на откуп.
Но в СОМе стратегия — QueryInterface.
