Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #76825 > unrolled thread

just a curiosity about starting array indexing at 0 as opposed to 1

Back to article view | Back to comp.lang.c

Contents

  just a curiosity about starting array indexing at 0 as opposed to 1 G G <gdotone@gmail.com> - 2015-11-21 18:50 -0800
    Re: just a curiosity about starting array indexing at 0 as opposed to 1 supercat@casperkitty.com - 2015-11-21 19:31 -0800
      Re: just a curiosity about starting array indexing at 0 as opposed to 1 Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-22 00:15 -0800
        Re: just a curiosity about starting array indexing at 0 as opposed to 1 supercat@casperkitty.com - 2015-11-22 07:20 -0800
          Re: just a curiosity about starting array indexing at 0 as opposed to 1 BartC <bc@freeuk.com> - 2015-11-22 16:22 +0000
            Re: just a curiosity about starting array indexing at 0 as opposed to 1 supercat@casperkitty.com - 2015-11-22 08:44 -0800
      Re: just a curiosity about starting array indexing at 0 as opposed to 1 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-22 10:37 -0500
        Re: just a curiosity about starting array indexing at 0 as opposed to 1 BartC <bc@freeuk.com> - 2015-11-22 15:50 +0000
          Re: just a curiosity about starting array indexing at 0 as opposed to 1 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-22 11:02 -0500
            Re: just a curiosity about starting array indexing at 0 as opposed to 1 BartC <bc@freeuk.com> - 2015-11-22 16:15 +0000
    Re: just a curiosity about starting array indexing at 0 as opposed to 1 Ian Collins <ian-news@hotmail.com> - 2015-11-22 16:42 +1300
      Re: just a curiosity about starting array indexing at 0 as opposed to 1 G G <gdotone@gmail.com> - 2015-11-21 19:55 -0800
      Re: just a curiosity about starting array indexing at 0 as opposed to 1 Keith Thompson <kst-u@mib.org> - 2015-11-23 11:01 -0800
        Re: just a curiosity about starting array indexing at 0 as opposed to 1 BartC <bc@freeuk.com> - 2015-11-23 19:18 +0000
          Re: just a curiosity about starting array indexing at 0 as opposed to 1 Keith Thompson <kst-u@mib.org> - 2015-11-23 11:26 -0800
            Re: just a curiosity about starting array indexing at 0 as opposed to 1 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-23 22:54 +0000
              Re: just a curiosity about starting array indexing at 0 as opposed to 1 Robert Wessel <robertwessel2@yahoo.com> - 2015-11-23 18:37 -0600
                Re: just a curiosity about starting array indexing at 0 as opposed to 1 raltbos@xs4all.nl (Richard Bos) - 2015-11-24 15:22 +0000
        Re: just a curiosity about starting array indexing at 0 as opposed to 1 raltbos@xs4all.nl (Richard Bos) - 2015-11-24 15:13 +0000
    Re: just a curiosity about starting array indexing at 0 as opposed to 1 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-22 01:21 -0500
      Re: just a curiosity about starting array indexing at 0 as opposed to 1 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-22 15:00 +0000
        Re: just a curiosity about starting array indexing at 0 as opposed to 1 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-22 10:15 -0500
          Re: just a curiosity about starting array indexing at 0 as opposed to 1 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-23 13:47 +0000
            Re: just a curiosity about starting array indexing at 0 as opposed to 1 BartC <bc@freeuk.com> - 2015-11-23 14:50 +0000
              Re: just a curiosity about starting array indexing at 0 as opposed to 1 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-23 12:01 -0500
                Re: just a curiosity about starting array indexing at 0 as opposed to 1 James Kuyper <jameskuyper@verizon.net> - 2015-11-23 12:12 -0500
                  Re: just a curiosity about starting array indexing at 0 as opposed to 1 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-23 12:57 -0500
              Re: just a curiosity about starting array indexing at 0 as opposed to 1 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-23 23:08 +0000
            Re: just a curiosity about starting array indexing at 0 as opposed to 1 bert <bert.hutchings@btinternet.com> - 2015-11-23 08:52 -0800
        Re: just a curiosity about starting array indexing at 0 as opposed to 1 BartC <bc@freeuk.com> - 2015-11-22 15:42 +0000
          Re: just a curiosity about starting array indexing at 0 as opposed to 1 Keith Thompson <kst-u@mib.org> - 2015-11-22 12:36 -0800
          Re: just a curiosity about starting array indexing at 0 as opposed to 1 BartC <bc@freeuk.com> - 2015-11-22 21:06 +0000
    Re: just a curiosity about starting array indexing at 0 as opposed to 1 BartC <bc@freeuk.com> - 2015-11-22 10:28 +0000
      Re: just a curiosity about starting array indexing at 0 as opposed to 1 gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-22 12:04 +0000
    Re: just a curiosity about starting array indexing at 0 as opposed to 1 Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-22 11:24 +0000
      Re: just a curiosity about starting array indexing at 0 as opposed to 1 G G <gdotone@gmail.com> - 2015-11-22 04:29 -0800
    Re: just a curiosity about starting array indexing at 0 as opposed to 1 see.my.homepage@gmail.com - 2015-11-22 04:54 -0800
      Re: just a curiosity about starting array indexing at 0 as opposed to 1 BartC <bc@freeuk.com> - 2015-11-22 13:43 +0000
      Re: just a curiosity about starting array indexing at 0 as opposed to 1 James Kuyper <jameskuyper@verizon.net> - 2015-11-22 11:04 -0500
    Re: just a curiosity about starting array indexing at 0 as opposed to 1 Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2015-11-22 15:29 +0000
    Re: just a curiosity about starting array indexing at 0 as opposed to 1 Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-22 14:06 -0800
    Re: just a curiosity about starting array indexing at 0 as opposed to 1 John Bode <jfbode1029@gmail.com> - 2015-11-23 07:49 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#76864

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Saturday November 21 2015 21:50, in comp.lang.c, "G G" <gdotone@gmail.com>
> wrote:
 
