Do the parentheses after the type name make a difference with new?












922














If 'Test' is an ordinary class, is there any difference between:



Test* test = new Test;


and



Test* test = new Test();









share|improve this question




















  • 1




    This is related to (but not identical to) stackoverflow.com/questions/1613341/…
    – Steve Jessop
    Dec 7 '10 at 17:21










  • Just use new Test() to make sure it is zero-initialized
    – Sung
    Jul 6 '16 at 5:51
















922














If 'Test' is an ordinary class, is there any difference between:



Test* test = new Test;


and



Test* test = new Test();









share|improve this question




















  • 1




    This is related to (but not identical to) stackoverflow.com/questions/1613341/…
    – Steve Jessop
    Dec 7 '10 at 17:21










  • Just use new Test() to make sure it is zero-initialized
    – Sung
    Jul 6 '16 at 5:51














922












922








922


521





If 'Test' is an ordinary class, is there any difference between:



Test* test = new Test;


and



Test* test = new Test();









share|improve this question















If 'Test' is an ordinary class, is there any difference between:



Test* test = new Test;


and



Test* test = new Test();






c++ constructor initialization new-operator c++-faq






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Oct 19 '15 at 15:38









Paul Maserrat

3,14931724




3,14931724










asked Mar 6 '09 at 19:39









David ReadDavid Read

4,6163124




4,6163124








  • 1




    This is related to (but not identical to) stackoverflow.com/questions/1613341/…
    – Steve Jessop
    Dec 7 '10 at 17:21










  • Just use new Test() to make sure it is zero-initialized
    – Sung
    Jul 6 '16 at 5:51














  • 1




    This is related to (but not identical to) stackoverflow.com/questions/1613341/…
    – Steve Jessop
    Dec 7 '10 at 17:21










  • Just use new Test() to make sure it is zero-initialized
    – Sung
    Jul 6 '16 at 5:51








1




1




This is related to (but not identical to) stackoverflow.com/questions/1613341/…
– Steve Jessop
Dec 7 '10 at 17:21




This is related to (but not identical to) stackoverflow.com/questions/1613341/…
– Steve Jessop
Dec 7 '10 at 17:21












Just use new Test() to make sure it is zero-initialized
– Sung
Jul 6 '16 at 5:51




Just use new Test() to make sure it is zero-initialized
– Sung
Jul 6 '16 at 5:51












5 Answers
5






active

oldest

votes


















884














Let's get pedantic, because there are differences that can actually affect your code's behavior. Much of the following is taken from comments made to an "Old New Thing" article.



Sometimes the memory returned by the new operator will be initialized, and sometimes it won't depending on whether the type you're newing up is a POD (plain old data), or if it's a class that contains POD members and is using a compiler-generated default constructor.




  • In C++1998 there are 2 types of initialization: zero and default

  • In C++2003 a 3rd type of initialization, value initialization was added.


Assume:



struct A { int m; }; // POD
struct B { ~B(); int m; }; // non-POD, compiler generated default ctor
struct C { C() : m() {}; ~C(); int m; }; // non-POD, default-initialising m


In a C++98 compiler, the following should occur:





  • new A - indeterminate value

  • new A() - zero-initialize


  • new B - default construct (B::m is uninitialized)


  • new B() - default construct (B::m is uninitialized)


  • new C - default construct (C::m is zero-initialized)



  • new C() - default construct (C::m is zero-initialized)


In a C++03 conformant compiler, things should work like so:





  • new A - indeterminate value

  • new A() - value-initialize A, which is zero-initialization since it's a POD.


  • new B - default-initializes (leaves B::m uninitialized)


  • new B() - value-initializes B which zero-initializes all fields since its default ctor is compiler generated as opposed to user-defined.


  • new C - default-initializes C, which calls the default ctor.



  • new C() - value-initializes C, which calls the default ctor.


So in all versions of C++ there's a difference between new A and new A() because A is a POD.



And there's a difference in behavior between C++98 and C++03 for the case new B().



This is one of the dusty corners of C++ that can drive you crazy. When constructing an object, sometimes you want/need the parens, sometimes you absolutely cannot have them, and sometimes it doesn't matter.






