C / C++ / MFC

Re: non-pure virtual function in C++ interface

4-Feb-08 2:01

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. Smile | :)

regards,
George

toxcct4-Feb-08 2:09

toxcct

4-Feb-08 2:09

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 !! Poke tongue | ;-P

[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]

AddRef and Release

George_George3-Feb-08 15:01

3-Feb-08 15:01

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

Lim Bio Liong3-Feb-08 19:15

Lim Bio Liong

3-Feb-08 19:15

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.

George_George3-Feb-08 19:23

3-Feb-08 19:23

Hi Bio,

I agree with your comment of using smart pointer like solution. Any comment about my original code, is it correct?

regards,
George

CPallini3-Feb-08 22:39

3-Feb-08 22:39

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]

George_George3-Feb-08 22:46

3-Feb-08 22:46

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

CPallini3-Feb-08 22:56

3-Feb-08 22:56

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)!
Smile | :)

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]

George_George3-Feb-08 23:04

3-Feb-08 23:04

Thanks CPallini,

I think you agree with my above statements about interfaces pointing to different object instances, right?

regards,
George

CPallini3-Feb-08 23:34

3-Feb-08 23:34

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]

George_George3-Feb-08 23:50

3-Feb-08 23:50

Thanks CPallini,

My question is answered.

regards,
George

CreateInstance

George_George3-Feb-08 14:52

3-Feb-08 14:52

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 an interface is derived from IUnkown, IY is an interface derived from
// IUnknown and CA is a class directly derived from both IX and IY.
</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

CPallini3-Feb-08 21:52

3-Feb-08 21:52

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]

George_George3-Feb-08 22:02

3-Feb-08 22:02

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

CPallini3-Feb-08 22:08

3-Feb-08 22:08

Probably you have some issue on formatting code. However, IMHO, yes and probably is more coherent.
Smile | :)

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]

George_George3-Feb-08 22:10

3-Feb-08 22:10

Hi CPallini,

I have correctly posted my code. Could you review and comment again? Smile | :)

regards,
George

CPallini3-Feb-08 22:19

3-Feb-08 22:19

My comment is the same:
IMHO, yes (i.e. you can use IUnknown* pI = static_cast <IUknown*> (new CA)) and probably is more coherent.
Smile | :)

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]

George_George3-Feb-08 22:25

3-Feb-08 22:25

Hi CPallini,

You are wrong. Smile | :)

It can not compile. Here is similar code segment to reproduce this issue. Do you know why there is compile error?

class Base {
public:
	int foo() {cout << "Base" << endl;}
};

class Derived1: public Base
{
public:
	int foo() {cout << "Derived1" << endl;}
};

class Derived2: public Base
{
public:
	int foo() {cout << "Derived2" << endl;}
};

class Final: public Derived1, public Derived2 {
public:
	int foo() {cout << "Final" << endl;}
};

int main()
{
	Final f;
	Base* pb = &f; //error C2594: 'initializing' : ambiguous conversions from 'Final *' to 'Base *'
	return 0;
}

regards,
George

CPallini3-Feb-08 22:35

3-Feb-08 22:35

OK, It seems I missed the diamod issue of multiple inheritance.
BTW you can simply fix it choosing a derivation path, for instance:

Base* pb = (Derived1 *)&f;

hence my suggestion, on the OP becomes

IUnknown* pI = static_cast<iunknown*>(static_cast <ix*> (new CA));
</ix*></iunknown*>

Weird, I know, but descriptive.

BTW diamond inheritance scheme is evil and should be avoided.

Smile | :)

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]

George_George3-Feb-08 22:40

3-Feb-08 22:40

Thanks CPallini,

I am confused why there is ambiguity issue. In my knowledge, class instance is different by the data members, but common (share) in executable code.

In my sample, IUnknown, IX and IY are all classes which do not have data members, they should share the common executable code. Could you explain in more details why compiler complaint ambiguity issue and what blocks compiler from type conversion?

regards,
George

CPallini3-Feb-08 22:52

3-Feb-08 22:52

Since C++ hasn't special syntax for interfaces, I think the compiler isn't allowed to make special assumptions on them. I mean the compiler probably behaves as it was dealing with standard classes (that can have data members), hence finds ambiguities on derivation path.
Smile | :)

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]

George_George3-Feb-08 23:01

3-Feb-08 23:01

Hi CPallini,

We can discuss in the situation of class other than interface. Smile | :)

Ambiguity means more than one different values could be selected. The different values in class is data members, not functions.

You can see there is no data members in IUnknown, IX and IY. Why there is ambiguity (I am not sure whether I have made myself understood about why in my context there is ambiguity)? I think the ambiguity occurs because of the data members are different.

regards,
George

CPallini3-Feb-08 23:33

3-Feb-08 23:33

George_George wrote:
We can discuss in the situation of class other than interface.

Actually the OOP term to designate a C++ abstract class is interface.

George_George wrote:
Ambiguity means more than one different values could be selected. The different values in class is data members, not functions.

I know that. But, as I suggested before, since C++ syntax has no special syntax to designate interfaces (i.e. abstract classes) then probably the compiler cannot make assumptions on them and remains stuck to the more general case, thus finding (inexisting) ambiguities on the derivation path.
However, there is another reason I missed before: suppose, for instance, both IX and IY classes override one IUnknown member, say AddRef, due to polymorphism, how can the compiler resolve between IX::AddRef or IY::AddRef if it cannot make assumptions on the abstract nature of IX and IY classes?
Smile | :)

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]

George_George3-Feb-08 23:53