Do the parentheses after the type name make a difference with new?
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
add a comment |
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
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
add a comment |
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
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
c++ constructor initialization new-operator c++-faq
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
add a comment |
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
add a comment |
5 Answers
5
active
oldest
votes
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 valuenew A()
- zero-initializenew 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 valuenew 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.
4
@j_random_hacker,new A()
will default-initialize the object in C++98, like it does withnew B()
,new B
,new C()
andnew C
, but not withnew 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 toB 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
|
show 18 more comments
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.
add a comment |
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.
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
|
show 4 more comments
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...
add a comment |
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.
add a comment |
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
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 valuenew A()
- zero-initializenew 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 valuenew 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.
4
@j_random_hacker,new A()
will default-initialize the object in C++98, like it does withnew B()
,new B
,new C()
andnew C
, but not withnew 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 toB 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
|
show 18 more comments
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 valuenew A()
- zero-initializenew 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 valuenew 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.
4
@j_random_hacker,new A()
will default-initialize the object in C++98, like it does withnew B()
,new B
,new C()
andnew C
, but not withnew 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 toB 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
|
show 18 more comments
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 valuenew A()
- zero-initializenew 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 valuenew 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.
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 valuenew A()
- zero-initializenew 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 valuenew 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.
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 withnew B()
,new B
,new C()
andnew C
, but not withnew 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 toB 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
|
show 18 more comments
4
@j_random_hacker,new A()
will default-initialize the object in C++98, like it does withnew B()
,new B
,new C()
andnew C
, but not withnew 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 toB 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
|
show 18 more comments
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.
add a comment |
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.
add a comment |
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.
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.
edited Apr 25 '14 at 22:12
hivert
8,95931944
8,95931944
answered Feb 15 '13 at 19:57
kfsonekfsone
63152
63152
add a comment |
add a comment |
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.
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
|
show 4 more comments
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.
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
|
show 4 more comments
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.
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.
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
|
show 4 more comments
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
|
show 4 more comments
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...
add a comment |
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...
add a comment |
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...
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...
edited Apr 25 '14 at 22:10
hivert
8,95931944
8,95931944
answered Mar 6 '09 at 20:00
baydabayda
10.4k63247
10.4k63247
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Mar 6 '09 at 19:59
answered Mar 6 '09 at 19:42
Evan ShawEvan Shaw
16.9k35455
16.9k35455
add a comment |
add a comment |
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?
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