sorting 5million minute data: choose std::list or std::vector

[Paul]

On 14/02/2011 14:40, James Kanze wrote:

Just because an array can decay to a pointer does not mean that arrays
are the same as pointers.

I know that, and you know that I know that. On the other hand,
there is no "array index operator" which operates on an array.
To index into an array, you have to convert the array to
a pointer, and use pointer arithmetic.

A compiler can optimize indexing into a local array as direct memory
read of the stack (i.e. offsetting the stack pointer) without performing
any pointer arithmetic at all.

Please cite the part of the Standard which says that indexing into an
array *requires* converting the array into a pointer. Although the
array/pointer *equivalence* exists it is not a *requirement* that such
*equivalence* always be utilized by a compiler (implementation) as far
as I can tell (I could be wrong; I am not familiar with the entire
Standard).

§5.2.1:
A postfix expression followed by an expression in square
brackets is a postfix expression. One of the expressions
shall have the type “pointer to T” and the other shall
have enumeration or integral type. The result is an
lvalue of type “T.” The type “T” shall be
a completely-defined object type. The expression E1[E2]
is identical (by definition) to *((E1)+(E2)).

It's the definition of the [] operator. (Note that this allows
things like 1["abc"].)

That simply defines an *equivalence*; an implementation is not required to
utilize such *equivalence* when subscripting an array.

§8.3.4/6:

"if E1 is an
array and E2 an integer, then E1[E2] refers to the E2-th member of E1."

An integer is a whole number positive or negative, the above confirms that
E2 can be an integer and therefore can be negative.

ergo E2 cannot be negative ergo you cannot have negative array indices.

Your twisted misinterpretation would redefine the meaning of integer.

 

[gwowen]

     [...]

People in the "use int everywhere" camp are lazy fuckers who no doubt
prefer "int" because it only involves typing 3 characters .. oh no teh
source codez doesn't fit in my editor windowz.. must use "int".

One can see the level of your communication skills.  Personally,
I don't think people like Stroustrup are "lazy fuckers".

The language designers intended for int to be used everywhere,
unless special considerations dictated otherwise.  If you have
some concrete arguments as to why this situation has changed,
present them.  But just calling the language designers "lazy
fuckers" isn't much of an argument.

What you fail to appreciate is that using types other than "int" are not
"special" cases; the language designers intended for all C++'s built-in
types to be used.

You must be one of the lazy fuckers.

/Leigh

/*
* The following code snippets are presented for Leigh's assesment
* whoever wrote clearly has no idea that the C++ language designers
* did not intend int to be used liberally for array indexing
*
* I should imagine the author is a lazy <expletive deleted as its
* neither big nor clever> and also a troll. I will try and get
* Bjarne to chastise them, and deprecate the book from which they
* are extracted
*/
void another_function ()
{
int v1[10];
int v2[10];

for(int i =0; i<10; ++i ) v1=v2;
}


namespace Stack { //representation
const int max_size=200;
struct Rep{
char v[max_size];
int top;
};
const int max=16; //maximumnumberofstacks
Rep stacks[max]; //preallocatedstackrepresentations
bool used[max]; //used is true if stacks is inuse
}

void rotate_all (vector <Shape *>& v ,int angle) // rotate v’s
elements angle degrees
{
for (int i=0;i<v.size();++i) v -> rotate(angle);
}

struct Entry {
string name ;
int number;
};

Entry phone_book[1000];
void print_entry (int i ) // simple use
{
cout << phone_book.name << ' ' << phone_book.number << '\n';
}

 

[Paul]

On 14/02/2011 14:40, James Kanze wrote:

Just because an array can decay to a pointer does not mean that
arrays
are the same as pointers.

I know that, and you know that I know that. On the other hand,
there is no "array index operator" which operates on an array.
To index into an array, you have to convert the array to
a pointer, and use pointer arithmetic.

