Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > type of array index?

Reply
Thread Tools

type of array index?

 
 
shmartonak@ticnet.com
Guest
Posts: n/a
 
      03-24-2005

For maximum portability what should the type of an array index be? Can
any integer type be used safely? Or should I only use an unsigned type?
Or what?

If I'm using pointers to access array elements as *(mptr+k) where I've
declared

MYTYPE *mptr;

what should be the type of 'k'? Should it be ptrdiff_t?

OT: near as I can tell my implementation of gcc doesn't have an
<stddef.h> file with ptrdiff_t defined. Am I overlooking something?

--


 
Reply With Quote
 
 
 
 
Jonathan Bartlett
Guest
Posts: n/a
 
      03-24-2005
> what should be the type of 'k'? Should it be ptrdiff_t?

It should be any type of integer.

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
 
Reply With Quote
 
 
 
 
Jonathan Bartlett
Guest
Posts: n/a
 
      03-24-2005
If you really want ptrdiff_t, it appears to be in malloc.h. stdint.h
has its limits. Interestingly, obstack.h thinks that it appears in
stddef.h, too. Perhaps someone should report that to the maintainers.
Using gcc 3.3.1.

Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      03-24-2005
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> For maximum portability what should the type of an array index be? Can
> any integer type be used safely? Or should I only use an unsigned type?
> Or what?


Essentially, there are two choices:
1. Use int whenever sufficient, use a wider type when necessary.
Sufficient means sufficient with respect to the minimal requirements
from the standard.
2. Always use size_t.
size_t is sufficient for all arrays and for indexing all storage you
can allocate (bytewise).

Personally, I favor the second approach but I am not religious
about it. Drawbacks: You have to be more careful due to the inherent
nonnegativity of the index type, e.g.
for (i=MAX-1; i>=0; i--)
operation_on(array[i]);
either has to become
for (i=MAX; i>0; i--)
operation_on(array[i-1]);
or
for (i=MAX-1; i!=-1; i--)
operation_on(array[i]);
which I like better.
As for int: It is possible that int indices are "faster" as int usually
is the "natural" integer type of the system but if this is really
the case, one can still optimise where necessary. Undefined behaviour
due to forgetting about "old-fashioned" 16 bit ints and resulting
strange errors are less nice.

However, there have been many discussions about that.
Do as you like and look for range/sanity checks as necessary (in both
cases).


> If I'm using pointers to access array elements as *(mptr+k) where I've
> declared
>
> MYTYPE *mptr;
>
> what should be the type of 'k'? Should it be ptrdiff_t?


Any integer type which suffices for your range requirements.
I would use ptrdiff_t only where appropriate.

If ssize_t had made it into the standard, I'd suggest that.


> OT: near as I can tell my implementation of gcc doesn't have an
> <stddef.h> file with ptrdiff_t defined. Am I overlooking something?


That you cannot find it in the header file does not mean that
it is not there by some magic (or simply comes in from another
included file).

Just try it out:
If

#include <stddef.h>
int main (void) { int a[3]; ptrdiff_t b = (a+2)-(a+1); return 0; }

does not compile, file a bug report.
If it does compile without the #include, do the same.


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      03-24-2005
Jonathan Bartlett wrote:
> If you really want ptrdiff_t, it appears to be in malloc.h. stdint.h


malloc.h is not a C standard header, thus offtopic.

> has its limits. Interestingly, obstack.h thinks that it appears in


dito for obstack.h

> stddef.h, too. Perhaps someone should report that to the maintainers.
> Using gcc 3.3.1.


If including <stddef.h> has the effect that size_t or ptrdiff_t
are available when they were not before, everything is fine:
The implementation may do each and everything behind the scenes.

I did not yet have any problems with gcc's compliance in _this_
respect.


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Andrey Tarasevich
Guest
Posts: n/a
 
      03-24-2005
(E-Mail Removed) wrote:
> For maximum portability what should the type of an array index be? Can
> any integer type be used safely? Or should I only use an unsigned type?
> Or what?
>
> If I'm using pointers to access array elements as *(mptr+k) where I've
> declared
>
> MYTYPE *mptr;
>
> what should be the type of 'k'? Should it be ptrdiff_t?


It depends.

In concrete (non-generic) code the type is usually dictated by the
natural properties of the application area. You should normally have a
type that designates the total amount of objects of 'MYTYPE' already.
This type is an obvious candidate for the array index type. For example,
if this is an array of, say, file handles and you use 'unsigned short'
object to store the total number of files, then 'unsigned short' would
be a natural choice for the index type for this array. This, of course,
applies only if you don't care about negative indexing. For negative
indexing you'd have to use either 'short' or 'int', depending on the
required range.

In generic code 'ptrdiff_t' is the first candidate for array index type,
which also supports negative indices. If you don't care about negative
indices or you want to emphasize the fact that negative indices are not
allowed in some context, then you might want to go with 'size_t'. This
unsigned type is large enough for indexing of any array.

However, from the pedantic point of view, 'size_t' is intended to
implement a concept of "object size", while array index is more related
to the concept of "container element count". These two concepts are not
related and using 'size_t' for array indexing is a conceptual error. It
might be more elegant to "hide" the 'size_t' behind a typedef name as
follows

typedef size_t pos_ptrdiff_t;

and use 'pos_ptrdiff_t' for generic non-negative array indexing.

