std::unique_ptr of base class holding reference of derived class does not show warning in gcc compiler while...
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I have a hierarchy of base class and derived class. Base class has one virtual function which is overridden by derived class.
class Base
{
public:
~Base();
virtual void other_functionality() = 0;
};
class Derived : public Base
{
public:
~Derived ();
void other_functionality() {//some code};
};
Now if i do like this:
int main()
{
Base * P = new Derived ();
delete p;
return 0;
}
It gives error:
deleting object of polymorphic class type which has non-virtual destructor.
But with unique_ptr it passes without warning.
int main()
{
std::unique_ptr<Base> p;
p.reset(new Derived ());
return 0;
}
I know if I use virtual destructor. Warning with naked pointer will be solved. But question remains - why absence of virtual destructor shows problem with naked pointer and not with unique_ptr.
c++ c++14 gcc-warning
|
show 6 more comments
I have a hierarchy of base class and derived class. Base class has one virtual function which is overridden by derived class.
class Base
{
public:
~Base();
virtual void other_functionality() = 0;
};
class Derived : public Base
{
public:
~Derived ();
void other_functionality() {//some code};
};
Now if i do like this:
int main()
{
Base * P = new Derived ();
delete p;
return 0;
}
It gives error:
deleting object of polymorphic class type which has non-virtual destructor.
But with unique_ptr it passes without warning.
int main()
{
std::unique_ptr<Base> p;
p.reset(new Derived ());
return 0;
}
I know if I use virtual destructor. Warning with naked pointer will be solved. But question remains - why absence of virtual destructor shows problem with naked pointer and not with unique_ptr.
c++ c++14 gcc-warning
2
For the record,clang
does complain: godbolt.org/z/qEp6Ts
– Max Langhof
Apr 25 at 12:24
1
@P.W I don't think this is a duplicate. At least, answers to both questions are different. (Answer to the original question is "because the Stadnard does not require such a check". Answer to this question is "because gcc supresses warnings for system headers".)
– Daniel Langr
Apr 25 at 12:35
1
@DanielLangr: The question seemed the same in essence. But the answers do not directly address why the compiler does not issue a diagnostic. So I will reopen.
– P.W
Apr 25 at 12:38
1
@gauravbharadwaj it's also in C++17 and pretty much guaranteed to be in C++20. I don't think this question is really specific to any particular version of the language at this point…
– Michael Kenzel
Apr 25 at 13:14
1
@gauravbharadwaj I think it is fair that you tagged boost, and that other guy's comment was ridiculously worded. However I also believe the tag is wrong, this is a pure standard C++ matter and you do not even know about the existence of boost to answer this question.
– ypnos
Apr 26 at 9:52
|
show 6 more comments
I have a hierarchy of base class and derived class. Base class has one virtual function which is overridden by derived class.
class Base
{
public:
~Base();
virtual void other_functionality() = 0;
};
class Derived : public Base
{
public:
~Derived ();
void other_functionality() {//some code};
};
Now if i do like this:
int main()
{
Base * P = new Derived ();
delete p;
return 0;
}
It gives error:
deleting object of polymorphic class type which has non-virtual destructor.
But with unique_ptr it passes without warning.
int main()
{
std::unique_ptr<Base> p;
p.reset(new Derived ());
return 0;
}
I know if I use virtual destructor. Warning with naked pointer will be solved. But question remains - why absence of virtual destructor shows problem with naked pointer and not with unique_ptr.
c++ c++14 gcc-warning
I have a hierarchy of base class and derived class. Base class has one virtual function which is overridden by derived class.
class Base
{
public:
~Base();
virtual void other_functionality() = 0;
};
class Derived : public Base
{
public:
~Derived ();
void other_functionality() {//some code};
};
Now if i do like this:
int main()
{
Base * P = new Derived ();
delete p;
return 0;
}
It gives error:
deleting object of polymorphic class type which has non-virtual destructor.
But with unique_ptr it passes without warning.
int main()
{
std::unique_ptr<Base> p;
p.reset(new Derived ());
return 0;
}
I know if I use virtual destructor. Warning with naked pointer will be solved. But question remains - why absence of virtual destructor shows problem with naked pointer and not with unique_ptr.
c++ c++14 gcc-warning
c++ c++14 gcc-warning
edited Apr 25 at 12:09
ypnos
37.6k1378114
37.6k1378114
asked Apr 25 at 12:01
gaurav bharadwajgaurav bharadwaj
645819
645819
2
For the record,clang
does complain: godbolt.org/z/qEp6Ts
– Max Langhof
Apr 25 at 12:24
1
@P.W I don't think this is a duplicate. At least, answers to both questions are different. (Answer to the original question is "because the Stadnard does not require such a check". Answer to this question is "because gcc supresses warnings for system headers".)
– Daniel Langr
Apr 25 at 12:35
1
@DanielLangr: The question seemed the same in essence. But the answers do not directly address why the compiler does not issue a diagnostic. So I will reopen.
– P.W
Apr 25 at 12:38
1
@gauravbharadwaj it's also in C++17 and pretty much guaranteed to be in C++20. I don't think this question is really specific to any particular version of the language at this point…
– Michael Kenzel
Apr 25 at 13:14
1
@gauravbharadwaj I think it is fair that you tagged boost, and that other guy's comment was ridiculously worded. However I also believe the tag is wrong, this is a pure standard C++ matter and you do not even know about the existence of boost to answer this question.
– ypnos
Apr 26 at 9:52
|
show 6 more comments
2
For the record,clang
does complain: godbolt.org/z/qEp6Ts
– Max Langhof
Apr 25 at 12:24
1
@P.W I don't think this is a duplicate. At least, answers to both questions are different. (Answer to the original question is "because the Stadnard does not require such a check". Answer to this question is "because gcc supresses warnings for system headers".)
– Daniel Langr
Apr 25 at 12:35
1
@DanielLangr: The question seemed the same in essence. But the answers do not directly address why the compiler does not issue a diagnostic. So I will reopen.
– P.W
Apr 25 at 12:38
1
@gauravbharadwaj it's also in C++17 and pretty much guaranteed to be in C++20. I don't think this question is really specific to any particular version of the language at this point…
– Michael Kenzel
Apr 25 at 13:14
1
@gauravbharadwaj I think it is fair that you tagged boost, and that other guy's comment was ridiculously worded. However I also believe the tag is wrong, this is a pure standard C++ matter and you do not even know about the existence of boost to answer this question.
– ypnos
Apr 26 at 9:52
2
2
For the record,
clang
does complain: godbolt.org/z/qEp6Ts– Max Langhof
Apr 25 at 12:24
For the record,
clang
does complain: godbolt.org/z/qEp6Ts– Max Langhof
Apr 25 at 12:24
1
1
@P.W I don't think this is a duplicate. At least, answers to both questions are different. (Answer to the original question is "because the Stadnard does not require such a check". Answer to this question is "because gcc supresses warnings for system headers".)
– Daniel Langr
Apr 25 at 12:35
@P.W I don't think this is a duplicate. At least, answers to both questions are different. (Answer to the original question is "because the Stadnard does not require such a check". Answer to this question is "because gcc supresses warnings for system headers".)
– Daniel Langr
Apr 25 at 12:35
1
1
@DanielLangr: The question seemed the same in essence. But the answers do not directly address why the compiler does not issue a diagnostic. So I will reopen.
– P.W
Apr 25 at 12:38
@DanielLangr: The question seemed the same in essence. But the answers do not directly address why the compiler does not issue a diagnostic. So I will reopen.
– P.W
Apr 25 at 12:38
1
1
@gauravbharadwaj it's also in C++17 and pretty much guaranteed to be in C++20. I don't think this question is really specific to any particular version of the language at this point…
– Michael Kenzel
Apr 25 at 13:14
@gauravbharadwaj it's also in C++17 and pretty much guaranteed to be in C++20. I don't think this question is really specific to any particular version of the language at this point…
– Michael Kenzel
Apr 25 at 13:14
1
1
@gauravbharadwaj I think it is fair that you tagged boost, and that other guy's comment was ridiculously worded. However I also believe the tag is wrong, this is a pure standard C++ matter and you do not even know about the existence of boost to answer this question.
– ypnos
Apr 26 at 9:52
@gauravbharadwaj I think it is fair that you tagged boost, and that other guy's comment was ridiculously worded. However I also believe the tag is wrong, this is a pure standard C++ matter and you do not even know about the existence of boost to answer this question.
– ypnos
Apr 26 at 9:52
|
show 6 more comments
2 Answers
2
active
oldest
votes
Well, first of all, deleting a derived object through a base pointer when the base class does not have a virtual destructor is undefined behavior. Compilers are not required to diagnose undefined behavior…
That being said, the reason why this warning does not appear when using std::unique_ptr
is most likely due to the fact that GCC does not report warnings that would appear in system headers.
5
That's a good find from GCC manual.
– P.W
Apr 25 at 12:48
add a comment |
I cannot find a link, but I did see a discussion of this online, in GCC bug database.
The warning is issued on the actual delete
expression. In the case of unique_ptr
, the delete
is called inside a system header file.
According to the discussion in that bug report, implementing C++ system libraries requires all sorts of compromises that result in various warnings. Therefore, the warnings are restricted inside system headers. That is the reason you won't see the warning you expect.
Update: and here it is, straight from the horse's mouth:
https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
The header files declaring interfaces to the operating system and runtime libraries often cannot be written in strictly conforming C. Therefore, GCC gives code found in system headers special treatment. All warnings, other than those generated by ‘#warning’ (see Diagnostics), are suppressed while GCC is processing a system header.
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55848866%2fstdunique-ptr-of-base-class-holding-reference-of-derived-class-does-not-show-w%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Well, first of all, deleting a derived object through a base pointer when the base class does not have a virtual destructor is undefined behavior. Compilers are not required to diagnose undefined behavior…
That being said, the reason why this warning does not appear when using std::unique_ptr
is most likely due to the fact that GCC does not report warnings that would appear in system headers.
5
That's a good find from GCC manual.
– P.W
Apr 25 at 12:48
add a comment |
Well, first of all, deleting a derived object through a base pointer when the base class does not have a virtual destructor is undefined behavior. Compilers are not required to diagnose undefined behavior…
That being said, the reason why this warning does not appear when using std::unique_ptr
is most likely due to the fact that GCC does not report warnings that would appear in system headers.
5
That's a good find from GCC manual.
– P.W
Apr 25 at 12:48
add a comment |
Well, first of all, deleting a derived object through a base pointer when the base class does not have a virtual destructor is undefined behavior. Compilers are not required to diagnose undefined behavior…
That being said, the reason why this warning does not appear when using std::unique_ptr
is most likely due to the fact that GCC does not report warnings that would appear in system headers.
Well, first of all, deleting a derived object through a base pointer when the base class does not have a virtual destructor is undefined behavior. Compilers are not required to diagnose undefined behavior…
That being said, the reason why this warning does not appear when using std::unique_ptr
is most likely due to the fact that GCC does not report warnings that would appear in system headers.
answered Apr 25 at 12:24
Michael KenzelMichael Kenzel
10.6k11926
10.6k11926
5
That's a good find from GCC manual.
– P.W
Apr 25 at 12:48
add a comment |
5
That's a good find from GCC manual.
– P.W
Apr 25 at 12:48
5
5
That's a good find from GCC manual.
– P.W
Apr 25 at 12:48
That's a good find from GCC manual.
– P.W
Apr 25 at 12:48
add a comment |
I cannot find a link, but I did see a discussion of this online, in GCC bug database.
The warning is issued on the actual delete
expression. In the case of unique_ptr
, the delete
is called inside a system header file.
According to the discussion in that bug report, implementing C++ system libraries requires all sorts of compromises that result in various warnings. Therefore, the warnings are restricted inside system headers. That is the reason you won't see the warning you expect.
Update: and here it is, straight from the horse's mouth:
https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
The header files declaring interfaces to the operating system and runtime libraries often cannot be written in strictly conforming C. Therefore, GCC gives code found in system headers special treatment. All warnings, other than those generated by ‘#warning’ (see Diagnostics), are suppressed while GCC is processing a system header.
add a comment |
I cannot find a link, but I did see a discussion of this online, in GCC bug database.
The warning is issued on the actual delete
expression. In the case of unique_ptr
, the delete
is called inside a system header file.
According to the discussion in that bug report, implementing C++ system libraries requires all sorts of compromises that result in various warnings. Therefore, the warnings are restricted inside system headers. That is the reason you won't see the warning you expect.
Update: and here it is, straight from the horse's mouth:
https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
The header files declaring interfaces to the operating system and runtime libraries often cannot be written in strictly conforming C. Therefore, GCC gives code found in system headers special treatment. All warnings, other than those generated by ‘#warning’ (see Diagnostics), are suppressed while GCC is processing a system header.
add a comment |
I cannot find a link, but I did see a discussion of this online, in GCC bug database.
The warning is issued on the actual delete
expression. In the case of unique_ptr
, the delete
is called inside a system header file.
According to the discussion in that bug report, implementing C++ system libraries requires all sorts of compromises that result in various warnings. Therefore, the warnings are restricted inside system headers. That is the reason you won't see the warning you expect.
Update: and here it is, straight from the horse's mouth:
https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
The header files declaring interfaces to the operating system and runtime libraries often cannot be written in strictly conforming C. Therefore, GCC gives code found in system headers special treatment. All warnings, other than those generated by ‘#warning’ (see Diagnostics), are suppressed while GCC is processing a system header.
I cannot find a link, but I did see a discussion of this online, in GCC bug database.
The warning is issued on the actual delete
expression. In the case of unique_ptr
, the delete
is called inside a system header file.
According to the discussion in that bug report, implementing C++ system libraries requires all sorts of compromises that result in various warnings. Therefore, the warnings are restricted inside system headers. That is the reason you won't see the warning you expect.
Update: and here it is, straight from the horse's mouth:
https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
The header files declaring interfaces to the operating system and runtime libraries often cannot be written in strictly conforming C. Therefore, GCC gives code found in system headers special treatment. All warnings, other than those generated by ‘#warning’ (see Diagnostics), are suppressed while GCC is processing a system header.
answered Apr 25 at 12:28
ArkadiyArkadiy
18.4k558103
18.4k558103
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55848866%2fstdunique-ptr-of-base-class-holding-reference-of-derived-class-does-not-show-w%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
For the record,
clang
does complain: godbolt.org/z/qEp6Ts– Max Langhof
Apr 25 at 12:24
1
@P.W I don't think this is a duplicate. At least, answers to both questions are different. (Answer to the original question is "because the Stadnard does not require such a check". Answer to this question is "because gcc supresses warnings for system headers".)
– Daniel Langr
Apr 25 at 12:35
1
@DanielLangr: The question seemed the same in essence. But the answers do not directly address why the compiler does not issue a diagnostic. So I will reopen.
– P.W
Apr 25 at 12:38
1
@gauravbharadwaj it's also in C++17 and pretty much guaranteed to be in C++20. I don't think this question is really specific to any particular version of the language at this point…
– Michael Kenzel
Apr 25 at 13:14
1
@gauravbharadwaj I think it is fair that you tagged boost, and that other guy's comment was ridiculously worded. However I also believe the tag is wrong, this is a pure standard C++ matter and you do not even know about the existence of boost to answer this question.
– ypnos
Apr 26 at 9:52