Quote:Original post by ToohrVykQuote:Original post by Ashkan
Besides, we definitely don't need runtime polymorphism here since we exactly know what implementation of the interface we need: the one that we are currently implementing.
No, you don't. You know that the implementation you need inherits from the one you are currently implementing.
As it stands, someone could inherit from Derived and change the behavior of the F function. For instance, using a multimap-like container to implement a map-like container where binding a key to a new value hides the old binding of that key until the new binding is removed—the old bindings are still being stored, but they do not count against the container's size nor do they appear in iterations.
If your function g assumes that Derived::F computes the number of elements in the container, then this assumption will be wrong and you will get strange behavior as a result.
Yes, I now see the point you guys are making, which makes me wonder what the correct solution is. Should I factor the common code into a third function which is used by both F() and g()?
Quote:Quote:Original post by Ashkan
A more verbose approach is to factor the common code in another function and use that in both F() and g().
This new function should probably be virtual for the same reason that F() is virtual now.
But this design is also prone to the same set of problems. What if this third virtual function is overridden in classes Derived from this class?!
