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

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

offset 1 list indexing

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

Contents

  offset 1 list indexing Michael Press <rubrum@pacbell.net> - 2011-06-14 21:02 -0700
    Re: offset 1 list indexing Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-06-14 21:29 -0700
    Re: offset 1 list indexing Nobody <nobody@nowhere.com> - 2011-06-15 05:58 +0100
    Re: offset 1 list indexing Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-15 02:51 -0700
    Re: offset 1 list indexing jacob navia <jacob@spamsink.net> - 2011-06-15 12:01 +0200
      Re: offset 1 list indexing gwowen <gwowen@gmail.com> - 2011-06-15 03:55 -0700
    Re: offset 1 list indexing Mark Bluemel <mark_bluemel@pobox.com> - 2011-06-15 11:07 +0100
      Re: offset 1 list indexing Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-06-15 07:30 -0700
        Re: offset 1 list indexing Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-15 11:19 -0600
          Re: offset 1 list indexing James Kuyper <jameskuyper@verizon.net> - 2011-06-15 22:57 -0400
          Re: offset 1 list indexing Joseph Huber <joseph.huber@NOREPLY.web.de> - 2011-06-16 09:28 +0200
            Re: offset 1 list indexing Angel <angel+news@spamcop.net> - 2011-06-16 15:05 +0000
            Re: offset 1 list indexing jacob navia <jacob@spamsink.net> - 2011-06-24 01:14 +0200
        Re: offset 1 list indexing Michael Press <rubrum@pacbell.net> - 2011-06-15 15:33 -0700
      Re: offset 1 list indexing Michael Press <rubrum@pacbell.net> - 2011-06-15 15:28 -0700
        Re: offset 1 list indexing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-15 23:34 -0400
          Re: offset 1 list indexing Michael Press <rubrum@pacbell.net> - 2011-06-15 21:42 -0700
            Re: offset 1 list indexing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-16 08:18 -0400
              Re: offset 1 list indexing James Kuyper <jameskuyper@verizon.net> - 2011-06-16 08:32 -0400
                Re: offset 1 list indexing Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-06-16 06:29 -0700
                  Re: offset 1 list indexing James Kuyper <jameskuyper@verizon.net> - 2011-06-16 09:43 -0400
                Re: offset 1 list indexing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-16 20:50 -0400
                  Re: offset 1 list indexing James Kuyper <jameskuyper@verizon.net> - 2011-06-17 08:56 -0400
                    Re: offset 1 list indexing cri@tiac.net (Richard Harter) - 2011-06-17 15:11 +0000
              Re: offset 1 list indexing Michael Press <rubrum@pacbell.net> - 2011-06-16 23:54 -0700
                Re: offset 1 list indexing Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-06-23 21:45 +0300
                  Re: offset 1 list indexing Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-25 09:30 -0700
                    Re: offset 1 list indexing pete <pfiland@mindspring.com> - 2011-06-25 13:10 -0400
                      Re: offset 1 list indexing cri@tiac.net (Richard Harter) - 2011-06-25 18:18 +0000
                        Re: offset 1 list indexing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-25 15:56 -0400
                          Re: offset 1 list indexing James Kuyper <jameskuyper@verizon.net> - 2011-06-25 17:42 -0400
                            Re: offset 1 list indexing cri@tiac.net (Richard Harter) - 2011-06-26 04:15 +0000
                              Re: offset 1 list indexing pete <pfiland@mindspring.com> - 2011-06-26 01:51 -0400
                                Re: offset 1 list indexing cri@tiac.net (Richard Harter) - 2011-06-26 15:48 +0000
                                  Re: offset 1 list indexing pete <pfiland@mindspring.com> - 2011-06-27 00:30 -0400
                                Re: offset 1 list indexing Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-06-28 21:26 +0300
                                  Re: offset 1 list indexing pete <pfiland@mindspring.com> - 2011-06-28 23:36 -0400
                                    Re: offset 1 list indexing cri@tiac.net (Richard Harter) - 2011-06-29 15:28 +0000
                                      Re: offset 1 list indexing pete <pfiland@mindspring.com> - 2011-06-30 15:02 -0400
                              Re: offset 1 list indexing Ike Naar <ike@sverige.freeshell.org> - 2011-06-26 07:00 +0000
                                Re: offset 1 list indexing cri@tiac.net (Richard Harter) - 2011-06-26 15:20 +0000
                          Re: offset 1 list indexing cri@tiac.net (Richard Harter) - 2011-06-26 03:41 +0000
                            Re: offset 1 list indexing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-26 08:51 -0400
                              Re: offset 1 list indexing cri@tiac.net (Richard Harter) - 2011-06-26 15:32 +0000
                                Re: offset 1 list indexing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-26 11:48 -0400
                                  Re: offset 1 list indexing cri@tiac.net (Richard Harter) - 2011-06-26 16:43 +0000
                                  Re: offset 1 list indexing Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-06-28 21:30 +0300
                        Re: offset 1 list indexing Karl Malbrain <malbrain@yahoo.com> - 2011-06-28 14:13 -0700
                    Re: offset 1 list indexing Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-06-28 21:14 +0300
                      Re: offset 1 list indexing Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-29 01:14 -0700
    Re: offset 1 list indexing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-15 07:21 -0400
    Re: offset 1 list indexing Shao Miller <sha0.miller@gmail.com> - 2011-06-15 10:09 -0400
      Re: offset 1 list indexing Michael Press <rubrum@pacbell.net> - 2011-06-15 15:38 -0700
    Re: offset 1 list indexing China Blue Dolls <chine.bleu@yahoo.com> - 2011-06-25 21:04 -0700
      Re: offset 1 list indexing Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-26 09:01 -0400
      Re: offset 1 list indexing Michael Press <rubrum@pacbell.net> - 2011-06-26 13:15 -0700

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

