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

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

G>>Да, но "приведение типов" с точки зрения com не совсем законная операция. Чтобы получить указатель на конкретный интерфейс надо обяpательно выполнять QI.
S>Вот в этом я не уверен. Беглый просмотр интернетов не дал ответа на вопрос, обязан ли я перезапрашивать интерфейс-предок, или таки нет.

ровно по той же причине по которой надо запрашивать QueryInterface(IUnknown) надо запрашивать и другие интерфейсы. Иначе просто не создавали бы эту функцию.

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

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

G>>Да, но "приведение типов" с точки зрения com не совсем законная операция. Чтобы получить указатель на конкретный интерфейс надо обяpательно выполнять QI.
S>Вот в этом я не уверен. Беглый просмотр интернетов не дал ответа на вопрос, обязан ли я перезапрашивать интерфейс-предок, или таки нет.
Мне тоже этот вопрос до конца не ясен в общем случае. Думаю, что любая навигация между интерфейсами должна производиться через QI. Но для того что бы переключиться, надо обратиться к методу QI интерфейса IUnknown (без IID). Вот к этому методу мы можем обращаться не вызывая QI(IID_IUnknown) (здесь IID не случайно), т.к. все интерфейсы одного объекта обязаны возвращать согласованные результаты QI. Отсюда следует, что любой интерфейс может быть использован как IUnknown без запроса QI(IID_IUnknown).

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

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

G>>>Его не надо хранить. Ты заранее выбери один интерфейс, к которому будет приводиться.
S>>Интерфейсы pXXX и pYYY лежат в разных местах. Нужна навигация между ними. Приведением навигацию не обеспечить.
G>Да без разницы, нам только надо возвращать всегда одинаковую ссылку на QueryInterface(IUnknown), остальное не интересует.
Интересует как ты будешь это выполнять в общем случае без состояния.


G>>>

G>>>return (IUnknown*)this;
G>>>

S>>this указывает на грань, отличную от IID_IUnknown. Как быть?
G>Пусть указывает, ведь каждый интерфейс является всегда IUnknown и при данной реализации всегда будет возвращать одно значение.
Это противоречит спецификации. Все интерфейсы/грани объекта должны возвращать всегда один и тот же указатель при запросе QI(IID_IUnknow).
G>Или ты что-то другое имеешь ввиду?
Именно то что пишу.


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

G>>>Я предлагаю решение для сценария, который ты сам придумал. Ведь можно и другой сценарий придумать, который будет не менее рабочий, и не менее COM.
S>>Сценарий multiple interface navigation придумал не я. Это довольно типичный сценарий в COM уровня чуть глубже букварного. В спеке он упоминается неоднократно, даже с примерами реализации.
G>А пример такого в компонентах есть?
В каких именно компонентах?
Я думаю что такие примеры надо искать не в компонентах в SDK продуктов типа ESRI ArgGIS и т.п. Вместо того что бы в дотнете наследоваться от IPlugin, COM прелагает именно агрегацию для расширения объектов.

S>>Не без разницы. Я тебе указываю на те случаи, когда результат QI нужно хранить в состоянии грани. Ты их упорно игнорируешь.
G>Если ты сделал такую реализацию что надо хранить, то ССЗБ. Не делай такую реализацию. Я же тебе говорил что можно почти все сделать через механизмы множественного наследования, которые уже давно работают в разных языках.
В Visual Basic тоже?
Нет, это если ты предлагаешь забить на агрегацию вопреки спеке COM, то ты ССЗБ.

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

S>Мне тоже этот вопрос до конца не ясен в общем случае. Думаю, что любая навигация между интерфейсами должна производиться через QI. Но для того что бы переключиться, надо обратиться к методу QI интерфейса IUnknown (без IID). Вот к этому методу мы можем обращаться не вызывая QI(IID_IUnknown) (здесь IID не случайно), т.к. все интерфейсы одного объекта обязаны возвращать согласованные результаты QI. Отсюда следует, что любой интерфейс может быть использован как IUnknown без запроса QI(IID_IUnknown).
Полагаю, вы правы. Согласованность результатов QI при обращении через разные интерфейсы гарантирована стандартом.
А вот то, что IWebBrowser2 можно пользоваться так же, как и IWebBrowser, не гарантирована ничем

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


G>>>>Не все сценарии, но основные вполне, для которых COM создавался — вполне. Некоторые фичи com по-моему вообще в дикой природе не встретишь.
S>>>Так ты предлагаешь отказаться от сценариев, где требуется состояние для реализации QI для того что бы убедить меня в том, что разработчики спеки не подразумевали использование состояния в QI при вычислении identity?
G>>Нет, я лишь говорю что если ты придумываешь сложности — ты их и решай. Но принципиальных проблем обеспечить независимость от состояния QueryInterface(IUnknown) я не вижу.
S>Это не мои сложности и я не вижу, как выполнить QI в общем случае без того что бы вернуть значение, хранящееся в состояние.
Как раз кроме отдельных извращенных случаев, которые нельзя свести множественному наследованию, можно без состояния. Ты же сам приводишь реализацию с состоянием и говоришь что там identity без состояния нельзя. Конечно нельзя, ты же сам сделал там состояние.

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

[]

S>Увы — получится. Надо просто отличать два понятия:
S>1. Просто указатель на IUnknown — любой указатель в COM является также и указателем на IUnknown. По причине наследования интерфейсов.

Разве COM говорит что-то про наследование? Что есть наследование, если объект реализован на Делфи а используется в С?
Говорить о "наследовании", афаик, можно только в терминах QI.

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

