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

[Hongzheng Wang]

Hi,
I saw some codes use `new classname' to get a point to
a new object of classname, but some codes, instead, use
`new classname()'.
Is these two usage equivalent?

Thank you.

--
Hongzheng Wang
Department of Electronics Engineering
Tsinghua University
wa******@mails.tsinghua.edu.cn

[Victor Bazarov]

"Hongzheng Wang" <wa******@mails.tsinghua.edu.cn> wrote...

I saw some codes use `new classname' to get a point to
a new object of classname, but some codes, instead, use
`new classname()'.
Is these two usage equivalent?

For POD they are not. The former leaves it uninitialised,
the latter makes it default-initialised, IIRC.

Victor

[Xenos]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:akyzb.416658$Fm2.425058@attbi_s04...

"Hongzheng Wang" <wa******@mails.tsinghua.edu.cn> wrote...

I saw some codes use `new classname' to get a point to
a new object of classname, but some codes, instead, use
`new classname()'.
Is these two usage equivalent?

For POD they are not. The former leaves it uninitialised,
the latter makes it default-initialised, IIRC.

Victor

No, both would cause default initialization. You cannot create an
uninitialized class object without a kludge.

DrX

[Karl Heinz Buchegger]

Xenos wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:akyzb.416658$Fm2.425058@attbi_s04...

"Hongzheng Wang" <wa******@mails.tsinghua.edu.cn> wrote...

I saw some codes use `new classname' to get a point to
a new object of classname, but some codes, instead, use
`new classname()'.
Is these two usage equivalent?
For POD they are not. The former leaves it uninitialised,
the latter makes it default-initialised, IIRC.

Victor

No, both would cause default initialization.

They don't
You cannot create an
uninitialized class object without a kludge.

you can:

#include <iostream>
using namespace std;

class A
{
public:
int m_n;
};