share|improve this answer



















  • 4




    @j_random_hacker, new A() will default-initialize the object in C++98, like it does with new B(), new B, new C() and new C, but not with new A. That is, default initialization is always done in C++98 when either: 1) The class is a non-POD and the initializer is missing, or 2) The initializer is (). default-initialization zero-initializes the object if it's a POD, but calls the default constructor for non-PODs.
    – Johannes Schaub - litb
    Jan 2 '11 at 13:32








  • 83




    Can someone add what is the case in C++11 now?
    – legends2k
    Aug 21 '12 at 4:39








  • 5




    @Jon: With C++11 you can do this in stack too; B obj{}; will make the object value-initialized (to 0s) as opposed to B obj; which will be default-initialized (garbage).
    – legends2k
    May 7 '13 at 14:03






  • 1




    @Jon: Well, I'd say it depends. Not all classes are written for external consumption where the client is some Joe coder who wouldn't know; some classes are written for a library's internal consumption, in such cases I guess going with POD is better, but in cases where it's absolutely necessary to always initialize vars into a particular state (and perf. isn't a prob) then ctor seems to be better.
    – legends2k
    May 14 '13 at 11:14








  • 1




    @MarkIngram AFAIK by doing = default; you are explicitly providing a constructor (even tho it is a compiler generated one, so you are in case B). If you don't provide a constructor, the compiler might implicitly generate it anyways (you remain in case A). The outcome is the same: new A/B -> default initialization, new A/B() -> value-initialization to zero. However, in C++11 you should not consider PODs but aggregates...
    – gnzlbg
    Mar 26 '14 at 14:41





















53














new Thing(); is explicit that you want a constructor called whereas new Thing; is taken to imply you don't mind if the constructor isn't called.



If used on a struct/class with a user-defined constructor, there is no difference. If called on a trivial struct/class (e.g. struct Thing { int i; };) then new Thing; is like malloc(sizeof(Thing)); whereas new Thing(); is like calloc(sizeof(Thing)); - it gets zero initialized.



The gotcha lies in-between:



struct Thingy {
~Thingy(); // No-longer a trivial class
virtual WaxOn();
int i;
};


The behavior of new Thingy; vs new Thingy(); in this case changed between C++98 and C++2003. See Michael Burr's explanation for how and why.






share|improve this answer































    19














    No, they are the same. But there is a difference between:



    Test t;      // create a Test called t


    and



    Test t();   // declare a function called t which returns a Test


    This is because of the basic C++ (and C) rule: If something can possibly be a declaration, then it is a declaration.



    Edit: Re the initialisation issues regarding POD and non-POD data, while I agree with everything that has been said, I would just like to point out that these issues only apply if the thing being new'd or otherwise constructed does not have a user-defined constructor. If there is such a constructor it will be used. For 99.99% of sensibly designed classes there will be such a constructor, and so the issues can be ignored.






    share|improve this answer



















    • 17




      Note that this is a particularly important point because the line "Test t(5);" is equivalent to "Test t = Test(5);" -- but "Test t();" is very different from "Test t = Test();". +1
      – ojrac
      Mar 6 '09 at 20:03






    • 9




      -1, I disagree with your statement that the issues can be ignored. You don't have to know the rules precisely, but you should be aware of them in case you have to new a class without a user-defined default constructor (you should then either write the constructor or look up the rules).
      – avakar
      Mar 6 '10 at 7:02






    • 10




      -1 for a known incorrect answer. Your Edit ignores the presence of code written by former C programmers who didn't understand/use constructors.
      – Tom
      Apr 16 '10 at 11:00






    • 4




      What about classes like struct point { float v[3]; };? For things like that, a constructor would be a bad idea, as it would prevent all the nice properties that come with being POD and aggregate. So "the issues can be ignored" is just wrong, imo.
      – me22
      Jan 2 '11 at 3:56






    • 5




      But they are not the same. This answer is plain wrong. It should be fixed or removed, because it seems to have caused some confusion, judging by the high number of up-votes.
      – juanchopanza
      Aug 11 '14 at 5:59



















    16














    In general we have default-initialization in first case and value-initialization in second case.



    For example:
    in case with int (POD type):




    • int* test = new int - we have any initialization and value of *test can be any.


    • int* test = new int() - *test will have 0 value.



    next behaviour depended from your type Test.
    We have defferent cases: Test have defult constructor, Test have generated default constructor, Test contain POD member, non POD member...






    share|improve this answer































      10














      Assuming that Test is a class with a defined constructor, there's no difference. The latter form makes it a little clearer that Test's constructor is running, but that's about it.






      share|improve this answer






















        protected by StoryTeller Oct 30 '17 at 12:45



        Thank you for your interest in this question.
        Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



        Would you like to answer one of these unanswered questions instead?














        5 Answers
        5






        active

        oldest

        votes








        5 Answers
        5






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        884














        Let's get pedantic, because there are differences that can actually affect your code's behavior. Much of the following is taken from comments made to an "Old New Thing" article.



        Sometimes the memory returned by the new operator will be initialized, and sometimes it won't depending on whether the type you're newing up is a POD (plain old data), or if it's a class that contains POD members and is using a compiler-generated default constructor.




        • In C++1998 there are 2 types of initialization: zero and default

        • In C++2003 a 3rd type of initialization, value initialization was added.


        Assume:



        struct A { int m; }; // POD
        struct B { ~B(); int m; }; // non-POD, compiler generated default ctor
        struct C { C() : m() {}; ~C(); int m; }; // non-POD, default-initialising m


        In a C++98 compiler, the following should occur:





        • new A - indeterminate value

        • new A() - zero-initialize


        • new B - default construct (B::m is uninitialized)


        • new B() - default construct (B::m is uninitialized)


        • new C - default construct (C::m is zero-initialized)



        • new C() - default construct (C::m is zero-initialized)


        In a C++03 conformant compiler, things should work like so:





        • new A - indeterminate value

        • new A() - value-initialize A, which is zero-initialization since it's a POD.


        • new B - default-initializes (leaves B::m uninitialized)


        • new B() - value-initializes B which zero-initializes all fields since its default ctor is compiler generated as opposed to user-defined.


        • new C - default-initializes C, which calls the default ctor.



        • new C() - value-initializes C, which calls the default ctor.


        So in all versions of C++ there's a difference between new A and new A() because A is a POD.



        And there's a difference in behavior between C++98 and C++03 for the case new B().



        This is one of the dusty corners of C++ that can drive you crazy. When constructing an object, sometimes you want/need the parens, sometimes you absolutely cannot have them, and sometimes it doesn't matter.






        share|improve this answer



















        • 4




          @j_random_hacker, new A() will default-initialize the object in C++98, like it does with new B(), new B, new C() and new C, but not with new A. That is, default initialization is always done in C++98 when either: 1) The class is a non-POD and the initializer is missing, or 2) The initializer is (). default-initialization zero-initializes the object if it's a POD, but calls the default constructor for non-PODs.
          – Johannes Schaub - litb
          Jan 2 '11 at 13:32








        • 83




          Can someone add what is the case in C++11 now?
          – legends2k
          Aug 21 '12 at 4:39








        • 5




          @Jon: With C++11 you can do this in stack too; B obj{}; will make the object value-initialized (to 0s) as opposed to B obj; which will be default-initialized (garbage).
          – legends2k
          May 7 '13 at 14:03






        • 1




          @Jon: Well, I'd say it depends. Not all classes are written for external consumption where the client is some Joe coder who wouldn't know; some classes are written for a library's internal consumption, in such cases I guess going with POD is better, but in cases where it's absolutely necessary to always initialize vars into a particular state (and perf. isn't a prob) then ctor seems to be better.
          – legends2k
          May 14 '13 at 11:14








        • 1




          @MarkIngram AFAIK by doing = default; you are explicitly providing a constructor (even tho it is a compiler generated one, so you are in case B). If you don't provide a constructor, the compiler might implicitly generate it anyways (you remain in case A). The outcome is the same: new A/B -> default initialization, new A/B() -> value-initialization to zero. However, in C++11 you should not consider PODs but aggregates...
          – gnzlbg
          Mar 26 '14 at 14:41


















        884














        Let's get pedantic, because there are differences that can actually affect your code's behavior. Much of the following is taken from comments made to an "Old New Thing" article.



        Sometimes the memory returned by the new operator will be initialized, and sometimes it won't depending on whether the type you're newing up is a POD (plain old data), or if it's a class that contains POD members and is using a compiler-generated default constructor.




        • In C++1998 there are 2 types of initialization: zero and default

        • In C++2003 a 3rd type of initialization, value initialization was added.


        Assume:



        struct A { int m; }; // POD
        struct B { ~B(); int m; }; // non-POD, compiler generated default ctor
        struct C { C() : m() {}; ~C(); int m; }; // non-POD, default-initialising m


        In a C++98 compiler, the following should occur:





        • new A - indeterminate value

        • new A() - zero-initialize


        • new B - default construct (B::m is uninitialized)


        • new B() - default construct (B::m is uninitialized)


        • new C - default construct (C::m is zero-initialized)



        • new C() - default construct (C::m is zero-initialized)


        In a C++03 conformant compiler, things should work like so:





        • new A - indeterminate value

        • new A() - value-initialize A, which is zero-initialization since it's a POD.


        • new B - default-initializes (leaves B::m uninitialized)


        • new B() - value-initializes B which zero-initializes all fields since its default ctor is compiler generated as opposed to user-defined.


        • new C - default-initializes C, which calls the default ctor.



        • new C() - value-initializes C, which calls the default ctor.


        So in all versions of C++ there's a difference between new A and new A() because A is a POD.



        And there's a difference in behavior between C++98 and C++03 for the case new B().



        This is one of the dusty corners of C++ that can drive you crazy. When constructing an object, sometimes you want/need the parens, sometimes you absolutely cannot have them, and sometimes it doesn't matter.






        share|improve this answer



















        • 4




          @j_random_hacker, new A() will default-initialize the object in C++98, like it does with new B(), new B, new C() and new C, but not with new A. That is, default initialization is always done in C++98 when either: 1) The class is a non-POD and the initializer is missing, or 2) The initializer is (). default-initialization zero-initializes the object if it's a POD, but calls the default constructor for non-PODs.
          – Johannes Schaub - litb
          Jan 2 '11 at 13:32








        • 83




          Can someone add what is the case in C++11 now?
          – legends2k
          Aug 21 '12 at 4:39








        • 5




          @Jon: With C++11 you can do this in stack too; B obj{}; will make the object value-initialized (to 0s) as opposed to B obj; which will be default-initialized (garbage).
          – legends2k
          May 7 '13 at 14:03






        • 1




          @Jon: Well, I'd say it depends. Not all classes are written for external consumption where the client is some Joe coder who wouldn't know; some classes are written for a library's internal consumption, in such cases I guess going with POD is better, but in cases where it's absolutely necessary to always initialize vars into a particular state (and perf. isn't a prob) then ctor seems to be better.
          – legends2k
          May 14 '13 at 11:14








        • 1




          @MarkIngram AFAIK by doing = default; you are explicitly providing a constructor (even tho it is a compiler generated one, so you are in case B). If you don't provide a constructor, the compiler might implicitly generate it anyways (you remain in case A). The outcome is the same: new A/B -> default initialization, new A/B() -> value-initialization to zero. However, in C++11 you should not consider PODs but aggregates...
          – gnzlbg
          Mar 26 '14 at 14:41
















        884












        884








        884






        Let's get pedantic, because there are differences that can actually affect your code's behavior. Much of the following is taken from comments made to an "Old New Thing" article.



        Sometimes the memory returned by the new operator will be initialized, and sometimes it won't depending on whether the type you're newing up is a POD (plain old data), or if it's a class that contains POD members and is using a compiler-generated default constructor.




        • In C++1998 there are 2 types of initialization: zero and default

        • In C++2003 a 3rd type of initialization, value initialization was added.


        Assume:



        struct A { int m; }; // POD
        struct B { ~B(); int m; }; // non-POD, compiler generated default ctor
        struct C { C() : m() {}; ~C(); int m; }; // non-POD, default-initialising m


        In a C++98 compiler, the following should occur:





        • new A - indeterminate value

        • new A() - zero-initialize


        • new B - default construct (B::m is uninitialized)


        • new B() - default construct (B::m is uninitialized)


        • new C - default construct (C::m is zero-initialized)



        • new C() - default construct (C::m is zero-initialized)


        In a C++03 conformant compiler, things should work like so:





        • new A - indeterminate value

        • new A() - value-initialize A, which is zero-initialization since it's a POD.


        • new B - default-initializes (leaves B::m uninitialized)


        • new B() - value-initializes B which zero-initializes all fields since its default ctor is compiler generated as opposed to user-defined.


        • new C - default-initializes C, which calls the default ctor.



        • new C() - value-initializes C, which calls the default ctor.


        So in all versions of C++ there's a difference between new A and new A() because A is a POD.



        And there's a difference in behavior between C++98 and C++03 for the case new B().



        This is one of the dusty corners of C++ that can drive you crazy. When constructing an object, sometimes you want/need the parens, sometimes you absolutely cannot have them, and sometimes it doesn't matter.






        share|improve this answer














        Let's get pedantic, because there are differences that can actually affect your code's behavior. Much of the following is taken from comments made to an "Old New Thing" article.



        Sometimes the memory returned by the new operator will be initialized, and sometimes it won't depending on whether the type you're newing up is a POD (plain old data), or if it's a class that contains POD members and is using a compiler-generated default constructor.




        • In C++1998 there are 2 types of initialization: zero and default

        • In C++2003 a 3rd type of initialization, value initialization was added.


        Assume:



        struct A { int m; }; // POD
        struct B { ~B(); int m; }; // non-POD, compiler generated default ctor
        struct C { C() : m() {}; ~C(); int m; }; // non-POD, default-initialising m


        In a C++98 compiler, the following should occur:





        • new A - indeterminate value

        • new A() - zero-initialize


        • new B - default construct (B::m is uninitialized)


        • new B() - default construct (B::m is uninitialized)


        • new C - default construct (C::m is zero-initialized)



        • new C() - default construct (C::m is zero-initialized)


        In a C++03 conformant compiler, things should work like so:





        • new A - indeterminate value

        • new A() - value-initialize A, which is zero-initialization since it's a POD.


        • new B - default-initializes (leaves B::m uninitialized)


        • new B() - value-initializes B which zero-initializes all fields since its default ctor is compiler generated as opposed to user-defined.


        • new C - default-initializes C, which calls the default ctor.



        • new C() - value-initializes C, which calls the default ctor.


        So in all versions of C++ there's a difference between new A and new A() because A is a POD.



        And there's a difference in behavior between C++98 and C++03 for the case new B().



        This is one of the dusty corners of C++ that can drive you crazy. When constructing an object, sometimes you want/need the parens, sometimes you absolutely cannot have them, and sometimes it doesn't matter.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Dec 18 '17 at 10:56









        Melebius

        2,97632134




        2,97632134










        answered Mar 6 '09 at 21:01









        Michael BurrMichael Burr

        281k40429666




        281k40429666








        • 4




          @j_random_hacker, new A() will default-initialize the object in C++98, like it does with new B(), new B, new C() and new C, but not with new A. That is, default initialization is always done in C++98 when either: 1) The class is a non-POD and the initializer is missing, or 2) The initializer is (). default-initialization zero-initializes the object if it's a POD, but calls the default constructor for non-PODs.
          – Johannes Schaub - litb
          Jan 2 '11 at 13:32








        • 83




          Can someone add what is the case in C++11 now?
          – legends2k
          Aug 21 '12 at 4:39








        • 5




          @Jon: With C++11 you can do this in stack too; B obj{}; will make the object value-initialized (to 0s) as opposed to B obj; which will be default-initialized (garbage).
          – legends2k
          May 7 '13 at 14:03






        • 1




          @Jon: Well, I'd say it depends. Not all classes are written for external consumption where the client is some Joe coder who wouldn't know; some classes are written for a library's internal consumption, in such cases I guess going with POD is better, but in cases where it's absolutely necessary to always initialize vars into a particular state (and perf. isn't a prob) then ctor seems to be better.
          – legends2k
          May 14 '13 at 11:14








        • 1




          @MarkIngram AFAIK by doing = default; you are explicitly providing a constructor (even tho it is a compiler generated one, so you are in case B). If you don't provide a constructor, the compiler might implicitly generate it anyways (you remain in case A). The outcome is the same: new A/B -> default initialization, new A/B() -> value-initialization to zero. However, in C++11 you should not consider PODs but aggregates...
          – gnzlbg
          Mar 26 '14 at 14:41
















        • 4




          @j_random_hacker, new A() will default-initialize the object in C++98, like it does with new B(), new B, new C() and new C, but not with new A. That is, default initialization is always done in C++98 when either: 1) The class is a non-POD and the initializer is missing, or 2) The initializer is (). default-initialization zero-initializes the object if it's a POD, but calls the default constructor for non-PODs.
          – Johannes Schaub - litb
          Jan 2 '11 at 13:32








        • 83




          Can someone add what is the case in C++11 now?
          – legends2k
          Aug 21 '12 at 4:39








        • 5




          @Jon: With C++11 you can do this in stack too; B obj{}; will make the object value-initialized (to 0s) as opposed to B obj; which will be default-initialized (garbage).
          – legends2k
          May 7 '13 at 14:03






        • 1




          @Jon: Well, I'd say it depends. Not all classes are written for external consumption where the client is some Joe coder who wouldn't know; some classes are written for a library's internal consumption, in such cases I guess going with POD is better, but in cases where it's absolutely necessary to always initialize vars into a particular state (and perf. isn't a prob) then ctor seems to be better.
          – legends2k
          May 14 '13 at 11:14








        • 1




          @MarkIngram AFAIK by doing = default; you are explicitly providing a constructor (even tho it is a compiler generated one, so you are in case B). If you don't provide a constructor, the compiler might implicitly generate it anyways (you remain in case A). The outcome is the same: new A/B -> default initialization, new A/B() -> value-initialization to zero. However, in C++11 you should not consider PODs but aggregates...
          – gnzlbg
          Mar 26 '14 at 14:41










        4




        4




        @j_random_hacker, new A() will default-initialize the object in C++98, like it does with new B(), new B, new C() and new C, but not with new A. That is, default initialization is always done in C++98 when either: 1) The class is a non-POD and the initializer is missing, or 2) The initializer is (). default-initialization zero-initializes the object if it's a POD, but calls the default constructor for non-PODs.
        – Johannes Schaub - litb
        Jan 2 '11 at 13:32






        @j_random_hacker, new A() will default-initialize the object in C++98, like it does with new B(), new B, new C() and new C, but not with new A. That is, default initialization is always done in C++98 when either: 1) The class is a non-POD and the initializer is missing, or 2) The initializer is (). default-initialization zero-initializes the object if it's a POD, but calls the default constructor for non-PODs.
        – Johannes Schaub - litb
        Jan 2 '11 at 13:32






        83




        83




        Can someone add what is the case in C++11 now?
        – legends2k
        Aug 21 '12 at 4:39






        Can someone add what is the case in C++11 now?
        – legends2k
        Aug 21 '12 at 4:39






        5




        5




        @Jon: With C++11 you can do this in stack too; B obj{}; will make the object value-initialized (to 0s) as opposed to B obj; which will be default-initialized (garbage).
        – legends2k
        May 7 '13 at 14:03




        @Jon: With C++11 you can do this in stack too; B obj{}; will make the object value-initialized (to 0s) as opposed to B obj; which will be default-initialized (garbage).
        – legends2k
        May 7 '13 at 14:03




        1




        1




        @Jon: Well, I'd say it depends. Not all classes are written for external consumption where the client is some Joe coder who wouldn't know; some classes are written for a library's internal consumption, in such cases I guess going with POD is better, but in cases where it's absolutely necessary to always initialize vars into a particular state (and perf. isn't a prob) then ctor seems to be better.
        – legends2k
        May 14 '13 at 11:14






        @Jon: Well, I'd say it depends. Not all classes are written for external consumption where the client is some Joe coder who wouldn't know; some classes are written for a library's internal consumption, in such cases I guess going with POD is better, but in cases where it's absolutely necessary to always initialize vars into a particular state (and perf. isn't a prob) then ctor seems to be better.
        – legends2k
        May 14 '13 at 11:14






        1




        1




        @MarkIngram AFAIK by doing = default; you are explicitly providing a constructor (even tho it is a compiler generated one, so you are in case B). If you don't provide a constructor, the compiler might implicitly generate it anyways (you remain in case A). The outcome is the same: new A/B -> default initialization, new A/B() -> value-initialization to zero. However, in C++11 you should not consider PODs but aggregates...
        – gnzlbg
        Mar 26 '14 at 14:41






        @MarkIngram AFAIK by doing = default; you are explicitly providing a constructor (even tho it is a compiler generated one, so you are in case B). If you don't provide a constructor, the compiler might implicitly generate it anyways (you remain in case A). The outcome is the same: new A/B -> default initialization, new A/B() -> value-initialization to zero. However, in C++11 you should not consider PODs but aggregates...
        – gnzlbg
        Mar 26 '14 at 14:41















        53














        new Thing(); is explicit that you want a constructor called whereas new Thing; is taken to imply you don't mind if the constructor isn't called.



        If used on a struct/class with a user-defined constructor, there is no difference. If called on a trivial struct/class (e.g. struct Thing { int i; };) then new Thing; is like malloc(sizeof(Thing)); whereas new Thing(); is like calloc(sizeof(Thing)); - it gets zero initialized.



        The gotcha lies in-between:



        struct Thingy {
        ~Thingy(); // No-longer a trivial class
        virtual WaxOn();
        int i;
        };


        The behavior of new Thingy; vs new Thingy(); in this case changed between C++98 and C++2003. See Michael Burr's explanation for how and why.






        share|improve this answer




























          53














          new Thing(); is explicit that you want a constructor called whereas new Thing; is taken to imply you don't mind if the constructor isn't called.



          If used on a struct/class with a user-defined constructor, there is no difference. If called on a trivial struct/class (e.g. struct Thing { int i; };) then new Thing; is like malloc(sizeof(Thing)); whereas new Thing(); is like calloc(sizeof(Thing)); - it gets zero initialized.



          The gotcha lies in-between:



          struct Thingy {
          ~Thingy(); // No-longer a trivial class
          virtual WaxOn();
          int i;
          };


          The behavior of new Thingy; vs new Thingy(); in this case changed between C++98 and C++2003. See Michael Burr's explanation for how and why.






          share|improve this answer


























            53












            53








            53






            new Thing(); is explicit that you want a constructor called whereas new Thing; is taken to imply you don't mind if the constructor isn't called.



            If used on a struct/class with a user-defined constructor, there is no difference. If called on a trivial struct/class (e.g. struct Thing { int i; };) then new Thing; is like malloc(sizeof(Thing)); whereas new Thing(); is like calloc(sizeof(Thing)); - it gets zero initialized.



            The gotcha lies in-between:



            struct Thingy {
            ~Thingy(); // No-longer a trivial class
            virtual WaxOn();
            int i;
            };


            The behavior of new Thingy; vs new Thingy(); in this case changed between C++98 and C++2003. See Michael Burr's explanation for how and why.






            share|improve this answer














            new Thing(); is explicit that you want a constructor called whereas new Thing; is taken to imply you don't mind if the constructor isn't called.



            If used on a struct/class with a user-defined constructor, there is no difference. If called on a trivial struct/class (e.g. struct Thing { int i; };) then new Thing; is like malloc(sizeof(Thing)); whereas new Thing(); is like calloc(sizeof(Thing)); - it gets zero initialized.



            The gotcha lies in-between:



            struct Thingy {
            ~Thingy(); // No-longer a trivial class
            virtual WaxOn();
            int i;
            };


            The behavior of new Thingy; vs new Thingy(); in this case changed between C++98 and C++2003. See Michael Burr's explanation for how and why.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 25 '14 at 22:12









            hivert

            8,95931944




            8,95931944










            answered Feb 15 '13 at 19:57









            kfsonekfsone

            63152




            63152























                19














                No, they are the same. But there is a difference between:



                Test t;      // create a Test called t


                and



                Test t();   // declare a function called t which returns a Test


                This is because of the basic C++ (and C) rule: If something can possibly be a declaration, then it is a declaration.



                Edit: Re the initialisation issues regarding POD and non-POD data, while I agree with everything that has been said, I would just like to point out that these issues only apply if the thing being new'd or otherwise constructed does not have a user-defined constructor. If there is such a constructor it will be used. For 99.99% of sensibly designed classes there will be such a constructor, and so the issues can be ignored.






                share|improve this answer



















                • 17




                  Note that this is a particularly important point because the line "Test t(5);" is equivalent to "Test t = Test(5);" -- but "Test t();" is very different from "Test t = Test();". +1
                  – ojrac
                  Mar 6 '09 at 20:03






                • 9




                  -1, I disagree with your statement that the issues can be ignored. You don't have to know the rules precisely, but you should be aware of them in case you have to new a class without a user-defined default constructor (you should then either write the constructor or look up the rules).
                  – avakar
                  Mar 6 '10 at 7:02






                • 10




                  -1 for a known incorrect answer. Your Edit ignores the presence of code written by former C programmers who didn't understand/use constructors.
                  – Tom
                  Apr 16 '10 at 11:00






                • 4




                  What about classes like struct point { float v[3]; };? For things like that, a constructor would be a bad idea, as it would prevent all the nice properties that come with being POD and aggregate. So "the issues can be ignored" is just wrong, imo.
                  – me22
                  Jan 2 '11 at 3:56






                • 5




                  But they are not the same. This answer is plain wrong. It should be fixed or removed, because it seems to have caused some confusion, judging by the high number of up-votes.
                  – juanchopanza
                  Aug 11 '14 at 5:59
















                19














                No, they are the same. But there is a difference between:



                Test t;      // create a Test called t


                and



                Test t();   // declare a function called t which returns a Test


                This is because of the basic C++ (and C) rule: If something can possibly be a declaration, then it is a declaration.



                Edit: Re the initialisation issues regarding POD and non-POD data, while I agree with everything that has been said, I would just like to point out that these issues only apply if the thing being new'd or otherwise constructed does not have a user-defined constructor. If there is such a constructor it will be used. For 99.99% of sensibly designed classes there will be such a constructor, and so the issues can be ignored.






                share|improve this answer



















                • 17




                  Note that this is a particularly important point because the line "Test t(5);" is equivalent to "Test t = Test(5);" -- but "Test t();" is very different from "Test t = Test();". +1
                  – ojrac
                  Mar 6 '09 at 20:03






                • 9




                  -1, I disagree with your statement that the issues can be ignored. You don't have to know the rules precisely, but you should be aware of them in case you have to new a class without a user-defined default constructor (you should then either write the constructor or look up the rules).
                  – avakar
                  Mar 6 '10 at 7:02






                • 10




                  -1 for a known incorrect answer. Your Edit ignores the presence of code written by former C programmers who didn't understand/use constructors.
                  – Tom
                  Apr 16 '10 at 11:00






                • 4




                  What about classes like struct point { float v[3]; };? For things like that, a constructor would be a bad idea, as it would prevent all the nice properties that come with being POD and aggregate. So "the issues can be ignored" is just wrong, imo.
                  – me22
                  Jan 2 '11 at 3:56






                • 5




                  But they are not the same. This answer is plain wrong. It should be fixed or removed, because it seems to have caused some confusion, judging by the high number of up-votes.
                  – juanchopanza
                  Aug 11 '14 at 5:59














                19












                19








                19






                No, they are the same. But there is a difference between:



                Test t;      // create a Test called t


                and



                Test t();   // declare a function called t which returns a Test


                This is because of the basic C++ (and C) rule: If something can possibly be a declaration, then it is a declaration.



                Edit: Re the initialisation issues regarding POD and non-POD data, while I agree with everything that has been said, I would just like to point out that these issues only apply if the thing being new'd or otherwise constructed does not have a user-defined constructor. If there is such a constructor it will be used. For 99.99% of sensibly designed classes there will be such a constructor, and so the issues can be ignored.






                share|improve this answer














                No, they are the same. But there is a difference between:



                Test t;      // create a Test called t


                and



                Test t();   // declare a function called t which returns a Test


                This is because of the basic C++ (and C) rule: If something can possibly be a declaration, then it is a declaration.



                Edit: Re the initialisation issues regarding POD and non-POD data, while I agree with everything that has been said, I would just like to point out that these issues only apply if the thing being new'd or otherwise constructed does not have a user-defined constructor. If there is such a constructor it will be used. For 99.99% of sensibly designed classes there will be such a constructor, and so the issues can be ignored.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Mar 6 '09 at 21:23

























                answered Mar 6 '09 at 19:42







                anon















                • 17




                  Note that this is a particularly important point because the line "Test t(5);" is equivalent to "Test t = Test(5);" -- but "Test t();" is very different from "Test t = Test();". +1
                  – ojrac
                  Mar 6 '09 at 20:03






                • 9




                  -1, I disagree with your statement that the issues can be ignored. You don't have to know the rules precisely, but you should be aware of them in case you have to new a class without a user-defined default constructor (you should then either write the constructor or look up the rules).
                  – avakar
                  Mar 6 '10 at 7:02






                • 10




                  -1 for a known incorrect answer. Your Edit ignores the presence of code written by former C programmers who didn't understand/use constructors.
                  – Tom
                  Apr 16 '10 at 11:00






                • 4




                  What about classes like struct point { float v[3]; };? For things like that, a constructor would be a bad idea, as it would prevent all the nice properties that come with being POD and aggregate. So "the issues can be ignored" is just wrong, imo.
                  – me22
                  Jan 2 '11 at 3:56






                • 5




                  But they are not the same. This answer is plain wrong. It should be fixed or removed, because it seems to have caused some confusion, judging by the high number of up-votes.
                  – juanchopanza
                  Aug 11 '14 at 5:59














                • 17




                  Note that this is a particularly important point because the line "Test t(5);" is equivalent to "Test t = Test(5);" -- but "Test t();" is very different from "Test t = Test();". +1
                  – ojrac
                  Mar 6 '09 at 20:03






                • 9




                  -1, I disagree with your statement that the issues can be ignored. You don't have to know the rules precisely, but you should be aware of them in case you have to new a class without a user-defined default constructor (you should then either write the constructor or look up the rules).
                  – avakar
                  Mar 6 '10 at 7:02






                • 10




                  -1 for a known incorrect answer. Your Edit ignores the presence of code written by former C programmers who didn't understand/use constructors.
                  – Tom
                  Apr 16 '10 at 11:00






                • 4




                  What about classes like struct point { float v[3]; };? For things like that, a constructor would be a bad idea, as it would prevent all the nice properties that come with being POD and aggregate. So "the issues can be ignored" is just wrong, imo.
                  – me22
                  Jan 2 '11 at 3:56






                • 5




                  But they are not the same. This answer is plain wrong. It should be fixed or removed, because it seems to have caused some confusion, judging by the high number of up-votes.
                  – juanchopanza
                  Aug 11 '14 at 5:59








                17




                17




                Note that this is a particularly important point because the line "Test t(5);" is equivalent to "Test t = Test(5);" -- but "Test t();" is very different from "Test t = Test();". +1
                – ojrac
                Mar 6 '09 at 20:03




                Note that this is a particularly important point because the line "Test t(5);" is equivalent to "Test t = Test(5);" -- but "Test t();" is very different from "Test t = Test();". +1
                – ojrac
                Mar 6 '09 at 20:03




                9




                9




                -1, I disagree with your statement that the issues can be ignored. You don't have to know the rules precisely, but you should be aware of them in case you have to new a class without a user-defined default constructor (you should then either write the constructor or look up the rules).
                – avakar
                Mar 6 '10 at 7:02




                -1, I disagree with your statement that the issues can be ignored. You don't have to know the rules precisely, but you should be aware of them in case you have to new a class without a user-defined default constructor (you should then either write the constructor or look up the rules).
                – avakar
                Mar 6 '10 at 7:02




                10




                10




                -1 for a known incorrect answer. Your Edit ignores the presence of code written by former C programmers who didn't understand/use constructors.
                – Tom
                Apr 16 '10 at 11:00




                -1 for a known incorrect answer. Your Edit ignores the presence of code written by former C programmers who didn't understand/use constructors.
                – Tom
                Apr 16 '10 at 11:00




                4




                4




                What about classes like struct point { float v[3]; };? For things like that, a constructor would be a bad idea, as it would prevent all the nice properties that come with being POD and aggregate. So "the issues can be ignored" is just wrong, imo.
                – me22
                Jan 2 '11 at 3:56




                What about classes like struct point { float v[3]; };? For things like that, a constructor would be a bad idea, as it would prevent all the nice properties that come with being POD and aggregate. So "the issues can be ignored" is just wrong, imo.
                – me22
                Jan 2 '11 at 3:56




                5




                5




                But they are not the same. This answer is plain wrong. It should be fixed or removed, because it seems to have caused some confusion, judging by the high number of up-votes.
                – juanchopanza
                Aug 11 '14 at 5:59




                But they are not the same. This answer is plain wrong. It should be fixed or removed, because it seems to have caused some confusion, judging by the high number of up-votes.
                – juanchopanza
                Aug 11 '14 at 5:59











                16














                In general we have default-initialization in first case and value-initialization in second case.



                For example:
                in case with int (POD type):




                • int* test = new int - we have any initialization and value of *test can be any.


                • int* test = new int() - *test will have 0 value.



                next behaviour depended from your type Test.
                We have defferent cases: Test have defult constructor, Test have generated default constructor, Test contain POD member, non POD member...






                share|improve this answer




























                  16














                  In general we have default-initialization in first case and value-initialization in second case.



                  For example:
                  in case with int (POD type):




                  • int* test = new int - we have any initialization and value of *test can be any.


                  • int* test = new int() - *test will have 0 value.



                  next behaviour depended from your type Test.
                  We have defferent cases: Test have defult constructor, Test have generated default constructor, Test contain POD member, non POD member...






                  share|improve this answer


























                    16












                    16








                    16






                    In general we have default-initialization in first case and value-initialization in second case.



                    For example:
                    in case with int (POD type):




                    • int* test = new int - we have any initialization and value of *test can be any.


                    • int* test = new int() - *test will have 0 value.



                    next behaviour depended from your type Test.
                    We have defferent cases: Test have defult constructor, Test have generated default constructor, Test contain POD member, non POD member...






                    share|improve this answer














                    In general we have default-initialization in first case and value-initialization in second case.



                    For example:
                    in case with int (POD type):




                    • int* test = new int - we have any initialization and value of *test can be any.


                    • int* test = new int() - *test will have 0 value.



                    next behaviour depended from your type Test.
                    We have defferent cases: Test have defult constructor, Test have generated default constructor, Test contain POD member, non POD member...







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Apr 25 '14 at 22:10









                    hivert

                    8,95931944




                    8,95931944










                    answered Mar 6 '09 at 20:00









                    baydabayda

                    10.4k63247




                    10.4k63247























                        10














                        Assuming that Test is a class with a defined constructor, there's no difference. The latter form makes it a little clearer that Test's constructor is running, but that's about it.






                        share|improve this answer




























                          10














                          Assuming that Test is a class with a defined constructor, there's no difference. The latter form makes it a little clearer that Test's constructor is running, but that's about it.






                          share|improve this answer


























                            10












                            10








                            10






                            Assuming that Test is a class with a defined constructor, there's no difference. The latter form makes it a little clearer that Test's constructor is running, but that's about it.






                            share|improve this answer














                            Assuming that Test is a class with a defined constructor, there's no difference. The latter form makes it a little clearer that Test's constructor is running, but that's about it.







                            share|improve this answer














                            share|improve this answer



                            share|improve this answer








                            edited Mar 6 '09 at 19:59

























                            answered Mar 6 '09 at 19:42









                            Evan ShawEvan Shaw

                            16.9k35455




                            16.9k35455

















                                protected by StoryTeller Oct 30 '17 at 12:45



                                Thank you for your interest in this question.
                                Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                                Would you like to answer one of these unanswered questions instead?



                                Popular posts from this blog

                                Xamarin.iOS Cant Deploy on Iphone

                                Glorious Revolution

                                Dulmage-Mendelsohn matrix decomposition in Python