Is it valid to “hide” a base class virtual function by making it pure virtual in derived classes?

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

asked Jan 23 at 15:47

usr

14.4k32143

5

Though it's "hidden" you can still use A::f() to call A's implementation (for example : o.A::f();).

– François Andrieux
Jan 23 at 15:50

7

Consider using override when overriding a base class' virtual member function to avoid errors.

– François Andrieux
Jan 23 at 15:50

@FrançoisAndrieux I understand A::f() can be called directly. I just wondered if this is a valid thing. Thanks for the override suggestion which I often forget!

– usr
Jan 23 at 16:12

One possibility would be that C::f() could delegate part of its implementation to A::f() again.

– Daniel Schepler
Jan 23 at 20:28

add a comment |

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();

}

asked Jan 23 at 15:47

usr

14.4k32143

5

Though it's "hidden" you can still use A::f() to call A's implementation (for example : o.A::f();).

– François Andrieux
Jan 23 at 15:50

7

Consider using override when overriding a base class' virtual member function to avoid errors.

– François Andrieux
Jan 23 at 15:50

@FrançoisAndrieux I understand A::f() can be called directly. I just wondered if this is a valid thing. Thanks for the override suggestion which I often forget!

– usr
Jan 23 at 16:12

One possibility would be that C::f() could delegate part of its implementation to A::f() again.

– Daniel Schepler
Jan 23 at 20:28

add a comment |

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();

}

asked Jan 23 at 15:47

usr

14.4k32143

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();

}

c++ c++11 language-lawyer

asked Jan 23 at 15:47

usr

14.4k32143

asked Jan 23 at 15:47

usr

14.4k32143

asked Jan 23 at 15:47

usr

14.4k32143

asked Jan 23 at 15:47

usr

14.4k32143

asked Jan 23 at 15:47

usr

14.4k32143

5

Though it's "hidden" you can still use A::f() to call A's implementation (for example : o.A::f();).

– François Andrieux
Jan 23 at 15:50

7

Consider using override when overriding a base class' virtual member function to avoid errors.

– François Andrieux
Jan 23 at 15:50

@FrançoisAndrieux I understand A::f() can be called directly. I just wondered if this is a valid thing. Thanks for the override suggestion which I often forget!

– usr
Jan 23 at 16:12

One possibility would be that C::f() could delegate part of its implementation to A::f() again.

– Daniel Schepler
Jan 23 at 20:28

add a comment |

5

Though it's "hidden" you can still use A::f() to call A's implementation (for example : o.A::f();).

– François Andrieux
Jan 23 at 15:50

7

Consider using override when overriding a base class' virtual member function to avoid errors.

– François Andrieux
Jan 23 at 15:50

@FrançoisAndrieux I understand A::f() can be called directly. I just wondered if this is a valid thing. Thanks for the override suggestion which I often forget!

– usr
Jan 23 at 16:12

One possibility would be that C::f() could delegate part of its implementation to A::f() again.

– Daniel Schepler
Jan 23 at 20:28

Though it's "hidden" you can still use A::f() to call A's implementation (for example : o.A::f();).

– François Andrieux
Jan 23 at 15:50

Consider using override when overriding a base class' virtual member function to avoid errors.

– François Andrieux
Jan 23 at 15:50

@FrançoisAndrieux I understand A::f() can be called directly. I just wondered if this is a valid thing. Thanks for the override suggestion which I often forget!

– usr
Jan 23 at 16:12

One possibility would be that C::f() could delegate part of its implementation to A::f() again.

– Daniel Schepler
Jan 23 at 20:28

add a comment |

5 Answers
5

active

oldest

votes

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.

answered Jan 23 at 16:03

Stephan Lechner

29.5k42143

add a comment |

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.

answered Jan 23 at 16:05

Lightness Races in Orbit

293k54476809

It's unclear what the OP thinks is being hidden. Seems quite clear what it does and I don't see anything being hidden.

– doug
Jan 23 at 16:19

I agree with your question - but a colleague argued this increases "safety" (i.e., it forces C to provide an implementation and avoids calling A::f() accidentally while allowing A::f() to be called directly if needed). bTW, the "hidden" is used for want of a better word. Hiding isn't really important to my question. Thanks.

– usr
Jan 23 at 16:19

@doug It hides "the ability of the non-pureness of A::f() to allow people not to bother overriding f()", I guess.

– Lightness Races in Orbit
Jan 23 at 16:54

@usr: I can sort of get behind that, if it is dangerous/undesirable for someone to forget to override f(). But then it should be pure virtual in the base already, no?

– Lightness Races in Orbit
Jan 23 at 16:55