A compiler can optimize indexing into a local array as direct memory
read of the stack (i.e. offsetting the stack pointer) without
performing
any pointer arithmetic at all.

Please cite the part of the Standard which says that indexing into an
array *requires* converting the array into a pointer. Although the
array/pointer *equivalence* exists it is not a *requirement* that such
*equivalence* always be utilized by a compiler (implementation) as far
as I can tell (I could be wrong; I am not familiar with the entire
Standard).

§5.2.1:
A postfix expression followed by an expression in square
brackets is a postfix expression. One of the expressions
shall have the type “pointer to T” and the other shall
have enumeration or integral type. The result is an
lvalue of type “T.” The type “T” shall be
a completely-defined object type. The expression E1[E2]
is identical (by definition) to *((E1)+(E2)).

It's the definition of the [] operator. (Note that this allows
things like 1["abc"].)

That simply defines an *equivalence*; an implementation is not required
to utilize such *equivalence* when subscripting an array.

§8.3.4/6:

"if E1 is an
array and E2 an integer, then E1[E2] refers to the E2-th member of E1."

ergo E2 cannot be negative ergo you cannot have negative array indices.

A pointer is not an array; an array is not a pointer. A pointer can point
to any array element; a pointer can point to the first array element in
which in which case it is pointing to an array and can be treated *as if*
it is an array.

This is absolute nonsense.
An array is a block of memory. The index into the array is an offset and is
only relative to the address it's offset against.

It all swings on the definition of "array" (E1); a negative offset can be
applied to a pointer into an array but the equivalent array index will
never be negative otherwise you are invoking undefined behaviour.

Bollocks, the offset *is* the index.
And the standard clearly states an index can be an integer, not an unsigned
integer.
Integer = whole number( postive or negative).

A "sub-array" of a multi-dimensional array is trickier and "sub-arrays"
are not mentioned by the Standard as far as I can tell.

Learn the basics first.

 

[Michael Doubez]

On 14 fév, 15:30, Leigh Johnston <[email protected]> wrote:

    [...]

Then lets take another example:
int array1[2][5];
int (&array2) [5] = array1[1];
array2[-1] = 42;
You will admit that array2 is a reference to a 'array of
5 int element'.  And I can rightfully use a -1 indexing.

Actually, according the C and (I think) the C++ standards, the
above is undefined behavior.

In my version of C99 §6.5.2.1/1 the constraints are:
<quote>
One of the expressions shall have type ‘‘pointer to object type’’, the
other expression shall have integer type, and the result has type
‘‘type’’.
</quote>

The array type is not mentioned until the note in Semantics(/2)
<quote>
[...]Because of the conversion rules that apply to the binary +
operator, if E1 is an array object (equivalently, a pointer to the
initial element of an array object) and E2 is an integer, E1[E2]
designates the E2-th element of E1 (counting from zero).
</quote>

Note: that the C99 standard give the precision of "counting from zero"
which is absent in the current C++ standard and C++0x proposal. [...]

In the example I gave, I expected array2 to decay to pointer array1 +
1*sizeof(array1[0]) and thus array2[-1] becomes *(array1 +
1*sizeof(array1[0]) - 1) which is indeed the -1th element of
array1when counting from sizeof(array1[0]) or sizeof(array1[0])-1th
element of array1 counting from 0

    [...]

The standard clearly recognizes "arrays": pointer arithmetic is
only valid within an array.  (For this purpose, a scalar is
treated as an array of 1 element.)

From a semantic point of view I agree. From a pointer arithmetic point
of view, shouldn't it be correct ?

[snip]

 

[Öö Tiib]

std::array::size_type is std::size_t not std:trdiff_t.

Is it already about next C++ standard? Pulling such decoys about
classes in next standard (that has nothing to do with current array
indexing) indicates that you consider it lost debate.

Strange ... since i think you are right, current array does not have
negative indexes.

 