#6971

On Sun, 26 Jun 2011 07:00:04 +0000 (UTC), Ike Naar
<ike@sverige.freeshell.org> wrote:

>On 2011-06-26, Richard Harter <cri@tiac.net> wrote:
>> In other words, if you want to do one based indexing and you're
>> willing to discard a location, you do something like:
>>
>> a = malloc((n+1)*sizeof(node));  /* Yes, Keith I know you don't need
>>                                     parentheses for sizeof.  */
>
>In the above case, you do need them; you can re-write it as
>
>    a = malloc((n+1) * sizeof *a);
>
>and then you don't need them.

Actually, sans declaration of node we don't know whether parentheses
are needed or not.  That said, your point is well taken.

>
>> heap = a+1;
>
>I don't follow; if ``heap'' is supposed to be one-based, wouldn't
>it simply be:
>
>    heap = malloc((n+1) * sizeof *heap);  /* or ... sizeof(node) */
> 
>and then ignore heap[0], use heap[1..n], and free(heap) when done?

At this remove I'm not sure what I was thinking about.  As you say, it
is simpler.  

This may be it, though.  There is a general issue, which is that it
can be easy to confuse allocation addresses and entity addresses when
they aren't the same.  As an entity the one based heap begins at
heap+1, whereas the allocation address is at heap.  If you pass heap
to a function which do you use?  If you pass allocation addresses then
the receiving code must be able to extract the entity address from the
allocation address.  In this case array indexing implictly takes care
of the extraction; in the general case things can get messy.  In the
general case passing the entity address is cleaner.   

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

#6949

On Sat, 25 Jun 2011 15:56:36 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

>On 6/25/2011 2:18 PM, Richard Harter wrote:
>> On Sat, 25 Jun 2011 13:10:35 -0400, pete<pfiland@mindspring.com>
>> wrote:
>>> [...]
>>> Tim Rentsch wrote:
>>>> [...]
>>> I don't see what the problem is with 0 based heaps.
>>
>> It's slightly awkward.  In a 0 based heap the children of node n are
>> at nodes 2*n+1 and 2*n+2.  The parent of node n is at (n-1)/2.  In a 1
>> based heap the children of node n are at 2*n and 2*n+2; the parent of
>> node n is at n/2.
>
>     Tastes vary, but I prefer correct awkwardness to graceful error.

