Matthew schrieb:
> All the other Win32 compilers - Borland, Comeau, CodePlay, CodeWarrior, GCC,
> Intel, MSVC, Watcom - work correctly in this regard.

Not an argument.

> The reason it's come up again is because I was expanding the compatibility
> of the recls test programs to as many compilers as possible, and one of the
> C clients uses my NUM_ELEMENTS macro, which uses the reversed subscript
> form. <pretty-shameless-plug>The reasons for doing so are to be found in
> Chapter 2 of "Imperfect C++", which should be out in
> Sept/Oct</pretty-shameless-plug>

Ah, you actually have some use for that! Interesting. Ok, this actually justifies it, although i cannot really imagine it too well. Say, does a simple addition not come into consideration? a[b] should standardly be the same as a+b, so that if one of them is a pointer, and another is an integer - no matter which - it works the same as pointer subscript if parenthesized correctly.

> IMO, if something is non-standard, then that looks (and is) bad, no matter
> how esoteric. The fact that it must be ridiculously simple to fix - since
> this works for C++, it must be - then I cannot see any good reason why the
> non-conformance would be dealt-with (Walter's ridiculous workload
> notwithstanding, of course).

Ah, it already works in C++? Then one of the behaviours is a bug. ;)

-eye

Ilya Minkov <minkov@cs.tum.edu> wrote in news:c43rh3$rh$1@digitaldaemon.com:

> Matthew schrieb:
>> All the other Win32 compilers - Borland, Comeau, CodePlay, CodeWarrior, GCC, Intel, MSVC, Watcom - work correctly in this regard.
> 
> Not an argument.

Nope, it's a standard! :)


>> The reason it's come up again is because I was expanding the compatibility of the recls test programs to as many compilers as possible, and one of the C clients uses my NUM_ELEMENTS macro, which uses the reversed subscript form. <pretty-shameless-plug>The reasons for doing so are to be found in Chapter 2 of "Imperfect C++", which should be out in Sept/Oct</pretty-shameless-plug>
> 
> Ah, you actually have some use for that! Interesting. Ok, this actually justifies it, although i cannot really imagine it too well. Say, does a simple addition not come into consideration? a[b] should standardly be the same as a+b, so that if one of them is a pointer, and another is an integer - no matter which - it works the same as pointer subscript if parenthesized correctly.

As they say in "C++: Core language" (where I saw this for the first time)

"The array support provided by the language is mostly just convenient memory management and pointer arithmetic. Perhaps the best evidence is that brackets operator is, surprisingly, commutative. That is, if 'a' is an array, a[5] and 5[a] are interchangeable. The brackets are just a shorthand for pointer arithmetic: a[5] = *(a+5) = *(5+a) = 5[a]."


>> IMO, if something is non-standard, then that looks (and is) bad, no matter how esoteric. The fact that it must be ridiculously simple to fix - since this works for C++, it must be - then I cannot see any good reason why the non-conformance would be dealt-with (Walter's ridiculous workload notwithstanding, of course).
> 
> Ah, it already works in C++? Then one of the behaviours is a bug. ;)
> 
> -eye


~/gnf.pt