Gfyuki

Consider the example:

#include <iostream>



class A {

    public:

    virtual void f();

};



void A::f()

{

    std::cout << "f() from An";

}



class B: public A {

    public:

    virtual void f() = 0;

};



class C: public B {

    public:

    void f();

};



void C::f()

{

    std::cout << "f() from Cn";

}



int main()

{

    C o;

    o.f();

}

A::f() implementation is "hidden" from class C, which provides its own implementation for f() - effectively making A::f() more or less pointless. I see little value in such class hierarchy design, but my question whether this is a valid C++ or just "works" (such as undefined behaviours)?

It is clearly allowed and supported by the standard (cf, for example, this online C++ standard draft), and thus clearly not undefined behaviour:

10.4 Abstract classes

5 [ Note: An abstract class can be derived from a class that is not
abstract, and a pure virtual function may override a virtual function
which is not pure. — end note ]

The effect is that your class B becomes abstract and any subclass - if it shall not be abstract, too - must define f() then; the implementation in class A can still be invoked through A::f(), such that it is - from the perspective of reusing the implementation - not pointless.

my question whether this is a valid C++ or just "works" (such as undefined behaviours)?

The behaviour of the program is well defined.

effectively making A::f() more or less pointless.

Of course, if you never call a function, then defining the function is unnecessary indeed. To clarify, the function would have to be declared pure virtual if you did choose to omit the definition (the opposite is not true; you can define a pure virtual function).

This will safely achieve the goal of requiring the author of C to provide an implementation for f().

I would query why this is needed — if the base implementation is not "valid" in your design then why does it exist, and/or why is it virtual?

They can still invoke A::f(), anyway, so whether this can be deemed "hiding" is open to debate.

This is valid and well-defined C++.

It can occasionally be useful if you want to force a user of your class to implement a method that's already implemented in a base class (and don't want to use a different name which would be a more obvious choice). GUI libraries implementing operating system message pumps are one application.

As far as I can see there's no undefined behavior = 0 only means that derived classes must override it. But you can still provide an out-of-line definition for that function in the same class.