It is perfectly reasonable for a base to provide a default implementation and it is perfectly reasonable for a derived to realize that the default implementation is contextually incorrect and further inheritors must write a correct one. Off the head instance: when layering an abstract logging system over an existing concrete error reporting object hierarchy, abstract loggers may not want to spew their logging content to stderr, but do need to store their content somewhere. (It's a mandatory 3rd part error reporter, so refactoring it is not going to happen.)

– Eric Towers
Jan 23 at 17:18

|
show 2 more comments

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.

answered Jan 23 at 16:03

Bathsheba

180k27254383

add a comment |

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

edited Jan 23 at 16:05

answered Jan 23 at 16:00

eerorika

85.9k663133

add a comment |

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.

answered Jan 23 at 16:07

Sebastian

2112

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54330926%2fis-it-valid-to-hide-a-base-class-virtual-function-by-making-it-pure-virtual-in%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

5 Answers
5

active

oldest

votes

5 Answers
5

active

oldest

votes

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 ]

answered Jan 23 at 16:03

Stephan Lechner

29.5k42143

add a comment |

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 ]

answered Jan 23 at 16:03

Stephan Lechner

29.5k42143

add a comment |

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 ]

answered Jan 23 at 16:03

Stephan Lechner

29.5k42143

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 ]

answered Jan 23 at 16:03

Stephan Lechner

29.5k42143

answered Jan 23 at 16:03

Stephan Lechner

29.5k42143

answered Jan 23 at 16:03

Stephan Lechner

29.5k42143

answered Jan 23 at 16:03

Stephan Lechner

29.5k42143

add a comment |

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.

answered Jan 23 at 16:05

Lightness Races in Orbit

293k54476809

It's unclear what the OP thinks is being hidden. Seems quite clear what it does and I don't see anything being hidden.

– doug
Jan 23 at 16:19

I agree with your question - but a colleague argued this increases "safety" (i.e., it forces C to provide an implementation and avoids calling A::f() accidentally while allowing A::f() to be called directly if needed). bTW, the "hidden" is used for want of a better word. Hiding isn't really important to my question. Thanks.

– usr
Jan 23 at 16:19

@doug It hides "the ability of the non-pureness of A::f() to allow people not to bother overriding f()", I guess.

– Lightness Races in Orbit
Jan 23 at 16:54

@usr: I can sort of get behind that, if it is dangerous/undesirable for someone to forget to override f(). But then it should be pure virtual in the base already, no?

– Lightness Races in Orbit
Jan 23 at 16:55