>> Just a curiosity about C starting array subscripts at 0 as
>> opposed to starting at 1.
 
(snip)

> It is implicit in the structure of arrays.
 
> K&R "The C Programming Language", Chapter 5 "Pointers and Arrays"
> 
>  "Rather more surprising, at least at first sight, is the fact that a
>   reference to a[i] can also be written as *(a+i). In evaluating a[i], C
>   converts it to *(a+i) immediately; the two forms are completely
>   equivalent."
 
> If arrays started at any subscript other than zero, then
>  a[subscript]
> could /not/ be equivalent to
>  *(a+subscript)

Yes, but a[i] could have been equivalent to *(a+i-1).

That might be a little strange, though. 

Note that in my programs I never write &a[i], but instead
always a+i. But with other definitions of a[i], you have to
be more careful. 

Fortran 66 programmers got used to all the +1 and -1 that come
about with array indexing. Fortran 77 added the ability to specify
the origin, but most arrays still index from 1.

Mathematicians still describe matrices as 1 origin.
 
> Consider: in a "arrays start at subscript 1" array,
>  array[1]
> would be equivalent to
>  *(array+0)
> and /not/ equivalent to
>  *(array+1)

-- glen

[toc] | [prev] | [next] | [standalone]

#76868

On Sunday November 22 2015 10:00, in comp.lang.c, "glen herrmannsfeldt"
<gah@ugcs.caltech.edu> wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Saturday November 21 2015 21:50, in comp.lang.c, "G G"
>> <gdotone@gmail.com> wrote:
>  
>>> Just a curiosity about C starting array subscripts at 0 as
>>> opposed to starting at 1.
>  
> (snip)
> 
>> It is implicit in the structure of arrays.
>  
>> K&R "The C Programming Language", Chapter 5 "Pointers and Arrays"
>> 
>>  "Rather more surprising, at least at first sight, is the fact that a
>>   reference to a[i] can also be written as *(a+i). In evaluating a[i], C
>>   converts it to *(a+i) immediately; the two forms are completely
>>   equivalent."
>  
>> If arrays started at any subscript other than zero, then
>>  a[subscript]
>> could /not/ be equivalent to
>>  *(a+subscript)
> 
> Yes, but a[i] could have been equivalent to *(a+i-1).