[Öö Tiib]

     [...]

People in the "use int everywhere" camp are lazy fuckers who no doubt
prefer "int" because it only involves typing 3 characters .. oh no teh
source codez doesn't fit in my editor windowz.. must use "int".

One can see the level of your communication skills.  Personally,
I don't think people like Stroustrup are "lazy fuckers".

The language designers intended for int to be used everywhere,
unless special considerations dictated otherwise.  If you have
some concrete arguments as to why this situation has changed,
present them.  But just calling the language designers "lazy
fuckers" isn't much of an argument.

What you fail to appreciate is that using types other than "int" are not
"special" cases; the language designers intended for all C++'s built-in
types to be used.

Situations where binary serialization or communication protocol,
legacy or hardware interface or some performance requirement makes it
unavoidable to use all the available fundamental types are indeed
quite exceptional. Also such a need can be often so well encapsulated
and hidden into details by C++.

You must be one of the lazy fuckers.

I think that fucking maintainers brains too diligently by unjustified
usage of all these intX_t, uintY_t, doubles and floats in mix is
nothing to be proud about. The code of "lazy fuckers" who limit or
hide their usage of various fundamental types is usually better to
read and easier to understand.

 

[Öö Tiib]

Not at all; it is simply something which backs up my position.  Also
many current C++ compilers ship with TR1.

If you insist on restricting the discussion to C++2003 (which is a
bizarre restriction on this forum):

std::vector<T>::size_type is std::allocator<T>::size_type which is
std::size_t not std:trdiff_t.

Yes, okay, std::vector does encapsulate dynamic array. What i wanted
to say was that the "array" under discussion so far was the good old
C-style array. It is different thing and therefore i said that it is a
decoy.

I also think that tr1::array will be part of language sooner or later,
only thing unfortunate is that the both things may be called "array"
and that will raise terminology confusion.

 

[Paul]

On 14/02/2011 14:40, James Kanze wrote:

Just because an array can decay to a pointer does not mean that
arrays
are the same as pointers.

I know that, and you know that I know that. On the other hand,
there is no "array index operator" which operates on an array.
To index into an array, you have to convert the array to
a pointer, and use pointer arithmetic.

A compiler can optimize indexing into a local array as direct memory
read of the stack (i.e. offsetting the stack pointer) without
performing
any pointer arithmetic at all.

Please cite the part of the Standard which says that indexing into an
array *requires* converting the array into a pointer. Although the
array/pointer *equivalence* exists it is not a *requirement* that such
*equivalence* always be utilized by a compiler (implementation) as far
as I can tell (I could be wrong; I am not familiar with the entire
Standard).

§5.2.1:
A postfix expression followed by an expression in square
brackets is a postfix expression. One of the expressions
shall have the type “pointer to T” and the other shall
have enumeration or integral type. The result is an
lvalue of type “T.” The type “T” shall be
a completely-defined object type. The expression E1[E2]
is identical (by definition) to *((E1)+(E2)).

It's the definition of the [] operator. (Note that this allows
things like 1["abc"].)

That simply defines an *equivalence*; an implementation is not required
to utilize such *equivalence* when subscripting an array.

§8.3.4/6:

"if E1 is an
array and E2 an integer, then E1[E2] refers to the E2-th member of E1."

ergo E2 cannot be negative ergo you cannot have negative array indices.

A pointer is not an array; an array is not a pointer. A pointer can point
to any array element; a pointer can point to the first array element in
which in which case it is pointing to an array and can be treated *as if*
it is an array.

It all swings on the definition of "array" (E1); a negative offset can be
applied to a pointer into an array but the equivalent array index will
never be negative otherwise you are invoking undefined behaviour. A
"sub-array" of a multi-dimensional array is trickier and "sub-arrays" are
not mentioned by the Standard as far as I can tell.

