«

James Dow Allen wrote:

<snip>

> I don't think Fortran programmers ever say
> "Let's make our language more like Pascal."
> Ones that might ... switch to Pascal!

Fortran 77 and 90 did borrow many features of structured programming
that already existed in Pascal and C, such as

(1) block if-else-elseif statements
(2) loops (without the need for a numbered CONTINUE in F90)
(3) user-defined types

Visual Basic, compared to the original BASIC, has undergone a similar
evolution.

Keith Thompson wrote:
> And we wonder why people think comp.lang.c is a hostile newsgroup.

Not to support rudeness ...

> There are applications in which 1-based arrays are more convenient
> than 0-based arrays.

Or disagree with this

> 1-based arrays
> are much more convenient for some mathematical algorithms (see
> _Numerical Recipes in C_, which I cited upthread).

But this is a bad argument. I am initimately familiar with the book
.... the use of 1 based arrays was for ease of translation from
algorithms that had been coded in Fortran in previous versions of the
book, and the exact implementation invoked undefined behaviour (as you
mentioned in passing). The original Fortran coded examples were
actually useful, they were idiomatic for the language. The C examples,
when that came out, were completely unidiomatic and difficult to
follow; but a limited amount of effort had been put into it making it
useable. The Fortran 90 version, as far as I and my friends can see,
are actually almost unuseable (and I haven't looked for any more modern
versions

Yes not letting the arrays be anything other than 0 based is a weakness
of C. There are, however, very few algorithms where the structure of
the indexing set matters nontrivially, and even in those cases it is
usually the order relation that is important. In the few cases that it
does matter, sets of the form {0...b^n-1} (I am using ^ for `to the
power') are by far the most common.

I am not saying that one does not think of the first or second rather
than zeroth element: one certainly does. But that is a trivial change
during i/o or converting some field in a record. What I am saying that
when one needs to do arithmetic with the index, it is usually (but not
always) the zero based index that one wants. (Ask me! Having
programmed in various versions of Fortran now for well over twenty
years, I know how happy I was when I could use zero based arrays in
Fortran. And I also know how little it really matters in real life
when one gets used to using the `wrong' offset.)

In fact next to the indexing set {0...b^n-1}, the one I would like most
is not {1...b^n-1}, but rather {-b^n+1...b^n-1}. 1 based arrays is,
and I speak from experience, is not really a big deal.

On 6 Oct 2005 01:39:21 -0700, in comp.lang.c , wrote:

>James Dow Allen wrote:
>
>...
> >Anyone who suggests that C indexes should start at 1,
> >doesn't even understand this much: the idea that their
> >opinion on C might have merit is laughable.
>
>I didn't suggest, that indices should start at 1,
>starting at 0 is fine, but
>I just suggested that e.g. int A[n]; should reserve n+1
>memory-cells instead of n. Or that we have a preprocessor utility
>to change int A[n] into int A[n+1] before the compiler
>gets it from batch file or in a child process.

Why? Because you're incapable of recalling that the first element of
an array is at zero off set from the start? Because you're lazy?

>Very often you are using A[n] and want it to hold integers 1..n,
>with or without 0.
>I guess, this is a quite common error for C-programmers,

Only when they're beginners. It must be practically the first lesson
one learns about arrays.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

On 6 Oct 2005 07:01:16 -0700, in comp.lang.c ,
wrote:

>
>Keith Thompson wrote:

(i'm not convinced he did, but...)

>> 1-based arrays
>> are much more convenient for some mathematical algorithms (see
>> _Numerical Recipes in C_, which I cited upthread).
>
>But this is a bad argument. I am initimately familiar with the book
>... the use of 1 based arrays was for ease of translation from
>algorithms that had been coded in Fortran

More accuirately, tehy were coded thus because the writers were
Fortran programmers who knew very little C, and seemingly lacked the
skills to reimplement their algos in C. So instead they literally
xlated the fortran, then wrote helper functions to mangle the C arrays
into fortran ones... yeuch.

>Yes not letting the arrays be anything other than 0 based is a weakness
>of C.

Sure, there are sometimes needs for arrays not starting at one, or for
sparse arrays. C happens not to have native support for that, well
excuse me but it also doesn't have native support for fast fourier
transforms or gaussian integrals or threads, all of which would also
be useful too. Is their lack a weakness?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Mark McIntyre wrote:
> On 6 Oct 2005 01:39:21 -0700, in comp.lang.c , wrote:
>
>
>>James Dow Allen wrote:
>>
>>...
>>
>>>Anyone who suggests that C indexes should start at 1,
>>>doesn't even understand this much: the idea that their
>>>opinion on C might have merit is laughable.
>>
>>I didn't suggest, that indices should start at 1,
>>starting at 0 is fine, but
>>I just suggested that e.g. int A[n]; should reserve n+1
>>memory-cells instead of n. Or that we have a preprocessor utility
>>to change int A[n] into int A[n+1] before the compiler
>>gets it from batch file or in a child process.
>
>
> Why? Because you're incapable of recalling that the first element of
> an array is at zero off set from the start? Because you're lazy?
>
>
>>Very often you are using A[n] and want it to hold integers 1..n,
>>with or without 0.
>>I guess, this is a quite common error for C-programmers,
>
>
> Only when they're beginners. It must be practically the first lesson
> one learns about arrays.
>

If you can't decide whether your indexing should be rel-0 or rel-1, to
what IBM does. Use both. IBM disk formats have Tracks and Sectors. The
first track on a disk is 0. The first sector on the track is 1. Go
figure.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Mark McIntyre <> writes:
> On 6 Oct 2005 07:01:16 -0700, in comp.lang.c ,
> wrote:
>>Keith Thompson wrote:
>
> (i'm not convinced he did, but...)
>
>>> 1-based arrays
>>> are much more convenient for some mathematical algorithms (see
>>> _Numerical Recipes in C_, which I cited upthread).
>>
>>But this is a bad argument. I am initimately familiar with the book
>>... the use of 1 based arrays was for ease of translation from
>>algorithms that had been coded in Fortran
>
> More accuirately, tehy were coded thus because the writers were
> Fortran programmers who knew very little C, and seemingly lacked the
> skills to reimplement their algos in C. So instead they literally
> xlated the fortran, then wrote helper functions to mangle the C arrays
> into fortran ones... yeuch.

Yes, I did write that, and I was very likely wrong. I briefly skimmed
the relevant section of _Numerical Recipes in C_ and came away with
the impression that the advantages of 1-based arrays are inherent to
certain algorithms rather than based on their initial implementation
in Fortran. Now that others have said that's not the case, I'll just
bow out, since I lack the expertise to say anything useful.

>>Yes not letting the arrays be anything other than 0 based is a weakness
>>of C.
>
> Sure, there are sometimes needs for arrays not starting at one, or for
> sparse arrays. C happens not to have native support for that, well
> excuse me but it also doesn't have native support for fast fourier
> transforms or gaussian integrals or threads, all of which would also
> be useful too. Is their lack a weakness?

Arrays starting at a user-specified base index are a common feature in
a number of other languages. There's always a tradeoff between adding
features and keeping a language small and elegant, and I'm not going
to argue that C made the wrong choice. FFTs and Gaussian integrals
are (I think) more sensibly implemented as library functions; threads
can be implemented as a library too. But in any case, I don't
consider it a huge deal.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

In C, given an array `whatever[size]' the expression
`whatever' (outside sizeof, etc.) is a pointer.
I'm sure I'm not the only who was amazed to discover
how well this works out: array arguments become, in
effect, calls by name automatically; analyzing
"multidimensional" array expressions becomes easy;
pointer and array addressing become a single thing
to understand instead of two.

C programmers are not *required* to agree that the
array/pointer relationship is *beautiful* but they
need to understand and accept it. It, unlike
trivia such as the spelling of `foo += 1', is central
to C's essence.

Keith Thompson wrote:
> "James Dow Allen" <> writes:
> ...
> > Viewed in total isolation, the question of whether
> > to start array indexes at 0 or 1 may be a legitimate
> > open question, but in C the question answers itself
> > once one notices that the following expressions
> > (outside sizeof, etc.) must be identical in C:
> > *p
> > *(p+0)
> > 0[p+0]
> > p[0+0]
> > p[0]
>
> They *must* be identical because existing code would break if they
> weren't. That doesn't necessarily imply that a C-like language
> couldn't be devised in which they aren't identical, and arrays behave
> differently.

Given that the array/pointer relationship is essential
to C, I assume what you're suggesting is that
C could have been consistently defined so that the
expression (*p) evaluates to (p[1]). Now (*(p+6))
would be (p[7]) and so on. Did you have something
else in mind?

> > No one claims the C language is a perfect panacea, but
> > it has an enviable elegance. Novices should devote
> > themselves to grasping that elegance before offering
> > "improvements."
>
> Other that the "elegance" part, I agree.

"Elegance" is hard to define and best grasped with
examples. The property of ordinary expressions that
*(p+6) is equivalent to p[6]
would be devastatingly less elegant if replaced with
*(p+6) is equivalent to p[7]


James D. Allen

"James Dow Allen" <> writes:
[...]
> Keith Thompson wrote:
[...]
>> They *must* be identical because existing code would break if they
>> weren't. That doesn't necessarily imply that a C-like language
>> couldn't be devised in which they aren't identical, and arrays behave
>> differently.
>
> Given that the array/pointer relationship is essential
> to C, I assume what you're suggesting is that
> C could have been consistently defined so that the
> expression (*p) evaluates to (p[1]). Now (*(p+6))
> would be (p[7]) and so on. Did you have something
> else in mind?

Yes, I did. What I had in mind is making arrays first-class objects,
and decoupling arrays and pointers. x[y] would be defined as the y'th
element of the array x, not as *(x+y). Array names would not decay to
pointers. Since indexing wouldn't be defined in terms of pointer
arithmetic, allowing a user-defined base (e.g., "int arr[10..20];")
wouldn't break anything further.

This is *purely* hypothetical, of course. Such a change could not be
made without breaking tons of existing code.

[...]

> "Elegance" is hard to define and best grasped with
> examples. The property of ordinary expressions that
> *(p+6) is equivalent to p[6]
> would be devastatingly less elegant if replaced with
> *(p+6) is equivalent to p[7]

Absolutely. There's probably no way to provide non-zero-based arrays
in C without radical changes to the language, and I'm not advocating
any such changes. (Operator overloading might provide some
possibilities, but there's always C++ for that.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

On Sun, 02 Oct 2005 20:50:19 GMT, Keith Thompson <kst->
wrote:
<snip>
> I'll rephrase. C has multidimensional arrays. They're implemented
> as, and are indistinguishable from, arrays of arrays.
>
> There are other languages that make the distinction. For example,
> Pascal has both multidimensional arrays:
> arr1: array[1..10,1..10] of float;
> and arrays of arrays:
> arr2: array[1..10] of array[1..10] of float;
> with distinct syntax for indexing into them (arr1[x,y] vs. arr2[x][y])
> and different semantics (you can easily extract a one-dimensional
> array from an array of arrays, but not from a multidimensional array).
>
Are you sure? The standard (7185) says these are just 'abbreviations'
(sugar) for the array-of-array form, and I don't recall original (J&W)
as being any different in this area.

COBOL similarly creates multidim arrays (only) as array of group
consisting of array etc., but allows abbreviated subscripting.

Fortran, PL/I, and Ada have true (distinct) multidim arrays, and the
first two have special notations for subarrays/slices. (Ada has slices
only for 1-dim arrays, the simple and easy case.) And APL of course.

> So yes, C has multidimensional arrays in much the same way that it has
> pass-by-reference: it lets you build it explicitly on top of other
> constructs. I'm not convinced the statement about multidimensional
> arrays in 6.5.2.1 is strictly necessary (I think it probably follows
> from other statements in the standard), but I have no problem with it
> being re-stated.
>
Concur.

> [snip]

- David.Thompson1 at worldnet.att.net

Dave Thompson <> writes:
> On Sun, 02 Oct 2005 20:50:19 GMT, Keith Thompson <kst->
> wrote:
> <snip>
>> I'll rephrase. C has multidimensional arrays. They're implemented
>> as, and are indistinguishable from, arrays of arrays.
>>
>> There are other languages that make the distinction. For example,
>> Pascal has both multidimensional arrays:
>> arr1: array[1..10,1..10] of float;
>> and arrays of arrays:
>> arr2: array[1..10] of array[1..10] of float;
>> with distinct syntax for indexing into them (arr1[x,y] vs. arr2[x][y])
>> and different semantics (you can easily extract a one-dimensional
>> array from an array of arrays, but not from a multidimensional array).
>>
> Are you sure? The standard (7185) says these are just 'abbreviations'
> (sugar) for the array-of-array form, and I don't recall original (J&W)
> as being any different in this area.
[...]

No, I'm not sure. I haven't used Pascal in a long time, and I
probably confused its treatment of arrays with Ada's. Now that I
think about it, I believe you're right.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.