Yes, it could be. But, Dennis Ritchie and the others that designed it decided
otherwise.

Perhaps that begs the question as to why Ritchie, et al decided to use the
notation
  *(a+i)
to address the i'th element of array a

But, then again, C was developed, at least in part, to permit Bell Labs to
rewrite Unix into a high-level-language from it's Assembler roots (see
https://www.bell-labs.com/usr/dmr/www/chist.html), and assembler (being very
close to the machine) indexes arrays from 0 (first element is address+0, 2nd
element is address+1, etc.)

> That might be a little strange, though.
> 
> Note that in my programs I never write &a[i], but instead
> always a+i. But with other definitions of a[i], you have to
> be more careful.
> 
> Fortran 66 programmers got used to all the +1 and -1 that come
> about with array indexing. Fortran 77 added the ability to specify
> the origin, but most arrays still index from 1.
> 
> Mathematicians still describe matrices as 1 origin.
>  
>> Consider: in a "arrays start at subscript 1" array,
>>  array[1]
>> would be equivalent to
>>  *(array+0)
>> and /not/ equivalent to
>>  *(array+1)
> 
> -- glen


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#76989

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

(snip)

>>> <gdotone@gmail.com> wrote:
  
>>>> Just a curiosity about C starting array subscripts at 0 as
>>>> opposed to starting at 1.
  
(snip)

>>> It is implicit in the structure of arrays.
  
(snip, someone else wrote)

>>> If arrays started at any subscript other than zero, then
>>>  a[subscript]
>>> could /not/ be equivalent to
>>>  *(a+subscript)
 
>> Yes, but a[i] could have been equivalent to *(a+i-1).
 
This has the interesting result that one can choose 1 origin with []
or 0 origin with *(...).

> Yes, it could be. But, Dennis Ritchie and the others that 
> designed it decided otherwise. 

The intteresting thing is to see what might have been the thought
process on the way.

One is that 0 origin is more obvious to assembly programmers
on most systems. That might be enough.

> Perhaps that begs the question as to why Ritchie, et al decided 
> to use the notation
>  *(a+i)
> to address the i'th element of array a

For some definition of i'th. Note that the term is often used
for 1 origin counting, too.
 
(snip on assembly programmers and 0 origin)
(regarding a[i] being *(a+i-1), I wrote)

>> That might be a little strange, though.

>> Note that in my programs I never write &a[i], but instead
>> always a+i. But with other definitions of a[i], you have to
>> be more careful.
 
>> Fortran 66 programmers got used to all the +1 and -1 that come
>> about with array indexing. Fortran 77 added the ability to specify
>> the origin, but most arrays still index from 1.

Arrays with specifiable lower bound go back at least to PL/I
from about 1964, and I believe ALGOL even earlier. Fortran had
only 1 origin arrays until 1977.

So there were two alternatives to 0 origin, 1 origin or
specifiable origin.

Also, C uses [] for both arrays (after they decay to pointers)
and for pointers. For 1D arrays, the two are pretty much the same,
but not for higher dimensions. It seems to me that C could have
allowed specifiable origin for the array case, but not the pointer
case.

(WARNING: hypothetical, non-standard C ahead)

int x[-10:10];

for(i=-10; i<=10;i++) x[i]=0;

This still leaves open what x does as a function argument.

It is about as easy to pass the address of x[0] as of x[-10], so
we don't have to decide yet.

Would it have been too strange to allow x[-10:10] in one function,
but, passed as an argument the caller gets x[0:20]?

Assumed shape, pass by descriptor, arrays in Fortran pretty much
work that way. (The origin is 1 in the called routine, unless
a different origin is specified.)