<quote>
8 [ Example: consider
int x[3][5];
Here x is a 3 × 5 array of integers. When x appears in an expression, it is
converted to a pointer to (the
first of three) five-membered arrays of integers. In the expression x
which is equivalent to *(x+i), x is
first converted to a pointer as described; then x+i is converted to the type
of x, which involves multiplying
i by the length of the object to which the pointer points, namely five
integer objects. The results are added
and indirection applied to yield an array (of five integers), which in turn
is converted to a pointer to the
first of the integers. If there is another subscript the same argument
applies again; this time the result is an
integer. —end example ]
</quote>

x[2][-1] must be identical to x[1][4].

 

[James Kanze]

On 14/02/2011 14:40, James Kanze wrote:
Just because an array can decay to a pointer does not mean that
arrays are the same as pointers.
I know that, and you know that I know that. On the other hand,
there is no "array index operator" which operates on an array.
To index into an array, you have to convert the array to
a pointer, and use pointer arithmetic.
A compiler can optimize indexing into a local array as direct memory
read of the stack (i.e. offsetting the stack pointer) without performing
any pointer arithmetic at all.
Please cite the part of the Standard which says that indexing into an
array *requires* converting the array into a pointer. Although the
array/pointer *equivalence* exists it is not a *requirement* that such
*equivalence* always be utilized by a compiler (implementation) as far
as I can tell (I could be wrong; I am not familiar with the entire
Standard).

5.2.1:
A postfix expression followed by an expression in square
brackets is a postfix expression. One of the expressions
shall have the type pointer to T and the other shall
have enumeration or integral type. The result is an
lvalue of type T. The type T shall be
a completely-defined object type. The expression E1[E2]
is identical (by definition) to *((E1)+(E2)).
It's the definition of the [] operator. (Note that this allows
things like 1["abc"].)

That simply defines an *equivalence*; an implementation is not
required to utilize such *equivalence* when subscripting an array.

It defines completely the semantics of a. What part of
"indentical"
don't you understand?

A conforming implementation is required to treat a exactly as if
you'd written "*(a+b)", within the scope of the standard.

 

[James Kanze]

On 15/02/2011 12:34, Leigh Johnston wrote:

[...]

8.3.4/6:
"if E1 is an
array and E2 an integer, then E1[E2] refers to the E2-th member of E1."

And you're quoting out of context. The full statement is:

Except where it has been declared for a class, the
subscript operator [] is interpreted in such a way that
E1[E2] is identical to *((E1)+(E2)). Because of the
conversion rules that apply to +, if E1 is an array and
E2 an integer, then E1[E2] refers to the E2-th member of
E1. Therefore, despite its asymmetric appearance,
subscripting is a commutative operation.

It is only legal for a pointer to point to somewhere between the
first element of an array, and one past the end of the array.
If the result of pointer arithmetic ends up somewhere else,
undefinde behavior occurs. But as the above paragraph clearly
states, there is no index operator for arrays---indexation is a
syntactic rewrite for pointer arithmetic followed by
dereferencing, and what looks like array indexation is actually
an implicit conversion of the array to a pointer, followed by
pointer arithmetic, followed by a dereference.

A pointer is not an array; an array is not a pointer.

Who's saying anything different?

