Inheritance: Implementing pure virtual functions by inheriting froman object providing an implementa

[Jaco Naude]

Hi

I'm wondering if an idea that I have should work. Well the compiler
(mingw) does not seem to allow it, but I'm not sure why it does not
work.

I have an interface class:

class IManagable {
public:
virtual void setID(int new_id) = 0;
virtual int getID() = 0;
}

And an object implementing this interface:

class ManagableObject {
public:
ManagableObject () { id = -1; }
~ManagableObject ();

// Implement functions
inline void setID(int new_id) { id = new_id; }
inline int getID() { return id; }

private:
int id;
}

I've read in the FAQ that inheritance should not be used for code
reuse in general. But in my case I think it is a good idea. I want to
be able to assign unique IDs to objects implementing the interface. If
all of these objects can use the interface as well as the
ManagableObject implementation of the interface, it will reduce my
workload quite a lot I believe.

Now the problem. I have an object that I want to be able to manage
that looks like this:

class ManageMe : virtual public IManagable, public ManagableObject {
ManageMe () {}
~ManageMe () {}
}

This complains that the IManagable pure virtual public functions
aren't implemented by ManageMe. So my approach to accomplish this is
not working. Is there a different way that I can do this without
having to implement the IManagable interface in ManageMe (where the
implementation calls the ManagableObject functions).

Thanks in advance for any advice
Jaco

 

[Alf P. Steinbach]

* Jaco Naude:

Hi

I'm wondering if an idea that I have should work. Well the compiler
(mingw) does not seem to allow it, but I'm not sure why it does not
work.

I have an interface class:

class IManagable {
public:
virtual void setID(int new_id) = 0;
virtual int getID() = 0;
}

And an object implementing this interface:

class ManagableObject {
public:
ManagableObject () { id = -1; }
~ManagableObject ();

// Implement functions
inline void setID(int new_id) { id = new_id; }
inline int getID() { return id; }

private:
int id;
}

I've read in the FAQ that inheritance should not be used for code
reuse in general. But in my case I think it is a good idea. I want to
be able to assign unique IDs to objects implementing the interface. If
all of these objects can use the interface as well as the
ManagableObject implementation of the interface, it will reduce my
workload quite a lot I believe.

Now the problem. I have an object that I want to be able to manage
that looks like this:

class ManageMe : virtual public IManagable, public ManagableObject {
ManageMe () {}
~ManageMe () {}
}

This complains that the IManagable pure virtual public functions
aren't implemented by ManageMe. So my approach to accomplish this is
not working. Is there a different way that I can do this without
having to implement the IManagable interface in ManageMe (where the
implementation calls the ManagableObject functions).

Thanks in advance for any advice

class ManagableObject: public virtual IManagable


Cheers & hth.,

- Alf

 

[Jaco Naude]

* Jaco Naude:
















class ManagableObject: public virtual IManagable

Cheers & hth.,

- Alf

Hi Alf

Thanks for the suggestion, I have not thought of that.

I'll give it a go.
Thanks
Jaco

 

[Jaco Naude]

Hi Alf

Thanks for the suggestion, I have not thought of that.

I'll give it a go.
Thanks
Jaco

Hi again,

I've tried the new implementation but casting becomes really confusing
in this implementation. Let me give some details on my implementation.
The ManageMe class from my first post looks like this:

class ManageMe: public GCF::AbstractComponent, public ManagableObject,
virtual public IToolbox, virtual public IData

where each of the parent classes are defined as follows (Using Qt,
hence the reason for the QObject class below):

class AbstractComponent : public QObject -- This is a singleton
class ManagableObject : virtual public IManagable
class IData : virtual public IContainer
class IToolbox : virtual public IContainer
class IManagable : virtual public IContainer

The IContainer class is a container class defined as follows:

class IContainer
{
public:
virtual QObject* containerObject() = 0;
};

In the ManageMe class the IContainer interface is implemented as
follows:

QObject* ManageMe ::containerObject()
{
return this;
}

Ok, that's my class hierarchy explained. Now I'm trying to cast to
IManagable* when I have a QObject pointer. The way I try to do it is
shown below and causes a program crash:

if (qobject_ptr) {
ManagableObject* tmp_ref = dynamic_cast<ManagableObject*>
(qobject_ptr);
if (tmp_ref) {
IManagable* managable_ptr = dynamic_cast<IManagable*>
(tmp_ref);
if (managable_ptr) {
// Access managable_ptr's contents here causes crash.
}
}
}

I've tried various variations of the above without anything working.
How is it possible to do this? Is it possible at all?

Thank you
Jaco

 

[Alf P. Steinbach]

* Jaco Naude:

Hi again,

I've tried the new implementation but casting becomes really confusing
in this implementation.

Casting is generally to be avoided.