It is perfectly reasonable for a base to provide a default implementation and it is perfectly reasonable for a derived to realize that the default implementation is contextually incorrect and further inheritors must write a correct one. Off the head instance: when layering an abstract logging system over an existing concrete error reporting object hierarchy, abstract loggers may not want to spew their logging content to stderr, but do need to store their content somewhere. (It's a mandatory 3rd part error reporter, so refactoring it is not going to happen.)

– Eric Towers
Jan 23 at 17:18

|
show 2 more comments

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.

answered Jan 23 at 16:05

Lightness Races in Orbit

293k54476809

It's unclear what the OP thinks is being hidden. Seems quite clear what it does and I don't see anything being hidden.

– doug
Jan 23 at 16:19

I agree with your question - but a colleague argued this increases "safety" (i.e., it forces C to provide an implementation and avoids calling A::f() accidentally while allowing A::f() to be called directly if needed). bTW, the "hidden" is used for want of a better word. Hiding isn't really important to my question. Thanks.

– usr
Jan 23 at 16:19

@doug It hides "the ability of the non-pureness of A::f() to allow people not to bother overriding f()", I guess.

– Lightness Races in Orbit
Jan 23 at 16:54

@usr: I can sort of get behind that, if it is dangerous/undesirable for someone to forget to override f(). But then it should be pure virtual in the base already, no?

– Lightness Races in Orbit
Jan 23 at 16:55

It is perfectly reasonable for a base to provide a default implementation and it is perfectly reasonable for a derived to realize that the default implementation is contextually incorrect and further inheritors must write a correct one. Off the head instance: when layering an abstract logging system over an existing concrete error reporting object hierarchy, abstract loggers may not want to spew their logging content to stderr, but do need to store their content somewhere. (It's a mandatory 3rd part error reporter, so refactoring it is not going to happen.)

– Eric Towers
Jan 23 at 17:18

|
show 2 more comments

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.

answered Jan 23 at 16:05

Lightness Races in Orbit

293k54476809

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.

answered Jan 23 at 16:05

Lightness Races in Orbit

293k54476809

answered Jan 23 at 16:05

Lightness Races in Orbit

293k54476809

answered Jan 23 at 16:05

Lightness Races in Orbit

293k54476809

answered Jan 23 at 16:05

Lightness Races in Orbit

293k54476809

It's unclear what the OP thinks is being hidden. Seems quite clear what it does and I don't see anything being hidden.

– doug
Jan 23 at 16:19

I agree with your question - but a colleague argued this increases "safety" (i.e., it forces C to provide an implementation and avoids calling A::f() accidentally while allowing A::f() to be called directly if needed). bTW, the "hidden" is used for want of a better word. Hiding isn't really important to my question. Thanks.

– usr
Jan 23 at 16:19

@doug It hides "the ability of the non-pureness of A::f() to allow people not to bother overriding f()", I guess.

– Lightness Races in Orbit
Jan 23 at 16:54

@usr: I can sort of get behind that, if it is dangerous/undesirable for someone to forget to override f(). But then it should be pure virtual in the base already, no?

– Lightness Races in Orbit
Jan 23 at 16:55

It is perfectly reasonable for a base to provide a default implementation and it is perfectly reasonable for a derived to realize that the default implementation is contextually incorrect and further inheritors must write a correct one. Off the head instance: when layering an abstract logging system over an existing concrete error reporting object hierarchy, abstract loggers may not want to spew their logging content to stderr, but do need to store their content somewhere. (It's a mandatory 3rd part error reporter, so refactoring it is not going to happen.)

– Eric Towers
Jan 23 at 17:18

|
show 2 more comments

It's unclear what the OP thinks is being hidden. Seems quite clear what it does and I don't see anything being hidden.

– doug
Jan 23 at 16:19

I agree with your question - but a colleague argued this increases "safety" (i.e., it forces C to provide an implementation and avoids calling A::f() accidentally while allowing A::f() to be called directly if needed). bTW, the "hidden" is used for want of a better word. Hiding isn't really important to my question. Thanks.

– usr
Jan 23 at 16:19

@doug It hides "the ability of the non-pureness of A::f() to allow people not to bother overriding f()", I guess.

– Lightness Races in Orbit
Jan 23 at 16:54

@usr: I can sort of get behind that, if it is dangerous/undesirable for someone to forget to override f(). But then it should be pure virtual in the base already, no?

– Lightness Races in Orbit
Jan 23 at 16:55

It is perfectly reasonable for a base to provide a default implementation and it is perfectly reasonable for a derived to realize that the default implementation is contextually incorrect and further inheritors must write a correct one. Off the head instance: when layering an abstract logging system over an existing concrete error reporting object hierarchy, abstract loggers may not want to spew their logging content to stderr, but do need to store their content somewhere. (It's a mandatory 3rd part error reporter, so refactoring it is not going to happen.)

– Eric Towers
Jan 23 at 17:18

It's unclear what the OP thinks is being hidden. Seems quite clear what it does and I don't see anything being hidden.

– doug
Jan 23 at 16:19

I agree with your question - but a colleague argued this increases "safety" (i.e., it forces C to provide an implementation and avoids calling A::f() accidentally while allowing A::f() to be called directly if needed). bTW, the "hidden" is used for want of a better word. Hiding isn't really important to my question. Thanks.

– usr
Jan 23 at 16:19

@doug It hides "the ability of the non-pureness of A::f() to allow people not to bother overriding f()", I guess.

– Lightness Races in Orbit
Jan 23 at 16:54

@usr: I can sort of get behind that, if it is dangerous/undesirable for someone to forget to override f(). But then it should be pure virtual in the base already, no?

– Lightness Races in Orbit
Jan 23 at 16:55

It is perfectly reasonable for a base to provide a default implementation and it is perfectly reasonable for a derived to realize that the default implementation is contextually incorrect and further inheritors must write a correct one. Off the head instance: when layering an abstract logging system over an existing concrete error reporting object hierarchy, abstract loggers may not want to spew their logging content to stderr, but do need to store their content somewhere. (It's a mandatory 3rd part error reporter, so refactoring it is not going to happen.)

– Eric Towers
Jan 23 at 17:18

|
show 2 more comments

This is valid and well-defined C++.

answered Jan 23 at 16:03

Bathsheba

180k27254383

add a comment |

This is valid and well-defined C++.

answered Jan 23 at 16:03

Bathsheba

180k27254383

add a comment |

This is valid and well-defined C++.

answered Jan 23 at 16:03

Bathsheba

180k27254383

This is valid and well-defined C++.

answered Jan 23 at 16:03

Bathsheba

180k27254383

answered Jan 23 at 16:03

Bathsheba

180k27254383

answered Jan 23 at 16:03

Bathsheba

180k27254383

answered Jan 23 at 16:03

Bathsheba

180k27254383

add a comment |

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.

edited Jan 23 at 16:05

answered Jan 23 at 16:00

eerorika

85.9k663133

add a comment |

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.

edited Jan 23 at 16:05

answered Jan 23 at 16:00

eerorika

85.9k663133

add a comment |

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.

edited Jan 23 at 16:05

answered Jan 23 at 16:00

eerorika

85.9k663133

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.

edited Jan 23 at 16:05

answered Jan 23 at 16:00

eerorika

85.9k663133

edited Jan 23 at 16:05

answered Jan 23 at 16:00

eerorika

85.9k663133

answered Jan 23 at 16:00

eerorika

85.9k663133

answered Jan 23 at 16:00

eerorika

85.9k663133

add a comment |

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.

answered Jan 23 at 16:07

Sebastian

2112

add a comment |

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.

answered Jan 23 at 16:07

Sebastian

2112

add a comment |

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.

answered Jan 23 at 16:07

Sebastian

2112

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.

answered Jan 23 at 16:07

Sebastian

2112

answered Jan 23 at 16:07

Sebastian

2112

answered Jan 23 at 16:07

Sebastian

2112

answered Jan 23 at 16:07

Sebastian

2112

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu