By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,655 Members | 1,005 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,655 IT Pros & Developers. It's quick & easy.

is there a difference between new MyClass; and new MyClass();?

P: n/a
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?

Thanks a lot,
Mario Fratelli.
Jul 22 '05 #1
Share this Question
Share on Google+
32 Replies


P: n/a
Hi,

"Mario Fratelli" <si**@yahoo.com> wrote in message
news:e4**************************@posting.google.c om...
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?
No, but note that:

MyClass p;
and
MyClass p();

does mean something different. The first is creating an object of MyClass.
The second is prototyping a function p() returning MyClass;
Regards, Ron AF Greve

Thanks a lot,
Mario Fratelli.

Jul 22 '05 #2

P: n/a
On 7 Dec 2003 07:27:00 -0800, si**@yahoo.com (Mario Fratelli) wrote:
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?


Yes, they do.

If MyClass is a POD (Plain Old Datastructure), roughly, no virtual
functions and no user-defined constructors, then with a standard-
conforming compiler the first statement creates a new instance without
initializing it, whereas the second gives default-initialization,
which for POD fields is zeroing.

If MyClass is not a POD then the two statements are equivalent.

Jul 22 '05 #3

P: n/a
> MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?


Yes: In the first example, p points at an object that is
default-initialized; in the second case, p points at an object that is
value-initialized.

Default- and value-initialization differ only in the case where MyClass does
not have a user-defined constructor (although it might have data members of
classes that themselves have user-defined constructors). For example:

class MyClass {
public:
std::string name, address;
int postalcode;
};

In both examples above, the initial values of p->name and p->address will be
empty strings. However, in the first case, p->postalcode will be undefined,
whereas in the second case (p = new MyClass()), p->postalcode will be zero.

Note that this behavior is a change from C++98; many compilers do not yet
implement this behavior correctly.
Jul 22 '05 #4

P: n/a
Mario Fratelli wrote in
news:e4**************************@posting.google.c om:
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?


Yes, but only in the case where MyClass *doesn't* have any constructors,
particularly a default ctor.

If so in the second case, "value initialization" (IIRC) is used,
which means all of MyClass members are initialized by "value
initialization", a recursive thing that ultimatly leads to the members
default constructors being called or in the case of inbuilt types
they are 0 initialized.

Note that for this to work all of MyClass 's members must have *no* user
defined constructors *or* they must also have a user defined default
constructor, this rule applies recusivly too.

example (simple):

class MyClass
{
public:

int i;
};

MyClass *initialized = new MyClass();
MyClass *not_initialized = new MyClass;

intialized->i == 0;
not_intialized->i == /* un-initialized (AKA garbage) */;

not_intialized->i should be initialized before it is value is used or
the programme will exhibit undefined behaviour.

HTH.

Rob.
--
http://www.victim-prime.dsl.pipex.com/
Jul 22 '05 #5

P: n/a
"Moonlit" <al******@jupiter.universe> wrote...
"Mario Fratelli" <si**@yahoo.com> wrote in message
news:e4**************************@posting.google.c om...
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?
No


Wrong. Depending on the 'MyClass', there may be a difference.
, but note that:

MyClass p;
and
MyClass p();

does mean something different. The first is creating an object of MyClass.
The second is prototyping a function p() returning MyClass;
Regards, Ron AF Greve

Thanks a lot,
Mario Fratelli.


Jul 22 '05 #6

P: n/a
"Andrew Koenig" <ar*@acm.org> wrote in message news:<P1***********************@bgtnsc04-news.ops.worldnet.att.net>...
Note that this behavior is a change from C++98; many compilers do not yet
implement this behavior correctly.


since the behaviour is differente only when you don't have default
constructors, how can I test the compiler?

Mario Fratelli.
Jul 22 '05 #7

P: n/a
"Mario Fratelli" <si**@yahoo.com> wrote...
"Andrew Koenig" <ar*@acm.org> wrote in message

news:<P1***********************@bgtnsc04-news.ops.worldnet.att.net>...
Note that this behavior is a change from C++98; many compilers do not yet implement this behavior correctly.


since the behaviour is differente only when you don't have default
constructors, how can I test the compiler?


It's rather difficult. It would involve using an uninitialised values
of POD, which in itself can cause undefined behaviour.

But try this:

struct A {
int a;
};
#include <iostream>
int main() {
char *storage = new char[sizeof(A)];
for (int i = 0; i < sizeof(A); ++i)
storage[i] = 1;
A *pa = new (storage) A;
std::cout << pa->a << std::endl;
pa = new (storage) A();
std::cout << pa->a << std::endl;
delete[] storage;
}

If you get two zeroes as output, your compiler value-initialises
PODs when it is supposed to leave it uninitialised.

Make sure to build a release version as debug ones often initialise
values to 0 without your specific actions.

Victor

P.S. I tested this with VC++ v6sp5 (and it failed to default-
initialise the 'A' the second time) and with Intel C++ v4.5, which
gave the expected output:

16843009
0

(well, the first value is not something specifically expected, just
so it is not 0)
Jul 22 '05 #8

P: n/a

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:rcJAb.457899$Fm2.450221@attbi_s04...
"Moonlit" <al******@jupiter.universe> wrote...
"Mario Fratelli" <si**@yahoo.com> wrote in message
news:e4**************************@posting.google.c om...
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?
No


Wrong. Depending on the 'MyClass', there may be a difference.


Oops, your right.

Sorry for my bad advice :-(
, but note that:

MyClass p;
and
MyClass p();

does mean something different. The first is creating an object of MyClass. The second is prototyping a function p() returning MyClass;
Regards, Ron AF Greve

Thanks a lot,
Mario Fratelli.



Jul 22 '05 #9

P: n/a
On Sun, 07 Dec 2003 15:53:16 GMT, al***@start.no (Alf P. Steinbach) wrote:
On 7 Dec 2003 07:27:00 -0800, si**@yahoo.com (Mario Fratelli) wrote:
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?


Yes, they do.

If MyClass is a POD (Plain Old Datastructure), roughly, no virtual
functions and no user-defined constructors, then with a standard-
conforming compiler the first statement creates a new instance without
initializing it, whereas the second gives default-initialization,
which for POD fields is zeroing.

If MyClass is not a POD then the two statements are equivalent.


Among 112 spams and Swen viruses a mail from Andrew Koenig, almost deleted
in my spam-removal frenzy, pointing my attention to that last sentence.

Ooops.

And thanks, Andrew.

While the sentence holds wrt. C++ 1998, the C++ 2003 standard revision changed
the rules slightly. The relevant paragraps are 5.3.4/15, which defines the
effect with and without "()", and 8.5/5, which defines the terms
"zero-initialization", "default-initialization" and, in C++ 2003, the new term
"value-initialization". In C++ 2003, the 'new' statement with "()" gives
value-initialization, which is not necessarily equivalent to
default-initialization: roughly, value-initialization only calls the default
constructor if it is a user-defined constructor, and otherwise gives
zero-initialization. So "()" can no longer be read as "call constructor".

The upshot is that in C++ 2003 you're guaranteed zero-initialization in at
least one more case than in C++ 1998, namely in the case of "new T()" where T
is non-POD and does not have a user-defined constructor.

This language keeps getting subtler and subtler.

Jul 22 '05 #10

P: n/a
> The upshot is that in C++ 2003 you're guaranteed zero-initialization in at
least one more case than in C++ 1998, namely in the case of "new T()" where T is non-POD and does not have a user-defined constructor.

This language keeps getting subtler and subtler.


Actually, the purpose of this change (of which I was the instigator, which
is why I know about it), is to *remove* a subtlety as seen from the user's
viewpoint. Consider:

struct Person {
NameType name;
long id;
};

What is the value of Person().id? In C++98, it is not possible to answer
that question without examining the definition of NameType. In C++2003, the
answer is always 0.
Jul 22 '05 #11

P: n/a

"Andrew Koenig" <ar*@acm.org> wrote in message
news:P1***********************@bgtnsc04-news.ops.worldnet.att.net...
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?


Yes: In the first example, p points at an object that is
default-initialized; in the second case, p points at an object that is
value-initialized.


Presumably, value initialization is preferred?
Jul 22 '05 #12

P: n/a

"Andrew Koenig" <ar*@acm.org> wrote in message news:P1***********************@bgtnsc04-news.ops.worldnet.att.net...
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?


Yes: In the first example, p points at an object that is
default-initialized; in the second case, p points at an object that is
value-initialized.

Default- and value-initialization differ only in the case where MyClass does
not have a user-defined constructor (although it might have data members of
classes that themselves have user-defined constructors). For example:

Despite the changes in the TC1 languatge, the first is still NOT default initialization
for POD's. For POD's NO initialization is done.
Jul 22 '05 #13

P: n/a

"Andrew Koenig" <ar*@acm.org> wrote in message
news:Kc***********************@bgtnsc04-news.ops.worldnet.att.net...
The upshot is that in C++ 2003 you're guaranteed zero-initialization in at least one more case than in C++ 1998, namely in the case of "new T()" where T
is non-POD and does not have a user-defined constructor.

This language keeps getting subtler and subtler.


Actually, the purpose of this change (of which I was the instigator, which
is why I know about it), is to *remove* a subtlety as seen from the user's
viewpoint. Consider:

struct Person {
NameType name;
long id;
};

What is the value of Person().id? In C++98, it is not possible to answer
that question without examining the definition of NameType. In C++2003,

the answer is always 0.


In C++98, why is it that the value of Person().id depends on the definition
of NameType? I would have thought that id would be uninitialized in C++98
and would have been zero-initialized in C++2003, regardless of the
definition of NameType, but I am clearly mistaken...

Having followed the whole thread, I'm still a bit confused. I wonder if
someone might post a concise but comprehensive summary of behavior under
both C++98 and C++2003 as well as definitions of relevant terms such as
default-initialize, value-initialize, zero-initialize, etc...

Also, of the more prevelant compilers, which currently implement C++98
semantics and which currently implement C++2003 semantics?
Jul 22 '05 #14

P: n/a
Ron Natalie wrote:
Andrew Koenig wrote:
MyClass *p = new MyClass;
MyClass *p = new MyClass();

do they mean something different?


Yes: In the first example, p points at an object
that is default-initialized; in the second case,
p points at an object that is value-initialized.

Default- and value-initialization differ only in the case
where MyClass does not have a user-defined constructor
(although it might have data members of classes
that themselves have user-defined constructors).


Despite the changes in the TC1 language,
the first is still NOT default initialization for POD's.
For PODs NO initialization is done.


I believe that it is up to the compiler developer
to decide whether PODs are initialized or not.

Jul 22 '05 #15

P: n/a
Dave wrote:
> The upshot is that in C++ 2003 you're guaranteed zero-initialization in at > least one more case than in C++ 1998, namely in the case of "new T()" where T
> is non-POD and does not have a user-defined constructor.
>
> This language keeps getting subtler and subtler.


Actually, the purpose of this change (of which I was the instigator, which
is why I know about it), is to *remove* a subtlety as seen from the user's
viewpoint. Consider:

struct Person {
NameType name;
long id;
};

What is the value of Person().id? In C++98, it is not possible to answer
that question without examining the definition of NameType. In C++2003,

the
answer is always 0.


In C++98, why is it that the value of Person().id depends on the definition
of NameType?


Because, once again, the value of 'Person().id' depends on whether
'Person' is POD or non-POD. And there's no way to answer this question
until you know what 'NameType' is. If 'NameType' is an alias for
'std::string', then 'Person' is not POD and the value of 'Person().id'
is unspecified. If 'NameType' is an alias for 'int', then 'Person' is
POD and the value of 'Person().id' is 0.
I would have thought that id would be uninitialized in C++98
It's already been said many times here, that in C++98 '()' initializer
causes default-initialization, which means zero-initialization for POS
types. That's why for POD types 'Person().id' is 0 in C++98
and would have been zero-initialized in C++2003, regardless of the
definition of NameType, but I am clearly mistaken...
Yes, it will be zero-initialized in C++2003
Having followed the whole thread, I'm still a bit confused. I wonder if
someone might post a concise but comprehensive summary of behavior under
both C++98 and C++2003 as well as definitions of relevant terms such as
default-initialize, value-initialize, zero-initialize, etc...
If you don't have a copy of the C++98 standard, you can simply download
a copy of draft C++98 standard for free and find all this information
there. The same applies to TC1. Or simply google the net for
value-initialization.
Also, of the more prevelant compilers, which currently implement C++98
semantics and which currently implement C++2003 semantics?


--
Best regards,
Andrey Tarasevich

Jul 22 '05 #16

P: n/a
> Despite the changes in the TC1 languatge, the first is still NOT default
initialization
for POD's. For POD's NO initialization is done.


Right you are. Sorry about that.
Jul 22 '05 #17

P: n/a
> In C++98, why is it that the value of Person().id depends on the
definition
of NameType? I would have thought that id would be uninitialized in C++98
and would have been zero-initialized in C++2003, regardless of the
definition of NameType, but I am clearly mistaken...


Suppose I defined NameType this way:

typedef int NameType;

Then my Person type is a POD, which would get zero-initialized in C++98.
Jul 22 '05 #18

P: n/a
Andrew Koenig wrote:
MyClass *p = new MyClass;
MyClass *p = new MyClass();

Do they mean something different?
Yes: In the first example,
p points at an object that is default-initialized;
in the second case,
p points at an object that is value-initialized.


Where did this terminology come from?
(Are you making this up?)
Default- and value-initialization differ only in the case
where MyClass does not have a user-defined constructor
(although it might have data members of classes
that themselves have user-defined constructors). For example:

class MyClass {
public:
std::string name, address;
int postalcode;
};
\begin{nit}
Shame on you!
This example would have served its purpose just as well
if you had made the data members private.
\end{nit}
In both examples above,
the initial values of p->name and p->address will be empty strings.
However, in the first case,
p->postalcode will be undefined,
whereas in the second case
(p = new MyClass()), p->postalcode will be zero.

Note that this behavior is a change from C++98;
many compilers do not yet implement this behavior correctly.


What changes this behavior? Some new ANSI/ISO C++ standard?
If so, please cite and quote the relevant passage.

Jul 22 '05 #19

P: n/a

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:3F**************@jpl.nasa.gov...
Despite the changes in the TC1 language,
the first is still NOT default initialization for POD's.
For PODs NO initialization is done.


I believe that it is up to the compiler developer
to decide whether PODs are initialized or not.


Correct, it is not DEFAULT INITIALIZATION. Default initialization
is still zero initialization for POD's. TC1 doesn't change that.
The value, as far as the standard is concerned is indeterminate.
If the compiler wants to make it determinate, that's fine, but it's
not something a programmer can rely on.
Jul 22 '05 #20

P: n/a

"Dave" <be***********@yahoo.com> wrote in message news:vt************@news.supernews.com...
Having followed the whole thread, I'm still a bit confused. I wonder if
someone might post a concise but comprehensive summary of behavior under
both C++98 and C++2003 as well as definitions of relevant terms such as
default-initialize, value-initialize, zero-initialize, etc...

Ok, here's the poop on initialization.

This part is the same before and after TC1.

There is a concept called default initialization. Default initialization means for, non-POD types
to run the constructor. For POD types, it means zero initialization. However, the confusing issue
is that POD's are sometimes not default initialized. For example, default initialization is skipped
with allocation via new (without the parens) and also for auto (local non-static) variables. This
I believe is a major defect in the language, but you'll never convince the bean counters that
consistant behavior is worth making people clean up their old code if they really want to create
an uninitialized variable.

What TC1 added is value initialization. Value initialization was added to the new() case and
what it says is that if the non-POD class has no default constructor, then any pod's would be
zero initialized where they wouldn't have been in the default initialization case.

The item it is fixing is this:

struct X {
SomeType st;
PodType pod;
};

new X(); in pre-TC1, if SomeType was not POD, then X would not be POD, and hence pod
would not be initialized (because X's implicitly generated constructor doesn't do it). In post TC1,
the value initialization is applied to st and pod when X is value initialized. st's implicit constructor
runs and pod gets zero'd.
Jul 22 '05 #21

P: n/a

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:3F**************@jpl.nasa.gov...
Where did this terminology come from?
(Are you making this up?)
It was introduced in TC1. It's part of the language now.

What changes this behavior? Some new ANSI/ISO C++ standard?
If so, please cite and quote the relevant passage.


The new 5.3.4 of TC1 changes the behavior of new () from default to value initialization.
The new 8.5 defines value initialization (right after default initialization) to say that if
there is no default constructor (even on POD types), then each base or member is
value initialized in turn (which means zero initialized for pods).
Jul 22 '05 #22

P: n/a
E. Robert Tisdale wrote:
...
Despite the changes in the TC1 language,
the first is still NOT default initialization for POD's.
For PODs NO initialization is done.


I believe that it is up to the compiler developer
to decide whether PODs are initialized or not.
...


Of course, it is! The standard says that in this case POD contains
_indeterminate_ _value(s)_, which means that it might contain virtually
anything. The compiler developer might decide to initialize it with
zeros. Or he might decide to put his girlfriend's initials and today's
date into each integral component of POD. That, of course, will be
nothing more than waste of time and code, since the user code will
re-initialize every "non-initialized" POD anyway.

--
Best regards,
Andrey Tarasevich

Jul 22 '05 #23

P: n/a

"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..

"Dave" <be***********@yahoo.com> wrote in message news:vt************@news.supernews.com...
Having followed the whole thread, I'm still a bit confused. I wonder if
someone might post a concise but comprehensive summary of behavior under
both C++98 and C++2003 as well as definitions of relevant terms such as
default-initialize, value-initialize, zero-initialize, etc...
Ok, here's the poop on initialization.

This part is the same before and after TC1.

There is a concept called default initialization. Default initialization

means for, non-POD types to run the constructor. For POD types, it means zero initialization. However, the confusing issue is that POD's are sometimes not default initialized. For example, default initialization is skipped with allocation via new (without the parens) and also for auto (local non-static) variables. This I believe is a major defect in the language, but you'll never convince the bean counters that consistant behavior is worth making people clean up their old code if they really want to create an uninitialized variable.

What TC1 added is value initialization. Value initialization was added to the new() case and what it says is that if the non-POD class has no default constructor, then any pod's would be zero initialized where they wouldn't have been in the default initialization case.
The item it is fixing is this:

struct X {
SomeType st;
PodType pod;
};

new X(); in pre-TC1, if SomeType was not POD, then X would not be POD, and hence pod would not be initialized (because X's implicitly generated constructor doesn't do it). In post TC1, the value initialization is applied to st and pod when X is value initialized. st's implicit constructor runs and pod gets zero'd.


Ahhh, there it is! Thank you! This helps tremendously and is well-written!
Jul 22 '05 #24

P: n/a
> >> MyClass *p = new MyClass;
MyClass *p = new MyClass();

Do they mean something different?
Yes: In the first example,
p points at an object that is default-initialized;
in the second case,
p points at an object that is value-initialized.


Where did this terminology come from?


The C++ standard.
(Are you making this up?)
Yes, but only in the sense that I originated the proposal that resulted in
this terminology becoming part of the standard.
Default- and value-initialization differ only in the case
where MyClass does not have a user-defined constructor
(although it might have data members of classes
that themselves have user-defined constructors). For example:

class MyClass {
public:
std::string name, address;
int postalcode;
};


\begin{nit}
Shame on you!
This example would have served its purpose just as well
if you had made the data members private.
\end{nit}


I disagree. If I had made the data members private, p->postalcode (which
appears below) would be an access violation.
In both examples above,
the initial values of p->name and p->address will be empty strings.
However, in the first case,
p->postalcode will be undefined,
whereas in the second case
(p = new MyClass()), p->postalcode will be zero.

Note that this behavior is a change from C++98;
many compilers do not yet implement this behavior correctly.

What changes this behavior? Some new ANSI/ISO C++ standard?
Yes -- the C++ 2003 standard.
If so, please cite and quote the relevant passage.


http://std.dkuug.dk/JTC1/SC22/WG21/d...g_defects.html

See issues 178 and 35.
Jul 22 '05 #25

P: n/a
Ron Natalie wrote:
Despite the changes in the TC1 languatge, the first is still NOT default initialization
for POD's. For POD's NO initialization is done.


Try this:

int * p = new int();
assert( 0 == *p );

--
Phlip
Jul 22 '05 #26

P: n/a
Andrey Tarasevich wrote:
E. Robert Tisdale wrote:
I believe that it is up to the compiler developer
to decide whether PODs are initialized or not.


Of course, it is! The standard says that, in this case,
POD contains _indeterminate_ _value(s)_
which means that it might contain virtually anything.
The compiler developer might decide to initialize it with anything.
Or 'he might decide to put his girlfriend's initials and today's date
into each integral component of POD.
That, of course,
will be nothing more than waste of time and code, since
the user code will re-initialize every "non-initialized" POD anyway.


No. It isn't a waste of time or code.
The compiler developer might provide an option
which initializes undefined variables with values
(INT_MIN, UINT_MAX, a signaling NaN, etc.)
that are likely to result in noticeable run-time errors
if the variables are not initialized explicitly before use.
This option would help programmers detect bugs
so they could fix them before recompiling
with the option turned off.

Jul 22 '05 #27

P: n/a
Andrew Koenig wrote:
MyClass *p = new MyClass;
MyClass *p = new MyClass();

Do they mean something different?

Yes: In the first example,
p points at an object that is default-initialized;
in the second case,
p points at an object that is value-initialized.


Where did this terminology come from?

The C++ standard.

(Are you making this up?)

Yes, but only in the sense that I originated the proposal that resulted in
this terminology becoming part of the standard.

Default- and value-initialization differ only in the case
where MyClass does not have a user-defined constructor
(although it might have data members of classes
that themselves have user-defined constructors). For example:

class MyClass {
public:
std::string name, address;
int postalcode;
};


\begin{nit}
Shame on you!
This example would have served its purpose just as well
if you had made the data members private.
\end{nit}

I disagree. If I had made the data members private, p->postalcode (which
appears below) would be an access violation.

In both examples above,
the initial values of p->name and p->address will be empty strings.
However, in the first case,
p->postalcode will be undefined,
whereas in the second case
(p = new MyClass()), p->postalcode will be zero.

Note that this behavior is a change from C++98;
many compilers do not yet implement this behavior correctly.

What changes this behavior? Some new ANSI/ISO C++ standard?

Yes -- the C++ 2003 standard.

If so, please cite and quote the relevant passage.

http://std.dkuug.dk/JTC1/SC22/WG21/d...g_defects.html

See issues 178 and 35.


Thanks Andrew

Jul 22 '05 #28

P: n/a
If you had top-posted, you could have had 2 no-nos in one post :-)

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:3F************@jpl.nasa.gov...
Andrew Koenig wrote:
>MyClass *p = new MyClass;
>MyClass *p = new MyClass();
>
>Do they mean something different?