Look, at the moment, you're not arguing against me; you're arguing
against the C++ standard. You may not like the way the standard
defines [] (and I certainly don't), but that's the way it is.

It all swings on the definition of "array" (E1);

No. It all swings on the definition of "E1[E2]". The
definition says that "One of the expressions shall have the type
'pointer to T' and the other shall have enumeration or integral
type." That is the constraint, word for word, as it is written
in the standard. The [] does not, and cannot, be used on an
array; it requires a conversion of the array to a pointer before
it applies.

 

[James Kanze]

On 15/02/2011 15:03, Öö Tiib wrote: [...]

I also think that tr1::array will be part of language sooner or later,
only thing unfortunate is that the both things may be called "array"
and that will raise terminology confusion.

std::array *is* currently part of C++0x.

But C++0x is not an official document (or term, or whatever),
and does not define the language. (IMHO, the probability of
std::array not being part of C++0x, once it becomes standard, is
close to zero.)

For implementations that include <array> and <vector> std::array should
be preferred over ordinary arrays in the same way that std::vector
should be preferred over dynamic arrays;

If you can guarantee that all of the implementations you will
ever be required to use implement <array> in a form that is
compatible with the not yet finalized standard, std::array
should be preferred, yes. In practice, this is almost never the
case today.

 

[James Kanze]

On 14/02/2011 22:38, Ian Collins wrote:

[...]

People in the "use int everywhere" camp are lazy fuckers who no doubt
prefer "int" because it only involves typing 3 characters .. oh no teh
source codez doesn't fit in my editor windowz.. must use "int".

One can see the level of your communication skills. Personally,
I don't think people like Stroustrup are "lazy fuckers".
The language designers intended for int to be used everywhere,
unless special considerations dictated otherwise. If you have
some concrete arguments as to why this situation has changed,
present them. But just calling the language designers "lazy
fuckers" isn't much of an argument.

What you fail to appreciate is that using types other than
"int" are not "special" cases; the language designers intended
for all C++'s built-in types to be used.

I would consider Stroustrup (and Kernighan and Richie for C) one
of the language designers.

You must be one of the lazy fuckers.

Beautiful technical argument.

 

[itaj sherman]

5.2.1:
A postfix expression followed by an expression in square
brackets is a postfix expression. One of the expressions
shall have the type pointer to T and the other shall
have enumeration or integral type. The result is an
lvalue of type T. The type T shall be
a completely-defined object type. The expression E1[E2]
is identical (by definition) to *((E1)+(E2)).
It's the definition of the [] operator. (Note that this allows
things like 1["abc"].)
That simply defines an *equivalence*; an implementation is not
required to utilize such *equivalence* when subscripting an array.

It defines completely the semantics of a. What part of
"indentical"
don't you understand?

A conforming implementation is required to treat a exactly as if
you'd written "*(a+b)", within the scope of the standard.

a is equivalent to *(a+b) yes however if a is an array (rather than
just a pointer) the Standard clearly states that b is the b'th member of
the array; pointers do not have "members".

For the third and final time: consider how an optimizing compiler
subscripts a local array (there is no pointer arithmetic, it offsets the
stack pointer directly instead).

What you are saying agrees, not contradicts.
If an implementation does that for a where a is a local array, then
it conforms to the standard. Because as Kanze explained it should be,
that calculation has the same result as if *(a+b) was done.

 

[Paul]

On 15/02/2011 15:03, Öö Tiib wrote: [...]
I also think that tr1::array will be part of language sooner or later,
only thing unfortunate is that the both things may be called "array"
and that will raise terminology confusion.

std::array *is* currently part of C++0x.

But C++0x is not an official document (or term, or whatever),
and does not define the language. (IMHO, the probability of
std::array not being part of C++0x, once it becomes standard, is
close to zero.)

Tell us something we don't know.

This is fuckin nonsense. vector is not a replacement for a dynamic array and
never fuckin will be you fuckin idiot.

 

[Paul]

On 15/02/2011 10:43, James Kanze wrote:
On 14/02/2011 14:40, James Kanze wrote:

Just because an array can decay to a pointer does not mean that
arrays are the same as pointers.

I know that, and you know that I know that. On the other hand,
there is no "array index operator" which operates on an array.
To index into an array, you have to convert the array to
a pointer, and use pointer arithmetic.

A compiler can optimize indexing into a local array as direct memory
read of the stack (i.e. offsetting the stack pointer) without
performing
any pointer arithmetic at all.