On the other hand, PL/I passes arrays by descriptor, including the
upper and lower bound. Called routines use the same subscript values.
Implementations that I know of pass the address of the element with
all subscripts zero, even if it isn't within the array. That an
appropriate multipliers make it easy to address any element.

If arrays decay to a pointer to element zero, instead of the
first element, they pretty much work the expected way.

There is a complication that, under some conditions and addressing
systems, a pointer might have the value zero.  With the current C
array system, an implementation can avoid pointers having the value
zero by reserving the bottom of addressing space, and not using it.
With origin 1, the next to the bottom of addressing space could have
the value zero, and would have to be avoided.

If 1D arrays work, then arrays of pointers work, too. A similar
extension could work for multidimension arrays not declared as
pointers:

iny y[1:10][1:10];

though avoiding a pointer with address zero gets harder.  It is
especially hard with smaller address spaces.

Seems to me, then, that it isn't so hard to implement non 0 origin,
though it does complicate things.

An important part of early C was its simplicity. This does complicate
things more than necessary, especially for problems otherwise written
in assembly.

-- glen

[toc] | [prev] | [next] | [standalone]

#76992

On 23/11/2015 13:47, glen herrmannsfeldt wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

> One is that 0 origin is more obvious to assembly programmers
> on most systems. That might be enough.

I wonder what the language would have looked like if we'd catered for 
all the other supposed preferences of assembly programmers?

And in assembly of course, you can also choose any array start index you 
like. But it means having to be aware of it every time you access an 
array element and modifying the instruction as needed.

Wouldn't it good if we could invent a 'higher level' language, where we 
state the array lower bound in just one place, then we don't need to 
worry about it every time we write a[i]?

> Also, C uses [] for both arrays (after they decay to pointers)
> and for pointers. For 1D arrays, the two are pretty much the same,
> but not for higher dimensions.

They're the same for higher dimensions too, if you choose to delegate 
array handling to the pointer mechanism (where're you dealing with 
pointers to elements, not arrays or pointers to arrays).

  It seems to me that C could have
> allowed specifiable origin for the array case, but not the pointer
> case.

Yes, because the two are different. I suppose it must have seemed a good 
idea in 1972...


> (WARNING: hypothetical, non-standard C ahead)
>
> int x[-10:10];
>
> for(i=-10; i<=10;i++) x[i]=0;
>
> This still leaves open what x does as a function argument.
>
> It is about as easy to pass the address of x[0] as of x[-10], so
> we don't have to decide yet.
>
> Would it have been too strange to allow x[-10:10] in one function,
> but, passed as an argument the caller gets x[0:20]?

It depends on how pedantic the language type system chooses to be. Here, 
with the arrays compatible apart from the lower bound, there isn't any 
particular problem.

> Assumed shape, pass by descriptor, arrays in Fortran pretty much
> work that way. (The origin is 1 in the called routine, unless
> a different origin is specified.)

I think Fortran didn't always have sight of the subroutine being called. 
So neither caller nor callee would know what lower bound was used by the 
other. I guess that's fixed now.

> Seems to me, then, that it isn't so hard to implement non 0 origin,
> though it does complicate things.

In C, or in general? Because I believe some languages have managed it!

> An important part of early C was its simplicity. This does complicate
> things more than necessary, especially for problems otherwise written
> in assembly.

I've been used N-based arrays in language as simple as C for many years, 
and it has never been an issue.

But I think C is stuck with 0-based simply because most people are 
against it.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#77009

On Monday November 23 2015 09:50, in comp.lang.c, "BartC" <bc@freeuk.com>
wrote:

> On 23/11/2015 13:47, glen herrmannsfeldt wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> 
>> One is that 0 origin is more obvious to assembly programmers
>> on most systems. That might be enough.

No, I didn't write that at all. That came from glen herrmannsfeldt's post.

[snip]

>> Also, C uses [] for both arrays (after they decay to pointers)
>> and for pointers. For 1D arrays, the two are pretty much the same,
>> but not for higher dimensions.

That also came from glen

[snip]

