Operator new and POD-struct

[Ivan A. Kosarev]

Hello,

Consider the fragment:

class C { // A POD-struct
public:
C() { puts("C::C()"); }
};

int main()
{
new C; // new-initializer is omitted
}

C++98 says (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 cvqualified) non-POD class type (or array
thereof)...
- Otherwise, the object created has indeterminate value...

And then (9 #4):
A POD-struct is an aggregate class that has no non-static data members of
type pointer to member, 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.

However, I've found that both MSVC 7.1 and EDG C front 3.6 generate a
constructor call at the new operator invocation. Can anybody explain why
they don't leave an object created unitialized, as written?

Thank you.

--
Unicals Group -- Development Tools for OEMs
http://www.unicals.com

[Gianni Mariani]

Ivan A. Kosarev wrote:

Hello,

Consider the fragment:

class C { // A POD-struct
public:
C() { puts("C::C()"); }
};

This is not a POD struct. If it has any user defined methods, it's not
POD type.

[Axter]

Ivan A. Kosarev wrote:

Hello,

Consider the fragment:

class C { // A POD-struct
public:
C() { puts("C::C()"); }
};

int main()
{
new C; // new-initializer is omitted
}

C++98 says (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 cvqualified) non-POD class type (or array
thereof)...
- Otherwise, the object created has indeterminate value...

And then (9 #4):
A POD-struct is an aggregate class that has no non-static data members of
type pointer to member, 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.

However, I've found that both MSVC 7.1 and EDG C front 3.6 generate a
constructor call at the new operator invocation. Can anybody explain why
they don't leave an object created unitialized, as written?

Thank you.

You need to look at what an aggregate class is defined as.
If you read section 8.5.1, it states the following:
-------------------------------------------------------------------------------------
An aggregate is an array or a class with no user declared constructors,
............
-------------------------------------------------------------------------------------

Your class has a constructor, so it's not an aggregate class, and
doesn't fit the criteria for a POD type as defined in the standard.

[Victor Bazarov]

Ivan A. Kosarev wrote:

Consider the fragment:

class C { // A POD-struct
It's not POD-struct. Please read the definition of POD-struct more
carefully. A POD-struct is _an_aggregate_ class. The definition of
an aggregate is in 8.5.1/1 and it requires no user-defined c-tor,
explicitly.
public:
C() { puts("C::C()"); }
};

int main()
{
new C; // new-initializer is omitted
}

C++98 says (5.3.4 #15):
It's time you get C++03 (although it didn't change much t
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 cvqualified) non-POD class type (or array
thereof)...
- Otherwise, the object created has indeterminate value...

And then (9 #4):
A POD-struct is an aggregate class that has no non-static data members of ^^^^^^^^^ type pointer to member, 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.

However, I've found that both MSVC 7.1 and EDG C front 3.6 generate a
constructor call at the new operator invocation. Can anybody explain why
they don't leave an object created unitialized, as written?

They are correct. Your 'C' is a non-POD class.

V

[Ron Natalie]

Gianni Mariani wrote:

Ivan A. Kosarev wrote:

Hello,

Consider the fragment:

class C { // A POD-struct
public:
C() { puts("C::C()"); }
};

This is not a POD struct. If it has any user defined methods, it's not
POD type.

Actually, it's the presence of a user-defined CONSTRUCTOR that makes it
not pod. Regular method functions are OK in PODS.

[Gianni Mariani]

Ron Natalie wrote:

Gianni Mariani wrote:

Ivan A. Kosarev wrote:

Hello,

Consider the fragment:

class C { // A POD-struct
public:
C() { puts("C::C()"); }
};

This is not a POD struct. If it has any user defined methods, it's
not POD type.

Actually, it's the presence of a user-defined CONSTRUCTOR that makes it
not pod. Regular method functions are OK in PODS.

I didn't know that. Now I do. Cool - thanks. Now I can sleep better that
all that code I wrote that violated this rule is actually standard.

[Michiel.Salters]

Ivan A. Kosarev wrote:

Hello,

Consider the fragment:

class C { // A POD-struct
public:
C() { puts("C::C()"); }
};

int main()
{
new C; // new-initializer is omitted
}
However, I've found that both MSVC 7.1 and EDG C front 3.6 generate a
constructor call at the new operator invocation. Can anybody explain why
they don't leave an object created unitialized, as written?

As noted, it's not a POD, so they have to call C::C( ).

However, leaving an object uninitialized is never mandatory for
compilers.
You simply can't detect whether an object is uninitialized. It the
standard
says the object is uninitialized, any attempt to read it is Undefined
Behavior.
So, if the read always returns 0, then that's just one special case of
UB. If
it always returns 0 except if your boss looks, it's another allowed
case.

Regards,
Michiel Salters