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.

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?)

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.