C++ Constructor/Destructor inheritance





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}







54















EDIT : Summary of answers



In the following, B is a subclass of A.



It's a matter of terminology; ctors and dtors are not inherited, in the sense that the ctor/dtor of B will not be borrowed from A's interface. A class has at least one constructor, and has exactly one destructor.





  • Constructors:


    • B does not inherit constructors from A;

    • Unless B's ctor explicitely calls one of A's ctor, the default ctor from A will be called automatically before B's ctor body (the idea being that A needs to be initialized before B gets created).




  • Destructors:


    • B does not inherit A's dtor;


    • After it exits, B's destructor will automatically call A's destructor.




Acknowledgements:
I would like to thank especially Oli Charlesworth and Kos for their answers, I set Kos' answer as the solution because it was the one I understood best.





ORIGINAL POST



When you search for "C++ destructor inheritance site:stackoverflow.com" on Google, you currently find the following posts:





  1. Constructor and Destructor Inheritance: two users with 30k+ reputation say that it is inherited, and that it's not


  2. Are virtual destructors inherited?: here nothing is mentioned that would point to destructors not being inherited


  3. Destructors and inheritance in C++?: The comments seem to indicate the destructors are inherited


Q1: What I also know from practice, is that you cannot initialize a derived object with the same prototype than it's parent constructor without explicitely defining a constructor for the derived class, is that correct?





Even though it's rather clear from the posts that destructors seem to be inherited, I'm still puzzled by the fact that a user with 32k reputation would say its not. I wrote a little example that should clarify everyone's mind:



#include <cstdio>

/******************************/

// Base class
struct A
{
A() { printf( "tInstance counter = %d (ctor)n", ++instance_counter ); }
~A() { printf( "tInstance counter = %d (dtor)n", --instance_counter ); }

static int instance_counter;
};

// Inherited class with default ctor/dtor
class B : public A {};

// Inherited class with defined ctor/dtor
struct C : public A
{
C() { printf("tC says hi!n"); }
~C() { printf("tC says bye!n"); }
};

/******************************/

// Initialize counter
int A::instance_counter = 0;

/******************************/

// A few tests
int main()
{
printf("Create An"); A a;
printf("Delete An"); a.~A();

printf("Create Bn"); B b;
printf("Delete Bn"); b.~B();

printf("Create new B stored as A*n"); A *a_ptr = new B();
printf("Delete previous pointern"); delete a_ptr;

printf("Create Cn"); C c;
printf("Delete Cn"); c.~C();

}


and here is the output (compiled with g++ 4.4.3):



Create A
Instance counter = 1 (ctor)
Delete A
Instance counter = 0 (dtor)
Create B
Instance counter = 1 (ctor)
Delete B
Instance counter = 0 (dtor)
Create new B stored as A*
Instance counter = 1 (ctor)
Delete previous pointer
Instance counter = 0 (dtor)
Create C
Instance counter = 1 (ctor)
C says hi!
Delete C
C says bye!
Instance counter = 0 (dtor) // We exit main() now
C says bye!
Instance counter = -1 (dtor)
Instance counter = -2 (dtor)
Instance counter = -3 (dtor)


Q2: Can anybody who thinks it's not inherited please explain that?



Q3: So what happens when you call the constructor of a subclass with inputs? Is the "empty constructor" of the superclass called as well?










