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.
Read it backwards (as driven by Clockwise/Spiral Rule):
int*
- pointer to int
int const *
- pointer to const int
int * const
- const pointer to int
int const * const
- const pointer to const int
Now the first const
can be on either side of the type so:
const int *
== int const *
const int * const
== int const * const
If you want to go really crazy you can do things like this:
int **
- pointer to pointer to int
int ** const
- a const pointer to a pointer to an int
int * const *
- a pointer to a const pointer to an int
int const **
- a pointer to a pointer to a const int
int * const * const
- a const pointer to a const pointer to an int
- ...
And to make sure we are clear on the meaning of const
:
int a = 5, b = 10, c = 15;
const int* foo; // pointer to constant int.
foo = &a; // assignment to where foo points to.
/* dummy statement*/
*foo = 6; // the value of a canĀ“t get changed through the pointer.
foo = &b; // the pointer foo can be changed.
int *const bar = &c; // constant pointer to int
// note, you actually need to set the pointer
// here because you can't change it later ;)
*bar = 16; // the value of c can be changed through the pointer.
/* dummy statement*/
bar = &a; // not possible because bar is a constant pointer.
foo
is a variable pointer to a constant integer. This lets you change what you point to but not the value that you point to. Most often this is seen with C-style strings where you have a pointer to a const char
. You may change which string you point to but you can't change the content of these strings. This is important when the string itself is in the data segment of a program and shouldn't be changed.
bar
is a constant or fixed pointer to a value that can be changed. This is like a reference without the extra syntactic sugar. Because of this fact, usually you would use a reference where you would use a T* const
pointer unless you need to allow NULL
pointers.
Best Answer
From 5.3.4/7
From 3.7.3.1/2
Also
That means you can do it, but you can not legally (in a well defined manner across all platforms) dereference the memory that you get - you can only pass it to array delete - and you should delete it.
Here is an interesting foot-note (i.e not a normative part of the standard, but included for expository purposes) attached to the sentence from 3.7.3.1/2