Please cite the part of the Standard which says that indexing into an
array *requires* converting the array into a pointer. Although the
array/pointer *equivalence* exists it is not a *requirement* that such
*equivalence* always be utilized by a compiler (implementation) as far
as I can tell (I could be wrong; I am not familiar with the entire
Standard).

5.2.1:
A postfix expression followed by an expression in square
brackets is a postfix expression. One of the expressions
shall have the type pointer to T and the other shall
have enumeration or integral type. The result is an
lvalue of type T. The type T shall be
a completely-defined object type. The expression E1[E2]
is identical (by definition) to *((E1)+(E2)).

It's the definition of the [] operator. (Note that this allows
things like 1["abc"].)

That simply defines an *equivalence*; an implementation is not
required to utilize such *equivalence* when subscripting an array.

It defines completely the semantics of a. What part of
"indentical"
don't you understand?

A conforming implementation is required to treat a exactly as if
you'd written "*(a+b)", within the scope of the standard.

a is equivalent to *(a+b) yes however if a is an array (rather than
just a pointer) the Standard clearly states that b is the b'th member of
the array; pointers do not have "members".

A pointer to an array is not *just* a pointer, it has a type, and the
implementation must use the sizeof that pointers type to calculate the true
offset for a given index.
With :
int arr[16];
arr doesn't have any members it is simply an identifier that is treated like
a pointer to an array.

For the third and final time: consider how an optimizing compiler
subscripts a local array (there is no pointer arithmetic, it offsets the
stack pointer directly instead).

This is totally implemtation specific but nonetheless what you say is
complete nonsense because SP+offset is pointer arithmetic, and you seem to
think it's not.

 

[Keith H Duggar]

No.  It all swings on the definition of "E1[E2]".  The
definition says that "One of the expressions shall have the type
'pointer to T' and the other shall have enumeration or integral
type."  That is the constraint, word for word, as it is written
in the standard.  The [] does not, and cannot, be used on an
array; it requires a conversion of the array to a pointer before
it applies.

Nonsense; where does the Standard say that such a conversion is
required?  It doesn't as far as I can tell as such a conversion is not
required.

For llort's sake what do you not understand about the phrase
"shall have the type 'pointer to T'"? As far as standards go
that language is as crystal clear /and/ strong (shall) as it
gets. As far as the C++ language is concerned E1[E2] is just
and only just syntatic sugar for a POINTER expression.

KHD

 

[Paul]

On 15/02/2011 18:10, James Kanze wrote:
It all swings on the definition of "array" (E1);

No. It all swings on the definition of "E1[E2]". The
definition says that "One of the expressions shall have the type
'pointer to T' and the other shall have enumeration or integral
type." That is the constraint, word for word, as it is written
in the standard. The [] does not, and cannot, be used on an
array; it requires a conversion of the array to a pointer before
it applies.

Nonsense; where does the Standard say that such a conversion is
required? It doesn't as far as I can tell as such a conversion is not
required.

For llort's sake what do you not understand about the phrase
"shall have the type 'pointer to T'"? As far as standards go
that language is as crystal clear /and/ strong (shall) as it
gets. As far as the C++ language is concerned E1[E2] is just
and only just syntatic sugar for a POINTER expression.

I never claimed that E1[E2] is not equivalent to *((E1)+(E2)); I am
claiming that according to the Standard -1 is an invalid array index.
Again:

"if E1 *is an array* and E2 an integer, then E1[E2] refers to the E2-th
member of E1."

The intent of this quotation is not to state an array index cannot be
negative, this is defining the implementation of the [] syntax. This
quotation supports the fact that a pointer is a valid identifier for an
array.

Your argument simply displays your willingness to deliberately misinterpret
the standard when it suits your argument. Unless you really are dumb enough
to think an array index should never be negative.

 

[James Kanze]

On 15/02/2011 12:34, Leigh Johnston wrote:

[...]

A pointer is not an array; an array is not a pointer.

