Добрый день. есть проблема. MFC советуют использовать вложение вместо наследования при реализации интерфейсов описанных в структурах, но как быть если внутри библиотеки необходимо добраться до члена класса за интерфейсом. Вот код:
В данном случае пользователю библиотеки совершенно не хочеться знать что у человека жолжен быть внутри описано свойство КРЕСЛО, пользователь хочет лишь посадить человека в машину в которой он уже знает что есть за кресла...
КАК ДОБРАТЬСЯ ИЗ
virtual bool SeatToCard (const ICar&);
до
CArmchair *m_pArmchair;
в CCar...?
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Здравствуйте, np9mi7, Вы писали:
N>Добрый день. есть проблема. MFC советуют использовать вложение вместо наследования при реализации интерфейсов описанных в структурах, но как быть если внутри библиотеки необходимо добраться до члена класса за интерфейсом.
Посмотри макросы METHOD_PROLOGUE и пр. Из MSDN:
class CInnerUnknown : public IUnknown
...
CInnerUnknown InnerUnknown;
...
// Inner IUnknown implementation
STDMETHODIMP_(ULONG) CInnerUnknown::AddRef()
{
METHOD_PROLOGUE(CCmdTarget, InnerUnknown)
returnpThis->InternalAddRef();
}
дело в том что этот макрос pThis устанавливает на IUnknown, когда this указывает на CInnerUnknown... У меня немного другая ситуация:
мне из
virtual bool SeatToCard (const ICar&)
— метод CPeople, нужно добраться до
CCar->getArmchair()
те зная объявление ССar (тк внутри библиотеки) + ICar — параметр (у которого есть реализация в этом классе, как она выглядет я не знаю — вложен класс) нужно добраться до
CCar->getArmchair()
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Здравствуйте, np9mi7, Вы писали:
N>те зная объявление ССar (тк внутри библиотеки) + ICar — параметр (у которого есть реализация в этом классе, как она выглядет я не знаю — вложен класс) нужно добраться до
CCar->getArmchair()N>
Как-то так:
STDMETHODIMP_(bool) CPeople::XPeopleInCar::SeatToCard(/*[in]*/const ICar&)
{
METHOD_PROLOGUE(CPeople, PeopleInCar)
pThis->getArmchair(); // к функции, если позволит доступ
pThis->m_pArmchair; // к данным, если позволит доступ
...
}
N>>те зная объявление ССar (тк внутри библиотеки) + ICar — параметр (у которого есть реализация в этом классе, как она выглядет я не знаю — вложен класс) нужно добраться до
CCar->getArmchair()N>
Vi2>Как-то так: Vi2>
Vi2>STDMETHODIMP_(bool) CPeople::XPeopleInCar::SeatToCard(/*[in]*/const ICar&)
Vi2>{
Vi2> METHOD_PROLOGUE(CPeople, PeopleInCar)
Vi2> pThis->getArmchair(); // к функции, если позволит доступ
Vi2> pThis->m_pArmchair; // к данным, если позволит доступ
Vi2>...
Vi2>}
Vi2>
неа... тут Вы получите указатель pThis на CPeople->getArmchair()... а мне нужно на CCar->getArmchair()....
если вы заметили, CPeople->getArmchair() — вообще этого метода нет!
METHOD_PROLOGUE(CPeople, PeopleInCar) — он и поднимет pThis на CPeople, а мне нужно на CCar!!!
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Здравствуйте, np9mi7, Вы писали:
N>неа... тут Вы получите указатель pThis на CPeople->getArmchair()... а мне нужно на CCar->getArmchair().... N>если вы заметили, CPeople->getArmchair() — вообще этого метода нет!
N>METHOD_PROLOGUE(CPeople, PeopleInCar) — он и поднимет pThis на CPeople, а мне нужно на CCar!!!
Если между CPeople и CCar нет внутренней связи, то ответ — никак.
жаль...
ТЕ полюбому нужно както передавать параметрически... черт...
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Здравствуйте, np9mi7, Вы писали:
N>жаль... N>ТЕ полюбому нужно както передавать параметрически... черт...
Мысли в терминах интерфейсов. Нет необходимости выставлять интерфейс (т.е. публиковать), но пользоваться-то им можно и без этого. Тем более что это твои классы и твои интерфейсы. Создай интерфейс, по которому можно обратиться к реализации ICar (т.е. CCar) через ICar::QueryInterface(IID_Armchair,&pArmchair) и Armchair->getArmchair();
Здравствуйте, Vi2, Вы писали:
Vi2>Мысли в терминах интерфейсов. Нет необходимости выставлять интерфейс (т.е. публиковать), но пользоваться-то им можно и без этого. Тем более что это твои классы и твои интерфейсы. Создай интерфейс, по которому можно обратиться к реализации ICar (т.е. CCar) через ICar::QueryInterface(IID_Armchair,&pArmchair) и Armchair->getArmchair();
ДА дело в том, что хотелось бы все эти вещи скрыть от пользователя. те, чтоб пользователь общался именно с теми интерфейсами которые я ему дам, не хотелось бы ему на верх отдавать КРЕСЛА...
Я вот думаю, может создать такой мега объект в котором описать как и МАШИНУ так и ЧЕЛОВЕКА В МАШИНЕ?
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Здравствуйте, np9mi7, Вы писали:
N>ДА дело в том, что хотелось бы все эти вещи скрыть от пользователя. те, чтоб пользователь общался именно с теми интерфейсами которые я ему дам, не хотелось бы ему на верх отдавать КРЕСЛА...
Пользователь увидит лишь тот интерфейс у объекта, который описан в IDL/ODL/TLB файле для данного кокласса. Если там будет
, то вообще неясно на какие интерфейсы будет откликаться этот объект. Также нет механизма, кроме описания кокласса в IDL/ODL/TLB файле, получения всех интерфейсов объекта. Потому что способ в СОМе прост: знаешь про интерфейс — запрашиваешь его у объекта. Если объект его понимает, то он отвечает, если не понимает, то возвращает код ошибки E_NOINTERFACE.
Более того, не каждый интерфейс, описанный в IDL/ODL файле, попадает в TLB файл. Если на интерфейс ничто в секции [library] не ссылается, то он в TLB не попадет, однако всегда попадет в H файл, генерируемый MIDLом. И поэтому твой сервер может спокойно работать с описанием этого интерфейса, знать его IID и т.п.
Единственная трудность при таком проектировании: нет описания интерфейса в TLB, значит, и нет typelib-маршаллинга интерфейса. Поэтому нужно предусматривать нахождение объектов в одном апартменте, что не всегда возможно, но почти всегда выполняется .
да, действиетльно раз возникли такие заморочки, имеет смысл задаться вопросами нормального проектирования и постановки другого взгляда на задачу...
СПАСИБО ЗА ПОМОЩЬ!!!!!!
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.