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;
}







34















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.










share|improve this question




















  • 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


















34















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.










share|improve this question




















  • 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














34












34








34


1






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.










share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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














  • 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












2 Answers
2






active

oldest

votes


















40














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.






share|improve this answer



















  • 5





    That's a good find from GCC manual.

    – P.W
    Apr 25 at 12:48



















21














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.







share|improve this answer
























    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


















    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









    40














    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.






    share|improve this answer



















    • 5





      That's a good find from GCC manual.

      – P.W
      Apr 25 at 12:48
















    40














    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.






    share|improve this answer



















    • 5





      That's a good find from GCC manual.

      – P.W
      Apr 25 at 12:48














    40












    40








    40







    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.






    share|improve this answer













    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    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














    • 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













    21














    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.







    share|improve this answer




























      21














      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.







      share|improve this answer


























        21












        21








        21







        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.







        share|improve this answer













        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.








        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Apr 25 at 12:28









        ArkadiyArkadiy

        18.4k558103




        18.4k558103






























            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














            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





















































            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







            Popular posts from this blog

            He _____ here since 1970 . Answer needed [closed]What does “since he was so high” mean?Meaning of “catch birds for”?How do I ensure “since” takes the meaning I want?“Who cares here” meaningWhat does “right round toward” mean?the time tense (had now been detected)What does the phrase “ring around the roses” mean here?Correct usage of “visited upon”Meaning of “foiled rail sabotage bid”It was the third time I had gone to Rome or It is the third time I had been to Rome

            Bunad

            Færeyskur hestur Heimild | Tengill | Tilvísanir | LeiðsagnarvalRossið - síða um færeyska hrossið á færeyskuGott ár hjá færeyska hestinum