Yes: In the first example,
p points at an object that is default-initialized;
in the second case,
p points at an object that is value-initialized.

Where did this terminology come from?

The C++ standard.

(Are you making this up?)

Yes, but only in the sense that I originated the proposal that resulted in this terminology becoming part of the standard.

Default- and value-initialization differ only in the case
where MyClass does not have a user-defined constructor
(although it might have data members of classes
that themselves have user-defined constructors). For example:

class MyClass {
public:
std::string name, address;
int postalcode;
};

\begin{nit}
Shame on you!
This example would have served its purpose just as well
if you had made the data members private.
\end{nit}

I disagree. If I had made the data members private, p->postalcode (which appears below) would be an access violation.

In both examples above,
the initial values of p->name and p->address will be empty strings.
However, in the first case,
p->postalcode will be undefined,
whereas in the second case
(p = new MyClass()), p->postalcode will be zero.

Note that this behavior is a change from C++98;
many compilers do not yet implement this behavior correctly.

What changes this behavior? Some new ANSI/ISO C++ standard?

Yes -- the C++ 2003 standard.

If so, please cite and quote the relevant passage.

http://std.dkuug.dk/JTC1/SC22/WG21/d...g_defects.html

See issues 178 and 35.


Thanks Andrew

Jul 22 '05 #29