And so you should.  I, on the other hand, prefer correct gracefulness
to awkward error.

>
>>> Not being able to write C code without 1 based arrays
>>> is like not be able to ride a bicycle without training wheels.
>>
>> True.  Then again, civilized languages let you select the array base
>> to suit the problem.
>
>     It's a poor workman who blames his tools.
 

Just so.  It is also a poor workman who chooses a bad tool when a good
tool is available.  Do you have any other platitudes you wish to share
with us?

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

#6964

On 6/25/2011 11:41 PM, Richard Harter wrote:
> On Sat, 25 Jun 2011 15:56:36 -0400, Eric Sosman
> <esosman@ieee-dot-org.invalid>  wrote:
>
>> On 6/25/2011 2:18 PM, Richard Harter wrote:
>>> On Sat, 25 Jun 2011 13:10:35 -0400, pete<pfiland@mindspring.com>
>>> wrote:
>>>> [...]
>>>> Tim Rentsch wrote:
>>>>> [...]
>>>> I don't see what the problem is with 0 based heaps.
>>>
>>> It's slightly awkward.  In a 0 based heap the children of node n are
>>> at nodes 2*n+1 and 2*n+2.  The parent of node n is at (n-1)/2.  In a 1
>>> based heap the children of node n are at 2*n and 2*n+2; the parent of
>>> node n is at n/2.
>>
>>      Tastes vary, but I prefer correct awkwardness to graceful error.
>
> And so you should.  I, on the other hand, prefer correct gracefulness
> to awkward error.

     Have you not spotted your mistake yet?

     Yes, it's a "simple" error -- but the fact that it was made
rather cuts against the arguments that 1-based indexing for heaps
is somehow "clearer" or "more natural" than 0-based.  If in fact
1-based indexing is better, why is it that you were unable to get
its arithmetic right while performing flawlessly on 0-based?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#6972

On Sun, 26 Jun 2011 08:51:18 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

>On 6/25/2011 11:41 PM, Richard Harter wrote:
>> On Sat, 25 Jun 2011 15:56:36 -0400, Eric Sosman
>> <esosman@ieee-dot-org.invalid>  wrote:
>>
>>> On 6/25/2011 2:18 PM, Richard Harter wrote:
>>>> On Sat, 25 Jun 2011 13:10:35 -0400, pete<pfiland@mindspring.com>
>>>> wrote:
>>>>> [...]
>>>>> Tim Rentsch wrote:
>>>>>> [...]
>>>>> I don't see what the problem is with 0 based heaps.
>>>>
>>>> It's slightly awkward.  In a 0 based heap the children of node n are
>>>> at nodes 2*n+1 and 2*n+2.  The parent of node n is at (n-1)/2.  In a 1
>>>> based heap the children of node n are at 2*n and 2*n+2; the parent of
>>>> node n is at n/2.
>>>
>>>      Tastes vary, but I prefer correct awkwardness to graceful error.
>>
>> And so you should.  I, on the other hand, prefer correct gracefulness
>> to awkward error.
>
>     Have you not spotted your mistake yet?
>
>     Yes, it's a "simple" error -- but the fact that it was made
>rather cuts against the arguments that 1-based indexing for heaps
>is somehow "clearer" or "more natural" than 0-based.  If in fact
>1-based indexing is better, why is it that you were unable to get
>its arithmetic right while performing flawlessly on 0-based?

Ah, you found a typo.  Well done sir.  I own my fault; I thought you
were called 1-based indexing an error; it didn't occur to me to check
for typos.  If you want to use a typo as an argument pro/con 1-based
indexing have at it.

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

#6974

