Pure virtual methods and interface class

Hello,
I develop add-ons for MS Flight Simulator and I use the poorly documented SDK for this. The SDK provides a .h file in which an interface class is defined (with pure virtual methods only), something like this:

Code:

---

class IPanelCCallback {
public:
        virtual IPanelCCallback* QueryInterface (PCSTRINGZ pszInterface) = 0;
        virtual bool  ConvertStringToProperty (PCSTRINGZ keyword, SINT32* pID) = 0;
        virtual bool  ConvertPropertyToString (SINT32 id, PPCSTRINGZ pKeyword) = 0;
};

---

In my code, I use this interface like this:

Code:

---

IPanelCCallback* pCallBack = panel_get_registered_c_callback("fs9gps");
...
SINT32 id;
pCallBack->ConvertStringToProperty(propertyName, &id);

---

Everything works fine, but I don't understand why... I thought the linker would stop with an "undefined symbol" error because the IPanelCCallback methods, such as ConvertStringToProperty, are declared as pure virtual but defined nowhere, and I don't use any library for linking. With such an interface class, I thought I would have to defined a subclass of IPanelCCallback and define the ConvertStringToProperty method. My code works, so I shouldn't complain, but I would like to know more about the use of interface classes, this is a subject I don't know much.

Any information is greatly welcome !!

Thank you,
Eric

The panel_get_registered_c_callback function returns a derived object of the IPanelCCallback base type. Object creation functions like this is quite common in OO.

The question is who owns the object, that is who deletes it, you or the SDK?

Yes, I understand what you say. Indeed, panel_get_registered_c_callback returns a pointer on a subclass of IPanelCCallback, the signature is:

Code:

---

IPanelCCallback* (FSAPI *panel_get_registered_c_callback) (PCSTRINGZ name);

---

I don't really know if I am in charge of deleting this pointer. I don't do it in my code but I think I should...
Anyway, the compiler and linker do not "see" this, they see the usage of a pure virtual class so I thought it would fail when linking. But I am happy to know it is a common way of using interface classes.

Thank you, I learnt something :)

Eric

Quote:

---

Originally Posted by Rocky651

Anyway, the compiler and linker do not "see" this

---

It's not as much what the compiler or linker sees as what C++ allows and it's perfectly fine to define variables of virtual classes. What you cannot do is creating objects of a virtual class. For that the class must be fully concrete.

Your example has both. A variable of a virtual class and a function that delivers objects of a concrete implementation of that virtual class.

Basically it's this ability to define variables of virtual classes that constitutes the very core of OO. The variable is not limited to holding objects of just one class. It can hold objects of any class as long as it implements the virtual class. This is how OO injects flexibility into code.

All right, I understand now. You're right, a pure virtual class can be used but cannot be instanciated, this is where my confusion comes from. In my code, there is no instanciation, the creation of the derived class is made by the code I don't see, which returns a pointer on IPanelCCallback. It is now perfectly clear to me.

Thank you for your great explanations :)
Eric

In addition, this is the typical COM scenario. You're interfacing to MS FliSi, and if this doesn't use COM then what does? ;) The root point of getting hold of any COM object is to obtain a pointer to its IUnknown interface which every COM object is required to implement. You're obtaining a pointer to a higher level interface from some higher level instance, but that doesn't really change anything about the principle.

Quote:

---

Originally Posted by Eri523

In addition, this is the typical COM scenario.

---

Well, if COM is involved it's quite easily recognizable. The pure virtual class definitions usually look something like this, at least in Microsoft code,

Code:

---

[uuid("FEC0E939-41BF-46E3-AA13-A6E66A8CA2F2")]
__interface IWindow : public IUnknown {
  HRESULT __stdcall Show(__in bool isVisible);
  HRESULT __stdcall RedrawWindow();
// .......
};

---

COM objects are reference counted and shouldn't be explicitly deleted.

On a side note. If I've got it right the ancient COM will form the basis for Metro programming although the above ugly looking code has been replaced by a much prettier C++ language extension to make people feel they're doing something new and modern :).