467,886 Members | 1,821 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,886 developers. It's quick & easy.

Operator new and POD-struct

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
Dec 1 '05 #1
  • viewed: 2043
Share:
6 Replies
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.
Dec 1 '05 #2

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.

Dec 1 '05 #3
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
Dec 1 '05 #4
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.
Dec 1 '05 #5
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.

Dec 2 '05 #6
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

Dec 2 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Giorgos P. | last post: by
reply views Thread by Martin Magnusson | last post: by
13 posts views Thread by Alex Vinokur | last post: by
16 posts views Thread by Joseph Paterson | last post: by
32 posts views Thread by Abhishek Srivastava | last post: by
13 posts views Thread by martyn_dobson | last post: by
19 posts views Thread by C++Liliput | last post: by
reply views Thread by MrMoon | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.