On 6/26/2011 11:32 AM, Richard Harter wrote:
> On Sun, 26 Jun 2011 08:51:18 -0400, Eric Sosman
> <esosman@ieee-dot-org.invalid>  wrote:
>
>> On 6/25/2011 11:41 PM, Richard Harter wrote:
>>> On Sat, 25 Jun 2011 15:56:36 -0400, Eric Sosman
>>> <esosman@ieee-dot-org.invalid>   wrote:
>>>
>>>> On 6/25/2011 2:18 PM, Richard Harter wrote:
>>>>> On Sat, 25 Jun 2011 13:10:35 -0400, pete<pfiland@mindspring.com>
>>>>> wrote:
>>>>>> [...]
>>>>>> Tim Rentsch wrote:
>>>>>>> [...]
>>>>>> I don't see what the problem is with 0 based heaps.
>>>>>
>>>>> It's slightly awkward.  In a 0 based heap the children of node n are
>>>>> at nodes 2*n+1 and 2*n+2.  The parent of node n is at (n-1)/2.  In a 1
>>>>> based heap the children of node n are at 2*n and 2*n+2; the parent of
>>>>> node n is at n/2.
>>>>
>>>>       Tastes vary, but I prefer correct awkwardness to graceful error.
>>>
>>> And so you should.  I, on the other hand, prefer correct gracefulness
>>> to awkward error.
>>
>>      Have you not spotted your mistake yet?
>>
>>      Yes, it's a "simple" error -- but the fact that it was made
>> rather cuts against the arguments that 1-based indexing for heaps
>> is somehow "clearer" or "more natural" than 0-based.  If in fact
>> 1-based indexing is better, why is it that you were unable to get
>> its arithmetic right while performing flawlessly on 0-based?
>
> Ah, you found a typo.  Well done sir.  I own my fault; I thought you
> were called 1-based indexing an error; it didn't occur to me to check
> for typos.  If you want to use a typo as an argument pro/con 1-based
> indexing have at it.

     Already did, thanks.  The fact that the error was made, and
the fact that it escaped your notice on re-reading, both somewhat
sap the strength of your argument that the 1-based code is

	"a bit easier to read, write, and debug"
	-- Richard Harter, 6/17/2011

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#6975

On Sun, 26 Jun 2011 11:48:46 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

>On 6/26/2011 11:32 AM, Richard Harter wrote:
>> On Sun, 26 Jun 2011 08:51:18 -0400, Eric Sosman
>> <esosman@ieee-dot-org.invalid>  wrote:
>>
>>> On 6/25/2011 11:41 PM, Richard Harter wrote:
>>>> On Sat, 25 Jun 2011 15:56:36 -0400, Eric Sosman
>>>> <esosman@ieee-dot-org.invalid>   wrote:
>>>>
>>>>> On 6/25/2011 2:18 PM, Richard Harter wrote:
>>>>>> On Sat, 25 Jun 2011 13:10:35 -0400, pete<pfiland@mindspring.com>
>>>>>> wrote:
>>>>>>> [...]
>>>>>>> Tim Rentsch wrote:
>>>>>>>> [...]
>>>>>>> I don't see what the problem is with 0 based heaps.
>>>>>>
>>>>>> It's slightly awkward.  In a 0 based heap the children of node n are
>>>>>> at nodes 2*n+1 and 2*n+2.  The parent of node n is at (n-1)/2.  In a 1
>>>>>> based heap the children of node n are at 2*n and 2*n+2; the parent of
>>>>>> node n is at n/2.
>>>>>
>>>>>       Tastes vary, but I prefer correct awkwardness to graceful error.
>>>>
>>>> And so you should.  I, on the other hand, prefer correct gracefulness
>>>> to awkward error.
>>>
>>>      Have you not spotted your mistake yet?
>>>
>>>      Yes, it's a "simple" error -- but the fact that it was made
>>> rather cuts against the arguments that 1-based indexing for heaps
>>> is somehow "clearer" or "more natural" than 0-based.  If in fact
>>> 1-based indexing is better, why is it that you were unable to get
>>> its arithmetic right while performing flawlessly on 0-based?
>>
>> Ah, you found a typo.  Well done sir.  I own my fault; I thought you
>> were called 1-based indexing an error; it didn't occur to me to check
>> for typos.  If you want to use a typo as an argument pro/con 1-based
>> indexing have at it.
>
>     Already did, thanks.  The fact that the error was made, and
>the fact that it escaped your notice on re-reading, both somewhat
>sap the strength of your argument that the 1-based code is
>
>	"a bit easier to read, write, and debug"
>	-- Richard Harter, 6/17/2011