int main()
{
A* pA = new A;
A* pB = new A();
Here pA->m_n is left uninitialized while
pB->m_n should be default initialized.

VC++ 6.0 however gets this wrong and I suspect that
most compiler get this wrong. In other words: don't
depend on it.

Oh, by the way: Yes in the above, class A is a POD.

--
Karl Heinz Buchegger
kb******@gascad.at

[Xenos]

"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:3F***************@gascad.at...

you can:

#include <iostream>
using namespace std;

class A
{
public:
int m_n;
};

int main()
{
A* pA = new A;
A* pB = new A();
Here pA->m_n is left uninitialized while
pB->m_n should be default initialized.

VC++ 6.0 however gets this wrong and I suspect that
most compiler get this wrong. In other words: don't
depend on it.

Oh, by the way: Yes in the above, class A is a POD.

I don't care what you call it, both uses of the new operator will call the
default constructor.

[Victor Bazarov]

"Xenos" <do**********@spamhate.com> wrote...

"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:3F***************@gascad.at...

you can:

#include <iostream>
using namespace std;

class A
{
public:
int m_n;
};

int main()
{
A* pA = new A;
A* pB = new A();
Here pA->m_n is left uninitialized while
pB->m_n should be default initialized.

VC++ 6.0 however gets this wrong and I suspect that
most compiler get this wrong. In other words: don't
depend on it.

Oh, by the way: Yes in the above, class A is a POD.

I don't care what you call it, both uses of the new operator will call the
default constructor.

There is no default constructor for an int.

Now, are these two forms the same

int a;

and

int a = int();

? If not, what's the difference? What value does 'a' get in each
case?

And if you don't know that POD is (or what it stands for), perhaps
you need to learn first, then begin arguing...

Victor

[Victor Bazarov]

"Victor Bazarov" <v.********@comAcast.net> wrote...

"Xenos" <do**********@spamhate.com> wrote...

"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:3F***************@gascad.at...

you can:

#include <iostream>
using namespace std;

class A
{
public:
int m_n;
};

int main()
{
A* pA = new A;
A* pB = new A();
Here pA->m_n is left uninitialized while
pB->m_n should be default initialized.

VC++ 6.0 however gets this wrong and I suspect that
most compiler get this wrong. In other words: don't
depend on it.

Oh, by the way: Yes in the above, class A is a POD.
I don't care what you call it, both uses of the new operator will call the default constructor.

Oh, I meant to refer you to 5.3.4/15, but you wouldn't know where
to look, would you?
There is no default constructor for an int.

Now, are these two forms the same

int a;

and

int a = int();

? If not, what's the difference? What value does 'a' get in each
case?

And if you don't know that POD is (or what it stands for), perhaps
you need to learn first, then begin arguing...

[Xenos]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:jMKzb.226707$Dw6.803084@attbi_s02...

"Xenos" <do**********@spamhate.com> wrote...

"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:3F***************@gascad.at...

you can:

#include <iostream>
using namespace std;

class A
{
public:
int m_n;
};

int main()
{
A* pA = new A;
A* pB = new A();
Here pA->m_n is left uninitialized while
pB->m_n should be default initialized.

VC++ 6.0 however gets this wrong and I suspect that
most compiler get this wrong. In other words: don't
depend on it.

Oh, by the way: Yes in the above, class A is a POD.

I don't care what you call it, both uses of the new operator will call the default constructor.

There is no default constructor for an int.

Now, are these two forms the same

int a;

and

int a = int();

? If not, what's the difference? What value does 'a' get in each
case?

And if you don't know that POD is (or what it stands for), perhaps
you need to learn first, then begin arguing...

Victor

If you refer back to my statement, I was talking about classes, not
primative types. The OP was asking about a struct, not an int.

And if you can't even read someone's statement, maybe you should learn
English before arguing.

DrX

[Pete Becker]

Xenos wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:jMKzb.226707$Dw6.803084@attbi_s02...

"Xenos" <do**********@spamhate.com> wrote...

"Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
news:3F***************@gascad.at...

> you can:
>
> #include <iostream>
> using namespace std;
>
> class A
> {
> public:
> int m_n;
> };
>
> int main()
> {
> A* pA = new A;
> A* pB = new A();
>
>
> Here pA->m_n is left uninitialized while
> pB->m_n should be default initialized.
>
> VC++ 6.0 however gets this wrong and I suspect that
> most compiler get this wrong. In other words: don't
> depend on it.
>
> Oh, by the way: Yes in the above, class A is a POD.
>
I don't care what you call it, both uses of the new operator will call the default constructor.

There is no default constructor for an int.

Now, are these two forms the same

int a;

and

int a = int();

? If not, what's the difference? What value does 'a' get in each
case?

And if you don't know that POD is (or what it stands for), perhaps
you need to learn first, then begin arguing...

Victor

If you refer back to my statement, I was talking about classes, not
primative types. The OP was asking about a struct, not an int.

What Victor said is absolutely correct: the two forms are different for
a POD. And a struct or a class can be a POD.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Xenos]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Xenos wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:jMKzb.226707$Dw6.803084@attbi_s02...

"Xenos" <do**********@spamhate.com> wrote...
>
> "Karl Heinz Buchegger" <kb******@gascad.at> wrote in message
> news:3F***************@gascad.at...
>
> > you can:
> >
> > #include <iostream>
> > using namespace std;
> >
> > class A
> > {
> > public:
> > int m_n;
> > };
> >
> > int main()
> > {
> > A* pA = new A;
> > A* pB = new A();
> >
> >
> > Here pA->m_n is left uninitialized while
> > pB->m_n should be default initialized.
> >
> > VC++ 6.0 however gets this wrong and I suspect that
> > most compiler get this wrong. In other words: don't
> > depend on it.
> >
> > Oh, by the way: Yes in the above, class A is a POD.
> >
> I don't care what you call it, both uses of the new operator will

call the

> default constructor.

There is no default constructor for an int.

Now, are these two forms the same

int a;

and

int a = int();

? If not, what's the difference? What value does 'a' get in each
case?

And if you don't know that POD is (or what it stands for), perhaps
you need to learn first, then begin arguing...

Victor

If you refer back to my statement, I was talking about classes, not
primative types. The OP was asking about a struct, not an int.

What Victor said is absolutely correct: the two forms are different for
a POD. And a struct or a class can be a POD.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

I didn't say a struct couldn't be. But the different between the two forms
is largely syntactical. In reality, there is no difference in code
generation. If you want to think of them as meaning different things, fine.
It not worth arguing over.

DrX

[Ron Natalie]

"Xenos" <do**********@spamhate.com> wrote in message news:bq*********@cui1.lmms.lmco.com...

I didn't say a struct couldn't be. But the different between the two forms
is largely syntactical. In reality, there is no difference in code
generation. If you want to think of them as meaning different things, fine.
It not worth arguing over.

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).

[E. Robert Tisdale]

Hongzheng Wang wrote:

I saw some codes use `new classname'
to get a point to a new object of classname
but some codes use `new classname()'instead.
Is these two usage equivalent?

Yes.

[Victor Bazarov]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote...

Hongzheng Wang wrote:

I saw some codes use `new classname'
to get a point to a new object of classname
but some codes use `new classname()'instead.
Is these two usage equivalent?

Yes.

'nuther wun... Read 5.3.4/15 before continuing.

[Pete Becker]

Xenos wrote:

I didn't say a struct couldn't be. But the different between the two forms
is largely syntactical. In reality, there is no difference in code
generation. If you want to think of them as meaning different things, 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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[E. Robert Tisdale]

Victor Bazarov wrote:

Hongzheng Wang wrote:

I saw some codes use `new classname'
to get a pointer to a new object of classname
but some codes use`new classname()' instead.
Are these two usages equivalent?
For Plain Old Data (POD) they are not.

See the C++ FAQ [26.7] What is a "POD type"?
http://www.parashift.com/c++-faq-lit....html#faq-26.7
The former leaves it uninitialized,
the latter makes it default-initialized, IIRC.

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

[Ali Cehreli]

Karl Heinz Buchegger <kb******@gascad.at> wrote in message news:<3F***************@gascad.at>...

Xenos wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:akyzb.416658$Fm2.425058@attbi_s04...

"Hongzheng Wang" <wa******@mails.tsinghua.edu.cn> wrote...
> I saw some codes use `new classname' to get a point to
> a new object of classname, but some codes, instead, use
> `new classname()'.
> Is these two usage equivalent?

For POD they are not. The former leaves it uninitialised,
the latter makes it default-initialised, IIRC.

Victor

No, both would cause default initialization.

They don't

You cannot create an
uninitialized class object without a kludge.

you can:

#include <iostream>
using namespace std;

class A
{
public:
int m_n;
};

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

A::A() {}

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.
int main()
{
A* pA = new A;
A* pB = new A();
Both call the default constructor.
Here pA->m_n is left uninitialized while
pB->m_n should be default initialized.
*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.
VC++ 6.0 however gets this wrong and I suspect that
most compiler get this wrong. In other words: don't
depend on it.

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.

Ali

[Andrey Tarasevich]

Xenos wrote:

you can:

#include <iostream>
using namespace std;

class A
{
public:
int m_n;
};

int main()
{
A* pA = new A;
A* pB = new A();
Here pA->m_n is left uninitialized while
pB->m_n should be default initialized.

VC++ 6.0 however gets this wrong and I suspect that
most compiler get this wrong. In other words: don't
depend on it.

Oh, by the way: Yes in the above, class A is a POD.

I don't care what you call it, both uses of the new operator will call the
default constructor.

Wrong. For POD types _neither_ form will call default constructor. The
first form will left object uninitialized. The second form will
defualt-initialize it (which means zero-initialization, not a
constructor call).

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

Xenos wrote:

...
I didn't say a struct couldn't be. But the different between the two forms
is largely syntactical. In reality, there is no difference in code
generation. If you want to think of them as meaning different things, fine.
It not worth arguing over.
...

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.

--
Best regards,
Andrey Tarasevich

[Andrey Tarasevich]

E. Robert Tisdale wrote:

Victor Bazarov wrote:

Hongzheng Wang wrote:

I saw some codes use `new classname'
to get a pointer to a new object of classname
but some codes use`new classname()' instead.
Are these two usages equivalent?

For Plain Old Data (POD) they are not.

See the C++ FAQ [26.7] What is a "POD type"?
http://www.parashift.com/c++-faq-lit....html#faq-26.7
...

So? Once again, the effect of '()' initializer on different kinds of
data types in new-expression is very clearly described in the standard.
See 5.3.4/15.

--
Best regards,
Andrey Tarasevich

[Pete Becker]

Ali Cehreli wrote:

Karl Heinz Buchegger <kb******@gascad.at> wrote in message news:<3F***************@gascad.at>...

Xenos wrote:

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:akyzb.416658$Fm2.425058@attbi_s04...
> "Hongzheng Wang" <wa******@mails.tsinghua.edu.cn> wrote...
> > I saw some codes use `new classname' to get a point to
> > a new object of classname, but some codes, instead, use
> > `new classname()'.
> > Is these two usage equivalent?
>
> For POD they are not. The former leaves it uninitialised,
> the latter makes it default-initialised, IIRC.
>
> Victor
>
>
No, both would cause default initialization.

They don't

You cannot create an
uninitialized class object without a kludge.

you can:

#include <iostream>
using namespace std;

class A
{
public:
int m_n;
};

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

A::A() {}

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.

Read paragraph 5.3.4/15 of the C++ Standard. Especially the part where
it says "if the new-initializer is of the form (), the item is
value-initialized." Then see 8.5/5 for the definition of
'value-initialized'. It says, in effect, that for built-in types
value-initializing means zero-initializing.

int *ip = new int(); // value-initialized (i.e. zero-initialized)
struct S
{
int i;
};

S *sp = new S; // not initialized
S *sp1 = new S(); // value-initialized (S::i gets zero-initialized)

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Andrey Tarasevich]

Ali Cehreli wrote:

#include <iostream>
using namespace std;

class A
{
public:
int m_n;
};
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.

int main()
{
A* pA = new A;
A* pB = new A();

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.

Here pA->m_n is left uninitialized while
pB->m_n should be default initialized.

*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.

VC++ 6.0 however gets this wrong and I suspect that
most compiler get this wrong. In other words: don't
depend on it.

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.

--
Best regards,
Andrey Tarasevich

[Pete Becker]

Andrey Tarasevich wrote:

Xenos wrote:

...
I didn't say a struct couldn't be. But the different between the two forms
is largely syntactical. In reality, there is no difference in code
generation. If you want to think of them as meaning different things, fine.
It not worth arguing over.
...

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

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Xenos]

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

"Xenos" <do**********@spamhate.com> wrote in message news:bq*********@cui1.lmms.lmco.com...

I didn't say a struct couldn't be. But the different between the two forms is largely syntactical. In reality, there is no difference in code
generation. If you want to think of them as meaning different things, fine. It not worth arguing over.
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]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Xenos wrote:

I didn't say a struct couldn't be. But the different between the two forms is largely syntactical. In reality, there is no difference in code
generation. If you want to think of them as meaning different things,

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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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]

Xenos wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Xenos wrote:

I didn't say a struct couldn't be. But the different between the two forms is largely syntactical. In reality, there is no difference in code
generation. If you want to think of them as meaning different things,

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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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
kb******@gascad.at

[Karl Heinz Buchegger]

Xenos wrote:

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.

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

--
Karl Heinz Buchegger
kb******@gascad.at

[Ron Natalie]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:3F**************@jpl.nasa.gov...

The former leaves it uninitialized,
the latter makes it default-initialized, IIRC.

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]

"Ali Cehreli" <ac******@yahoo.com> wrote in message news:f0**************************@posting.google.c om...

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]

Xenos wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Xenos wrote:

I didn't say a struct couldn't be. But the different between the two forms is largely syntactical. In reality, there is no difference in code
generation. If you want to think of them as meaning different things,

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?

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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Xenos]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Xenos wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Xenos wrote:
>
>
> I didn't say a struct couldn't be. But the different between the two

forms

> is largely syntactical. In reality, there is no difference in code
> generation. If you want to think of them as meaning different

things, 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?

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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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]

Xenos wrote:

>

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.
...

Care to provide a reference? A chapter number?

--
Best regards,
Andrey Tarasevich

[Victor Bazarov]

"Xenos" <do**********@spamhate.com> wrote...

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Xenos wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...
> Xenos wrote:
> >
> >
> > I didn't say a struct couldn't be. But the different between the two forms
> > is largely syntactical. In reality, there is no difference in code > > generation. If you want to think of them as meaning different things, 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?
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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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]

"Xenos" <do**********@spamhate.com> wrote in message
news:bq*********@cui1.lmms.lmco.com...

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

Xenos wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...
> Xenos wrote:
> >
> >
> > I didn't say a struct couldn't be. But the different between the two forms
> > is largely syntactical. In reality, there is no difference in code > > generation. If you want to think of them as meaning different things, 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?
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.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

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++!