P: n/a
Phlip wrote:
Despite the changes in the TC1 languatge, the first is still NOT default initialization
for POD's. For POD's NO initialization is done.


Try this:

int * p = new int();
assert( 0 == *p );
...


You are not following the discussion. Ron clearly stated that he is
talking about the _first_ case

MyClass *p = new MyClass;

No initializer is provided. No initialization is performed.

Now, would you please explain, what is is the relevance of your example
(which uses explicit '()' initializer) to this branch of the discussion?

--
Best regards,
Andrey Tarasevich

Jul 22 '05 #30

P: n/a
jeffc wrote:

If you had top-posted, you could have had 2 no-nos in one post :-)

Pretty much any post by Trollsdale is a no-no.


Brian Rodenborn
Jul 22 '05 #31

P: n/a

"Phlip" <ph*******@yahoo.com> wrote in message news:63*************************@posting.google.co m...
Ron Natalie wrote:
Despite the changes in the TC1 languatge, the first is still NOT default initialization
for POD's. For POD's NO initialization is done.


Try this:

int * p = new int();
assert( 0 == *p );

That's not the case I was talking about. I said the first case (in the original posters
program). IT does not have () after the type name.
Jul 22 '05 #32

P: n/a
Ron Natalie wrote:
Try this:

int * p = new int();
assert( 0 == *p );

That's not the case I was talking about. I said the first case (in the original posters
program). IT does not have () after the type name.


I didn't read that far back, so I wrote ambiguously.

Even this works, but it looks freaky!

assert( 0 == int() );

--
Phlip
Jul 22 '05 #33

This discussion thread is closed

Replies have been disabled for this discussion.