I don't agree.  The text in question is a usenet posting rather than
code; they are different animals.  You assume I re-read my text, I
merely commented on your text; your remark was sufficiently vague that
it didn't suggest to me that there was an actual error in the text.  
  
I don't know why I made that particular typo.  It may have been simple
fat fingering or it may have been the fact that I had typed 2*n+2
earlier.  Be that as it may, your argument is a non sequitur.

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

#7160

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 6/26/2011 11:32 AM, Richard Harter wrote:
> > On Sun, 26 Jun 2011 08:51:18 -0400, Eric Sosman
> > <esosman@ieee-dot-org.invalid>  wrote:
> >
> >> On 6/25/2011 11:41 PM, Richard Harter wrote:
> >>> On Sat, 25 Jun 2011 15:56:36 -0400, Eric Sosman
> >>> <esosman@ieee-dot-org.invalid>   wrote:
> >>>
> >>>> On 6/25/2011 2:18 PM, Richard Harter wrote:
> >>>>> On Sat, 25 Jun 2011 13:10:35 -0400, pete<pfiland@mindspring.com>
> >>>>> wrote:
> >>>>>> [...]
> >>>>>> Tim Rentsch wrote:
> >>>>>>> [...]
> >>>>>> I don't see what the problem is with 0 based heaps.
> >>>>>
> >>>>> It's slightly awkward.  In a 0 based heap the children of node n are
> >>>>> at nodes 2*n+1 and 2*n+2.  The parent of node n is at (n-1)/2.  In a 1
> >>>>> based heap the children of node n are at 2*n and 2*n+2; the parent of
> >>>>> node n is at n/2.
> >>>>
> >>>>       Tastes vary, but I prefer correct awkwardness to graceful error.
> >>>
> >>> And so you should.  I, on the other hand, prefer correct gracefulness
> >>> to awkward error.
> >>
> >>      Have you not spotted your mistake yet?
> >>
> >>      Yes, it's a "simple" error -- but the fact that it was made
> >> rather cuts against the arguments that 1-based indexing for heaps
> >> is somehow "clearer" or "more natural" than 0-based.  If in fact
> >> 1-based indexing is better, why is it that you were unable to get
> >> its arithmetic right while performing flawlessly on 0-based?
> >
> > Ah, you found a typo.  Well done sir.  I own my fault; I thought you
> > were called 1-based indexing an error; it didn't occur to me to check
> > for typos.  If you want to use a typo as an argument pro/con 1-based
> > indexing have at it.
> 
>      Already did, thanks.  The fact that the error was made, and
> the fact that it escaped your notice on re-reading, both somewhat
> sap the strength of your argument that the 1-based code is
> 
> 	"a bit easier to read, write, and debug"
> 	-- Richard Harter, 6/17/2011

Well, it wasn't code so isn't strictly relevant, but you proved his 
description was easy to debug.

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

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

#7166

On Jun 25, 11:18 am, c...@tiac.net (Richard Harter) wrote:
> On Sat, 25 Jun 2011 13:10:35 -0400, pete <pfil...@mindspring.com>
> wrote:
>
> >Tim Rentsch wrote:
>
> >> Phil Carmody <thefatphil_demun...@yahoo.co.uk> writes:
>
> >> > [discussing 1-origin arrays versus 0-origin arrays]
>
> >> > 0-based heaps have carbunkles. End of.
>
> >> Please excuse my temerity, but I think you are too good
> >> a programmer for this to be true.  Take a run at writing
> >> a 0-based heap, not just dashing it off but really trying
> >> to do a good clean job, and see if it comes out better
> >> than you expect.  I will if you will.
>
> >I don't see what the problem is with 0 based heaps.
>
> It's slightly awkward.  In a 0 based heap the children of node n are
> at nodes 2*n+1 and 2*n+2.  The parent of node n is at (n-1)/2.  In a 1
> based heap the children of node n are at 2*n and 2*n+2; the parent of
> node n is at n/2.
>
>
>
> >Not being able to write C code without 1 based arrays
> >is like not be able to ride a bicycle without training wheels.
>
> True.  Then again, civilized languages let you select the array base
> to suit the problem.