share|improve this question































    54















    EDIT : Summary of answers



    In the following, B is a subclass of A.



    It's a matter of terminology; ctors and dtors are not inherited, in the sense that the ctor/dtor of B will not be borrowed from A's interface. A class has at least one constructor, and has exactly one destructor.





    • Constructors:


      • B does not inherit constructors from A;

      • Unless B's ctor explicitely calls one of A's ctor, the default ctor from A will be called automatically before B's ctor body (the idea being that A needs to be initialized before B gets created).




    • Destructors:


      • B does not inherit A's dtor;


      • After it exits, B's destructor will automatically call A's destructor.




    Acknowledgements:
    I would like to thank especially Oli Charlesworth and Kos for their answers, I set Kos' answer as the solution because it was the one I understood best.





    ORIGINAL POST



    When you search for "C++ destructor inheritance site:stackoverflow.com" on Google, you currently find the following posts:





    1. Constructor and Destructor Inheritance: two users with 30k+ reputation say that it is inherited, and that it's not


    2. Are virtual destructors inherited?: here nothing is mentioned that would point to destructors not being inherited


    3. Destructors and inheritance in C++?: The comments seem to indicate the destructors are inherited


    Q1: What I also know from practice, is that you cannot initialize a derived object with the same prototype than it's parent constructor without explicitely defining a constructor for the derived class, is that correct?





    Even though it's rather clear from the posts that destructors seem to be inherited, I'm still puzzled by the fact that a user with 32k reputation would say its not. I wrote a little example that should clarify everyone's mind:



    #include <cstdio>

    /******************************/

    // Base class
    struct A
    {
    A() { printf( "tInstance counter = %d (ctor)n", ++instance_counter ); }
    ~A() { printf( "tInstance counter = %d (dtor)n", --instance_counter ); }

    static int instance_counter;
    };

    // Inherited class with default ctor/dtor
    class B : public A {};

    // Inherited class with defined ctor/dtor
    struct C : public A
    {
    C() { printf("tC says hi!n"); }
    ~C() { printf("tC says bye!n"); }
    };

    /******************************/

    // Initialize counter
    int A::instance_counter = 0;

    /******************************/

    // A few tests
    int main()
    {
    printf("Create An"); A a;
    printf("Delete An"); a.~A();

    printf("Create Bn"); B b;
    printf("Delete Bn"); b.~B();

    printf("Create new B stored as A*n"); A *a_ptr = new B();
    printf("Delete previous pointern"); delete a_ptr;

    printf("Create Cn"); C c;
    printf("Delete Cn"); c.~C();

    }


    and here is the output (compiled with g++ 4.4.3):



    Create A
    Instance counter = 1 (ctor)
    Delete A
    Instance counter = 0 (dtor)
    Create B
    Instance counter = 1 (ctor)
    Delete B
    Instance counter = 0 (dtor)
    Create new B stored as A*
    Instance counter = 1 (ctor)
    Delete previous pointer
    Instance counter = 0 (dtor)
    Create C
    Instance counter = 1 (ctor)
    C says hi!
    Delete C
    C says bye!
    Instance counter = 0 (dtor) // We exit main() now
    C says bye!
    Instance counter = -1 (dtor)
    Instance counter = -2 (dtor)
    Instance counter = -3 (dtor)


    Q2: Can anybody who thinks it's not inherited please explain that?



    Q3: So what happens when you call the constructor of a subclass with inputs? Is the "empty constructor" of the superclass called as well?










    share|improve this question



























      54












      54








      54


      29






      EDIT : Summary of answers



      In the following, B is a subclass of A.



      It's a matter of terminology; ctors and dtors are not inherited, in the sense that the ctor/dtor of B will not be borrowed from A's interface. A class has at least one constructor, and has exactly one destructor.





      • Constructors:


        • B does not inherit constructors from A;

        • Unless B's ctor explicitely calls one of A's ctor, the default ctor from A will be called automatically before B's ctor body (the idea being that A needs to be initialized before B gets created).




      • Destructors:


        • B does not inherit A's dtor;


        • After it exits, B's destructor will automatically call A's destructor.




      Acknowledgements:
      I would like to thank especially Oli Charlesworth and Kos for their answers, I set Kos' answer as the solution because it was the one I understood best.





      ORIGINAL POST



      When you search for "C++ destructor inheritance site:stackoverflow.com" on Google, you currently find the following posts:





      1. Constructor and Destructor Inheritance: two users with 30k+ reputation say that it is inherited, and that it's not


      2. Are virtual destructors inherited?: here nothing is mentioned that would point to destructors not being inherited


      3. Destructors and inheritance in C++?: The comments seem to indicate the destructors are inherited


      Q1: What I also know from practice, is that you cannot initialize a derived object with the same prototype than it's parent constructor without explicitely defining a constructor for the derived class, is that correct?





      Even though it's rather clear from the posts that destructors seem to be inherited, I'm still puzzled by the fact that a user with 32k reputation would say its not. I wrote a little example that should clarify everyone's mind:



      #include <cstdio>

      /******************************/

      // Base class
      struct A
      {
      A() { printf( "tInstance counter = %d (ctor)n", ++instance_counter ); }
      ~A() { printf( "tInstance counter = %d (dtor)n", --instance_counter ); }

      static int instance_counter;
      };

      // Inherited class with default ctor/dtor
      class B : public A {};

      // Inherited class with defined ctor/dtor
      struct C : public A
      {
      C() { printf("tC says hi!n"); }
      ~C() { printf("tC says bye!n"); }
      };

      /******************************/

      // Initialize counter
      int A::instance_counter = 0;

      /******************************/

      // A few tests
      int main()
      {
      printf("Create An"); A a;
      printf("Delete An"); a.~A();

      printf("Create Bn"); B b;
      printf("Delete Bn"); b.~B();

      printf("Create new B stored as A*n"); A *a_ptr = new B();
      printf("Delete previous pointern"); delete a_ptr;

      printf("Create Cn"); C c;
      printf("Delete Cn"); c.~C();

      }


      and here is the output (compiled with g++ 4.4.3):



      Create A
      Instance counter = 1 (ctor)
      Delete A
      Instance counter = 0 (dtor)
      Create B
      Instance counter = 1 (ctor)
      Delete B
      Instance counter = 0 (dtor)
      Create new B stored as A*
      Instance counter = 1 (ctor)
      Delete previous pointer
      Instance counter = 0 (dtor)
      Create C
      Instance counter = 1 (ctor)
      C says hi!
      Delete C
      C says bye!
      Instance counter = 0 (dtor) // We exit main() now
      C says bye!
      Instance counter = -1 (dtor)
      Instance counter = -2 (dtor)
      Instance counter = -3 (dtor)


      Q2: Can anybody who thinks it's not inherited please explain that?



      Q3: So what happens when you call the constructor of a subclass with inputs? Is the "empty constructor" of the superclass called as well?










      share|improve this question
















      EDIT : Summary of answers



      In the following, B is a subclass of A.



      It's a matter of terminology; ctors and dtors are not inherited, in the sense that the ctor/dtor of B will not be borrowed from A's interface. A class has at least one constructor, and has exactly one destructor.





      • Constructors:


        • B does not inherit constructors from A;

        • Unless B's ctor explicitely calls one of A's ctor, the default ctor from A will be called automatically before B's ctor body (the idea being that A needs to be initialized before B gets created).




      • Destructors:


        • B does not inherit A's dtor;


        • After it exits, B's destructor will automatically call A's destructor.




      Acknowledgements:
      I would like to thank especially Oli Charlesworth and Kos for their answers, I set Kos' answer as the solution because it was the one I understood best.





      ORIGINAL POST



      When you search for "C++ destructor inheritance site:stackoverflow.com" on Google, you currently find the following posts:





      1. Constructor and Destructor Inheritance: two users with 30k+ reputation say that it is inherited, and that it's not


      2. Are virtual destructors inherited?: here nothing is mentioned that would point to destructors not being inherited


      3. Destructors and inheritance in C++?: The comments seem to indicate the destructors are inherited


      Q1: What I also know from practice, is that you cannot initialize a derived object with the same prototype than it's parent constructor without explicitely defining a constructor for the derived class, is that correct?





      Even though it's rather clear from the posts that destructors seem to be inherited, I'm still puzzled by the fact that a user with 32k reputation would say its not. I wrote a little example that should clarify everyone's mind:



      #include <cstdio>

      /******************************/

      // Base class
      struct A
      {
      A() { printf( "tInstance counter = %d (ctor)n", ++instance_counter ); }
      ~A() { printf( "tInstance counter = %d (dtor)n", --instance_counter ); }

      static int instance_counter;
      };

      // Inherited class with default ctor/dtor
      class B : public A {};

      // Inherited class with defined ctor/dtor
      struct C : public A
      {
      C() { printf("tC says hi!n"); }
      ~C() { printf("tC says bye!n"); }
      };

      /******************************/

      // Initialize counter
      int A::instance_counter = 0;

      /******************************/

      // A few tests
      int main()
      {
      printf("Create An"); A a;
      printf("Delete An"); a.~A();

      printf("Create Bn"); B b;
      printf("Delete Bn"); b.~B();

      printf("Create new B stored as A*n"); A *a_ptr = new B();
      printf("Delete previous pointern"); delete a_ptr;

      printf("Create Cn"); C c;
      printf("Delete Cn"); c.~C();

      }


      and here is the output (compiled with g++ 4.4.3):



      Create A
      Instance counter = 1 (ctor)
      Delete A
      Instance counter = 0 (dtor)
      Create B
      Instance counter = 1 (ctor)
      Delete B
      Instance counter = 0 (dtor)
      Create new B stored as A*
      Instance counter = 1 (ctor)
      Delete previous pointer
      Instance counter = 0 (dtor)
      Create C
      Instance counter = 1 (ctor)
      C says hi!
      Delete C
      C says bye!
      Instance counter = 0 (dtor) // We exit main() now
      C says bye!
      Instance counter = -1 (dtor)
      Instance counter = -2 (dtor)
      Instance counter = -3 (dtor)


      Q2: Can anybody who thinks it's not inherited please explain that?



      Q3: So what happens when you call the constructor of a subclass with inputs? Is the "empty constructor" of the superclass called as well?







      c++ inheritance constructor destructor






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited May 23 '17 at 11:46









      Community

      11




      11










      asked Jan 6 '13 at 16:46









      SheljohnSheljohn

      4,08122656




      4,08122656
























          7 Answers
          7






          active

          oldest

          votes


















          31














          Terminology, terminology...



          OK, what do we mean by "Foo is inherited"? We mean that if objects of class A have Foo in its interface, then objects of class B which is a subclass of A also have Foo in its interface.





          • Constructors aren't a part of objects' interface. They belong directly to classes. Classes A and B may provide completely different sets of constructors. No "being inherited" here.



            (Implementation detail: each B's constructors calls some A's constructor.)




          • Destructors indeed are a part of each object's interface, since the object's user is responsible for calling them (i.e. directly with delete or indirectly by letting an object out of scope). Each object has exactly one destructor: its own destructor, which might optionally be a virtual one. It is always its own, and it's not inherited.



            (Implementation detail: B's destructor calls A's destructor.)




          So: there's a connection between base and derived constructors and destructors, but it's not like "they're inherited".



          I hope this answers what you have in mind.






          share|improve this answer


























          • Comment 1: I just don't understand your first sentence, wouldn't it be "then objects of class B which is a subclass of A also have Foo in their interface"?

            – Sheljohn
            Jan 6 '13 at 17:15











          • Comment 2: So, as with the two comments of Oli Charlesworth and Pete Becker, it seems to be a matter of terminology. It's not inherited, but it calls automatically something from the superclass, is that it?

            – Sheljohn
            Jan 6 '13 at 17:16











          • @Sh3ljohn Comment 1: Of course you're right, I'll edit and fix. Comment 2: Yes, "not inherited" as in "not in the public interface of derived objects", unlike other public class members (methods and fields).

            – Kos
            Jan 6 '13 at 17:30



















          7















          Q1: What I also know from practice, is that you cannot initialize a derived object with the same prototype than it's parent constructor without explicitly defining a constructor for the derived class, is that correct?




          Other than the trivial case where you've defined a default constructor in the superclass, yes you are correct.






          Q2: Can anybody who thinks it's not inherited please explain that?




          This may be a matter of definitions of terminology. Whilst it's clear that virtual destructors exist and work "as expected", we see in the C++ standard ([class.virtual]):




          Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual




          (emphasis mine)






          Q3: So what happens when you call the constructor of a subclass with inputs? Is the "empty constructor" of the superclass called as well?




          If you don't explicitly invoke a specific superclass constructor, then the default superclass constructor will be called (assuming it's visible).






          share|improve this answer


























          • Thank you :) So for Q2, what does it mean exactly? From what I understand of the quote; destructors are not inherited, which means deleting B should not decrement the counter.

            – Sheljohn
            Jan 6 '13 at 16:59













          • @Sh3ljohn: What, specifically, are you asking whether "it's not supposed to be like that"?

            – Oliver Charlesworth
            Jan 6 '13 at 17:01











          • Sorry I was editing my comment when you posted your answer, this should be clearer.

            – Sheljohn
            Jan 6 '13 at 17:04








          • 1





            @Sh3ljohn: The superclass destructor are implicitly called by the subclass destructor, whether it's explicitly defined or not.

            – Oliver Charlesworth
            Jan 6 '13 at 17:09






          • 1





            @Sh3ljohn: The term 'inherited' has a very specific meaning within the C++ standard that differs slightly from the common usage of the term. This is the main area where that difference manifests itself. What the C++ standard is essentially stating is that the destructor of a base class is not part of a derived class (it is not inherited in that sense). But the virtual-call mechanism is still required to work if destructors are involved (so in that sense, destructors are 'inherited')

            – Bart van Ingen Schenau
            Jan 6 '13 at 17:11



















          4














          Destructors are not inherited. If a class doesn't define one, the compiler generates one. For trivial cases that destructor just calls the base class' destructor, and often that means that there is no explicit code for its destructor (which imitates inheritance). But if a class has members with destructors, the generated destructor calls destructors for those members before calling the base class' destructor. That's something that an inherited function would not do.






          share|improve this answer
























          • So it's all about the word "inheritance" right? Because C's destructor still calls A's destructor in the example.

            – Sheljohn
            Jan 6 '13 at 17:12






          • 1





            if C::f() calls A::f(), it is not the case that C inherits A::f.

            – Pete Becker
            Jan 6 '13 at 17:14











          • Hmm. So why does an example in the Standard use, and g++ allows, d.B::~B();?

            – aschepler
            Jan 6 '13 at 21:33











          • @aschepler - inheritance is about interfaces: if you don't write it in the derived class but it's available from the base, it's inherited.

            – Pete Becker
            Jan 7 '13 at 12:43



















          3














          Inheritance is what : mechanism of reusing and extending existing classes without modifying them, thus producing hierarchical relationships between them.



          Inheritance is almost like embedding an object into a class.



          when class is inheriting a base class then the base class's constructor is called first then derived class's ,and the destructor's call is in reverse order.



          So Why Base Class Constructor is called (called not inherited may be with parameters/default) : to guarantees that the base class is properly constructed when the constructor for the derived class is executed.



          Now Calling of Destructor (calling not inherit) : when base object get out of scope then the destructor is called on its own.so there is np issue of inheritance of destructor.



          now your questions:



          ans 1 - yes you are correct for first question.
          ans 2 - so destructor is called not inherited after the scope of object goes out.

          & ans 3 - if in derived class you are giving the call with parameters then only that constructor would get called , with it no other constructor would get called.


          there is no point of issuse that 2 constructor of same object would get called on object creation,as
          constructor called at the creation of an object. It prepares the new object for use.so there is no logic of preparing the object twice with different constructors.






          share|improve this answer

































            3














            Technically, destructors ARE inherited. But in normal circumstances, the inherited destructors are not directly used for a derived class; they're invoked because the derived class's own destructor calls them in order to destroy its own "base class subobjects" as a step within destroying the larger object. And in the unusual circumstances where you do directly use a base class destructor on a derived object, it's very difficult to avoid Undefined Behavior.



            This example comes straight from the C++ Standard (12.4p12).



            struct B {
            virtual ~B() { }
            };
            struct D : B {
            ~D() { }
            };

            D D_object;
            typedef B B_alias;
            B* B_ptr = &D_object;

            void f() {
            D_object.B::~B(); // calls B's destructor
            B_ptr->~B(); // calls D's destructor
            B_ptr->~B_alias(); // calls D's destructor
            B_ptr->B_alias::~B(); // calls B's destructor
            B_ptr->B_alias::~B_alias(); // calls B's destructor
            }


            If ~B were not an inherited member of D, the first statement in f would be ill-formed. As it is, it's legal C++, though extremely dangerous.






            share|improve this answer
























            • What if you made ~B() non-virtual? Would any of the above examples fail?

              – Sheljohn
              Jan 6 '13 at 21:41











            • I think they would all be well-formed, but all do the same thing (call B's destructor, not D's).

              – aschepler
              Jan 6 '13 at 21:42



















            1














            In your example, you're explicitly calling the destructor functions. This is legal (obviously, since it compiled and ran) but almost always incorrect.



            For dynamically-allocated objects created with new, the destructor will be run when the objected is removed with delete.



            For statically-allocated objects, which are created simply by declaring the object within the scope of a function, the destructor is run when the object's scope disappears. That is, when main() exits, the objects' destructors will be run. But you've already run the destructors for those objects by calling them manually! This is why your example's output shows the count decreasing to -3... you've run the destructors for a, b, and c twice.



            Here's the same code, annotated to show when destructors will be automatically run:



            int main()
            {
            printf("Create An"); A a;
            printf("Delete An"); a.~A();

            printf("Create Bn"); B b;
            printf("Delete Bn"); b.~B();

            printf("Create new B stored as A*n"); A *a_ptr = new B();
            printf("Delete previous pointern");
            delete a_ptr; // Implicitly calls destructor for a_ptr. a_ptr is class B,
            // so it would call a_ptr->~B() if it existed. Because B is an A, after
            // its destructor is called, it calls the superclass's destructor,
            // a_ptr->~A().

            printf("Create Cn"); C c;
            printf("Delete Cn"); c.~C();
            }
            // Function exits here at the close brace, so anything declared in its scope is
            // deallocated from the stack and their destructors run.
            // First `c` is destroyed, which calls c.~C(), then because C is a subclass of A
            // calls c.~B() (which doesn't exist, so a blank implementation is used), then
            // because B is a subclass of A calls c.~A(). This decrements the counter, but
            // the count is wrong because you already manually called c.~C(), which you
            // ordinarily shouldn't have done.
            // Then `b` is destroyed, in a similar manner. Now the count is off by 2,
            // because you had already called b.~B().
            // Lastly `a` is destroyed, just as above. And again, because you had already
            // called a.~A(), the count is now off by 3.





            share|improve this answer
























            • I disagree, IMO the destructor of a class should be implemented such that it handles potentially multiple calls (typically, test a member pointer before deleting it). In my case I don't really care if the integer gets negative, and I don't care about the prints either (see comment "we exit main now"). You should delete your post because it doesn't provide an answer to the OP (which already has one btw), if you leave it up people are probably going to downvote...

              – Sheljohn
              Mar 29 '14 at 4:18











            • Unless you know your particular C++ implmentation supports it, calling destructors multiple times isn't safe. "Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended" (C++ standard §12.4.14)

              – BigPeteB
              Mar 31 '14 at 18:10











            • Actually you are right :) I still think it's usually a small effort to make sure the behavior is defined in that case.. You should put this in comment though, this really has nothing to do with the question :)

              – Sheljohn
              Mar 31 '14 at 19:36



















            0














            I would want to express my thoughts. Creating any object is done in two stages:


            1. Allocating area of memory for the object.





            1. Initializing this area of memory.



              The constructor of object is the function (method) of class (for this object), which initializes allocated area of memory and called automatically.
              The inheritance is embedding the object of the one class to the object of other class. There are plays with poiners "this" "under lid". The "this" is pass on implicitly to the method of class.



              What is happening when the code "B b" is done. Firstly the area of memory is allocated for object b. The class B has own default constructor B(), which is automatically called for initializing this memeory. B() is the function therefore the stack frame is created for working one. This constructor has address of b (implicity). But the object of A must be embedded to the object b. The object of A has no name. Constructor of B knows the noname embedded object of A must be created too (so the compiler C++ works). Therefore the constructor of class A for initializing noname embadded object of class A is called in the constructor of B. The new stack frame is called and noname object is being initialized. After that the stack frames are being closed and our object b of class B has been done. I think that address of b and the noname object coincide.



              The destructor is the method of class too. When we call ~B() the b is not destroyed. The destructor is the function called avtomatically when the object is being destroyed. But it doesn't mean that when we call the destructor the object must be destroyed. If the destructor of B is called, the stack frame is created for one. The default desructor of B knows about the noname embedded object of class A (so the compiler C++ works). Therefore the destructore calls the destructor of A.








            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%2f14184341%2fc-constructor-destructor-inheritance%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              7 Answers
              7






              active

              oldest

              votes








              7 Answers
              7






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              31














              Terminology, terminology...



              OK, what do we mean by "Foo is inherited"? We mean that if objects of class A have Foo in its interface, then objects of class B which is a subclass of A also have Foo in its interface.





              • Constructors aren't a part of objects' interface. They belong directly to classes. Classes A and B may provide completely different sets of constructors. No "being inherited" here.



                (Implementation detail: each B's constructors calls some A's constructor.)




              • Destructors indeed are a part of each object's interface, since the object's user is responsible for calling them (i.e. directly with delete or indirectly by letting an object out of scope). Each object has exactly one destructor: its own destructor, which might optionally be a virtual one. It is always its own, and it's not inherited.



                (Implementation detail: B's destructor calls A's destructor.)




              So: there's a connection between base and derived constructors and destructors, but it's not like "they're inherited".



              I hope this answers what you have in mind.






              share|improve this answer


























              • Comment 1: I just don't understand your first sentence, wouldn't it be "then objects of class B which is a subclass of A also have Foo in their interface"?

                – Sheljohn
                Jan 6 '13 at 17:15











              • Comment 2: So, as with the two comments of Oli Charlesworth and Pete Becker, it seems to be a matter of terminology. It's not inherited, but it calls automatically something from the superclass, is that it?

                – Sheljohn
                Jan 6 '13 at 17:16











              • @Sh3ljohn Comment 1: Of course you're right, I'll edit and fix. Comment 2: Yes, "not inherited" as in "not in the public interface of derived objects", unlike other public class members (methods and fields).

                – Kos
                Jan 6 '13 at 17:30
















              31














              Terminology, terminology...



              OK, what do we mean by "Foo is inherited"? We mean that if objects of class A have Foo in its interface, then objects of class B which is a subclass of A also have Foo in its interface.





              • Constructors aren't a part of objects' interface. They belong directly to classes. Classes A and B may provide completely different sets of constructors. No "being inherited" here.



                (Implementation detail: each B's constructors calls some A's constructor.)




              • Destructors indeed are a part of each object's interface, since the object's user is responsible for calling them (i.e. directly with delete or indirectly by letting an object out of scope). Each object has exactly one destructor: its own destructor, which might optionally be a virtual one. It is always its own, and it's not inherited.



                (Implementation detail: B's destructor calls A's destructor.)




              So: there's a connection between base and derived constructors and destructors, but it's not like "they're inherited".



              I hope this answers what you have in mind.






              share|improve this answer


























              • Comment 1: I just don't understand your first sentence, wouldn't it be "then objects of class B which is a subclass of A also have Foo in their interface"?

                – Sheljohn
                Jan 6 '13 at 17:15











              • Comment 2: So, as with the two comments of Oli Charlesworth and Pete Becker, it seems to be a matter of terminology. It's not inherited, but it calls automatically something from the superclass, is that it?

                – Sheljohn
                Jan 6 '13 at 17:16











              • @Sh3ljohn Comment 1: Of course you're right, I'll edit and fix. Comment 2: Yes, "not inherited" as in "not in the public interface of derived objects", unlike other public class members (methods and fields).

                – Kos
                Jan 6 '13 at 17:30














              31












              31








              31







              Terminology, terminology...



              OK, what do we mean by "Foo is inherited"? We mean that if objects of class A have Foo in its interface, then objects of class B which is a subclass of A also have Foo in its interface.





              • Constructors aren't a part of objects' interface. They belong directly to classes. Classes A and B may provide completely different sets of constructors. No "being inherited" here.



                (Implementation detail: each B's constructors calls some A's constructor.)




              • Destructors indeed are a part of each object's interface, since the object's user is responsible for calling them (i.e. directly with delete or indirectly by letting an object out of scope). Each object has exactly one destructor: its own destructor, which might optionally be a virtual one. It is always its own, and it's not inherited.



                (Implementation detail: B's destructor calls A's destructor.)




              So: there's a connection between base and derived constructors and destructors, but it's not like "they're inherited".



              I hope this answers what you have in mind.






              share|improve this answer















              Terminology, terminology...



              OK, what do we mean by "Foo is inherited"? We mean that if objects of class A have Foo in its interface, then objects of class B which is a subclass of A also have Foo in its interface.





              • Constructors aren't a part of objects' interface. They belong directly to classes. Classes A and B may provide completely different sets of constructors. No "being inherited" here.



                (Implementation detail: each B's constructors calls some A's constructor.)




              • Destructors indeed are a part of each object's interface, since the object's user is responsible for calling them (i.e. directly with delete or indirectly by letting an object out of scope). Each object has exactly one destructor: its own destructor, which might optionally be a virtual one. It is always its own, and it's not inherited.



                (Implementation detail: B's destructor calls A's destructor.)




              So: there's a connection between base and derived constructors and destructors, but it's not like "they're inherited".



              I hope this answers what you have in mind.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Jan 6 '13 at 18:36









              Matthieu M.

              207k29285525




              207k29285525










              answered Jan 6 '13 at 17:07









              KosKos

              50.7k19124201




              50.7k19124201













              • Comment 1: I just don't understand your first sentence, wouldn't it be "then objects of class B which is a subclass of A also have Foo in their interface"?

                – Sheljohn
                Jan 6 '13 at 17:15











              • Comment 2: So, as with the two comments of Oli Charlesworth and Pete Becker, it seems to be a matter of terminology. It's not inherited, but it calls automatically something from the superclass, is that it?

                – Sheljohn
                Jan 6 '13 at 17:16











              • @Sh3ljohn Comment 1: Of course you're right, I'll edit and fix. Comment 2: Yes, "not inherited" as in "not in the public interface of derived objects", unlike other public class members (methods and fields).

                – Kos
                Jan 6 '13 at 17:30



















              • Comment 1: I just don't understand your first sentence, wouldn't it be "then objects of class B which is a subclass of A also have Foo in their interface"?

                – Sheljohn
                Jan 6 '13 at 17:15











              • Comment 2: So, as with the two comments of Oli Charlesworth and Pete Becker, it seems to be a matter of terminology. It's not inherited, but it calls automatically something from the superclass, is that it?

                – Sheljohn
                Jan 6 '13 at 17:16











              • @Sh3ljohn Comment 1: Of course you're right, I'll edit and fix. Comment 2: Yes, "not inherited" as in "not in the public interface of derived objects", unlike other public class members (methods and fields).

                – Kos
                Jan 6 '13 at 17:30

















              Comment 1: I just don't understand your first sentence, wouldn't it be "then objects of class B which is a subclass of A also have Foo in their interface"?

              – Sheljohn
              Jan 6 '13 at 17:15





              Comment 1: I just don't understand your first sentence, wouldn't it be "then objects of class B which is a subclass of A also have Foo in their interface"?

              – Sheljohn
              Jan 6 '13 at 17:15













              Comment 2: So, as with the two comments of Oli Charlesworth and Pete Becker, it seems to be a matter of terminology. It's not inherited, but it calls automatically something from the superclass, is that it?

              – Sheljohn
              Jan 6 '13 at 17:16





              Comment 2: So, as with the two comments of Oli Charlesworth and Pete Becker, it seems to be a matter of terminology. It's not inherited, but it calls automatically something from the superclass, is that it?

              – Sheljohn
              Jan 6 '13 at 17:16













              @Sh3ljohn Comment 1: Of course you're right, I'll edit and fix. Comment 2: Yes, "not inherited" as in "not in the public interface of derived objects", unlike other public class members (methods and fields).

              – Kos
              Jan 6 '13 at 17:30





              @Sh3ljohn Comment 1: Of course you're right, I'll edit and fix. Comment 2: Yes, "not inherited" as in "not in the public interface of derived objects", unlike other public class members (methods and fields).

              – Kos
              Jan 6 '13 at 17:30













              7















              Q1: What I also know from practice, is that you cannot initialize a derived object with the same prototype than it's parent constructor without explicitly defining a constructor for the derived class, is that correct?




              Other than the trivial case where you've defined a default constructor in the superclass, yes you are correct.






              Q2: Can anybody who thinks it's not inherited please explain that?




              This may be a matter of definitions of terminology. Whilst it's clear that virtual destructors exist and work "as expected", we see in the C++ standard ([class.virtual]):




              Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual




              (emphasis mine)






              Q3: So what happens when you call the constructor of a subclass with inputs? Is the "empty constructor" of the superclass called as well?




              If you don't explicitly invoke a specific superclass constructor, then the default superclass constructor will be called (assuming it's visible).






              share|improve this answer


























              • Thank you :) So for Q2, what does it mean exactly? From what I understand of the quote; destructors are not inherited, which means deleting B should not decrement the counter.

                – Sheljohn
                Jan 6 '13 at 16:59













              • @Sh3ljohn: What, specifically, are you asking whether "it's not supposed to be like that"?

                – Oliver Charlesworth
                Jan 6 '13 at 17:01











              • Sorry I was editing my comment when you posted your answer, this should be clearer.

                – Sheljohn
                Jan 6 '13 at 17:04








              • 1





                @Sh3ljohn: The superclass destructor are implicitly called by the subclass destructor, whether it's explicitly defined or not.

                – Oliver Charlesworth
                Jan 6 '13 at 17:09






              • 1





                @Sh3ljohn: The term 'inherited' has a very specific meaning within the C++ standard that differs slightly from the common usage of the term. This is the main area where that difference manifests itself. What the C++ standard is essentially stating is that the destructor of a base class is not part of a derived class (it is not inherited in that sense). But the virtual-call mechanism is still required to work if destructors are involved (so in that sense, destructors are 'inherited')

                – Bart van Ingen Schenau
                Jan 6 '13 at 17:11
















              7















              Q1: What I also know from practice, is that you cannot initialize a derived object with the same prototype than it's parent constructor without explicitly defining a constructor for the derived class, is that correct?




              Other than the trivial case where you've defined a default constructor in the superclass, yes you are correct.






              Q2: Can anybody who thinks it's not inherited please explain that?




              This may be a matter of definitions of terminology. Whilst it's clear that virtual destructors exist and work "as expected", we see in the C++ standard ([class.virtual]):




              Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual




              (emphasis mine)






              Q3: So what happens when you call the constructor of a subclass with inputs? Is the "empty constructor" of the superclass called as well?




              If you don't explicitly invoke a specific superclass constructor, then the default superclass constructor will be called (assuming it's visible).






              share|improve this answer


























              • Thank you :) So for Q2, what does it mean exactly? From what I understand of the quote; destructors are not inherited, which means deleting B should not decrement the counter.

                – Sheljohn
                Jan 6 '13 at 16:59













              • @Sh3ljohn: What, specifically, are you asking whether "it's not supposed to be like that"?

                – Oliver Charlesworth
                Jan 6 '13 at 17:01











              • Sorry I was editing my comment when you posted your answer, this should be clearer.

                – Sheljohn
                Jan 6 '13 at 17:04








              • 1





                @Sh3ljohn: The superclass destructor are implicitly called by the subclass destructor, whether it's explicitly defined or not.

                – Oliver Charlesworth
                Jan 6 '13 at 17:09






              • 1





                @Sh3ljohn: The term 'inherited' has a very specific meaning within the C++ standard that differs slightly from the common usage of the term. This is the main area where that difference manifests itself. What the C++ standard is essentially stating is that the destructor of a base class is not part of a derived class (it is not inherited in that sense). But the virtual-call mechanism is still required to work if destructors are involved (so in that sense, destructors are 'inherited')

                – Bart van Ingen Schenau
                Jan 6 '13 at 17:11














              7












              7








              7








              Q1: What I also know from practice, is that you cannot initialize a derived object with the same prototype than it's parent constructor without explicitly defining a constructor for the derived class, is that correct?




              Other than the trivial case where you've defined a default constructor in the superclass, yes you are correct.






              Q2: Can anybody who thinks it's not inherited please explain that?




              This may be a matter of definitions of terminology. Whilst it's clear that virtual destructors exist and work "as expected", we see in the C++ standard ([class.virtual]):




              Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual




              (emphasis mine)






              Q3: So what happens when you call the constructor of a subclass with inputs? Is the "empty constructor" of the superclass called as well?




              If you don't explicitly invoke a specific superclass constructor, then the default superclass constructor will be called (assuming it's visible).






              share|improve this answer
















              Q1: What I also know from practice, is that you cannot initialize a derived object with the same prototype than it's parent constructor without explicitly defining a constructor for the derived class, is that correct?




              Other than the trivial case where you've defined a default constructor in the superclass, yes you are correct.






              Q2: Can anybody who thinks it's not inherited please explain that?




              This may be a matter of definitions of terminology. Whilst it's clear that virtual destructors exist and work "as expected", we see in the C++ standard ([class.virtual]):




              Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual




              (emphasis mine)






              Q3: So what happens when you call the constructor of a subclass with inputs? Is the "empty constructor" of the superclass called as well?




              If you don't explicitly invoke a specific superclass constructor, then the default superclass constructor will be called (assuming it's visible).







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Jan 6 '13 at 16:58

























              answered Jan 6 '13 at 16:53









              Oliver CharlesworthOliver Charlesworth

              230k25469599




              230k25469599













              • Thank you :) So for Q2, what does it mean exactly? From what I understand of the quote; destructors are not inherited, which means deleting B should not decrement the counter.

                – Sheljohn
                Jan 6 '13 at 16:59













              • @Sh3ljohn: What, specifically, are you asking whether "it's not supposed to be like that"?

                – Oliver Charlesworth
                Jan 6 '13 at 17:01











              • Sorry I was editing my comment when you posted your answer, this should be clearer.

                – Sheljohn
                Jan 6 '13 at 17:04








              • 1





                @Sh3ljohn: The superclass destructor are implicitly called by the subclass destructor, whether it's explicitly defined or not.

                – Oliver Charlesworth
                Jan 6 '13 at 17:09






              • 1





                @Sh3ljohn: The term 'inherited' has a very specific meaning within the C++ standard that differs slightly from the common usage of the term. This is the main area where that difference manifests itself. What the C++ standard is essentially stating is that the destructor of a base class is not part of a derived class (it is not inherited in that sense). But the virtual-call mechanism is still required to work if destructors are involved (so in that sense, destructors are 'inherited')

                – Bart van Ingen Schenau
                Jan 6 '13 at 17:11



















              • Thank you :) So for Q2, what does it mean exactly? From what I understand of the quote; destructors are not inherited, which means deleting B should not decrement the counter.

                – Sheljohn
                Jan 6 '13 at 16:59













              • @Sh3ljohn: What, specifically, are you asking whether "it's not supposed to be like that"?

                – Oliver Charlesworth
                Jan 6 '13 at 17:01











              • Sorry I was editing my comment when you posted your answer, this should be clearer.

                – Sheljohn
                Jan 6 '13 at 17:04








              • 1





                @Sh3ljohn: The superclass destructor are implicitly called by the subclass destructor, whether it's explicitly defined or not.

                – Oliver Charlesworth
                Jan 6 '13 at 17:09






              • 1





                @Sh3ljohn: The term 'inherited' has a very specific meaning within the C++ standard that differs slightly from the common usage of the term. This is the main area where that difference manifests itself. What the C++ standard is essentially stating is that the destructor of a base class is not part of a derived class (it is not inherited in that sense). But the virtual-call mechanism is still required to work if destructors are involved (so in that sense, destructors are 'inherited')

                – Bart van Ingen Schenau
                Jan 6 '13 at 17:11

















              Thank you :) So for Q2, what does it mean exactly? From what I understand of the quote; destructors are not inherited, which means deleting B should not decrement the counter.

              – Sheljohn
              Jan 6 '13 at 16:59







              Thank you :) So for Q2, what does it mean exactly? From what I understand of the quote; destructors are not inherited, which means deleting B should not decrement the counter.

              – Sheljohn
              Jan 6 '13 at 16:59















              @Sh3ljohn: What, specifically, are you asking whether "it's not supposed to be like that"?

              – Oliver Charlesworth
              Jan 6 '13 at 17:01





              @Sh3ljohn: What, specifically, are you asking whether "it's not supposed to be like that"?

              – Oliver Charlesworth
              Jan 6 '13 at 17:01













              Sorry I was editing my comment when you posted your answer, this should be clearer.

              – Sheljohn
              Jan 6 '13 at 17:04







              Sorry I was editing my comment when you posted your answer, this should be clearer.

              – Sheljohn
              Jan 6 '13 at 17:04






              1




              1





              @Sh3ljohn: The superclass destructor are implicitly called by the subclass destructor, whether it's explicitly defined or not.

              – Oliver Charlesworth
              Jan 6 '13 at 17:09





              @Sh3ljohn: The superclass destructor are implicitly called by the subclass destructor, whether it's explicitly defined or not.

              – Oliver Charlesworth
              Jan 6 '13 at 17:09




              1




              1





              @Sh3ljohn: The term 'inherited' has a very specific meaning within the C++ standard that differs slightly from the common usage of the term. This is the main area where that difference manifests itself. What the C++ standard is essentially stating is that the destructor of a base class is not part of a derived class (it is not inherited in that sense). But the virtual-call mechanism is still required to work if destructors are involved (so in that sense, destructors are 'inherited')

              – Bart van Ingen Schenau
              Jan 6 '13 at 17:11





              @Sh3ljohn: The term 'inherited' has a very specific meaning within the C++ standard that differs slightly from the common usage of the term. This is the main area where that difference manifests itself. What the C++ standard is essentially stating is that the destructor of a base class is not part of a derived class (it is not inherited in that sense). But the virtual-call mechanism is still required to work if destructors are involved (so in that sense, destructors are 'inherited')

              – Bart van Ingen Schenau
              Jan 6 '13 at 17:11











              4














              Destructors are not inherited. If a class doesn't define one, the compiler generates one. For trivial cases that destructor just calls the base class' destructor, and often that means that there is no explicit code for its destructor (which imitates inheritance). But if a class has members with destructors, the generated destructor calls destructors for those members before calling the base class' destructor. That's something that an inherited function would not do.






              share|improve this answer
























              • So it's all about the word "inheritance" right? Because C's destructor still calls A's destructor in the example.

                – Sheljohn
                Jan 6 '13 at 17:12






              • 1





                if C::f() calls A::f(), it is not the case that C inherits A::f.

                – Pete Becker
                Jan 6 '13 at 17:14











              • Hmm. So why does an example in the Standard use, and g++ allows, d.B::~B();?

                – aschepler
                Jan 6 '13 at 21:33











              • @aschepler - inheritance is about interfaces: if you don't write it in the derived class but it's available from the base, it's inherited.

                – Pete Becker
                Jan 7 '13 at 12:43
















              4














              Destructors are not inherited. If a class doesn't define one, the compiler generates one. For trivial cases that destructor just calls the base class' destructor, and often that means that there is no explicit code for its destructor (which imitates inheritance). But if a class has members with destructors, the generated destructor calls destructors for those members before calling the base class' destructor. That's something that an inherited function would not do.






              share|improve this answer
























              • So it's all about the word "inheritance" right? Because C's destructor still calls A's destructor in the example.

                – Sheljohn
                Jan 6 '13 at 17:12






              • 1





                if C::f() calls A::f(), it is not the case that C inherits A::f.

                – Pete Becker
                Jan 6 '13 at 17:14











              • Hmm. So why does an example in the Standard use, and g++ allows, d.B::~B();?

                – aschepler
                Jan 6 '13 at 21:33











              • @aschepler - inheritance is about interfaces: if you don't write it in the derived class but it's available from the base, it's inherited.

                – Pete Becker
                Jan 7 '13 at 12:43














              4












              4








              4







              Destructors are not inherited. If a class doesn't define one, the compiler generates one. For trivial cases that destructor just calls the base class' destructor, and often that means that there is no explicit code for its destructor (which imitates inheritance). But if a class has members with destructors, the generated destructor calls destructors for those members before calling the base class' destructor. That's something that an inherited function would not do.






              share|improve this answer













              Destructors are not inherited. If a class doesn't define one, the compiler generates one. For trivial cases that destructor just calls the base class' destructor, and often that means that there is no explicit code for its destructor (which imitates inheritance). But if a class has members with destructors, the generated destructor calls destructors for those members before calling the base class' destructor. That's something that an inherited function would not do.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Jan 6 '13 at 17:11









              Pete BeckerPete Becker

              59k442122




              59k442122













              • So it's all about the word "inheritance" right? Because C's destructor still calls A's destructor in the example.

                – Sheljohn
                Jan 6 '13 at 17:12






              • 1





                if C::f() calls A::f(), it is not the case that C inherits A::f.

                – Pete Becker
                Jan 6 '13 at 17:14











              • Hmm. So why does an example in the Standard use, and g++ allows, d.B::~B();?

                – aschepler
                Jan 6 '13 at 21:33











              • @aschepler - inheritance is about interfaces: if you don't write it in the derived class but it's available from the base, it's inherited.

                – Pete Becker
                Jan 7 '13 at 12:43



















              • So it's all about the word "inheritance" right? Because C's destructor still calls A's destructor in the example.

                – Sheljohn
                Jan 6 '13 at 17:12






              • 1





                if C::f() calls A::f(), it is not the case that C inherits A::f.

                – Pete Becker
                Jan 6 '13 at 17:14











              • Hmm. So why does an example in the Standard use, and g++ allows, d.B::~B();?

                – aschepler
                Jan 6 '13 at 21:33











              • @aschepler - inheritance is about interfaces: if you don't write it in the derived class but it's available from the base, it's inherited.

                – Pete Becker
                Jan 7 '13 at 12:43

















              So it's all about the word "inheritance" right? Because C's destructor still calls A's destructor in the example.

              – Sheljohn
              Jan 6 '13 at 17:12





              So it's all about the word "inheritance" right? Because C's destructor still calls A's destructor in the example.

              – Sheljohn
              Jan 6 '13 at 17:12




              1




              1





              if C::f() calls A::f(), it is not the case that C inherits A::f.

              – Pete Becker
              Jan 6 '13 at 17:14





              if C::f() calls A::f(), it is not the case that C inherits A::f.

              – Pete Becker
              Jan 6 '13 at 17:14













              Hmm. So why does an example in the Standard use, and g++ allows, d.B::~B();?

              – aschepler
              Jan 6 '13 at 21:33





              Hmm. So why does an example in the Standard use, and g++ allows, d.B::~B();?

              – aschepler
              Jan 6 '13 at 21:33













              @aschepler - inheritance is about interfaces: if you don't write it in the derived class but it's available from the base, it's inherited.

              – Pete Becker
              Jan 7 '13 at 12:43





              @aschepler - inheritance is about interfaces: if you don't write it in the derived class but it's available from the base, it's inherited.

              – Pete Becker
              Jan 7 '13 at 12:43











              3














              Inheritance is what : mechanism of reusing and extending existing classes without modifying them, thus producing hierarchical relationships between them.



              Inheritance is almost like embedding an object into a class.



              when class is inheriting a base class then the base class's constructor is called first then derived class's ,and the destructor's call is in reverse order.



              So Why Base Class Constructor is called (called not inherited may be with parameters/default) : to guarantees that the base class is properly constructed when the constructor for the derived class is executed.



              Now Calling of Destructor (calling not inherit) : when base object get out of scope then the destructor is called on its own.so there is np issue of inheritance of destructor.



              now your questions:



              ans 1 - yes you are correct for first question.
              ans 2 - so destructor is called not inherited after the scope of object goes out.

              & ans 3 - if in derived class you are giving the call with parameters then only that constructor would get called , with it no other constructor would get called.


              there is no point of issuse that 2 constructor of same object would get called on object creation,as
              constructor called at the creation of an object. It prepares the new object for use.so there is no logic of preparing the object twice with different constructors.






              share|improve this answer






























                3














                Inheritance is what : mechanism of reusing and extending existing classes without modifying them, thus producing hierarchical relationships between them.



                Inheritance is almost like embedding an object into a class.



                when class is inheriting a base class then the base class's constructor is called first then derived class's ,and the destructor's call is in reverse order.



                So Why Base Class Constructor is called (called not inherited may be with parameters/default) : to guarantees that the base class is properly constructed when the constructor for the derived class is executed.



                Now Calling of Destructor (calling not inherit) : when base object get out of scope then the destructor is called on its own.so there is np issue of inheritance of destructor.



                now your questions:



                ans 1 - yes you are correct for first question.
                ans 2 - so destructor is called not inherited after the scope of object goes out.

                & ans 3 - if in derived class you are giving the call with parameters then only that constructor would get called , with it no other constructor would get called.


                there is no point of issuse that 2 constructor of same object would get called on object creation,as
                constructor called at the creation of an object. It prepares the new object for use.so there is no logic of preparing the object twice with different constructors.






                share|improve this answer




























                  3












                  3








                  3







                  Inheritance is what : mechanism of reusing and extending existing classes without modifying them, thus producing hierarchical relationships between them.



                  Inheritance is almost like embedding an object into a class.



                  when class is inheriting a base class then the base class's constructor is called first then derived class's ,and the destructor's call is in reverse order.



                  So Why Base Class Constructor is called (called not inherited may be with parameters/default) : to guarantees that the base class is properly constructed when the constructor for the derived class is executed.



                  Now Calling of Destructor (calling not inherit) : when base object get out of scope then the destructor is called on its own.so there is np issue of inheritance of destructor.



                  now your questions:



                  ans 1 - yes you are correct for first question.
                  ans 2 - so destructor is called not inherited after the scope of object goes out.

                  & ans 3 - if in derived class you are giving the call with parameters then only that constructor would get called , with it no other constructor would get called.


                  there is no point of issuse that 2 constructor of same object would get called on object creation,as
                  constructor called at the creation of an object. It prepares the new object for use.so there is no logic of preparing the object twice with different constructors.






                  share|improve this answer















                  Inheritance is what : mechanism of reusing and extending existing classes without modifying them, thus producing hierarchical relationships between them.



                  Inheritance is almost like embedding an object into a class.



                  when class is inheriting a base class then the base class's constructor is called first then derived class's ,and the destructor's call is in reverse order.



                  So Why Base Class Constructor is called (called not inherited may be with parameters/default) : to guarantees that the base class is properly constructed when the constructor for the derived class is executed.



                  Now Calling of Destructor (calling not inherit) : when base object get out of scope then the destructor is called on its own.so there is np issue of inheritance of destructor.



                  now your questions:



                  ans 1 - yes you are correct for first question.
                  ans 2 - so destructor is called not inherited after the scope of object goes out.

                  & ans 3 - if in derived class you are giving the call with parameters then only that constructor would get called , with it no other constructor would get called.


                  there is no point of issuse that 2 constructor of same object would get called on object creation,as
                  constructor called at the creation of an object. It prepares the new object for use.so there is no logic of preparing the object twice with different constructors.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Jan 6 '13 at 17:27

























                  answered Jan 6 '13 at 17:18









                  sourcecodesourcecode

                  1,55721117




                  1,55721117























                      3














                      Technically, destructors ARE inherited. But in normal circumstances, the inherited destructors are not directly used for a derived class; they're invoked because the derived class's own destructor calls them in order to destroy its own "base class subobjects" as a step within destroying the larger object. And in the unusual circumstances where you do directly use a base class destructor on a derived object, it's very difficult to avoid Undefined Behavior.



                      This example comes straight from the C++ Standard (12.4p12).



                      struct B {
                      virtual ~B() { }
                      };
                      struct D : B {
                      ~D() { }
                      };

                      D D_object;
                      typedef B B_alias;
                      B* B_ptr = &D_object;

                      void f() {
                      D_object.B::~B(); // calls B's destructor
                      B_ptr->~B(); // calls D's destructor
                      B_ptr->~B_alias(); // calls D's destructor
                      B_ptr->B_alias::~B(); // calls B's destructor
                      B_ptr->B_alias::~B_alias(); // calls B's destructor
                      }


                      If ~B were not an inherited member of D, the first statement in f would be ill-formed. As it is, it's legal C++, though extremely dangerous.






                      share|improve this answer
























                      • What if you made ~B() non-virtual? Would any of the above examples fail?

                        – Sheljohn
                        Jan 6 '13 at 21:41











                      • I think they would all be well-formed, but all do the same thing (call B's destructor, not D's).

                        – aschepler
                        Jan 6 '13 at 21:42
















                      3














                      Technically, destructors ARE inherited. But in normal circumstances, the inherited destructors are not directly used for a derived class; they're invoked because the derived class's own destructor calls them in order to destroy its own "base class subobjects" as a step within destroying the larger object. And in the unusual circumstances where you do directly use a base class destructor on a derived object, it's very difficult to avoid Undefined Behavior.



                      This example comes straight from the C++ Standard (12.4p12).



                      struct B {
                      virtual ~B() { }
                      };
                      struct D : B {
                      ~D() { }
                      };

                      D D_object;
                      typedef B B_alias;
                      B* B_ptr = &D_object;

                      void f() {
                      D_object.B::~B(); // calls B's destructor
                      B_ptr->~B(); // calls D's destructor
                      B_ptr->~B_alias(); // calls D's destructor
                      B_ptr->B_alias::~B(); // calls B's destructor
                      B_ptr->B_alias::~B_alias(); // calls B's destructor
                      }


                      If ~B were not an inherited member of D, the first statement in f would be ill-formed. As it is, it's legal C++, though extremely dangerous.






                      share|improve this answer
























                      • What if you made ~B() non-virtual? Would any of the above examples fail?

                        – Sheljohn
                        Jan 6 '13 at 21:41











                      • I think they would all be well-formed, but all do the same thing (call B's destructor, not D's).

                        – aschepler
                        Jan 6 '13 at 21:42














                      3












                      3








                      3







                      Technically, destructors ARE inherited. But in normal circumstances, the inherited destructors are not directly used for a derived class; they're invoked because the derived class's own destructor calls them in order to destroy its own "base class subobjects" as a step within destroying the larger object. And in the unusual circumstances where you do directly use a base class destructor on a derived object, it's very difficult to avoid Undefined Behavior.



                      This example comes straight from the C++ Standard (12.4p12).



                      struct B {
                      virtual ~B() { }
                      };
                      struct D : B {
                      ~D() { }
                      };

                      D D_object;
                      typedef B B_alias;
                      B* B_ptr = &D_object;

                      void f() {
                      D_object.B::~B(); // calls B's destructor
                      B_ptr->~B(); // calls D's destructor
                      B_ptr->~B_alias(); // calls D's destructor
                      B_ptr->B_alias::~B(); // calls B's destructor
                      B_ptr->B_alias::~B_alias(); // calls B's destructor
                      }


                      If ~B were not an inherited member of D, the first statement in f would be ill-formed. As it is, it's legal C++, though extremely dangerous.






                      share|improve this answer













                      Technically, destructors ARE inherited. But in normal circumstances, the inherited destructors are not directly used for a derived class; they're invoked because the derived class's own destructor calls them in order to destroy its own "base class subobjects" as a step within destroying the larger object. And in the unusual circumstances where you do directly use a base class destructor on a derived object, it's very difficult to avoid Undefined Behavior.



                      This example comes straight from the C++ Standard (12.4p12).



                      struct B {
                      virtual ~B() { }
                      };
                      struct D : B {
                      ~D() { }
                      };

                      D D_object;
                      typedef B B_alias;
                      B* B_ptr = &D_object;

                      void f() {
                      D_object.B::~B(); // calls B's destructor
                      B_ptr->~B(); // calls D's destructor
                      B_ptr->~B_alias(); // calls D's destructor
                      B_ptr->B_alias::~B(); // calls B's destructor
                      B_ptr->B_alias::~B_alias(); // calls B's destructor
                      }


                      If ~B were not an inherited member of D, the first statement in f would be ill-formed. As it is, it's legal C++, though extremely dangerous.







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Jan 6 '13 at 21:21









                      aschepleraschepler

                      53.7k580131




                      53.7k580131













                      • What if you made ~B() non-virtual? Would any of the above examples fail?

                        – Sheljohn
                        Jan 6 '13 at 21:41











                      • I think they would all be well-formed, but all do the same thing (call B's destructor, not D's).

                        – aschepler
                        Jan 6 '13 at 21:42



















                      • What if you made ~B() non-virtual? Would any of the above examples fail?

                        – Sheljohn
                        Jan 6 '13 at 21:41











                      • I think they would all be well-formed, but all do the same thing (call B's destructor, not D's).

                        – aschepler
                        Jan 6 '13 at 21:42

















                      What if you made ~B() non-virtual? Would any of the above examples fail?

                      – Sheljohn
                      Jan 6 '13 at 21:41





                      What if you made ~B() non-virtual? Would any of the above examples fail?

                      – Sheljohn
                      Jan 6 '13 at 21:41













                      I think they would all be well-formed, but all do the same thing (call B's destructor, not D's).

                      – aschepler
                      Jan 6 '13 at 21:42





                      I think they would all be well-formed, but all do the same thing (call B's destructor, not D's).

                      – aschepler
                      Jan 6 '13 at 21:42











                      1














                      In your example, you're explicitly calling the destructor functions. This is legal (obviously, since it compiled and ran) but almost always incorrect.



                      For dynamically-allocated objects created with new, the destructor will be run when the objected is removed with delete.



                      For statically-allocated objects, which are created simply by declaring the object within the scope of a function, the destructor is run when the object's scope disappears. That is, when main() exits, the objects' destructors will be run. But you've already run the destructors for those objects by calling them manually! This is why your example's output shows the count decreasing to -3... you've run the destructors for a, b, and c twice.



                      Here's the same code, annotated to show when destructors will be automatically run:



                      int main()
                      {
                      printf("Create An"); A a;
                      printf("Delete An"); a.~A();

                      printf("Create Bn"); B b;
                      printf("Delete Bn"); b.~B();

                      printf("Create new B stored as A*n"); A *a_ptr = new B();
                      printf("Delete previous pointern");
                      delete a_ptr; // Implicitly calls destructor for a_ptr. a_ptr is class B,
                      // so it would call a_ptr->~B() if it existed. Because B is an A, after
                      // its destructor is called, it calls the superclass's destructor,
                      // a_ptr->~A().

                      printf("Create Cn"); C c;
                      printf("Delete Cn"); c.~C();
                      }
                      // Function exits here at the close brace, so anything declared in its scope is
                      // deallocated from the stack and their destructors run.
                      // First `c` is destroyed, which calls c.~C(), then because C is a subclass of A
                      // calls c.~B() (which doesn't exist, so a blank implementation is used), then
                      // because B is a subclass of A calls c.~A(). This decrements the counter, but
                      // the count is wrong because you already manually called c.~C(), which you
                      // ordinarily shouldn't have done.
                      // Then `b` is destroyed, in a similar manner. Now the count is off by 2,
                      // because you had already called b.~B().
                      // Lastly `a` is destroyed, just as above. And again, because you had already
                      // called a.~A(), the count is now off by 3.





                      share|improve this answer
























                      • I disagree, IMO the destructor of a class should be implemented such that it handles potentially multiple calls (typically, test a member pointer before deleting it). In my case I don't really care if the integer gets negative, and I don't care about the prints either (see comment "we exit main now"). You should delete your post because it doesn't provide an answer to the OP (which already has one btw), if you leave it up people are probably going to downvote...

                        – Sheljohn
                        Mar 29 '14 at 4:18











                      • Unless you know your particular C++ implmentation supports it, calling destructors multiple times isn't safe. "Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended" (C++ standard §12.4.14)

                        – BigPeteB
                        Mar 31 '14 at 18:10











                      • Actually you are right :) I still think it's usually a small effort to make sure the behavior is defined in that case.. You should put this in comment though, this really has nothing to do with the question :)

                        – Sheljohn
                        Mar 31 '14 at 19:36
















                      1














                      In your example, you're explicitly calling the destructor functions. This is legal (obviously, since it compiled and ran) but almost always incorrect.



                      For dynamically-allocated objects created with new, the destructor will be run when the objected is removed with delete.



                      For statically-allocated objects, which are created simply by declaring the object within the scope of a function, the destructor is run when the object's scope disappears. That is, when main() exits, the objects' destructors will be run. But you've already run the destructors for those objects by calling them manually! This is why your example's output shows the count decreasing to -3... you've run the destructors for a, b, and c twice.



                      Here's the same code, annotated to show when destructors will be automatically run:



                      int main()
                      {
                      printf("Create An"); A a;
                      printf("Delete An"); a.~A();

                      printf("Create Bn"); B b;
                      printf("Delete Bn"); b.~B();

                      printf("Create new B stored as A*n"); A *a_ptr = new B();
                      printf("Delete previous pointern");
                      delete a_ptr; // Implicitly calls destructor for a_ptr. a_ptr is class B,
                      // so it would call a_ptr->~B() if it existed. Because B is an A, after
                      // its destructor is called, it calls the superclass's destructor,
                      // a_ptr->~A().

                      printf("Create Cn"); C c;
                      printf("Delete Cn"); c.~C();
                      }
                      // Function exits here at the close brace, so anything declared in its scope is
                      // deallocated from the stack and their destructors run.
                      // First `c` is destroyed, which calls c.~C(), then because C is a subclass of A
                      // calls c.~B() (which doesn't exist, so a blank implementation is used), then
                      // because B is a subclass of A calls c.~A(). This decrements the counter, but
                      // the count is wrong because you already manually called c.~C(), which you
                      // ordinarily shouldn't have done.
                      // Then `b` is destroyed, in a similar manner. Now the count is off by 2,
                      // because you had already called b.~B().
                      // Lastly `a` is destroyed, just as above. And again, because you had already
                      // called a.~A(), the count is now off by 3.





                      share|improve this answer
























                      • I disagree, IMO the destructor of a class should be implemented such that it handles potentially multiple calls (typically, test a member pointer before deleting it). In my case I don't really care if the integer gets negative, and I don't care about the prints either (see comment "we exit main now"). You should delete your post because it doesn't provide an answer to the OP (which already has one btw), if you leave it up people are probably going to downvote...

                        – Sheljohn
                        Mar 29 '14 at 4:18











                      • Unless you know your particular C++ implmentation supports it, calling destructors multiple times isn't safe. "Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended" (C++ standard §12.4.14)

                        – BigPeteB
                        Mar 31 '14 at 18:10











                      • Actually you are right :) I still think it's usually a small effort to make sure the behavior is defined in that case.. You should put this in comment though, this really has nothing to do with the question :)

                        – Sheljohn
                        Mar 31 '14 at 19:36














                      1












                      1








                      1







                      In your example, you're explicitly calling the destructor functions. This is legal (obviously, since it compiled and ran) but almost always incorrect.



                      For dynamically-allocated objects created with new, the destructor will be run when the objected is removed with delete.



                      For statically-allocated objects, which are created simply by declaring the object within the scope of a function, the destructor is run when the object's scope disappears. That is, when main() exits, the objects' destructors will be run. But you've already run the destructors for those objects by calling them manually! This is why your example's output shows the count decreasing to -3... you've run the destructors for a, b, and c twice.



                      Here's the same code, annotated to show when destructors will be automatically run:



                      int main()
                      {
                      printf("Create An"); A a;
                      printf("Delete An"); a.~A();

                      printf("Create Bn"); B b;
                      printf("Delete Bn"); b.~B();

                      printf("Create new B stored as A*n"); A *a_ptr = new B();
                      printf("Delete previous pointern");
                      delete a_ptr; // Implicitly calls destructor for a_ptr. a_ptr is class B,
                      // so it would call a_ptr->~B() if it existed. Because B is an A, after
                      // its destructor is called, it calls the superclass's destructor,
                      // a_ptr->~A().

                      printf("Create Cn"); C c;
                      printf("Delete Cn"); c.~C();
                      }
                      // Function exits here at the close brace, so anything declared in its scope is
                      // deallocated from the stack and their destructors run.
                      // First `c` is destroyed, which calls c.~C(), then because C is a subclass of A
                      // calls c.~B() (which doesn't exist, so a blank implementation is used), then
                      // because B is a subclass of A calls c.~A(). This decrements the counter, but
                      // the count is wrong because you already manually called c.~C(), which you
                      // ordinarily shouldn't have done.
                      // Then `b` is destroyed, in a similar manner. Now the count is off by 2,
                      // because you had already called b.~B().
                      // Lastly `a` is destroyed, just as above. And again, because you had already
                      // called a.~A(), the count is now off by 3.





                      share|improve this answer













                      In your example, you're explicitly calling the destructor functions. This is legal (obviously, since it compiled and ran) but almost always incorrect.



                      For dynamically-allocated objects created with new, the destructor will be run when the objected is removed with delete.



                      For statically-allocated objects, which are created simply by declaring the object within the scope of a function, the destructor is run when the object's scope disappears. That is, when main() exits, the objects' destructors will be run. But you've already run the destructors for those objects by calling them manually! This is why your example's output shows the count decreasing to -3... you've run the destructors for a, b, and c twice.



                      Here's the same code, annotated to show when destructors will be automatically run:



                      int main()
                      {
                      printf("Create An"); A a;
                      printf("Delete An"); a.~A();

                      printf("Create Bn"); B b;
                      printf("Delete Bn"); b.~B();

                      printf("Create new B stored as A*n"); A *a_ptr = new B();
                      printf("Delete previous pointern");
                      delete a_ptr; // Implicitly calls destructor for a_ptr. a_ptr is class B,
                      // so it would call a_ptr->~B() if it existed. Because B is an A, after
                      // its destructor is called, it calls the superclass's destructor,
                      // a_ptr->~A().

                      printf("Create Cn"); C c;
                      printf("Delete Cn"); c.~C();
                      }
                      // Function exits here at the close brace, so anything declared in its scope is
                      // deallocated from the stack and their destructors run.
                      // First `c` is destroyed, which calls c.~C(), then because C is a subclass of A
                      // calls c.~B() (which doesn't exist, so a blank implementation is used), then
                      // because B is a subclass of A calls c.~A(). This decrements the counter, but
                      // the count is wrong because you already manually called c.~C(), which you
                      // ordinarily shouldn't have done.
                      // Then `b` is destroyed, in a similar manner. Now the count is off by 2,
                      // because you had already called b.~B().
                      // Lastly `a` is destroyed, just as above. And again, because you had already
                      // called a.~A(), the count is now off by 3.






                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Mar 28 '14 at 18:04









                      BigPeteBBigPeteB

                      212




                      212













                      • I disagree, IMO the destructor of a class should be implemented such that it handles potentially multiple calls (typically, test a member pointer before deleting it). In my case I don't really care if the integer gets negative, and I don't care about the prints either (see comment "we exit main now"). You should delete your post because it doesn't provide an answer to the OP (which already has one btw), if you leave it up people are probably going to downvote...

                        – Sheljohn
                        Mar 29 '14 at 4:18











                      • Unless you know your particular C++ implmentation supports it, calling destructors multiple times isn't safe. "Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended" (C++ standard §12.4.14)

                        – BigPeteB
                        Mar 31 '14 at 18:10











                      • Actually you are right :) I still think it's usually a small effort to make sure the behavior is defined in that case.. You should put this in comment though, this really has nothing to do with the question :)

                        – Sheljohn
                        Mar 31 '14 at 19:36



















                      • I disagree, IMO the destructor of a class should be implemented such that it handles potentially multiple calls (typically, test a member pointer before deleting it). In my case I don't really care if the integer gets negative, and I don't care about the prints either (see comment "we exit main now"). You should delete your post because it doesn't provide an answer to the OP (which already has one btw), if you leave it up people are probably going to downvote...

                        – Sheljohn
                        Mar 29 '14 at 4:18











                      • Unless you know your particular C++ implmentation supports it, calling destructors multiple times isn't safe. "Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended" (C++ standard §12.4.14)

                        – BigPeteB
                        Mar 31 '14 at 18:10











                      • Actually you are right :) I still think it's usually a small effort to make sure the behavior is defined in that case.. You should put this in comment though, this really has nothing to do with the question :)

                        – Sheljohn
                        Mar 31 '14 at 19:36

















                      I disagree, IMO the destructor of a class should be implemented such that it handles potentially multiple calls (typically, test a member pointer before deleting it). In my case I don't really care if the integer gets negative, and I don't care about the prints either (see comment "we exit main now"). You should delete your post because it doesn't provide an answer to the OP (which already has one btw), if you leave it up people are probably going to downvote...

                      – Sheljohn
                      Mar 29 '14 at 4:18





                      I disagree, IMO the destructor of a class should be implemented such that it handles potentially multiple calls (typically, test a member pointer before deleting it). In my case I don't really care if the integer gets negative, and I don't care about the prints either (see comment "we exit main now"). You should delete your post because it doesn't provide an answer to the OP (which already has one btw), if you leave it up people are probably going to downvote...

                      – Sheljohn
                      Mar 29 '14 at 4:18













                      Unless you know your particular C++ implmentation supports it, calling destructors multiple times isn't safe. "Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended" (C++ standard §12.4.14)

                      – BigPeteB
                      Mar 31 '14 at 18:10





                      Unless you know your particular C++ implmentation supports it, calling destructors multiple times isn't safe. "Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended" (C++ standard §12.4.14)

                      – BigPeteB
                      Mar 31 '14 at 18:10













                      Actually you are right :) I still think it's usually a small effort to make sure the behavior is defined in that case.. You should put this in comment though, this really has nothing to do with the question :)

                      – Sheljohn
                      Mar 31 '14 at 19:36





                      Actually you are right :) I still think it's usually a small effort to make sure the behavior is defined in that case.. You should put this in comment though, this really has nothing to do with the question :)

                      – Sheljohn
                      Mar 31 '14 at 19:36











                      0














                      I would want to express my thoughts. Creating any object is done in two stages:


                      1. Allocating area of memory for the object.





                      1. Initializing this area of memory.



                        The constructor of object is the function (method) of class (for this object), which initializes allocated area of memory and called automatically.
                        The inheritance is embedding the object of the one class to the object of other class. There are plays with poiners "this" "under lid". The "this" is pass on implicitly to the method of class.



                        What is happening when the code "B b" is done. Firstly the area of memory is allocated for object b. The class B has own default constructor B(), which is automatically called for initializing this memeory. B() is the function therefore the stack frame is created for working one. This constructor has address of b (implicity). But the object of A must be embedded to the object b. The object of A has no name. Constructor of B knows the noname embedded object of A must be created too (so the compiler C++ works). Therefore the constructor of class A for initializing noname embadded object of class A is called in the constructor of B. The new stack frame is called and noname object is being initialized. After that the stack frames are being closed and our object b of class B has been done. I think that address of b and the noname object coincide.



                        The destructor is the method of class too. When we call ~B() the b is not destroyed. The destructor is the function called avtomatically when the object is being destroyed. But it doesn't mean that when we call the destructor the object must be destroyed. If the destructor of B is called, the stack frame is created for one. The default desructor of B knows about the noname embedded object of class A (so the compiler C++ works). Therefore the destructore calls the destructor of A.








                      share|improve this answer






























                        0














                        I would want to express my thoughts. Creating any object is done in two stages:


                        1. Allocating area of memory for the object.





                        1. Initializing this area of memory.



                          The constructor of object is the function (method) of class (for this object), which initializes allocated area of memory and called automatically.
                          The inheritance is embedding the object of the one class to the object of other class. There are plays with poiners "this" "under lid". The "this" is pass on implicitly to the method of class.



                          What is happening when the code "B b" is done. Firstly the area of memory is allocated for object b. The class B has own default constructor B(), which is automatically called for initializing this memeory. B() is the function therefore the stack frame is created for working one. This constructor has address of b (implicity). But the object of A must be embedded to the object b. The object of A has no name. Constructor of B knows the noname embedded object of A must be created too (so the compiler C++ works). Therefore the constructor of class A for initializing noname embadded object of class A is called in the constructor of B. The new stack frame is called and noname object is being initialized. After that the stack frames are being closed and our object b of class B has been done. I think that address of b and the noname object coincide.



                          The destructor is the method of class too. When we call ~B() the b is not destroyed. The destructor is the function called avtomatically when the object is being destroyed. But it doesn't mean that when we call the destructor the object must be destroyed. If the destructor of B is called, the stack frame is created for one. The default desructor of B knows about the noname embedded object of class A (so the compiler C++ works). Therefore the destructore calls the destructor of A.








                        share|improve this answer




























                          0












                          0








                          0







                          I would want to express my thoughts. Creating any object is done in two stages:


                          1. Allocating area of memory for the object.





                          1. Initializing this area of memory.



                            The constructor of object is the function (method) of class (for this object), which initializes allocated area of memory and called automatically.
                            The inheritance is embedding the object of the one class to the object of other class. There are plays with poiners "this" "under lid". The "this" is pass on implicitly to the method of class.



                            What is happening when the code "B b" is done. Firstly the area of memory is allocated for object b. The class B has own default constructor B(), which is automatically called for initializing this memeory. B() is the function therefore the stack frame is created for working one. This constructor has address of b (implicity). But the object of A must be embedded to the object b. The object of A has no name. Constructor of B knows the noname embedded object of A must be created too (so the compiler C++ works). Therefore the constructor of class A for initializing noname embadded object of class A is called in the constructor of B. The new stack frame is called and noname object is being initialized. After that the stack frames are being closed and our object b of class B has been done. I think that address of b and the noname object coincide.



                            The destructor is the method of class too. When we call ~B() the b is not destroyed. The destructor is the function called avtomatically when the object is being destroyed. But it doesn't mean that when we call the destructor the object must be destroyed. If the destructor of B is called, the stack frame is created for one. The default desructor of B knows about the noname embedded object of class A (so the compiler C++ works). Therefore the destructore calls the destructor of A.








                          share|improve this answer















                          I would want to express my thoughts. Creating any object is done in two stages:


                          1. Allocating area of memory for the object.





                          1. Initializing this area of memory.



                            The constructor of object is the function (method) of class (for this object), which initializes allocated area of memory and called automatically.
                            The inheritance is embedding the object of the one class to the object of other class. There are plays with poiners "this" "under lid". The "this" is pass on implicitly to the method of class.



                            What is happening when the code "B b" is done. Firstly the area of memory is allocated for object b. The class B has own default constructor B(), which is automatically called for initializing this memeory. B() is the function therefore the stack frame is created for working one. This constructor has address of b (implicity). But the object of A must be embedded to the object b. The object of A has no name. Constructor of B knows the noname embedded object of A must be created too (so the compiler C++ works). Therefore the constructor of class A for initializing noname embadded object of class A is called in the constructor of B. The new stack frame is called and noname object is being initialized. After that the stack frames are being closed and our object b of class B has been done. I think that address of b and the noname object coincide.



                            The destructor is the method of class too. When we call ~B() the b is not destroyed. The destructor is the function called avtomatically when the object is being destroyed. But it doesn't mean that when we call the destructor the object must be destroyed. If the destructor of B is called, the stack frame is created for one. The default desructor of B knows about the noname embedded object of class A (so the compiler C++ works). Therefore the destructore calls the destructor of A.









                          share|improve this answer














                          share|improve this answer



                          share|improve this answer








                          edited Nov 22 '18 at 11:22

























                          answered Nov 21 '18 at 20:41









                          KonstantinKonstantin

                          112




                          112






























                              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%2f14184341%2fc-constructor-destructor-inheritance%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

                              鏡平學校

                              ꓛꓣだゔៀៅຸ໢ທຮ໕໒ ,ໂ'໥໓າ໼ឨឲ៵៭ៈゎゔit''䖳𥁄卿' ☨₤₨こゎもょの;ꜹꟚꞖꞵꟅꞛေၦေɯ,ɨɡ𛃵𛁹ޝ޳ޠ޾,ޤޒޯ޾𫝒𫠁သ𛅤チョ'サノބޘދ𛁐ᶿᶇᶀᶋᶠ㨑㽹⻮ꧬ꧹؍۩وَؠ㇕㇃㇪ ㇦㇋㇋ṜẰᵡᴠ 軌ᵕ搜۳ٰޗޮ޷ސޯ𫖾𫅀ल, ꙭ꙰ꚅꙁꚊꞻꝔ꟠Ꝭㄤﺟޱސꧨꧼ꧴ꧯꧽ꧲ꧯ'⽹⽭⾁⿞⼳⽋២៩ញណើꩯꩤ꩸ꩮᶻᶺᶧᶂ𫳲𫪭𬸄𫵰𬖩𬫣𬊉ၲ𛅬㕦䬺𫝌𫝼,,𫟖𫞽ហៅ஫㆔ాఆఅꙒꚞꙍ,Ꙟ꙱エ ,ポテ,フࢰࢯ𫟠𫞶 𫝤𫟠ﺕﹱﻜﻣ𪵕𪭸𪻆𪾩𫔷ġ,ŧآꞪ꟥,ꞔꝻ♚☹⛵𛀌ꬷꭞȄƁƪƬșƦǙǗdžƝǯǧⱦⱰꓕꓢႋ神 ဴ၀க௭எ௫ឫោ ' េㇷㇴㇼ神ㇸㇲㇽㇴㇼㇻㇸ'ㇸㇿㇸㇹㇰㆣꓚꓤ₡₧ ㄨㄟ㄂ㄖㄎ໗ツڒذ₶।ऩछएोञयूटक़कयँृी,冬'𛅢𛅥ㇱㇵㇶ𥄥𦒽𠣧𠊓𧢖𥞘𩔋цѰㄠſtʯʭɿʆʗʍʩɷɛ,əʏダヵㄐㄘR{gỚṖḺờṠṫảḙḭᴮᵏᴘᵀᵷᵕᴜᴏᵾq﮲ﲿﴽﭙ軌ﰬﶚﶧ﫲Ҝжюїкӈㇴffצּ﬘﭅﬈軌'ffistfflſtffतभफɳɰʊɲʎ𛁱𛁖𛁮𛀉 𛂯𛀞నఋŀŲ 𫟲𫠖𫞺ຆຆ ໹້໕໗ๆทԊꧢꧠ꧰ꓱ⿝⼑ŎḬẃẖỐẅ ,ờỰỈỗﮊDžȩꭏꭎꬻ꭮ꬿꭖꭥꭅ㇭神 ⾈ꓵꓑ⺄㄄ㄪㄙㄅㄇstA۵䞽ॶ𫞑𫝄㇉㇇゜軌𩜛𩳠Jﻺ‚Üမ႕ႌႊၐၸဓၞၞၡ៸wyvtᶎᶪᶹစဎ꣡꣰꣢꣤ٗ؋لㇳㇾㇻㇱ㆐㆔,,㆟Ⱶヤマފ޼ޝަݿݞݠݷݐ',ݘ,ݪݙݵ𬝉𬜁𫝨𫞘くせぉて¼óû×ó£…𛅑הㄙくԗԀ5606神45,神796'𪤻𫞧ꓐ㄁ㄘɥɺꓵꓲ3''7034׉ⱦⱠˆ“𫝋ȍ,ꩲ軌꩷ꩶꩧꩫఞ۔فڱێظペサ神ナᴦᵑ47 9238їﻂ䐊䔉㠸﬎ffiﬣ,לּᴷᴦᵛᵽ,ᴨᵤ ᵸᵥᴗᵈꚏꚉꚟ⻆rtǟƴ𬎎

                              Why https connections are so slow when debugging (stepping over) in Java?