Bart, please check your attributions before posting. I do not like people
putting words in my mouth.

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#77012

On 11/23/2015 12:01 PM, Lew Pitcher wrote:
> On Monday November 23 2015 09:50, in comp.lang.c, "BartC" <bc@freeuk.com>
> wrote:
> 
>> On 23/11/2015 13:47, glen herrmannsfeldt wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>
>>> One is that 0 origin is more obvious to assembly programmers
>>> on most systems. That might be enough.
> 
> No, I didn't write that at all. That came from glen herrmannsfeldt's post.

While this message contains an attribution line for you, it doesn't
actually attribute anything to you. The convention is that any text
corresponding to a given attribution line has one more '>' at the
beginning than the attribution line itself. There are no such lines in
BartC's message. All of the lines which have the same number of '>' as
your attribution line are, in accordance with that convention, being
attributed to glen.

BartC should have removed your attribution line, since there's no
corresponding attributed text - but he's not misattributing anything.

[toc] | [prev] | [next] | [standalone]

#77016

On Monday November 23 2015 12:12, in comp.lang.c, "James Kuyper"
<jameskuyper@verizon.net> wrote:

> On 11/23/2015 12:01 PM, Lew Pitcher wrote:
>> On Monday November 23 2015 09:50, in comp.lang.c, "BartC" <bc@freeuk.com>
>> wrote:
>> 
>>> On 23/11/2015 13:47, glen herrmannsfeldt wrote:
>>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>
>>>> One is that 0 origin is more obvious to assembly programmers
>>>> on most systems. That might be enough.
>> 
>> No, I didn't write that at all. That came from glen herrmannsfeldt's post.
> 
> While this message contains an attribution line for you, it doesn't
> actually attribute anything to you.

On reread, it appears that you are correct and I jumped the gun on my reply to
BartC.

BartC: I apologize. I was mistaken.


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#77041

BartC <bc@freeuk.com> wrote:

(snip, I wrote)
>> One is that 0 origin is more obvious to assembly programmers
>> on most systems. That might be enough.
 
> I wonder what the language would have looked like if we'd catered for 
> all the other supposed preferences of assembly programmers?
 
> And in assembly of course, you can also choose any array start index you 
> like. But it means having to be aware of it every time you access an 
> array element and modifying the instruction as needed.

One case I know is translation tables for S/360 (and successor)
TR (translate) instruction. It is not unusual to want to translate
only the digits (X'F0' to X'F9') and not need the 240 entries 
before them. You can put -240 (or -C'0') in every TR instruction,
but you can also EQU a new symbol.

TABLE EQU *-240
      DC   C'0123456789ABCDEF'

that works as long as *-240 is addressable, which usually means not
before the beginning of the CSECT.

> Wouldn't it good if we could invent a 'higher level' language, where we 
> state the array lower bound in just one place, then we don't need to 
> worry about it every time we write a[i]?
 
(snip on other things related to non-0 origin in C)

(then I wrote)
>> Assumed shape, pass by descriptor, arrays in Fortran pretty much
>> work that way. (The origin is 1 in the called routine, unless
>> a different origin is specified.)
 
> I think Fortran didn't always have sight of the subroutine being called. 
> So neither caller nor callee would know what lower bound was used by the 
> other. I guess that's fixed now.

Assumed shape is new in Fortran 90. It passes arrays by descriptor,
such that the bounds are also passed. But as seen in the called
routine, the bounds are from 1, or an origin specified in the
called routine, not the original origin.

The only array passing method available (without cheating) in PL/I
passes by descriptor, using both lower and upper bound.
(It is a favorite trick to call Fortran, and maybe C, passing the
first element of an array by reference.)
 
>> Seems to me, then, that it isn't so hard to implement non 0 origin,
>> though it does complicate things.
 
> In C, or in general? Because I believe some languages have managed it!

Yes, I meand in C. 
 
>> An important part of early C was its simplicity. This does complicate
>> things more than necessary, especially for problems otherwise written
>> in assembly.
 
