Well, I see this in the gcc error message. Can someone here kindly
point to me which part of the Standard specified this behaviour? I
thought it should be in 5.3.4, but was not able to find the words
there.
By the way, anyone knows the rationale of this behaviour?
Thanks in advance.
Best regards,
Yongwei

Jonathan Wakely wrote:

WU Yongwei wrote:

Well, I see this in the gcc error message. Can someone here kindly
point to me which part of the Standard specified this behaviour? I
thought it should be in 5.3.4, but was not able to find the words
there.

It might be better if the error message said "non-default
initialization" since default initialization is allowed (and required).

! that was meant to say "required for some types" (e.g.
const-qualified types, non-PD types)

Too early in the morning for me to be answering questions like this!

jon

WU Yongwei wrote:

Well, I see this in the gcc error message. Can someone here kindly
point to me which part of the Standard specified this behaviour? I
thought it should be in 5.3.4, but was not able to find the words
there.

By the way, anyone knows the rationale of this behaviour?

It is not explicitly forbidden. Rather, there is no syntax defined that
would enable it (so it is implicitly forbidden)

you might be interested in the following paper from the last IS
mailing ;)

AlisdairM

Fri, Aug 19, 2005 at 09:19:55AM +0100, Jonathan Wakely wrote:
WU Yongwei wrote:

Well, I see this in the gcc error message. Can someone here kindly
point to me which part of the Standard specified this behaviour? I
thought it should be in 5.3.4, but was not able to find the words
there.

It might be better if the error message said "non-default
initialization" since default initialization is allowed (and required).

I assume you are trying something like this:

int* i = new int[5](23);

While this is not gcc-help, maybe we could make a FAQ item for this.
For people who want to do something like this, I suggest

std::vector<inti(5, 23);

If the reason vector wasn't used in the first place was because some
API needs an array, then use

std::vector<intvector_i(5, 23);
int* i = &*vector.begin();

The reason for the &* is to convert the vector iterator into a
pointer to the first element.

8/19/05, Jonathan Wakely <cow (AT) compsoc (DOT) man.ac.ukwrote:
WU Yongwei wrote:
Well, I see this in the gcc error message. Can someone here kindly
point to me which part of the Standard specified this behaviour? I
thought it should be in 5.3.4, but was not able to find the words
there.
[snipped]
This is K, and default initialises the array, which default initialises
each element (8.5/5)

int* i = new int[5]();

but this is not K:

int* i = new int[5](23);

because it is not valid to initialise an array like this:

typedef int (five_ints)[5];
five_ints i(23);

this gives:

array_init.cc:8: error: cannot initialize arrays using this syntax

This sounds reasonable. The only problem is that it does not
constitute proof. It is complete K if the standard disallowed `int
a[5](23)' while allowing `new int[5](23)', just as older GCC did.

8/19/05, Alisdair Meredith <alisdair.meredith (AT) uk (DOT) renaultf1.comwrote:
WU Yongwei wrote:

Well, I see this in the gcc error message. Can someone here kindly
point to me which part of the Standard specified this behaviour? I
thought it should be in 5.3.4, but was not able to find the words
there.

By the way, anyone knows the rationale of this behaviour?

It is not explicitly forbidden. Rather, there is no syntax defined that
would enable it (so it is implicitly forbidden)

My observations. According to 5.3.4, an expression like `new
int[5](23)' is well-formed. Just that no semantics are formally
defined for it.

The behaviour might be K, but the message seems a little misleading.
Would something like `cannot specify initializer for arrays' be better
since it really has little to do with `array new'?

Also, the trends of gcc removing existing `extensions' are a little
worrisome. IMH, the extension should be allowed and a warning in the
case of `-W' or `-ansi' should be issued.

Best regards,

Yongwei