Why is the "virtuality" of methods implicitly propagated in C++?

Question

What is the reason for removing the ability to stop the propagation of methods virtuality?

Let me be clearer: In C++, whether you write "virtual void foo()" or "void foo()" in the derived class, it will be virtual as long as in the base class, foo is declared virtual.

This means that a call to foo() through a derived* pointer will result in a virtual table lookup (in case a derived2 function overrides foo), even if this behavior is not wanted by the programmer.

Let me give you an example (that looks pretty blatant to me) of how it would be useful to stop virtuality propagation:

template <class T>
class Iterator // Here is an iterator interface useful for defining iterators
{              // when implementation details need to be hidden
public:
    virtual T& next() { ... }
    ...
};

template <class T>
class Vector
{
public:
    class VectIterator : public Iterator<T>
    {
    public:
        T& next() { ... }
        ...
    };
    ...
};

In the example above, the Iterator base class can be used to achieve a form of "type erasure" in a much more clearer and Object-Oriented way. (See http://www.artima.com/cppsource/type_erasure.html for an example of type erasure.)

But still, in my example one can use a Vector::VectIterator object directly (which will be done in most cases) in order to access the real object without using the interface.

If virtuality was not propagated, calls to Vector::VectIterator::next() even from a pointer or reference would not be virtual and would be able to be inlined and to run efficiently, just as if the Iterator interface didn't exist.

Answer 1

C++11 added the contextual keyword final for this purpose.

class VectIterator : public Iterator<T>
{
public:
    T& next() final { ... }
    ...
};

struct Nope : VecIterator {
    T& next() { ... } // ill-formed
};

Answer 2

The simple snswer is : Don't mix concrete and abstract interfaces! The obvious approach in you example would be the use of a non-virtual function next() which delegates to a virtual function, e.g., do_next(). A derived class would override do_next() possibly delegating to a non-virtual function next(). Since the next() functions are likely inline there isn't any cost involved in the delegation.