• Advertisement
Sign in to follow this  

Again classes, multiple inheritance, one base class

This topic is 3911 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello its me again. I have one class CMessageHandler, this it the base class for all other classes. This class provide a communication channel between all other classes. It have list of messages, and two methods: PostMessage, GetMessage. Now there is a class CLog: class CLog: public virtual CMessageHandler CLog create log file and using method CLog::Logic() get messages using CMessageHandler::GetMessage() and write them to Log file. Another class is CGraphics: class CGraphics: public virtual CMessageHandler. Both CGraphics and CLog virtually derived from CMessageHandler in order to have only one CMessageHandler. But seems like Messages that was posted by CGraphics not shown to CLog, it looks like I have two CMessageHandler classes anyway. I thought using virtual inheritance will solve this problem, but seems it not. Am I doing something wrong?

Share this post


Link to post
Share on other sites
Advertisement
Where is the multiple inheritance here? Do you have a class that inherits from both Graphics and Log? What sense does that make?

Share this post


Link to post
Share on other sites
Quote:

Am I doing something wrong?

Yes.

Consider the class hierarchy below:

Foo class Foo
/ \ {
ChildA ChildB protected:
\ / int A;
Bar };

This is an appropriate scenario for virtual inheritance. Since a derived type inherits the members of its base, in this example, ChildA and ChildB both contain the members of Foo. But Bar contains the members of both ChildA and ChildB. Which means it has two copies of A, the one it got from ChildA and the one it got from ChildB. Virtual inheritance prevents this -- if Child and ChildB iherited virtuallly from Foo, only one copy of Foo's data members would exist in Bar.

Your scenario is like this:

CMessageHandler CMessageHandler
| |
CLog CGraphics

This is not the "diamond" inheritance issue virtual inheritance was designed for. You also seem to be confused about the "one instance" thing. Unless CMessageHandler data is all static (making it, effectively, a singleton), CLog and CGraphics instances will have completely isolated copies of the CMessageHandler data members. These are not shared in any way, and virtual inheritance is not designed to make them shared. If you want to share the member variables of CMessageHandler between all instances of CMessageHandler (including instances that are sub-objects of derived types), you need to make those members static. However, this would probably result in a bad design (you'd essentially be making a singleton). There are better ways -- you should look into existing signal/slot implementations, such as the one in Boost.

Share this post


Link to post
Share on other sites
Oh... I though I can use virtual inheritance not only with "diamond".
So the only why is to create one more class that will derive from CLog and CGraphics?

Share this post


Link to post
Share on other sites
Quote:

Oh... I though I can use virtual inheritance not only with "diamond".
So the only why is to create one more class that will derive from CLog and CGraphics?

Absolutely not. That would be abusing the language mechanics to achieve a goal that is incorrect because your design is broken and you're too lazy to fix it.

Any object that derives from both CLog and CGraphics must be both a CLog and a CGraphics. There are not very many objects that could realistically exist like that -- a CLoggableGraphics object maybe, but that's just ungainly.

I mentioned the most-direct solution already: make the message handler methods static. This is ugly, and just a band aid that renders the entire system an over engineered hack around a global variable, but it would work. I also mentioned a better solution: using a signal/slot implementation, similar perhaps to the one in Boost's libraries. I suggest you look into that.

Virtual inheritance is not the solution to your problem -- stop trying to apply a solution that solves a problem other than the one you're having. Look up Boost's signal library and study it (or just use it directly; why reinvent the wheel?)

Share this post


Link to post
Share on other sites
Hey don't be angry with me, I am just asking questions in order to learn new thing.
No one born programmer.
If there is no solution to my problem (due bad design or other things) so there is no solution. I'll not get with my head into wall.
If my design is bad so I'll redesign it again, and if second time will be bad I'll try again and again and again, until I'll not get the necessary knowledge to do it normally.
But I cant learn without asking questions.
I'm sure you know a lot of thing more than me 101%, but hey don't tell things like "you're too lazy to fix it". I didn't say I'm lazy to fix something and you have no right do judge me, I just asked a question.

Share this post


Link to post
Share on other sites
I'm not angry. Your location field is pretty ambiguous, I presume English is not your native language?

In the sentence "That would be abusing the language mechanics to achieve a goal that is incorrect because your design is broken and you're too lazy to fix it," the you is being used as a hypothetical non-specific "you." The sentence is essentially the same as "that would be abusing the language mechanics because one's design is broken," but the usage of "one" is more formal and stilted. I was not directly accusing you, s.kwee, of being lazy; instead I was pointing out the effect of a hypothetical cause.

Share this post


Link to post
Share on other sites
Quote:
Original post by s.kwee
Hey don't be angry with me, I am just asking questions in order to learn new thing.
No one born programmer.
If there is no solution to my problem (due bad design or other things) so there is no solution. I'll not get with my head into wall.
If my design is bad so I'll redesign it again, and if second time will be bad I'll try again and again and again, until I'll not get the necessary knowledge to do it normally.
But I cant learn without asking questions.
I'm sure you know a lot of thing more than me 101%, but hey don't tell things like "you're too lazy to fix it". I didn't say I'm lazy to fix something and you have no right do judge me, I just asked a question.


You are reading too much into that statement. I'm 99% positive jpetrie isn't angry at anyone. That is quite a strong emotion to have in response to an anonymous internet post. [grin]

Possibly "you're too lazy" could have been better worded, but it was meant to prompt you into action, preferably action directed towards your class design, not towards an "offended response" post. [smile]

How about you read jpetrie's post again and put more energy into researching the various suggestions he mentioned (Boost, etc), rather than focusing on the least important part of his post.

Share this post


Link to post
Share on other sites
So in this case I made a fool of myself.
And yes English is not my native language.
So that I want to apologize about my mistake.

rip-off
Every word of every post is important, if it wasn't people wouldn't post it.
And I'm already reading about Boosts signal lib.

Thanks again

Share this post


Link to post
Share on other sites
Quote:
Original post by s.kwee
So in this case I made a fool of myself.
And yes English is not my native language.
So that I want to apologize about my mistake.


No worries.

Quote:

rip-off
Every word of every post is important, if it wasn't people wouldn't post it.


Not really. Its quite easy to make a mistake or to word something wrong. I often edit my posts quite a few times before I'm happy enough with the wording (but I'm just unusual).

Some other people you may meet on your journey just have what some would describe as an "aggressive" or "abrasive" style. But it's nothing personal, these people just have a straightforward manner.

Just to note, jpetrie is not one who I would consider to have such a style...

Personally, while I may not enjoy it at the time I would rather be put in my place harshly by someone and come out of it smarter than treated nicely and go off doing something stupid with regards to my programs design.

Share this post


Link to post
Share on other sites
Just as an aside s.kwee...

learn the concept of "Design To An Interface".

This means, (in C++), create a single base class for each set of responsibilities... one per set... which should remain abstract and which should have all the member functions you need (virtual).

Then create one more level of heirarchy for the concrete classes, derived from your base classes. This creates only two levels of heirarchy, which is inherently less coupled than a long inheritance tree.

Once you're practiced and proficient at that... you can blend templates, policy classes, design patterns and whatever best fits your problem domain with this simple idea of an "interface first".

Discard the idea that every "object" should derive from a single base Object. That was a flawed idea from the early days of OOD. Inheritance is not the strongest suit of OOD.


Good luck!

Share this post


Link to post
Share on other sites
MaulingMonkey
Thanks for support :)

Verg
Thanks you! I got you're idea and I'll read the article.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement