Virtual methods
-
I have a base class with a virtual method, from this base there are multiple derived classes, but more than one needs to overide that virtual method.
class A{ virtual void OnSth(); } class B : public A { virtual void OnSth(); } class C : public B { } class D : public C { virtual void OnSth(); }In the snippet above when class A callsOnSth()I need it to call the overide in bothclass Bandclass D. Everything I have tried only results in theclass B's method being called. What am I doing wrong?Waldermort
WalderMort wrote:
In the snippet above when class A calls OnSth() I need it to call the overide in both class B and class D.
I don't really understand that part of your question. Do you mean that when something outside your class calls the OnSth function, it should be redirected to D::OnSth (standard behavior of virtual functions) ? Because if you call OnSth from inside class A, it cannot call both B::OnSth and D::OnSth, it will only call the function in the most derived class.
Cédric Moonen Software developer
Charting control [v1.2] -
WalderMort wrote:
In the snippet above when class A calls OnSth() I need it to call the overide in both class B and class D.
I don't really understand that part of your question. Do you mean that when something outside your class calls the OnSth function, it should be redirected to D::OnSth (standard behavior of virtual functions) ? Because if you call OnSth from inside class A, it cannot call both B::OnSth and D::OnSth, it will only call the function in the most derived class.
Cédric Moonen Software developer
Charting control [v1.2]Cedric Moonen wrote:
it will only call the function in the most derived class
yes, and that's his problem... D's method should be executed, but it's actually the method from B class that is called.
[VisualCalc][Binary Guide][CommDialogs] | [Forums Guidelines]
-
WalderMort wrote:
In the snippet above when class A calls OnSth() I need it to call the overide in both class B and class D.
I don't really understand that part of your question. Do you mean that when something outside your class calls the OnSth function, it should be redirected to D::OnSth (standard behavior of virtual functions) ? Because if you call OnSth from inside class A, it cannot call both B::OnSth and D::OnSth, it will only call the function in the most derived class.
Cédric Moonen Software developer
Charting control [v1.2]The problem was that the derived method in class D was not being called and instead calling that of class B. I realise only one method may be called, but in reality I need both methods in classes B and D to be called. I suppose the only way to do this is to call B::OnSth() explicitly from class D or to add a new virtual method in class B. The type of behaviour I'm looking for is when class A, internally, calls DoSth(), then the code should call the method in class B THEN call the method in class D. Not exactly C++ standard I know. As for the main problem, I fixed it.
Waldermort
-
The problem was that the derived method in class D was not being called and instead calling that of class B. I realise only one method may be called, but in reality I need both methods in classes B and D to be called. I suppose the only way to do this is to call B::OnSth() explicitly from class D or to add a new virtual method in class B. The type of behaviour I'm looking for is when class A, internally, calls DoSth(), then the code should call the method in class B THEN call the method in class D. Not exactly C++ standard I know. As for the main problem, I fixed it.
Waldermort
Perhaps this could be a design issue... Basic OO design gives that a child class is a specialization of the base class and inherits the behavior of the base class. It's like saying "a rectangle is a shape" and shape would be the base class of rectangle. I guess you already know this. But the implication is that when you derive from a class you also derive its behavior, i.e. the implementation of a certain method in case it's declared as virtual. Calling a base class implementation of a method is quite alright, it just means that you want the behavior of the base class and want to add a little something to it. From my understanding you want to go the other way around, i.e. calling the child class implementation from the base class and this creates some problems. Not that they cannot be solved, but there's a possibility that you're trying to solve the problem using the wrong tool. Perhaps it's the observer design pattern[^] you really need. It's the same pattern used in the doc/view architecture when the document notifies all views about a change in the document.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Perhaps this could be a design issue... Basic OO design gives that a child class is a specialization of the base class and inherits the behavior of the base class. It's like saying "a rectangle is a shape" and shape would be the base class of rectangle. I guess you already know this. But the implication is that when you derive from a class you also derive its behavior, i.e. the implementation of a certain method in case it's declared as virtual. Calling a base class implementation of a method is quite alright, it just means that you want the behavior of the base class and want to add a little something to it. From my understanding you want to go the other way around, i.e. calling the child class implementation from the base class and this creates some problems. Not that they cannot be solved, but there's a possibility that you're trying to solve the problem using the wrong tool. Perhaps it's the observer design pattern[^] you really need. It's the same pattern used in the doc/view architecture when the document notifies all views about a change in the document.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
Perhaps it's the observer design pattern[^] you really need
That sounds like exactly what I am looking for. I have several windows, each represented by a class, that display certain aspects of a main class. When something changes in the base class, one or more windows may need to update their content. After quick glance at a few articles relating to the topic, it seems a little difficult to implement. Guess I have some reading to do. Thanks for pointing out this, new to me, design pattern.
Waldermort
-
Roger Stoltz wrote:
Perhaps it's the observer design pattern[^] you really need
That sounds like exactly what I am looking for. I have several windows, each represented by a class, that display certain aspects of a main class. When something changes in the base class, one or more windows may need to update their content. After quick glance at a few articles relating to the topic, it seems a little difficult to implement. Guess I have some reading to do. Thanks for pointing out this, new to me, design pattern.
Waldermort
WalderMort wrote:
I have several windows, each represented by a class, that display certain aspects of a main class. When something changes in the base class, one or more windows may need to update their content.
Yep, that sounds like a school book situation for an observer pattern. ;) Perhaps you won't need to do a fully fledged implementation if you don't separate the data from the presentation: you could have a static list in the top-most class containing the "observers" and when the observers need to be notified you simply traverse the list calling the virtual "notify" method of each observer. Just a thought... :->
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
WalderMort wrote:
I have several windows, each represented by a class, that display certain aspects of a main class. When something changes in the base class, one or more windows may need to update their content.
Yep, that sounds like a school book situation for an observer pattern. ;) Perhaps you won't need to do a fully fledged implementation if you don't separate the data from the presentation: you could have a static list in the top-most class containing the "observers" and when the observers need to be notified you simply traverse the list calling the virtual "notify" method of each observer. Just a thought... :->
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownSounds like a suitable solution, for now anyway. Funny thing is I started off with a similar method, but used callback methods. I had to change from this because the more code I wrote, the more complicated it became trying to manage each instance.
Waldermort
-
WalderMort wrote:
I have several windows, each represented by a class, that display certain aspects of a main class. When something changes in the base class, one or more windows may need to update their content.
Yep, that sounds like a school book situation for an observer pattern. ;) Perhaps you won't need to do a fully fledged implementation if you don't separate the data from the presentation: you could have a static list in the top-most class containing the "observers" and when the observers need to be notified you simply traverse the list calling the virtual "notify" method of each observer. Just a thought... :->
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownA little further reading on the subject makes it all the more clearer. It shouldn't be too much hassle to create a CSubject and CObserver containing only the virtual methods I need. Then it's a simple matter of deriving my existing code from these new classes, and have the observers call CSubject::HeyTellMeWhenSomethingChangesWillYa()
Waldermort
-
A little further reading on the subject makes it all the more clearer. It shouldn't be too much hassle to create a CSubject and CObserver containing only the virtual methods I need. Then it's a simple matter of deriving my existing code from these new classes, and have the observers call CSubject::HeyTellMeWhenSomethingChangesWillYa()
Waldermort
WalderMort wrote:
It shouldn't be too much hassle to create a CSubject and CObserver containing only the virtual methods I need.
Nope.
WalderMort wrote:
Then it's a simple matter of deriving my existing code from these new classes, and have the observers call CSubject::HeyTellMeWhenSomethingChangesWillYa()
Yes, and now that you strike me as empowered I really suggest you do it this way instead of a lazy shortcut like the one I suggested earlier :-O, because in this case you would create reusable base classes that you can benefit from later. You will also get a clear understanding of the observer design pattern, which will also help you later since the pattern is quite common. Go 'n get'em boy! Yiee-ha! :-D
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
WalderMort wrote:
It shouldn't be too much hassle to create a CSubject and CObserver containing only the virtual methods I need.
Nope.
WalderMort wrote:
Then it's a simple matter of deriving my existing code from these new classes, and have the observers call CSubject::HeyTellMeWhenSomethingChangesWillYa()
Yes, and now that you strike me as empowered I really suggest you do it this way instead of a lazy shortcut like the one I suggested earlier :-O, because in this case you would create reusable base classes that you can benefit from later. You will also get a clear understanding of the observer design pattern, which will also help you later since the pattern is quite common. Go 'n get'em boy! Yiee-ha! :-D
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
in this case you would create reusable base classes that you can benefit from later
I have to agree there, it's always useful to create re-usable code and add it to a common folder somewhere. I have got to the point now that I am re-using so much code, that I had to create a single header file just to #include my most used snippets. As for this Subject Observer pattern. Most of the examples/articles I found simply pass a this pointer back to the observer through a single virtual method. In my eyes this is somewhat over the top, each observer wouldn't know what type of update or even if the update is relevent, but still have to call back to the subject to check what changed. I took a different approach, much the same as you would normaly use virtual methods. I created a single base class, complete with a list of all virtual calls a class would need. This way the method can be over-ridden directly and whatever updated data is already there. Infact I may even write an article on it. To think of all those projects where I could have used this, but instead took the far more complicated route of multiple derived types and callbacks... Again, thanks for introducing this.
Waldermort