--
Best regards,
Andrey Tarasevich
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      03-24-2005
Andrey Tarasevich wrote:
> (E-Mail Removed) wrote:
>
>>For maximum portability what should the type of an array index be? Can
>>any integer type be used safely? Or should I only use an unsigned type?
>>Or what?
>>
>>If I'm using pointers to access array elements as *(mptr+k) where I've
>>declared
>>
>> MYTYPE *mptr;
>>
>>what should be the type of 'k'? Should it be ptrdiff_t?

>
>
> It depends.
>
> In concrete (non-generic) code the type is usually dictated by the
> natural properties of the application area. You should normally have a
> type that designates the total amount of objects of 'MYTYPE' already.
> This type is an obvious candidate for the array index type. For example,
> if this is an array of, say, file handles and you use 'unsigned short'
> object to store the total number of files, then 'unsigned short' would
> be a natural choice for the index type for this array. This, of course,
> applies only if you don't care about negative indexing. For negative
> indexing you'd have to use either 'short' or 'int', depending on the
> required range.
>
> In generic code 'ptrdiff_t' is the first candidate for array index type,
> which also supports negative indices. If you don't care about negative
> indices or you want to emphasize the fact that negative indices are not
> allowed in some context, then you might want to go with 'size_t'. This
> unsigned type is large enough for indexing of any array.
>
> However, from the pedantic point of view, 'size_t' is intended to
> implement a concept of "object size", while array index is more related
> to the concept of "container element count". These two concepts are not
> related and using 'size_t' for array indexing is a conceptual error. It
> might be more elegant to "hide" the 'size_t' behind a typedef name as
> follows
>
> typedef size_t pos_ptrdiff_t;
>
> and use 'pos_ptrdiff_t' for generic non-negative array indexing.


Nicely put.
Something for a confessing size_t-user like me to think about
Grabbed and stored.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      03-24-2005
Jonathan Bartlett <(E-Mail Removed)> writes:
> If you really want ptrdiff_t, it appears to be in malloc.h. stdint.h
> has its limits. Interestingly, obstack.h thinks that it appears in
> stddef.h, too. Perhaps someone should report that to the
> maintainers. Using gcc 3.3.1.


ptrdiff_t is declared in <stddef.h>. <malloc.h> is not a standard
header (the malloc() function is declared in <stdlib.h>), nor is
<obstack.h>. And <stdint.h> is a standard header in C99, but not in
C90, so not all current implementations will provide it (though it's
not too difficult to roll your own).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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.
 
Reply With Quote
 
those who know me have no need of my name
Guest
Posts: n/a
 
      03-25-2005
in comp.lang.c i read:

>OT: near as I can tell my implementation of gcc doesn't have an
><stddef.h> file with ptrdiff_t defined. Am I overlooking something?


there is no requirement by the standard that a file exist -- it's allowed
to be magical, perhaps entirely internal. though in fact it does exist,
it's just that it's not where you are looking.

--
a signature
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      03-25-2005
"Andrey Tarasevich" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> (E-Mail Removed) wrote:
> > For maximum portability what should the type of an array index be? Can
> > any integer type be used safely? Or should I only use an unsigned type?
> > Or what?
> >
> > If I'm using pointers to access array elements as *(mptr+k) where I've
> > declared
> >
> > MYTYPE *mptr;
> >
> > what should be the type of 'k'? Should it be ptrdiff_t?

>
> It depends.

....
> In generic code 'ptrdiff_t' is the first candidate for array index type,
> which also supports negative indices. If you don't care about negative
> indices or you want to emphasize the fact that negative indices are not
> allowed in some context, then you might want to go with 'size_t'. This
> unsigned type is large enough for indexing of any array.
>
> However, from the pedantic point of view, 'size_t' is intended to
> implement a concept of "object size", while array index is more related
> to the concept of "container element count". These two concepts are not
> related and using 'size_t' for array indexing is a conceptual error.


Since an array is an object, and size_t is defined to be large enough to
represent the size of any object, size_t naturally must be able to represent
any possible array subscript.

In _The Standard C Library_, P. J. Plauger writes:

"Unlike ptrdiff_t, however, size_t is /very/ useful. It is the safest type
to represent any integer data object you use as an array subscript. You
don't have to worry if a small array evolves into a very large one as the
program changes. Subscript arithmetic will never overflow when performed in
type size_t." and "You should make a point of using type size_t /anywhere/
your program performs array subscripting or address arithmetic." (emphasis
in original)

The only reason one might prefer ptrdiff_t for array subscripts is where,
due to looping, you need the ability to count down past zero. In this case,
I would prefer ssize_t (where available) over ptrdiff_t, but first I'd
consider whether it was feasible to restructure the loop condition such that
a signed subscript wasn't needed.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
type(d) != type(d.copy()) when type(d).issubclass(dict) kj Python 5 12-26-2010 06:48 PM
array type has incomplete element type shrav4ever@gmail.com C Programming 1 01-17-2008 08:42 AM
#define ALLOCIT(Type) ((Type*) malloc (sizeof (Type))) Yevgen Muntyan C Programming 10 02-13-2007 02:52 AM
Re: Type casting- a larger type to a smaller type pete C Programming 4 04-02-2004 05:19 PM
Re: Type casting- a larger type to a smaller type heyo C Programming 3 04-01-2004 06:35 PM



Advertisments