> I've been used N-based arrays in language as simple as C for many years, 
> and it has never been an issue.
 
> But I think C is stuck with 0-based simply because most people are 
> against it.

I have converted some 1 origin based programs to C, and it takes much
longer than might be expected, to get the arrays right.

-- glen

[toc] | [prev] | [next] | [standalone]

#77008

On Monday, 23 November 2015 13:47:25 UTC, glen herrmannsfeldt  wrote:
> Arrays with specifiable lower bound go back at least to PL/I
> from about 1964, and I believe ALGOL even earlier.

Yes, ALGOL 60 arrays have a specified lower bound.

> If arrays decay to a pointer to element zero, instead of the
> first element, they pretty much work the expected way.

Yes, that's how ALGOL 60 implementations usually did it. 
If C did that, along with specifiable lower bounds, 
then *(a+n) and a[n] would always mean the same thing.
-- 

[toc] | [prev] | [next] | [standalone]

#76876

On 22/11/2015 15:00, glen herrmannsfeldt wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>> On Saturday November 21 2015 21:50, in comp.lang.c, "G G" <gdotone@gmail.com>
>> wrote:
>
>>> Just a curiosity about C starting array subscripts at 0 as
>>> opposed to starting at 1.
>
> (snip)
>
>> It is implicit in the structure of arrays.
>
>> K&R "The C Programming Language", Chapter 5 "Pointers and Arrays"
>>
>>   "Rather more surprising, at least at first sight, is the fact that a
>>    reference to a[i] can also be written as *(a+i). In evaluating a[i], C
>>    converts it to *(a+i) immediately; the two forms are completely
>>    equivalent."
>
>> If arrays started at any subscript other than zero, then
>>   a[subscript]
>> could /not/ be equivalent to
>>   *(a+subscript)
>
> Yes, but a[i] could have been equivalent to *(a+i-1).

There are some problems with adding 1-based arrays to C as well as 
0-based ones.

The correspondence of a[i] with *(a+i) is the main one. The issue is 
that if a is an int array, then 'a' decays to a pointer to an int. All 
array type information including its lower bound is lost.

In that case, for a 1-based array of int, then *a is still the first 
element, which necessarily has to be the same as *(a+0).

So with pointer-based indexing, offsets still need to be 0-based. That 
means that a[i] only corresponds exactly with *(a+i) when the array is 
zero-based.

Another problem is that in C, dynamic arrays tend not to be implemented 
with a pointer to an array (which gives an opportunity to define the 
lower bound), even though C is capable. Instead pointers to an array 
element are used, such as 'int *a'.

Then pointer accesses such as *(a+i) will necessarily be 0-based. But if 
array notation is used like a[i], that would also need to be 0-based in 
the absence of a proper array type.

Clearly C is not going to make it easy to add any other lower bound than 
zero!

The wrong choices of pointer syntax play a part too. Suppose this is a 
1-based dynamic array declaration:

  int (*a)[1:] = malloc(...);

Then that array needs to be indexed as (*a)[i]. That's not going to be 
popular. A postfix dereference op would have meant no parentheses and 
made it more palatable, but still not as nice as no reference op at all 
as using a simple pointer and 0 lower bound mean you just write a[i].

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#76908

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> BartC <bc@freeuk.com> writes:
>>Clearly C is not going to make it easy to add any other lower bound than 
>>zero!
>
>   The following code is /not/ standard-conformant C,
>   but it might have the intended effect under some
>   implementations:
>
> #include <stdio.h>
>
> int main( void )
> { int zero_based[] ={ 1, 2, 3 };
>   int * const one_based = zero_based - 1;
>   printf
>   ( "{ %d, %d, %d }\n", 
>     one_based[ 1 ], one_based[ 2 ], one_based[ 3 ]); }
>
>   There are some automatic translation tools that transform
>   from Pascal to C, which have to deal with this problem, IIRC.
>   Once, one such a tool was used to compile TeX with a C compiler. 

I think the C version of "Numerical Recipes" (originally written
using Fortran) used that trick.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#76914

