Is `new classname' the same as `new classname()' ?

[Andrey Tarasevich]

A does not have a user-defined constructor. The compiler generated one
will be similar to the following:

A::A() {}

That's how the _definition_ of the implicitly declared constructor will
look like, if the compiler actually decides to define it. The implicitly
declared constructor is implicitly defined _if_ _and_ _only_ _if_ it is
used in the program. But the truth is that it is not used in this
program. See below.

In other words, the compiler will not write the constructor like this:

A::A() : m_n() {}

which would be the equivalent of

A::A() : m_n(0) {}

The built-in types are never default constructed.

You are right, they aren't. But that's largely irrelevant in this case.
See below.

Both call the default constructor.

Wrong. Neither calls any constructors.

The first form leaves object uninitialized. No constructors called.

The second form performs default initialization, which is
zero-initialization in this case. This initialization is done
_directly_, it does not involve any constructor calls either.

*pA and *pB are both default constructed, but since the compiler
generated constructor does not initialize the built-in types, m_n
members are both left uninitialized.

Incorrect. 'pB->m_n' is zero. Default initialization took care of that.

None of those compilers are wrong if they don't initialize the
built-in members. They are not required to default-initialize built-in
types.

No, it is a known bug in MSVC++ 6. You are confused because you don't
understand the difference between two separate concepts in C++: the
concept of initialization and the concept of construction.

 

[Pete Becker]

Wrong again. The difference in code generation is extremely hard to
miss. '()' form causes default-initialization, which boils down to
zero-initialization for POD types. Zero-initialization requires
additional code. '()'-less form leaves the object non-initialized, which
means that no initialization-related code is generated.

"Against ignorance the gods themselves struggle in vain."
-- Schiller

 

[Xenos]

There's a substantial difference in code generation. It's not a "fine meaning."

class pod {
public:
int x;
};

new pod; // yields an uninitialized pod (x has indeterminate value).
new pod(); // yields a default initialized pod (x has value 0).

Not according to Stroustrup. There are both undefined.

 

[Xenos]

fine.

There is also a difference in semantics. There is a difference in code
generation, because they mean different things. If you would stop being
arrogant long enough to read what everyone is saying you might learn
something.

I'm arrogant because I don't agree with you? We disagree; whether you are
right or wrong you don't need to be condescending.

 

[Karl Heinz Buchegger]

I'm arrogant because I don't agree with you? We disagree; whether you are
right or wrong you don't need to be condescending.

It's easy to shed some light on it.
We just need to look what the standard has to say about it.
It seems the standard backs us up.

 

[Karl Heinz Buchegger]

Not according to Stroustrup. There are both undefined.

Stroustrup doesn't define the language any longer. The standard does.
And the standard say that they are different. End of story.

 

[Ron Natalie]

I don't think so.
I believe it is left up to the implementation
to determine whether the object is "initialized" or not.

It is NOT up to the implementation. What part of 5.3.4 do you
not understand? It says:

If the new initializer is omitted and the type is POD it is not initialized.
If it is present as a set of empty parens, the object (no matter what it is)
is default initialized.

 

[Ron Natalie]

A does not have a user-defined constructor. The compiler generated one
will be similar to the following:

Please listen carefully. We are talking about POD types.

Default initialization of a POD class type does NOT call an implicit constructor.
Straight from the standard (8.5):

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 storage for the object is zero-initialized.

Note that the constructor is only called for non-POD classes.

 

[Pete Becker]

I'm arrogant because I don't agree with you?

No. You're arrogant because you insist you're right without giving
reasons and without regard to the reasons other people give. You've been
given the citation to the appropriate paragraph in the standard several
times. Read it or shut up.

 

[Xenos]

No. You're arrogant because you insist you're right without giving
reasons and without regard to the reasons other people give. You've been
given the citation to the appropriate paragraph in the standard several
times. Read it or shut up.

And you quoting an obscure line proofs your point?
Again: I don't agree with you; get over it; you know need to be an asshole.
No wonder the STL that comes with VC6 sucks canal water.

 

[Andrey Tarasevich]

Not according to Stroustrup. There are both undefined.
...

Care to provide a reference? A chapter number?

 

[Victor Bazarov]

And you quoting an obscure line proofs your point?
Again: I don't agree with you; get over it; you know need to be an asshole.
No wonder the STL that comes with VC6 sucks canal water.

You don't need to become abusive to try to prove your point (which
you will not be able to, just because you finally showed your true
nature here: arrogant, abusive, unable to listen to what others are
saying, in other words, somebody not worth talking to or arguing with).

And please don't call text from the language standard document
"obscure lines". If you have no brain to understand it doesn't mean
everybody is the same.

It's time for you to crawl back under your rock..

 

[Dave]

And you quoting an obscure line proofs your point?
Again: I don't agree with you; get over it; you know need to be an asshole.
No wonder the STL that comes with VC6 sucks canal water.

I *very* rarely jump into a frey like this because I don't like to
contribute to something that detracts from the main purpose of why we're all
here - discussing C++. But for the first time since I've become involved
with this newsgroup I am going to jump in, even if briefly. This will be my
only post on this topic regardless of your response.

You are out of line. Pete was right - you *did* come across as arrogant
from the start of this thread, and then when someone calls you on your poor
behavior, you resort to name calling, profanity and insults. If you want to
partake of this forum, you need to step your maturity level up a few
notches. Until such time as you do that, I, and I'm sure others, would like
to see you go away.

Now lets get back to the business of discussing C++!