P>Разве COM говорит что-то про наследование?
Конечно. Про наследование интерфейсов.

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

I>>Это слишком общая формулировка. Разве здесь сказано, что "все структуры данных должны иметь хотя бы один метод для работы с этими данными" ?

L>Конечно общая. ООП — это вообще довольно мутное понятие.

Ну что, господа, наставившие минусов, количество сообщений в теме еще не убедило вас в правоте отквоченной фразы?

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

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


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

L>> Более того, очень многими неглупыми людьми ставится под сомнение его полезность.
М>про все ооп не скажу, но вот никак не могу понять -- действительно ли язык программирования должен быть таким сложным, как плюсы? говорят, что плюсы обеспечивают высокую производительность. и где же она?
для того чтобы получить высокую производительность, нужно проектировать для высокой производительности. Производительность не может быть поздней идеей, так же как и безопасность.
Программа не станет автоматичски быстрой если ее просто писать на плюсах, или безопасной — если писать на .нет\жабе


М>вот я и думаю -- а что мне дадут плюсы, если их выучить?
тебе — скорее всего ничего. Ты сам много раз говорил что ты не разработчик, а реверсер.

М>у плюсов же -- производительность только в теории, на практике оно тормозит и отжирает память
ты вообще-то рассуждаешь о том чего не знаешь

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

М>>у плюсов же -- производительность только в теории, на практике оно тормозит и отжирает память
R>ты вообще-то рассуждаешь о том чего не знаешь
для того, чтобы разбираться в устрицах не обязательно их готовить. достаточно их есть.

М>для того, чтобы разбираться в устрицах не обязательно их готовить. достаточно их есть.
ну конечно, попользовался несколькими продуктами и однозначно сделал вывод и достоинствах языка на котором он написан

S>Это не определение. Это чушь, которой забивают мозг неопытным разработчикам. Потом их очень трудно лечить от заблуждений.
S>Для начала, нужно твёрдо усвоить, что ООП — оно целиком про поведение. А не про структуру полей и методов.
А что в твоем понимании есть ооп? (Гугл выдал нерелевантные запросы на алана кея и определение ооп)
В моем понимании OOP — есть просто следствие OOD(esign). Т.е. если софт следует OOD принципам, таким как SOLID — програмирование можно считать ОО, независимо от того если в языке такие инструменты как классы, наследование или полиморфное поведение.

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

VD>А так тема очень широкая, так как методы метапрограммирования и DSL-естроения очень разнообразны. От строковой конкатинации и T4, до Nemerle и Lisp.

Ви ест имели в виду m4 ?

Просто, мне, как человеку, ежедневно использующему, режет глаз.

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

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

VD>>А так тема очень широкая, так как методы метапрограммирования и DSL-естроения очень разнообразны. От строковой конкатинации и T4, до Nemerle и Lisp.

B>Ви ест имели в виду m4 ?
http://en.wikipedia.org/wiki/Text_Template_Transformation_Toolkit

B>Просто, мне, как человеку, ежедневно использующему, режет глаз.

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

VD>>А так тема очень широкая, так как методы метапрограммирования и DSL-естроения очень разнообразны. От строковой конкатинации и T4, до Nemerle и Lisp.

B>Ви ест имели в виду m4 ?

Не, M16, конечно еже .

B>Просто, мне, как человеку, ежедневно использующему, режет глаз.

Ежедневно использующему что? Lisp, Nemerle или T4?

Я, вообще-то, говорил о текстуальном шаблонизаторе T4. Это, конечно же, очень убогий тул. Но за не имением прекрасной горничной, как говорится, имеют старого дворника.

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

[]

P>>Разве COM говорит что-то про наследование?

S>Конечно. Про наследование интерфейсов.

Можно развернуть? Имеется в виду

IUnknown* u1 = QI(...)
IUnknown* u2 = (IUnknown*)some_iface_ptr;
assert(u1 != u2);

?

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

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

P>[]

S>>Увы — получится. Надо просто отличать два понятия:
S>>1. Просто указатель на IUnknown — любой указатель в COM является также и указателем на IUnknown. По причине наследования интерфейсов.

P>Разве COM говорит что-то про наследование? Что есть наследование, если объект реализован на Делфи а используется в С?
COM определяет двоичный стандарт, потому возможность самого вызова COM объекта — это забота производителя компилятора, не говоря уже о наследовании.
P>Говорить о "наследовании", афаик, можно только в терминах QI.

3.3 The IUnknown Interface
This specification has already mentioned the IUnknown interface many times. It is the fun-
damental interface in COM that contains basic operations of not only all objects, but all
interfaces as well: reference counting and QueryInterface. All interfaces in COM are poly-
morphic with IUnknown, that is, if you look at the first three functions in any interface you
see QueryInterface, AddRef, and Release. In other words, IUnknown is base interface from which
all other interfaces inherit.

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

P>Можно развернуть? Имеется в виду
P>?
Нет. Не надо усложнять. COM говорит о том, что интерфейсы могут наследоваться друг от друга, но любой интерфейс, явно или неявно, обязан наследоваться от IUnknown. Что именно вам непонятно?

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

I>>>Это слишком общая формулировка. Разве здесь сказано, что "все структуры данных должны иметь хотя бы один метод для работы с этими данными" ?

L>>Конечно общая. ООП — это вообще довольно мутное понятие.

L>Ну что, господа, наставившие минусов, количество сообщений в теме еще не убедило вас в правоте отквоченной фразы?

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