Who's saying anything different?
Look, at the moment, you're not arguing against me; you're arguing
against the C++ standard. You may not like the way the standard
defines [] (and I certainly don't), but that's the way it is.

Nonsense; I am arguing with your interpretation of the Standard not the
Standard itself. The Standard specifies behaviour that is specific to
arrays (not pointers) i.e. if E1 is an array rather than just a pointer.
Again:

"if E1 *is an array* and E2 an integer, then E1[E2] refers to the E2-th
member of E1."

Except where it has been declared for a class, the
subscript operator [] is interpreted in such a way that
E1[E2] is identical to *((E1)+(E2)). Because of the
conversion rules that apply to +, if E1 is an array and
E2 an integer, then E1[E2] refers to the E2-th member of
E1. Therefore, despite its asymmetric appearance,
subscripting is a commutative operation.

That's the complete quote. Note the "Because of the conversion
rules that apply", and the rest.

Arrays have have members; pointers do not have members.
So?

I am well aware that E1[E2] is semantically identical to
*((E1)+(E2)) which is unsurprising given I have been using C++
for a not insignificant time. If my posts indicated otherwise
then I apologize for any confusion.

It is not just semantically identical. That is the definition
of the [] operator.

It all swings on the definition of "array" (E1);

No. It all swings on the definition of "E1[E2]". The
definition says that "One of the expressions shall have the type
'pointer to T' and the other shall have enumeration or integral
type." That is the constraint, word for word, as it is written
in the standard. The [] does not, and cannot, be used on an
array; it requires a conversion of the array to a pointer before
it applies.

Nonsense; where does the Standard say that such a conversion is
required? It doesn't as far as I can tell as such a conversion is not
required.

It's clear in the cited passage. What don't you understand
about the requirement that "One of the expression shall have the
type 'pointer to T' and the other shall have enumeration or
integral type"? An array type is not a legal operand of [].

 

[Keith H Duggar]

On 15/02/2011 18:10, James Kanze wrote:
No.  It all swings on the definition of "E1[E2]".  The
definition says that "One of the expressions shall have the type
'pointer to T' and the other shall have enumeration or integral
type."  That is the constraint, word for word, as it is written
in the standard.  The [] does not, and cannot, be used on an
array; it requires a conversion of the array to a pointer before
it applies.
Nonsense; where does the Standard say that such a conversion is
required?  It doesn't as far as I can tell as such a conversion is not
required.

It's clear in the cited passage.  What don't you understand
about the requirement that "One of the expression shall have the
type 'pointer to T' and the other shall have enumeration or
integral type"?  An array type is not a legal operand of [].

Nonsense; again:

"if E1 *is an array* and E2 an integer, then E1[E2] refers to the E2-th
member of E1."

Often one needs to read more than just one paragraph of the Standard;
i.e. read [dcl.array] not just [expr.sub].

Curious then that you stopped reading 8.3.4 as soon as you hit
subsection 6. Had you continued further to 8.3.4.7-8 you would
have seen /explicit/ conversion requirements for multi-D arrays.
Given that the standard calls this "A consistent [with 1D] rule"
and given the /defining/ equivalence already discussed in detail,
it would be dense to think it doesn't apply to the 1D case.

What a specific implementation of this /language/ standard
does by utilizing the as-if rule is irrelevant.

Why has nobody complained so loudly about what you see as a lack
of explicit detail in the 1D case? Probably because it is rather
obvious to experts; and nobody but you such mystical significance
on unsigned.

The the concept of negative array indices is useful and obvious
to any serious computing community. For example, several languages
among them Fortran, Pascal, Ada, etc provide direct (ie using array
looking [..] or similar) syntax for custom integer index ranges.
C/C++ provides for the same by simple pointer realignment.

To anyone familiar with such features and domains (ie domains other
than wizard created VC++ gui toys), the "array's cannot have negative
indices" yelping seems like an interpretation nitpick at best and
plain ignorant at worst.

KHD