Let me give some details on my implementation.
The ManageMe class from my first post looks like this:

class ManageMe: public GCF::AbstractComponent, public ManagableObject,
virtual public IToolbox, virtual public IData

where each of the parent classes are defined as follows (Using Qt,
hence the reason for the QObject class below):

Hm. I only tried installing Qt once, for Windows. Had to try to install three
times to get it working, and the backspace key didn't work in the installation
dialog; one wonders how on Earth they managed to make that not work. I was very
tempted to walk up the street to Trolltech and tell them how uncute their
product was, and even more tempted when I tried to uninstall...

class AbstractComponent : public QObject -- This is a singleton

Double hm. Singletons are generally problematic. When you inherit from a
singleton class, if that's what you're doing, how do you ensure the singleton
will be of your class?

class ManagableObject : virtual public IManagable
class IData : virtual public IContainer
class IToolbox : virtual public IContainer
class IManagable : virtual public IContainer

No AbstractComponent here, AFAICS.

The IContainer class is a container class defined as follows:

class IContainer
{
public:
virtual QObject* containerObject() = 0;
};

From the name it sames that an IContainer /contains/ a QObject.

In the ManageMe class the IContainer interface is implemented as
follows:

QObject* ManageMe ::containerObject()
{
return this;
}

If this compiles then it seems ManageMe inherits from QObject.

Ok, that's my class hierarchy explained. Now I'm trying to cast to
IManagable* when I have a QObject pointer.

Well, above I see no inheritance relationship between IManagable and QObject. On
the contrary, IManagable implements the IContainer interface. Which indicates
that an IManagable is an interface on an object that /contains/ a QObject.

The way I try to do it is shown below and causes a program crash:

if (qobject_ptr) {
ManagableObject* tmp_ref = dynamic_cast<ManagableObject*>
(qobject_ptr);
if (tmp_ref) {
IManagable* managable_ptr = dynamic_cast<IManagable*>
(tmp_ref);
if (managable_ptr) {
// Access managable_ptr's contents here causes crash.
}
}
}

I've tried various variations of the above without anything working.
How is it possible to do this? Is it possible at all?

Try to reproduce the problem in a *minimal* program.

That often helps.

But also think about inheritance versus containment, and think about that
singleton thing -- could be a problem.

Also, it seems you have a needless proliferation of interface classes.

Interface abstraction is good when it helps you avoid doing wrong things or
helps avoid too close coupling, but it's bad when any realistic concrete class
has to implement and expose umpteen interfaces. Then the abstraction tool that
should simplify things instead complicates things. That happened a lot with COM;
if you look up the standard joke "progression of a programmer" starting with
hello, world in basic, and so on, the final horrifying mess is COM-based code.


Cheers & hth.,

- Alf

 

[Jaco Naude]

* Jaco Naude:





Casting is generally to be avoided.

I actually cast quite a lot between different interfaces on objects. I
work with quite a lot of plugins that implement different interfaces
(IAboutPlugin, IPluginSpecificInterfaces etc.).

Hm. I only tried installing Qt once, for Windows. Had to try to install three
times to get it working, and the backspace key didn't work in the installation
dialog; one wonders how on Earth they managed to make that not work. I was very
tempted to walk up the street to Trolltech and tell them how uncute their
product was, and even more tempted when I tried to uninstall...


Double hm. Singletons are generally problematic. When you inherit from a
singleton class, if that's what you're doing, how do you ensure the singleton
will be of your class?


No AbstractComponent here, AFAICS.

It was defined in the beginning of the list:
class AbstractComponent : public QObject -- This is a singleton

 From the name it sames that an IContainer /contains/ a QObject.



If this compiles then it seems ManageMe inherits from QObject.

Correct, through AbstractComponent

Well, above I see no inheritance relationship between IManagable and QObject. On
the contrary, IManagable implements the IContainer interface. Which indicates
that an IManagable is an interface on an object that /contains/ a QObject..






Try to reproduce the problem in a *minimal* program.

That often helps.

But also think about inheritance versus containment, and think about that
singleton thing  --  could be a problem.

I agree on this. I am going to use use containment for the
ManagableObject instance.

Also, it seems you have a needless proliferation of interface classes.

Interface abstraction is good when it helps you avoid doing wrong things or
helps avoid too close coupling, but it's bad when any realistic concrete class
has to implement and expose umpteen interfaces. Then the abstraction tool that
should simplify things instead complicates things. That happened a lot with COM;
if you look up the standard joke "progression of a programmer" starting with
hello, world in basic, and so on, the final horrifying mess is COM-based code.

Thanks for the advice. During my effort to try and solve this I've
read up quite a lot on multiple inheritance and am quite confused in
regard with casting at this stage. However I'll try to make my class
hierarchies simpler to avoid this complexity.

Thanks again for the help.
Regards,
Jaco