But C does allow you to select the base.  Just use BES (originally
from the IBM 700 series,  Block ending with symbol), and use negative
indexing down from the high end.

Karl M

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

#7158

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> 
> > [discussing 1-origin arrays versus 0-origin arrays]
> >
> > 0-based heaps have carbunkles. End of.
> 
> Please excuse my temerity, but I think you are too good
> a programmer for this to be true. 

Well thanks, but it wasn't the programmer in me speaking, 
it was the craftsman.

> Take a run at writing
> a 0-based heap, not just dashing it off but really trying
> to do a good clean job, and see if it comes out better
> than you expect.  I will if you will.

I'm a great believer that less is more. The simplicity of
the representation of the indices in binary is the epitomy
of clean. The equivalence between length of representation
and depth of the node likewise. Nothing with a '+2' in can 
ever be as clean.

I've been meaning to revisit my heap library for a while,
but I know that when I do the first thing I will do is 
remove a little inefficiency, and even looking at 0-basing
it will be the last thing on my mind. Sorry.

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

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

#7190

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>> 
>> > [discussing 1-origin arrays versus 0-origin arrays]
>> >
>> > 0-based heaps have carbunkles. End of.
>> 
>> Please excuse my temerity, but I think you are too good
>> a programmer for this to be true. 
>
> Well thanks, but it wasn't the programmer in me speaking, 
> it was the craftsman.

My comment was meant to include both aspects.

>> Take a run at writing
>> a 0-based heap, not just dashing it off but really trying
>> to do a good clean job, and see if it comes out better
>> than you expect.  I will if you will.
>
> [snip]
>
> I've been meaning to revisit my heap library for a while,
> but I know that when I do the first thing I will do is 
> remove a little inefficiency, and even looking at 0-basing
> it will be the last thing on my mind. Sorry.

I understand.  Thank you for replying.

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

#6102

On 6/15/2011 12:02 AM, Michael Press wrote:
> I want to index into a list using offset one indexing.
> The obvious thing to do is make a pointer that points
> one element before the list.
> [...]

     This is Question 6.17 on the comp.lang.c Frequently Asked
Questions (FAQ) page at <http://www.c-faq.com/>.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#6108

On 6/15/2011 00:02, Michael Press wrote:
> I want to index into a list using offset one indexing.
> The obvious thing to do is make a pointer that points
> one element before the list.
>
> void work_on_stuff(int *offset0, int length)
> {
>      int offset1 = offset0 - 1;
>
>      for(idx = 1; idx<= length; idx++)
>      {
>           ... offset1[idx] ...
>      }
> }
>
> Is this likely to fail? Possible to fail?
> Very unlikely to fail? Not guaranteed by the standard?
>

How about:

   void work_on_stuff(int * array, int length) {
       enum {start_pos = 1};
       int idx;

       for(idx = start_pos; idx <= length; ++idx) {
           #define idx (idx - start_pos)
           /* Work with array[idx] */
           ;
           #undef idx
         }
     }

?  Have a pleasant day.

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

#6123

In article <itaead$hhu$1@dont-email.me>,
 Shao Miller <sha0.miller@gmail.com> wrote:

> On 6/15/2011 00:02, Michael Press wrote:
> > I want to index into a list using offset one indexing.
> > The obvious thing to do is make a pointer that points
> > one element before the list.
> >
> > void work_on_stuff(int *offset0, int length)
> > {
> >      int offset1 = offset0 - 1;
> >
> >      for(idx = 1; idx<= length; idx++)
> >      {
> >           ... offset1[idx] ...
> >      }
> > }
> >
> > Is this likely to fail? Possible to fail?
> > Very unlikely to fail? Not guaranteed by the standard?
> >
> 
> How about:
> 
>    void work_on_stuff(int * array, int length) {
>        enum {start_pos = 1};
>        int idx;
> 
>        for(idx = start_pos; idx <= length; ++idx) {
>            #define idx (idx - start_pos)
>            /* Work with array[idx] */
>            ;
>            #undef idx
>          }
>      }
> 
> ?  Have a pleasant day.

