For POD structure, could new Demo_Class[CONST_NUMBER]() guarantee the dynamically allocated structures are well initialised(i.e. not garbage) in C++11 and afterwards?
It would be appreciated that if somebody shed the light on the detailed rules about the initialization the POD structure array.
There are posts about base types, say new int{} and etc. But there is no direct answer about POD structures.
What more, most posts does not mention C++11 and afterwards at all.
UPDATE:
Thanks to eerorika's for the repid answer.
As per the said answer, which says that[emphasise mine]:
To value-initialize an object of type T means:
otherwise, the object is zero-initialized.
How to fully understand that? The struct\class may has many member variables with different types. Does it mean every member variable would be the object is zero-initialized? For example:
struct Point
{
int x;inty;
};
struct Demo
{
Point pt;
double* ptr;
std::string str;
};.
For POD structure, could new Demo_Class[CONST_NUMBER]() guarantee the dynamically allocated structures are well initialised(i.e. not garbage) in C++11 and afterwards?
It has been guaranteed at least since C++03 when value initialisation was introduced (probably also before through older default initialisation rules). The guarantee hasn't been removed in C++11 nor afterwards.
Standard quotes from latest draft:
[dcl.init.general]
If the initializer is (), the object is value-initialized.
To value-initialize an object of type T means:
if T is a (possibly cv-qualified) class type ([class]), then
if T has either no default constructor ([class.default.ctor]) or a default constructor that is user-provided or deleted, then the object is default-initialized;
otherwise, the object is zero-initialized and the semantic constraints for default-initialization are checked, and if T has a non-trivial default constructor, the object is default-initialized;
if T is an array type, then each element is value-initialized;
otherwise, the object is zero-initialized.
To zero-initialize an object or reference of type T means:
if T is a scalar type ([basic.types.general]), the object is initialized to the value obtained by converting the integer literal 0 (zero) to T;84
if T is a (possibly cv-qualified) non-union class type, its padding bits ([basic.types.general]) are initialized to zero bits and each non-static data member, each non-virtual base class subobject, and, if the object is not a base class subobject, each virtual base class subobject is zero-initialized;
if T is a (possibly cv-qualified) union type, its padding bits ([basic.types.general]) are initialized to zero bits and the object's first non-static named data member is zero-initialized;
if T is an array type, each element is zero-initialized;
if T is a reference type, no initialization is performed.
P.S. Avoid using allocating new. Consider using std::vector instead.
Related
In C++11, I have the following union:
union SomeData
{
std::uint8_t Byte;
std::uint16_t Word;
std::uint32_t DWord;
unsigned char String[128];
};
If I initialize the union thusly;
SomeData data {};
Is it guaranteed that the entire contents of the union will be "zero'd" out? Put another way; is an empty list-initializer of a union functionally equivalent to memset-ing the union to Zero?:
memset(&data, 0, sizeof(data));
In particular, I'm concerned about the string data. I'd like to ensure the entire length of the string contains zeros. It appears to work in my current compiler, but does the language of the spec guarantee this to always be true?
If not: is there a better way to initialize the full length of the union to zero?
No, it is not guaranteed that the entire union will be zeroed out. Only the first declared member of the union, plus any padding, is guaranteed to be zeroed (proof below).
So to ensure the entire memory region of the union object is zeroed, you have these options:
Order the members such that the largest member is first and thus the one zeroed out.
Use std::memset or equivalent functionality. To prevent accidentally forgetting that, you can of course give SomeData a default constructor which will call this.
Quoting C++11:
8.5.4 [dcl.init.list]/3
List-initialization of an object or reference of type T is defined as follows:
If the initializer list has no elements and T is a class type with a default constructor, the object is
value-initialized.
8.5 [dcl.init]/7
To value-initialize an object of type T means:
if T is a (possibly cv-qualified) class type (Clause 9) with a user-provided constructor (12.1), then the
default constructor for T is called (and the initialization is ill-formed if T has no accessible default
constructor);
if T is a (possibly cv-qualified) non-union class type without a user-provided constructor, then the object
is zero-initialized and, if T’s implicitly-declared default constructor is non-trivial, that constructor is
called.
...
otherwise, the object is zero-initialized.
8.5 [dcl.init]/5:
To zero-initialize an object or reference of type T means:
...
if T is a (possibly cv-qualified) union type, the object’s first non-static named data member is zero-initialized
and padding is initialized to zero bits;
From these quotes, you can see that using {} to initialise data will cause the object to be value-initialized (since SomeData is a class type with a default constructor).
Value-initializing a union without a user-provided default constructor (which SomeData is) means zero-initializing it.
Finally, zero-initializing a union means zero-initializing its first non-static named data member.
The entire union will be zeroed out. More exactly the first member of the union will be default initialized and all the remaining bytes in the union will be set to 0 as padding.
References (emphasize mine):
8.5 Initializers [dcl.init]...
5 To zero-initialize an object or reference of type T means:...
— if T is a (possibly cv-qualified) union type, the object’s first non-static named data member is zero initialized
and padding is initialized to zero bits;
That means that the first member of the union (here std::uint8_t Byte;) will be initialized to a 0 and that all other bytes in the union will be set to 0 because they are padding bytes.
But beware. As stated by Angew "padding" is wonderfully underspecified in the standard and a C compiler could interpret that the padding bytes in a union are only the bytes that follow the largest member. I would really find that weird because compatibility changes are specifically documented and previous versions (C) first initialized everything to 0 and next did specific initialization. But a new implementer could not be aware of it...
TL/DR: I really think that the intent of the standard is that all bytes in the union are set to 0 in OP's example, but for a mission critical program, I would certainly add an explicit 0 constructor...
C++2003 8.5/5 says:
To default-initialize an object of type T means:
— if T is a non-POD class type (clause 9), the default constructor for T is called (and the initialization is
ill-formed if T has no accessible default constructor);
— if T is an array type, each element is default-initialized;
— otherwise, the object is zero-initialized.
[Emphasis added.]
The C++2011 standard changed that last item to
— otherwise, no initialization is performed.
This seems like it would be a breaking change for some programs. Was this intentional?
Edit
Here's some code to motivate this question:
class Foo {
public:
Foo() : m_values() {}
int m_values[3];
};
Before C++11, I thought the explicit mention of m_values in the default constructor would default-initialize that array. And since the elements of the array are scalar, I expected that to mean the values were all set to 0.
In C++11, it seems there's no longer a guarantee that this will happen. But maybe, as Mooing Duck pointed out in the comments, perhaps this is no longer a case of default initialization but some other form which preserves the expected behavior. Citations welcome.
The final effects are almost the same. In C++03, the use of default-initialize was restricted to non-POD class type, so the last point never applied. In C++11, the standard simplifies the wording by eliminating the condition with regards to where default-initialization was used, and changes the definition of default-initialization to cover all of the cases in a way to correspond what happened before.
According to cppreference.com (because it uses friendlier language than the standard):
Default initialization is performed in three situations:
3) when a base class or a non-static data member is not mentioned in a
constructor initializer list and that constructor is called.
Value initialization is performed in three situations:
3,7) when a non-static data member or a base class is initialized
using a member initializer with an empty pair of parentheses or braces (since C++11)
Note that the C++11 part belongs with the or braces, not with the entire paragraph.
And:
To value-initialize an object of type T means:
— if T is an array type, then each element is value-initialized;
— otherwise, the object is zero-initialized
So in C++11 default-initialization does not zero-initialize members but value-initialization does.
Strictly speaking, the definition of default-initialize has changed from C++03 to C++11. But one has also to take into account that the situations when an object is _default-initialize_d changed:
§8.5p9 C++03 states:
If no initializer is specified for an object, and the object is of (possibly cv-qualified) non-POD class type (or array thereof), the object shall be default-initialized; if the object is of const-qualified type, the underlying class type shall have a user-declared default constructor. Otherwise, if no initializer is specified for a nonstatic object, the object and its subobjects, if any, have an indeterminate initial value; if the object or any of its subobjects are of const-qualified type, the program is ill-formed.
§8.5p11 C++11 states:
If no initializer is specified for an object, the object is default-initialized; if no initialization is performed, an object with automatic or dynamic storage duration has indeterminate value.
As #JamesKanze already pointed out, default-initialization is performed in C++03 when no initializer for an object of non-POD class type is specified. In C++11 an object (of arbitrary type) is default-initialized if no initializer is specified. Because of this change, the definition of default-initialize had also to be changed in order to be compatible with C++03.
Your example has nothing to do with default-initialization. It has been always the case that an object whose initializer is an empty set of parentheses is value-initialized.
Does the C++ standard guarantee that uninitialized POD members retain their previous value after a placement new?
Or more precisely, will the following assert always be satisfied according to C++11?
#include <cstdlib>
#include <cassert>
struct Foo {
int alpha; // NOTE: Uninitialized
int beta = 0;
};
int main()
{
void* p = std::malloc(sizeof (Foo));
int i = some_random_integer();
static_cast<Foo*>(p)->alpha = i;
new (p) Foo;
assert(static_cast<Foo*>(p)->alpha == i);
}
Is the answer the same for C++03?
Does the C++ standard guarantee that uninitialized POD members retain their previous value after a placement new?
Will the following assert always be satisfied according to C++11?
No.
Uninitialized data members have an indeterminate value, and this is not at all the same as saying that the underlying memory is left alone.
[C++11: 5.3.4/15]: A new-expression that creates an object of type T initializes that object as follows:
If the new-initializer is omitted, the object is default-initialized (8.5); if no initialization is performed, the object has indeterminate value.
Otherwise, the new-initializer is interpreted according to the initialization rules of 8.5 for direct-initialization.
[C++11: 8.5/6]: To default-initialize an object of type T means:
if T is a (possibly cv-qualified) class type (Clause 9), the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor);
if T is an array type, each element is default-initialized;
otherwise, no initialization is performed.
[C++11: 12.1/6]: A default constructor that is defaulted and not defined as deleted is implicitly defined when it is odr-used (3.2) to create an object of its class type (1.8) or when it is explicitly defaulted after its first declaration. The implicitly-defined default constructor performs the set of initializations of the class that would be
performed by a user-written default constructor for that class with no ctor-initializer (12.6.2) and an empty compound-statement.
[C++11: 12.6.2/8]: In a non-delegating constructor, if a given non-static data member or base class is not designated by a mem-initializer-id (including the case where there is no mem-initializer-list because the constructor has no ctor-initializer) and the entity is not a virtual base class of an abstract class (10.4), then
if the entity is a non-static data member that has a brace-or-equal-initializer, the entity is initialized as specified in 8.5;
otherwise, if the entity is a variant member (9.5), no initialization is performed;
otherwise, the entity is default-initialized (8.5).
(NB. the first option in 12.6.2/8 is how your member beta is handled)
[C++11: 8.5/6]: To default-initialize an object of type T means:
if T is a (possibly cv-qualified) class type (Clause 9), the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor);
if T is an array type, each element is default-initialized;
otherwise, no initialization is performed.
[C++11: 8.5/11]: If no initializer is specified for an object, the object is default-initialized; if no initialization is performed, an object with automatic or dynamic storage duration has indeterminate value.
A compiler could choose to zero-out (or otherwise alter) the underlying memory during allocation. For example, Visual Studio in debug mode is known to write recognisable values such as 0xDEADBEEF into memory to aid debugging; in this case, you're likely to see 0xCDCDCDCD which they use to mean "clean memory" (reference).
Will it, in this case? I don't know. I don't think that we can know.
What we do know is that C++ doesn't prohibit it, and I believe that brings us to the conclusion of this answer. :)
Is the answer the same for C++03?
Yes, though through slightly different logic:
[C++03: 5.3.4/15]: A new-expression that creates an object of type T initializes that object as follows:
If the new-initializer is omitted:
If T is a (possibly cv-qualified) non-POD class type (or array thereof), the object is default-initialized (8.5). If T is a const-qualified type, the underlying class type shall have a user-declared default constructor.
Otherwise, the object created has indeterminate value. If T is a const-qualified type, or a (possibly cv-qualified) POD class type (or array thereof) containing (directly or indirectly) a member of const-qualified type, the program is ill-formed;
If the new-initializer is of the form (), the item is value-initialized (8.5);
If the new-initializer is of the form (expression-list) and T is a class type, the appropriate constructor is called, using expression-list as the arguments (8.5);
If the new-initializer is of the form (expression-list) and T is an arithmetic, enumeration, pointer, or pointer-to-member type and expression-list comprises exactly one expression, then the object is initialized to the (possibly converted) value of the expression (8.5);
Otherwise the new-expression is ill-formed.
Now, all that was my strict interpretation of the rules of initialisation.
Speaking practically, I think you're probably correct in seeing a potential conflict with the definition of placement operator new syntax:
[C++11: 18.6.1/3]: Remarks: Intentionally performs no other action.
An example that follows explains that placement new "can be useful for constructing an object at a known address".
However, it doesn't actually talk about the common use of constructing an object at a known address without mungling the values that were already there, but the phrase "performs no other action" does suggest that the intention is that your "indeterminate value" be whatever was in memory previously.
Alternatively, it may simply prohibit the operator itself from taking any action, leaving the allocator free to. It does seem to me that the important point the standard trying to make is that no new memory is allocated.
Regardless, accessing this data invokes undefined behaviour:
[C++11: 4.1/1]: A glvalue (3.10) of a non-function, non-array type T can be converted to a prvalue. If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the glvalue refers is not
an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior. If T is a non-class type, the type of the prvalue is the cv-unqualified version of T. Otherwise, the type of the prvalue is T.
So it doesn't really matter: you couldn't compliantly observe the original value anyway.
C++11 12.6.2/8 "Initializing bases and members" says:
In a non-delegating constructor, if a given non-static data member or
base class is not designated by a mem-initializer-id (including the
case where there is no mem-initializer-list because the constructor
has no ctor-initializer) and the entity is not a virtual base class of
an abstract class (10.4), then
if the entity is a non-static data member that has a brace-or-equal-initializer, the entity is initialized as specified in
8.5;
otherwise, if the entity is a variant member (9.5), no initialization is performed;
otherwise, the entity is default-initialized (8.5).
Default initialization on an int does nothing (8.5/6 "Initializers"):
To default-initialize an object of type T means:
if T is a (possibly cv-qualified) class type (Clause 9), the default constructor for T is called (and the initialization is
ill-formed if T has no accessible default constructor);
if T is an array type, each element is default-initialized;
otherwise, no initialization is performed.
So the member alpha should be left alone.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What do the following phrases mean in C++: zero-, default- and value-initialization?
I am confused about an issue in C++.
When creating an object on the stack using the default constructor, I thought either one of the following two syntax notations would give the same result:
class MyClass { public: int i; }
int main()
{
MyClass a = MyClass();
MyClass b;
}
However, the first syntax initializes the field to zero, whereas the second one leaves the field uninitialized. So my questions are:
Why is this so? I thought fields in C++ were not supposed to be automatically initialized.
Is there any other differences between the two syntaxes?
Do these syntax variations have separate names to distinguish them from each other?
I’m currently using Microsoft Visual C++ 2010 Express.
Thanks!
In the first, you copy-initialize a from a value-initialized instance of MyClass. From the C++03 standard, §8.5/7:
An object whose initializer is an empty set of parentheses, i.e., (), shall be value-initialized.
And from §8.5/5:
To value-initialize an object of type T means:
if T is a class type with a user-declared constructor, then the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor);
if T is a non-union class type without a user-declared constructor, then every non-static data member and base-class component of T is value-initialized;
if T is an array type, then each element is value-initialized;
otherwise, the object is zero-initialized
To zero-initialize an object of type T means:
if T is a scalar type, the object is set to the value of 0 (zero) converted to T;
if T is a non-union class type, each nonstatic data member and each base-class subobject is zero-initialized;
if T is a union type, the object’s first named data member) is zero-initialized;
if T is an array type, each element is zero-initialized;
if T is a reference type, no initialization is performed.
In the second, you declare b in a manner that would cause it to be default-initialized if MyClass were not a POD type -- §8.5/5:
To default-initialize an object of type T means:
if T is a non-POD class type, the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor);
if T is an array type, each element is default-initialized;
otherwise, the object is zero-initialized.
However, because MyClass is a POD type, b is uninitialized -- §8.5/9:
If no initializer is specified for an object, and the object is of (possibly cv-qualified) non-POD class type (or array thereof), the object shall be default-initialized; if the object is of const-qualified type, the underlying class type shall have a user-declared default constructor. Otherwise, if no initializer is specified for a non-static object, the object and its subobjects, if any, have an indeterminate initial value; if the object or any of its subobjects are of const-qualified type, the program is ill-formed.
Basically, this is a (relatively) simple WTF in the language, where primitive types will not be initialized by default. The first syntax explicitly initializes them- the second doesn't. User-defined types will always be initialized, so it's only meaningful if you don't initialize it in the constructor, and it will be an error if you don't call the init functions of UDTs that need them.
UDTs that do not do anything insane should not require the first syntax and it's normal to use the second.
I'm quite certain that arrays of built in types are unitialized, whereas arrays of UDTs are default initialized.
int foo[5]; // will contain junk
Foo foo[5]; // will contain 5 Foo objects that are default initialized
This occurs regardless of whether the array is allocated on the stack or heap.
However, I'm finding it hard to find an authoritative source on this. Bjarne states that:
"Members of arrays and structures are default initialized or not depending on whether the array or structure is static" which doesn't really tell me too much.
I've also tried to find something in the standard, but so far no to no avail.
Does anyone know of an authoritative source to confirm the above?
ISO C++03 is about as authoritative as it gets:
A POD-struct is an aggregate class that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator and no user-defined destructor. Similarly, a POD-union is an aggregate union that has no non-static data members of type non-POD-struct, non-POD-union (or array of such types) or reference, and has no user-defined copy assignment operator and no user-defined destructor. A POD class is a class that is either a POD-struct or a POD-union.
Arithmetic types (3.9.1), enumeration types, pointer types, and pointer to member types (3.9.2), and cv-qualified versions of these types (3.9.3) are collectively called scalar types. Scalar types, POD-struct types, POD-union types (clause 9), arrays of such types and cv-qualified versions of these types (3.9.3) are collectively called POD types.
To zero-initialize an object of type T means:
if T is a scalar type (3.9), the object is set to the value of 0 (zero) converted to T;
if T is a non-union class type, each nonstatic data member and each base-class
subobject is zero-initialized;
if T is a union type, the object’s first named data member is zero-initialized;
if T is an array type, each element is zero-initialized;
if T is a reference type, no initialization is performed.
To default-initialize an object of type T means:
if T is a non-POD class type (clause 9), the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor);
if T is an array type, each element is default-initialized;
otherwise, the object is zero-initialized.
To value-initialize an object of type T means:
if T is a class type (clause 9) with a user-declared constructor (12.1), then the default constructor for T is called (and the initialization is ill-formed if T has no accessible default constructor);
if T is a non-union class type without a user-declared constructor, then every non-static data member and base-class component of T is value-initialized;
if T is an array type, then each element is value-initialized;
otherwise, the object is zero-initialized
Every object of static storage duration shall be zero-initialized at program startup before any other initialization takes place. [Note: in some cases, additional initialization is done later.]
An object whose initializer is an empty set of parentheses, i.e., (), shall be value-initialized.
If no initializer is specified for an object, and the object is of (possibly cv-qualified) non-POD class type (or array thereof), the object shall be default-initialized; if the object is of const-qualified type, the underlying class type shall have a user-declared default constructor. Otherwise, if no initializer is specified for a nonstatic object, the object and its subobjects, if any, have an indeterminate initial value); if the object or any of its subobjects are of const-qualified type, the program is ill-formed.
For your example, int is definitely a POD type (it's an arithmetic type), and therefore a local or field of type int, in the absence of initializer, will have an indeterminate value. For Foo, this depends on how it is defined - roughly speaking, if it doesn't have a constructor, and all its members are of POD types, then it is itself a POD type, and no initialization takes place either. Otherwise, the default constructor is called. Even then, this doesn't mean that members are initialized - rules are recursive, so POD members of non-POD type won't be initialized unless the constructor of that type specifically does that (in its initializer list).
Static variables and fields will in all cases be zero-initialized. Note that this applies to non-PODs too - meaning that a static variable of a class type is guaranteed to have all fields recursively set to (T)0 even before its constructor runs.
A handy trick to default-initialize any aggregate POD type is to use {} in initializer - note that it works with structs as well as arrays:
char s[10] = {}; // all elements default-initialized
Foo foo = {}; // all fields recursively default-initialized
It says in the C++ standard, in 8.5.9:
If no initializer is specified for an
object, and the object is of (possibly
cv-qualified) non-POD class type (or
array thereof), the object shall be
default-initialized; if the object is
of const-qualified type, the
underlying class type shall have a
user-declared default constructor.
Otherwise, if no initializer is
specified for a non-static object, the
object and its subobjects, if any,
have an indeterminate initial value.
"Members of arrays and structures are default initialized or not depending on whether the array or structure is static"
This is authoritative, although it could be clearer:
Arrays and structures declared as static are initialized to zeroes.
Local arrays and structures of built-in types (i.e. types that have no constructors) are not initialized.