On 22/11/2015 15:49, Stefan Ram wrote:
> BartC <bc@freeuk.com> writes:
>> Clearly C is not going to make it easy to add any other lower bound than
>> zero!
>
>    The following code is /not/ standard-conformant C,
>    but it might have the intended effect under some
>    implementations:
>
> #include <stdio.h>
>
> int main( void )
> { int zero_based[] ={ 1, 2, 3 };
>    int * const one_based = zero_based - 1;
>    printf
>    ( "{ %d, %d, %d }\n",
>      one_based[ 1 ], one_based[ 2 ], one_based[ 3 ]); }
>
>    There are some automatic translation tools that transform
>    from Pascal to C, which have to deal with this problem, IIRC.
>    Once, one such a tool was used to compile TeX with a C compiler.

It's not much of a problem when targeting C code. So this fragment of 
non-C 1-based code (but it can easily be N-based too):

ref[]int aa
[10]int bb
int i,j,k

k:=aa^[i]+bb[i]

gets turned into this 0-based C code:

  int (*aa)[];
  int bb[10];
  int i,j,k;

  k=(*aa)[i-1]+bb[i-1];

But I don't know if those tricks with offsetting pointers are practical 
for normal coding. For example, if you want to pass 'one-based' to a 
function, then that function will have to cooperate with the scheme.

You also wouldn't be able to use *one_based to access the first element. 
etc.

You'd have to keep pretty much on your toes.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#76847

On 22/11/2015 02:50, G G wrote:
> Just a curiosity about C starting array subscripts at 0 as
> opposed to starting at 1.
>
> Did Kernaghan or Ritchie ever explain why they chose to
> have array subscripts start a 0?
>
> Is there a thought behind it, like it's intuitive to think that
> way when programming so close to the hardware (assembly
> language), so to speak? Or was it thought to be a natural
> starting position? Or just to be different from Pascal cause
> of copyrights, intellectual property... ?
>
> Just curious.

