Inheritance ambiguety problem

[Morten Aune Lyrstad]

Hi there! I have written this message before, but for some reason it did
not appear to show up on the board. If it does, then I have a problem
with my newsgroup app, and I apologize for double posting.

Here's my problem:
I have a base interface class, named IObject. Next I have two classes
based on this, named IControl and ICommandMaster. Third I have a control
class named CCommand which inherits from /both/ IControl and
ICommandMaster. So, obviously, my compiler screams
<quote>
ambiguous access of 'Release' in 'Win32::Controls::CCommand'
could be the 'Release' in base 'CS::IObject::Release'
or the 'Release' in base 'CS::IObject::Release'
</quote>.

(Weird error message, btw;-)). But can I somehow solve this ambiguety?
Both IControl and ICommandMaster _must_ derive from IObject somehow,
because I have to be able to call a function named Release in IObject. I
might have a ICommandMaster which is _not_ a IControl and vice versa.

[Howard]

"Morten Aune Lyrstad" <mo****@wantsno.spam> wrote in message
news:g4******************@news4.e.nsc.no...

Hi there! I have written this message before, but for some reason it did
not appear to show up on the board. If it does, then I have a problem with
my newsgroup app, and I apologize for double posting.

Here's my problem:
I have a base interface class, named IObject. Next I have two classes
based on this, named IControl and ICommandMaster. Third I have a control
class named CCommand which inherits from /both/ IControl and
ICommandMaster. So, obviously, my compiler screams
<quote>
ambiguous access of 'Release' in 'Win32::Controls::CCommand'
could be the 'Release' in base 'CS::IObject::Release'
or the 'Release' in base 'CS::IObject::Release'
</quote>.

(Weird error message, btw;-)). But can I somehow solve this ambiguety?
Both IControl and ICommandMaster _must_ derive from IObject somehow,
because I have to be able to call a function named Release in IObject. I
might have a ICommandMaster which is _not_ a IControl and vice versa.

In that case, you can use "virtual" inheritance (as opposed to public,
etc.). A good C++ book should show you how to set that up properly.

-Howard

[Jay Nabonne]

On Mon, 03 Jan 2005 22:47:58 +0100, Morten Aune Lyrstad wrote:

<snip>

(Weird error message, btw;-)). But can I somehow solve this ambiguety?
Both IControl and ICommandMaster _must_ derive from IObject somehow,
because I have to be able to call a function named Release in IObject. I
might have a ICommandMaster which is _not_ a IControl and vice versa.

A critical question: what is supposed to happen when the Release function
is called on CCommand? Does it call Release on both parent classes?

Virtual inheritance will solve multiple reference counts (assuming that's
what's going on :) by sharing the common data, but you still need to
implement Release in CCommand to invoke the correct functionality.

BTW, though this is a bit off-topic, the usual way this is solved in COM
is to use aggregation, not inheritance, using QueryInterface to pick the
right interface object.

- Jay

[Morten Aune Lyrstad]

Jay Nabonne wrote:

On Mon, 03 Jan 2005 22:47:58 +0100, Morten Aune Lyrstad wrote:

<snip>

(Weird error message, btw;-)). But can I somehow solve this ambiguety?
Both IControl and ICommandMaster _must_ derive from IObject somehow,
because I have to be able to call a function named Release in IObject. I
might have a ICommandMaster which is _not_ a IControl and vice versa.

A critical question: what is supposed to happen when the Release function
is called on CCommand? Does it call Release on both parent classes?

Virtual inheritance will solve multiple reference counts (assuming that's
what's going on :) by sharing the common data, but you still need to
implement Release in CCommand to invoke the correct functionality.

BTW, though this is a bit off-topic, the usual way this is solved in COM
is to use aggregation, not inheritance, using QueryInterface to pick the
right interface object.

- Jay

IObject is a reference counting system. It contains the functions AddRef
and Release. When the reference count reaches zero, Release calls
'delete this'.

Why would I have to implement Release in CCommand? It is not implemented
any other place than in IObject.

[Ivan Vecerina]

"Morten Aune Lyrstad" <mo****@wantsno.spam> wrote in message
news:vy******************@news4.e.nsc.no...

Jay Nabonne wrote:

On Mon, 03 Jan 2005 22:47:58 +0100, Morten Aune Lyrstad wrote:

<snip>

(Weird error message, btw;-)). But can I somehow solve this ambiguety?
Both IControl and ICommandMaster _must_ derive from IObject somehow,
because I have to be able to call a function named Release in IObject. I
might have a ICommandMaster which is _not_ a IControl and vice versa.

A critical question: what is supposed to happen when the Release function
is called on CCommand? Does it call Release on both parent classes?

Virtual inheritance will solve multiple reference counts (assuming that's
what's going on :) by sharing the common data, but you still need to
implement Release in CCommand to invoke the correct functionality.
Not unless both IControl and ICommandMaster override the Release() function
defined in the virtual base class.
BTW, though this is a bit off-topic, the usual way this is solved in COM
is to use aggregation, not inheritance, using QueryInterface to pick the
right interface object. NB: with all due respect, the design of Microsoft COM has merits,
but it is definitely not a good example of (pure) C++ design.
- Jay

IObject is a reference counting system. It contains the functions AddRef
and Release. When the reference count reaches zero, Release calls 'delete
this'.

Why would I have to implement Release in CCommand? It is not implemented
any other place than in IObject.

People tend to name classes with an "I" prefix when the class is a purely
abstract interface - that is, when it contains only virtual abstract methods
(as: virtual void f()=0; ) and no data members.

This is the case in Microsoft COM, a previously popular component
infrastructure (now deprecated in favor of .NET/CLI).
Cheers,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Morten Aune Lyrstad]

>

People tend to name classes with an "I" prefix when the class is a purely
abstract interface - that is, when it contains only virtual abstract methods
(as: virtual void f()=0; ) and no data members.

This is the case in Microsoft COM, a previously popular component
infrastructure (now deprecated in favor of .NET/CLI).
Cheers,
Ivan

I respect that, but I use the I to identify classes which _must_ be
derived from and cannot be used alone.

[Ivan Vecerina]

"Morten Aune Lyrstad" <mo****@wantsno.spam> wrote in message
news:xy******************@news2.e.nsc.no...

People tend to name classes with an "I" prefix when the class is a purely
abstract interface - that is, when it contains only virtual abstract
methods
(as: virtual void f()=0; ) and no data members. NB: I should have said "Some people..." (doesn't even include me...)
This is the case in Microsoft COM, a previously popular component
infrastructure (now deprecated in favor of .NET/CLI).
Cheers,
Ivan

I respect that, but I use the I to identify classes which _must_ be
derived from and cannot be used alone.

And that is perfectly fine: I just wanted to explain
Jay's misinterpretation. My intent was not to defend it ;)

Some use A (like Abstract) as a prefix for classes that
are not pure interfaces but have to be derived from.
Many others prefer not to use any such prefix.

:)

Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

[Morten Aune Lyrstad]

I never got an answer on this question, so I'll rephrase it: Do I have
to reimplement Release if it is created like this in IObject?

virtual bool Release() {
if (objectReferenceCount <= 1) {
MemDelete this;
return true;
} else {
objectReferenceCount--;
return false;
}
}

objectReferenceCount gets the value 1 in the constructor.