|
That call would only be valid if the method was static! On a side note virtual functions can't be static (it doesn't make sense).
Steve
|
|
|
|
|
I agree Steve, I have tried Rajkumar's solution will cause compile error. 
regards,
George
|
|
|
|
|
Rajkumar is correct.
Steve
|
|
|
|
|
Where is the object man, goo is not a static function to call like.
I would recall steve's example and modify like this,
Derived d.
d.Base::Func(); // scope resolution
|
|
|
|
|
I changed my mind, Rajkumar! You are correct and Steve's sample is wrong. He should use __interface other than class.
__interface Base
{
public:
virtual void Func() = 0 { cout << "Base::Func()" << endl; }
};
class Derived : public Base
{
public: virtual void Func() { cout << "Derived::Func()" << endl; }
};
int main(int argc, char* argv[])
{
Derived d;
d.Base::Func();
return 0;
}
regards,
George
|
|
|
|
|
We need a George_George message board.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Definitely.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
I don't want to argue much on the subject, because i'm simply not an expert about "C++ Interfaces".
and the designation "C++ Interface" is just a paradox and should **NOT** be employed like that.
the C++ Standard doesn't even talk about interfaces.
this is a pure invention of Microsoft and Visual C++ Compiler.
So i'd advise you to be very careful with'em.
that been said, why do you keep argueing with MVPs as if you were better than them ?
the way you reply to Cedric, Stephen and CPallini is not very nice of you, you you should be happy they still answer your weird questions.
|
|
|
|
|
Thanks toxcct!
Previously I think according to MSDN standard __interface should contain only pure virtual methods, but I read some code which contains implemented method in __interface, which makes me confused about my previous knowledge. This is the initiative of why I am asking this question.
regards,
George
|
|
|
|
|
but remember, MSDN is microsoft, thus not standard.
so, MSDN only tells how the Microsoft C++ compiler will understand a C++ code. It never tells that this code is C++ standard. to understand this well, try to compile your code under gcc. you gonna pull some hair !! 
|
|
|
|
|
Hello everyone,
Here is section of code I wrote about AddRef and Release. My questions are,
1. Are they correct code?
2. It looks redundant to call so many times of AddRef and Release just to make the counter consistent, if you were me, do you have ways to write better code?
[Code]
IX* pI = NULL;
pI = pI1;
pI -> AddRef();
...
pI -> Release(); // release before binding to a new interface
pI = pI2;
pI -> AddRef();
...
pI -> Release(); // release before binding to a new interface
pI = pI3;
pI -> AddRef();
...
[/Code]
thanks in advance,
George
|
|
|
|
|
Hello George_George,
Try smart pointers like _com_ptr_t and CComPtr. These are C++ classes which function as wrappers around actual interface pointers.
Each wrapper stores an actual interface pointer internally. AddRef() and Release() are called automatically as you perform assignment and copy operations.
- Bio.
|
|
|
|
|
Hi Bio,
I agree with your comment of using smart pointer like solution. Any comment about my original code, is it correct?
regards,
George
|
|
|
|
|
George_George wrote:
1. Are they correct code?
Yes. Don't forget to call the final release on pI.
George_George wrote: 2. It looks redundant to call so many times of AddRef and Release just to make the counter consistent, if you were me, do you have ways to write better code?
It is the only correct way to handle lifetime of COM objects.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks CPallini,
I have some further thinking. The interface pointers, like pI, pI1, pI2, ... , may be pointed to different instances of object, right?
Here is a sample. Suppose there are 4 object instances of type IX, pointed by pIX1, pIX2, pIX3 and pIX4 repectively. And we have a temporary pointer called pIXTmp. Also suppose at the beginning pIXTmp is NULL;
1. When assigning pIXTmp = pIX1, pIXTmp is pointed to the 1st instance of object;
2. When assigning pIXTmp = pIX2, we need to call Release at first, pIXTmp -> Release() to decrease the reference counter for the 1st object instance, and call pIXTmp -> AddRef() to increase reference conuter to the 2nd object. You can see AddRef and Release are working on different object instance.
Is my understanding correct? Previously, I have not thought of the case when interfaces pointed to different object instances.
regards,
George
|
|
|
|
|
Oh George, we're coming back to OOP basics: by definition a method acts on this object (i.e. on pointed instances in your example)!
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks CPallini,
I think you agree with my above statements about interfaces pointing to different object instances, right?
regards,
George
|
|
|
|
|
Do you really need comfort about?
My answer was and is yes.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Thanks CPallini,
My question is answered.
regards,
George
|
|
|
|
|
Hello everyone,
In the book "Inside COM", there is an interesting code segment like this,
IUnknown* CreateInstance()
{
IUnknown* pI = static_cast <ix*> (new CA);
pI -> AddRef();
return pI;
}
</ix*>
My question is, why static_cast <ix*> to result in IUnknown*? Why not static_cast <iunknown*> to result in IUnknown* to be more straightforward (even if I think using IX* and IUnknown* have the same effect)? Are there any reasons or advantages if we use IX* other than IUnknown*?
thanks in advance,
George
|
|
|
|
|
George_George wrote: My question is, why static_cast to result in IUnknown*? Why not static_cast to result in IUnknown* to be more straightforward (even if I think using IX* and IUnknown* have the same effect)? Are there any reasons or advantages if we use IX* other than IUnknown*?
Sorry, but I'm not able to understand the above sentences.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi CPallini,
My question is, can I use
IUnknown* pI = static_cast <IUknown*> (new CA);
other than
IUnknown* pI = static_cast <IX*> (new CA);
regards,
George
|
|
|
|
|
Probably you have some issue on formatting code. However, IMHO, yes and probably is more coherent.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
Hi CPallini,
I have correctly posted my code. Could you review and comment again?
regards,
George
|
|
|
|
|
My comment is the same:
IMHO, yes (i.e. you can use IUnknown* pI = static_cast <IUknown*> (new CA)) and probably is more coherent.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