Yes, thanks.

-- 
Michael Press

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

#6950

In article <rubrum-E97163.21022514062011@news.albasani.net>,
 Michael Press <rubrum@pacbell.net> wrote:

> I want to index into a list using offset one indexing.
> The obvious thing to do is make a pointer that points
> one element before the list.
> 
> void work_on_stuff(int *offset0, int length)
> {
>     int offset1 = offset0 - 1;
> 
>     for(idx = 1; idx <= length; idx++)
>     {
>          ... offset1[idx] ...
>     }
> }
> 
> Is this likely to fail? Possible to fail?
> Very unlikely to fail? Not guaranteed by the standard?

An assinine compiler might make a big deal that offset0-1 is an address outside 
the array and therefore an error. Any compiler you're likely to use won't have a 
problem.

You might also allocate the array with an extra element and just ignore [0]:
    int array[n+1];
    for (i=1; i<=n; i++) array[i] = f(i);
If you never use array[0], it's uninitialisedness is irrelevant.

-- 
I remember finding out about you,  |A free Thai dyed shirt in every box.
Everyday my mind is all around you,|      I'm whoever you want me to be.
Looking out from my lonely room    | Annoying Usenet one post at a time.
Day after day.                     |   At least I can stay in character.

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

#6966

On 6/26/2011 12:04 AM, China Blue Dolls wrote:
> In article<rubrum-E97163.21022514062011@news.albasani.net>,
>   Michael Press<rubrum@pacbell.net>  wrote:
>
>> I want to index into a list using offset one indexing.
>> The obvious thing to do is make a pointer that points
>> one element before the list.
>>
>> void work_on_stuff(int *offset0, int length)
>> {
>>      int offset1 = offset0 - 1;
>>
>>      for(idx = 1; idx<= length; idx++)
>>      {
>>           ... offset1[idx] ...
>>      }
>> }
>>
>> Is this likely to fail? Possible to fail?
>> Very unlikely to fail? Not guaranteed by the standard?
>
> An assinine compiler might make a big deal that offset0-1 is an address outside
> the array and therefore an error. Any compiler you're likely to use won't have a
> problem.

     AS/400 (or whatever they're calling it these days) is rather
persnickety about addresses.  I've not personally written code for
it, but an acquaintance who has done so reported

	char *p = malloc(N);  // assume success
	char *q = p + N;      // perfectly legal
	q += 42;              // undefined behavior -- but, hey...
	q -= 42;              // all back to normal now, right?
	assert (q == p + N);  // fails -- hey, what happened?

True, that's probing beyond the high end rather than the low.  But
since the hardware detects straying in one direction, it wouldn't
surprise me at all if it detected the other.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#6985

In article 
<chine.bleu-449ED4.21041325062011@news.eternal-september.org>,
 China Blue Dolls <chine.bleu@yahoo.com> wrote:

> In article <rubrum-E97163.21022514062011@news.albasani.net>,
>  Michael Press <rubrum@pacbell.net> wrote:
> 
> > I want to index into a list using offset one indexing.
> > The obvious thing to do is make a pointer that points
> > one element before the list.
> > 
> > void work_on_stuff(int *offset0, int length)
> > {
> >     int offset1 = offset0 - 1;
> > 
> >     for(idx = 1; idx <= length; idx++)
> >     {
> >          ... offset1[idx] ...
> >     }
> > }
> > 
> > Is this likely to fail? Possible to fail?
> > Very unlikely to fail? Not guaranteed by the standard?
> 
> An assinine compiler might make a big deal that offset0-1 is an address outside 
> the array and therefore an error. Any compiler you're likely to use won't have a 
> problem.
> 
> You might also allocate the array with an extra element and just ignore [0]:
>     int array[n+1];
>     for (i=1; i<=n; i++) array[i] = f(i);
> If you never use array[0], it's uninitialisedness is irrelevant.

Yes, thanks.

-- 
Michael Press

[toc] | [prev] | [standalone]

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

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

csiph-web