std::unique_ptr of base class holding reference of derived class does not show warning in gcc compiler while...
Can a level 2 Warlock take one level in rogue, then continue advancing as a warlock?
How long after the last departure shall the airport stay open for an emergency return?
How to not starve gigantic beasts
"Whatever a Russian does, they end up making the Kalashnikov gun"? Are there any similar proverbs in English?
How important is it that $TERM is correct?
Does a large simulator bay have standard public address announcements?
"The cow" OR "a cow" OR "cows" in this context
How to have a sharp product image?
Injection into a proper class and choice without regularity
Why do distances seem to matter in the Foundation world?
A Paper Record is What I Hamper
A strange hotel
Island of Knights, Knaves and Spies
My bank got bought out, am I now going to have to start filing tax returns in a different state?
Israeli soda type drink
Why is the underscore command _ useful?
How much of a wave function must reside inside event horizon for it to be consumed by the black hole?
What is the unit of time_lock_delta in LND?
Can I criticise the more senior developers around me for not writing clean code?
Contradiction proof for inequality of P and NP?
Is there a word for the censored part of a video?
Is it acceptable to use working hours to read general interest books?
Is Electric Central Heating worth it if using Solar Panels?
Do I need to watch Ant-Man and the Wasp and Captain Marvel before watching Avengers: Endgame?
std::unique_ptr of base class holding reference of derived class does not show warning in gcc compiler while naked pointer shows it. Why?
Why unique-ptr doesn't check base class to virtual destructible?Does delete work with pointers to base class?Why does an overridden function in the derived class hide other overloads of the base class?Why simple destructor does not delete the derived object if declared using base pointerCalling a Derived Class method from a Void Pointer cast to a Base Objectclang & gcc don't warn about non-virtual base destructors for polymorphism when using smart pointers?Why is initialization of derived class through a base class pointer different from that through a derived class pointer?Destructor when derived class contains a pointer to base class objectUsing base class rather than base pointer to work on derived classHow to prevent a derived class object under base class pointer calling a public nonvirtual function defined in base class but overridden in derived?How can I convert std::make_unique<derived>() to std::unique_ptr<base>
.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
edited 17 hours ago
ypnos
37.2k1377113
asked 17 hours ago
gaurav bharadwajgaurav bharadwaj
572618
|
show 5 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
edited 17 hours ago
ypnos
37.2k1377113
asked 17 hours ago
gaurav bharadwajgaurav bharadwaj
572618
@AndriyTylychko unique_ptr exist in boost too and behavior of that and std::unique_ptr has lot of similarity. Isn't it.
– gaurav bharadwaj
17 hours ago
2
For the record,clangdoes complain: godbolt.org/z/qEp6Ts
– Max Langhof
16 hours ago
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
16 hours ago
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
16 hours ago
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
16 hours ago
|
show 5 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
edited 17 hours ago
ypnos
37.2k1377113
asked 17 hours ago
gaurav bharadwajgaurav bharadwaj
572618
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 17 hours ago
ypnos
37.2k1377113
asked 17 hours ago
gaurav bharadwajgaurav bharadwaj
572618
edited 17 hours ago
ypnos
37.2k1377113
asked 17 hours ago
gaurav bharadwajgaurav bharadwaj
572618
edited 17 hours ago
ypnos
37.2k1377113
edited 17 hours ago
ypnos
37.2k1377113
edited 17 hours ago
ypnos
37.2k1377113
37.2k1377113
asked 17 hours ago
gaurav bharadwajgaurav bharadwaj
572618
asked 17 hours ago
gaurav bharadwajgaurav bharadwaj
572618
asked 17 hours ago
gaurav bharadwajgaurav bharadwaj
572618
572618
@AndriyTylychko unique_ptr exist in boost too and behavior of that and std::unique_ptr has lot of similarity. Isn't it.
– gaurav bharadwaj
17 hours ago
2
For the record,clangdoes complain: godbolt.org/z/qEp6Ts
– Max Langhof
16 hours ago
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
16 hours ago
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
16 hours ago
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
16 hours ago
|
show 5 more comments
@AndriyTylychko unique_ptr exist in boost too and behavior of that and std::unique_ptr has lot of similarity. Isn't it.
– gaurav bharadwaj
17 hours ago
2
For the record,clangdoes complain: godbolt.org/z/qEp6Ts
– Max Langhof
16 hours ago
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
16 hours ago
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
16 hours ago
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
16 hours ago
@AndriyTylychko unique_ptr exist in boost too and behavior of that and std::unique_ptr has lot of similarity. Isn't it.
– gaurav bharadwaj
17 hours ago
@AndriyTylychko unique_ptr exist in boost too and behavior of that and std::unique_ptr has lot of similarity. Isn't it.
– gaurav bharadwaj
17 hours ago
2
2
For the record,
clang does complain: godbolt.org/z/qEp6Ts– Max Langhof
16 hours ago
For the record,
clang does complain: godbolt.org/z/qEp6Ts– Max Langhof
16 hours ago
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
16 hours ago
@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
16 hours ago
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
16 hours ago
@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
16 hours ago
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
16 hours ago
@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
16 hours ago
|
show 5 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.
answered 16 hours ago
Michael KenzelMichael Kenzel
8,68811625
4
That's a good find from GCC manual.
– P.W
16 hours ago
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.
answered 16 hours ago
ArkadiyArkadiy
18.2k559103
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.
answered 16 hours ago
Michael KenzelMichael Kenzel
8,68811625
4
That's a good find from GCC manual.
– P.W
16 hours ago
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.
answered 16 hours ago
Michael KenzelMichael Kenzel
8,68811625
4
That's a good find from GCC manual.
– P.W
16 hours ago
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.
answered 16 hours ago
Michael KenzelMichael Kenzel
8,68811625
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 16 hours ago
Michael KenzelMichael Kenzel
8,68811625
answered 16 hours ago
Michael KenzelMichael Kenzel
8,68811625
answered 16 hours ago
Michael KenzelMichael Kenzel
8,68811625
answered 16 hours ago
Michael KenzelMichael Kenzel
8,68811625
8,68811625
4
That's a good find from GCC manual.
– P.W
16 hours ago
add a comment |
4
That's a good find from GCC manual.
– P.W
16 hours ago
4
4
That's a good find from GCC manual.
– P.W
16 hours ago
That's a good find from GCC manual.
– P.W
16 hours ago
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.
answered 16 hours ago
ArkadiyArkadiy
18.2k559103
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.
answered 16 hours ago
ArkadiyArkadiy
18.2k559103
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.
answered 16 hours ago
ArkadiyArkadiy
18.2k559103
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 16 hours ago
ArkadiyArkadiy
18.2k559103
answered 16 hours ago
ArkadiyArkadiy
18.2k559103
answered 16 hours ago
ArkadiyArkadiy
18.2k559103
answered 16 hours ago
ArkadiyArkadiy
18.2k559103
18.2k559103
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
@AndriyTylychko unique_ptr exist in boost too and behavior of that and std::unique_ptr has lot of similarity. Isn't it.
– gaurav bharadwaj
17 hours ago
2
For the record,
clangdoes complain: godbolt.org/z/qEp6Ts– Max Langhof
16 hours ago
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
16 hours ago
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
16 hours ago
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
16 hours ago