In comp.std.c, the on-going thread 'Proposal to remove forward 
declaration requirements' has a sub-thread on the subject, among other 
things. You might have a job finding it though. (First post mentioning 
starting at 0, by Rick C Hodgin, 19th Nov 2015, 15:24 GMT.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#76855

In article <n2s58k$gi2$1@dont-email.me>, BartC  <bc@freeuk.com> wrote:
>On 22/11/2015 02:50, G G wrote:
>> Just a curiosity about C starting array subscripts at 0 as
>> opposed to starting at 1.
>>
>> Did Kernaghan or Ritchie ever explain why they chose to
>> have array subscripts start a 0?
>>
>> Is there a thought behind it, like it's intuitive to think that
>> way when programming so close to the hardware (assembly
>> language), so to speak? Or was it thought to be a natural
>> starting position? Or just to be different from Pascal cause
>> of copyrights, intellectual property... ?
>>
>> Just curious.
>
>In comp.std.c, the on-going thread 'Proposal to remove forward 
>declaration requirements' has a sub-thread on the subject, among other 
>things. You might have a job finding it though. (First post mentioning 
>starting at 0, by Rick C Hodgin, 19th Nov 2015, 15:24 GMT.)

What's Rick's next project going to be?

I can see it now: Proposal to rename "printf" (which is, obviously, way too
many letters) to a much-more-pleasing-to-the-eye "pf".

Works for me!

-- 
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy  of the church so decides." 

    - Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

[toc] | [prev] | [next] | [standalone]

#76853

On Sun, 2015-11-22, G G wrote:
> Just a curiosity about C starting array subscripts at 0 as
> opposed to starting at 1.
>
> Did Kernaghan or Ritchie ever explain why they chose to 
> have array subscripts start a 0?
>
> Is there a thought behind it, like it's intuitive to think that
> way when programming so close to the hardware (assembly 
> language), so to speak? Or was it thought to be a natural 
> starting position? Or just to be different from Pascal cause 
> of copyrights, intellectual property... ?
>
> Just curious.

There's some material at
https://en.wikipedia.org/wiki/Zero-based_numbering

I suspect that Pascal wasn't a factor in the decision; there were many
earlier languages to look at, including actual ancestors to C.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#76856

On Sunday, November 22, 2015 at 6:24:24 AM UTC-5, Jorgen Grahn wrote:
> 
> There's some material at
> https://en.wikipedia.org/wiki/Zero-based_numbering

hmm. ok. this was an interesting read. thanks.

 

[toc] | [prev] | [next] | [standalone]

#76857

> Just a curiosity about C starting array subscripts at 0 as
> opposed to starting at 1.

Another curiosity is why most programmers think that the starting point must be forced on them by the programming language instead of being part of the array definition, provided by the programmer.

There are many cases where starting at 0 is convenient. There are others, where starting at 1 is convenient and there might as well be others where starting at *any* arbitrary index is appropriate for the given problem domain.

It is reasonable that the programmer might want to *choose* his array starting index, for whatever reason. But it is unreasonable to expect that the choice will be already made for us (that is, there will be no choice), whatever that number is.

-- 
Maciej Sobczak * http://www.inspirel.com

[toc] | [prev] | [next] | [standalone]

#76859

On 22/11/2015 12:54, see.my.homepage@gmail.com wrote:
>
>> Just a curiosity about C starting array subscripts at 0 as
>> opposed to starting at 1.
>
> Another curiosity is why most programmers think that the starting point must be forced on them by the programming language instead of being part of the array definition, provided by the programmer.
>
> There are many cases where starting at 0 is convenient. There are others, where starting at 1 is convenient and there might as well be others where starting at *any* arbitrary index is appropriate for the given problem domain.
>
> It is reasonable that the programmer might want to *choose* his array starting index, for whatever reason. But it is unreasonable to expect that the choice will be already made for us (that is, there will be no choice), whatever that number is.

Yes, exactly.

I find 1 to be the most natural start index.

Sometimes it needs to be 0 (usually, because I'm translating code 
written in C! Revising code to change the start index is not simple and 
introduces bugs).

And every so often, the array really demands that it be indexed from N.

Quite a few languages (mainly, the ones not touched by C), allow any 
start index.

In C, a start index of 0 is necessary because array indexing is 
inextricably linked with pointers, and with pointer to an array, you 
need an offset of 0 to refer to the first element.

I suppose it can be an advantage of sorts in not needing to ever think 
about what the start index is, because it's always 0. But you can apply 
that argument to to 1 too..

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#76883

On 11/22/2015 07:54 AM, see.my.homepage@gmail.com wrote:
> 
>> Just a curiosity about C starting array subscripts at 0 as
>> opposed to starting at 1.
> 
> Another curiosity is why most programmers think that the starting
> point must be forced on them by the programming language instead of
> being part of the array definition, provided by the programmer.

I don't believe that "most programmers" feel that way. Instead, I think
that most programmers are unaware of the issue. Of the programmers who
are aware of it, I suspect that most of them feel only that some
programming languages DO force the choice of the starting point; not
that those languages MUST force the choice.

> It is reasonable that the programmer might want to *choose* his array
> starting index, for whatever reason. But it is unreasonable to expect
> that the choice will be already made for us (that is, there will be
> no choice), whatever that number is.

When an expectation that you label "unreasonable" is in fact true of
many popular languages, I'd recommend reevaluating your reasons for
considering it "unreasonable" - the designers of those languages thought
they had reasons, and the users of those languages didn't find that
feature sufficiently objectionable to refuse to use them.

[toc] | [prev] | [next] | [standalone]

#76874

On Sat, 21 Nov 2015 18:50:31 -0800, G G wrote:

> Just a curiosity about C starting array subscripts at 0 as opposed to
> starting at 1.
> 
> Did Kernaghan or Ritchie ever explain why they chose to have array
> subscripts start a 0?

	They wanted to appear frugal. You see, with this approach you can 
claim to have one thing, when in fact you have two.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web