Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #56922 > unrolled thread
| Started by | jeffkrob16@gmail.com |
|---|---|
| First post | 2015-02-03 09:33 -0800 |
| Last post | 2015-02-05 15:12 -0800 |
| Articles | 20 on this page of 144 — 26 participants |
Back to article view | Back to comp.lang.c
Fortran Guy Learning C - Structures... jeffkrob16@gmail.com - 2015-02-03 09:33 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-03 17:59 +0000
Re: Fortran Guy Learning C - Structures... James Kuyper <jameskuyper@verizon.net> - 2015-02-03 13:01 -0500
Re: Fortran Guy Learning C - Structures... Barry Schwarz <schwarzb@dqel.com> - 2015-02-03 10:49 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <invalid@see.sig.invalid> - 2015-02-03 18:54 +0000
Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 11:50 -0800
Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 12:07 -0800
Re: Fortran Guy Learning C - Structures... Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-02-03 15:14 -0500
Re: Fortran Guy Learning C - Structures... Barry Schwarz <schwarzb@dqel.com> - 2015-02-03 15:06 -0800
Re: Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 22:19 -0800
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-03 21:40 +0000
Re: Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 22:56 -0800
Re: Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-03 23:02 -0800
Re: Fortran Guy Learning C - Structures... asetofsymbols@gmail.com - 2015-02-04 00:01 -0800
Re: Fortran Guy Learning C - Structures... jeffkrob16@gmail.com - 2015-02-04 10:53 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-04 11:21 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-04 19:32 +0000
Re: Fortran Guy Learning C - Structures... Barry Schwarz <schwarzb@dqel.com> - 2015-02-04 11:59 -0800
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-04 15:30 -0800
Re: Fortran Guy Learning C - Structures... jeffkrob16@gmail.com - 2015-02-04 19:41 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 04:06 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-05 10:36 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 10:59 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-05 11:03 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-05 12:30 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 12:46 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 12:49 +0000
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-05 15:08 -0800
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-05 08:48 -0800
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-05 15:16 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-05 23:35 +0000
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-07 12:11 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-07 12:22 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-07 22:03 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-07 14:47 -0800
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-07 17:15 -0800
Re: Fortran Guy Learning C - Structures... Ian Collins <ian-news@hotmail.com> - 2015-02-08 17:22 +1300
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-08 02:47 -0800
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 11:20 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-08 14:36 -0800
Re: Fortran Guy Learning C - Structures... Ian Collins <ian-news@hotmail.com> - 2015-02-09 11:51 +1300
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 15:02 -0800
Re: Fortran Guy Learning C - Structures... Geoff <geoff@invalid.invalid> - 2015-02-08 16:55 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-09 03:24 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 11:56 +0000
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-09 14:25 +0100
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 14:00 +0000
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-09 15:26 +0100
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 14:39 +0000
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-09 16:59 +0100
Re: Fortran Guy Learning C - Structures... raltbos@xs4all.nl (Richard Bos) - 2015-02-09 16:01 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-09 13:39 +0000
Re: Fortran Guy Learning C - Structures... James Kuyper <jameskuyper@verizon.net> - 2015-02-09 09:46 -0500
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 14:50 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 08:22 -0800
Re: Fortran Guy Learning C - Structures... gazelle@shell.xmission.com (Kenny McCormack) - 2015-02-09 13:24 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 16:03 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-09 11:01 -0800
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 21:54 +0000
Re: Fortran Guy Learning C - Structures... Öö Tiib <ootiib@hot.ee> - 2015-02-09 19:22 -0800
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-10 11:34 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-10 14:15 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-10 00:38 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-10 09:21 +0000
Re: Fortran Guy Learning C - Structures... Ian Collins <ian-news@hotmail.com> - 2015-02-10 22:24 +1300
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-10 09:25 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-10 09:03 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-10 17:12 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-10 09:56 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-10 18:12 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-10 11:24 -0800
Re: Fortran Guy Learning C - Structures... gazelle@shell.xmission.com (Kenny McCormack) - 2015-02-10 20:18 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-10 09:16 -0800
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-10 22:12 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-11 02:58 +0000
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-10 19:00 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-11 07:56 +0000
Re: Fortran Guy Learning C - Structures... David Thompson <dave.thompson2@verizon.net> - 2015-02-22 18:08 -0500
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-10 16:01 -0800
Re: Fortran Guy Learning C - Structures... Ian Collins <ian-news@hotmail.com> - 2015-02-10 11:26 +1300
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-10 10:29 +0100
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 08:32 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-09 11:09 -0800
Re: Fortran Guy Learning C - Structures... gazelle@shell.xmission.com (Kenny McCormack) - 2015-02-09 19:39 +0000
Re: Fortran Guy Learning C - Structures... Martin Shobe <martin.shobe@yahoo.com> - 2015-02-09 14:04 -0600
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 12:24 -0800
Re: Fortran Guy Learning C - Structures... David Brown <david.brown@hesbynett.no> - 2015-02-10 10:34 +0100
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 11:42 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-07 22:50 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-07 17:07 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 11:29 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-08 12:14 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 13:44 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-08 22:39 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 11:12 -0800
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 20:01 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 20:06 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 21:04 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 21:11 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-08 23:48 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 13:30 -0800
Re: Fortran Guy Learning C - Structures... Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-02-08 16:47 -0500
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 14:53 -0800
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-09 02:31 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 10:35 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-09 13:57 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 07:59 -0800
Re: Fortran Guy Learning C - Structures... Öö Tiib <ootiib@hot.ee> - 2015-02-09 18:15 -0800
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-10 05:54 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 16:17 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 22:04 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 14:57 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 23:45 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-09 02:53 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 09:29 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 10:10 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 11:24 +0000
Re: Fortran Guy Learning C - Structures... Ike Naar <ike@iceland.freeshell.org> - 2015-02-09 17:36 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-09 17:56 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 10:51 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 11:10 +0000
Re: Fortran Guy Learning C - Structures... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-02-09 11:25 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 11:43 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-10 02:13 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-10 03:26 +0000
Re: Fortran Guy Learning C - Structures... raltbos@xs4all.nl (Richard Bos) - 2015-02-09 21:18 +0000
Re: Fortran Guy Learning C - Structures... Bartc <bc@freeuk.com> - 2015-02-09 23:11 +0000
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 12:10 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-08 11:18 -0800
Re: Fortran Guy Learning C - Structures... Richard Heathfield <rjh@cpax.org.uk> - 2015-02-08 19:27 +0000
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-09 15:00 -0800
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-09 16:00 -0800
Re: Fortran Guy Learning C - Structures... Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-02-05 02:49 -0800
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-05 11:16 +0000
Re: Fortran Guy Learning C - Structures... Keith Thompson <kst-u@mib.org> - 2015-02-05 09:00 -0800
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-06 00:29 +0000
Re: Fortran Guy Learning C - Structures... Robert Wessel <robertwessel2@yahoo.com> - 2015-02-05 19:20 -0600
Re: Fortran Guy Learning C - Structures... "Charles Richmond" <numerist@aquaporin4.com> - 2015-02-06 16:15 -0600
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-07 00:57 +0000
Re: Fortran Guy Learning C - Structures... Kaz Kylheku <kaz@kylheku.com> - 2015-02-07 01:40 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-07 08:22 +0000
Re: Fortran Guy Learning C - Structures... glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-02-07 12:06 +0000
Re: Fortran Guy Learning C - Structures... John Bode <jfbode1029@gmail.com> - 2015-02-06 15:03 -0800
Re: Fortran Guy Learning C - Structures... hormelfree@gmail.com - 2015-02-05 15:12 -0800
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-02-08 13:30 -0800 |
| Message-ID | <lnr3u0hz0k.fsf@nuthaus.mib.org> |
| In reply to | #57146 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 08/02/15 20:01, Bartc wrote:
>> On 08/02/2015 19:12, Keith Thompson wrote:
> <snip>
>>>
>>> Look at this piece of code:
>>>
>>> x = y + z;
>>>
>>> Any of x, y, and z could be either an integer or a floating-point
>>> object. In some languages, including C, they could be certain
>>> combinations of integers and pointers.
>>
>> Sure, but in the absence of any "*" prefix operators, you know there is
>> no pointer dereferencing going on. Not so with array indexing.
>>
>> With a[i][j], is that a direct, rectangular array,
>
> No such thing in C, unless you mean a rather long, very thin rectangle.
>
> a[i][j] means *(a[i] + j), which means *( *(a + i) + j)
>
> so you know for sure that there is some pointer dereferencing going on.
>
> <snip>
Yes, but `a` could be defined as a 2-dimensional array (i.e., an array
of arrays):
int a[10][10];
int i = 5;
int j = 5;
a[i][j] = 42;
The [] operator is defined to operate on a pointer (which must point to
an array element), and in this case there are two levels of an array
expression decaying to a pointer and being dereferenced. But Bartc is
correct in saying that given `a[i][j]`, `a` could have been defined as
an array of arrays (which can reasonably be called a rectangular array).
--
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]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-02-08 16:47 -0500 |
| Message-ID | <rPQBw.36321$oR6.25972@fx01.iad> |
| In reply to | #57149 |
On Sunday February 8 2015 16:30, in comp.lang.c, "Keith Thompson" <kst-u@mib.org> wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 08/02/15 20:01, Bartc wrote: >>> On 08/02/2015 19:12, Keith Thompson wrote: >> <snip> >>>> >>>> Look at this piece of code: >>>> >>>> x = y + z; >>>> >>>> Any of x, y, and z could be either an integer or a floating-point >>>> object. In some languages, including C, they could be certain >>>> combinations of integers and pointers. >>> >>> Sure, but in the absence of any "*" prefix operators, you know there is >>> no pointer dereferencing going on. Not so with array indexing. >>> >>> With a[i][j], is that a direct, rectangular array, >> >> No such thing in C, unless you mean a rather long, very thin rectangle. >> >> a[i][j] means *(a[i] + j), which means *( *(a + i) + j) >> >> so you know for sure that there is some pointer dereferencing going on. >> >> <snip> > > Yes, but `a` could be defined as a 2-dimensional array (i.e., an array > of arrays): > > int a[10][10]; > int i = 5; > int j = 5; > a[i][j] = 42; > > The [] operator is defined to operate on a pointer (which must point to > an array element), and in this case there are two levels of an array > expression decaying to a pointer and being dereferenced. But Bartc is > correct in saying that given `a[i][j]`, `a` could have been defined as > an array of arrays (which can reasonably be called a rectangular array). Quote: "In C, by definition a two-dimensional array is really a one-dimensional array, each of whose elements is an array." Kernighan & Richie, The C Programming Language (1978, Bell Telephone Laboratories) -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-02-08 14:53 -0800 |
| Message-ID | <lnmw4ohv6c.fsf@nuthaus.mib.org> |
| In reply to | #57150 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Sunday February 8 2015 16:30, in comp.lang.c, "Keith Thompson"
> <kst-u@mib.org> wrote:
[...]
>> The [] operator is defined to operate on a pointer (which must point to
>> an array element), and in this case there are two levels of an array
>> expression decaying to a pointer and being dereferenced. But Bartc is
>> correct in saying that given `a[i][j]`, `a` could have been defined as
>> an array of arrays (which can reasonably be called a rectangular array).
>
> Quote: "In C, by definition a two-dimensional array is really a
> one-dimensional array, each of whose elements is an array."
Yes, did I imply otherwise? I used the phrase "rectangular array"
because that's the term Bartc used upthread. The standard calls it
either an "array of arrays" or a "2-dimensional array", but IMHO the
phrase "rectangular array" is also reasonable.
--
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]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-02-09 02:31 +0000 |
| Message-ID | <mb9658$l4$1@speranza.aioe.org> |
| In reply to | #57150 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: (snip) > Quote: "In C, by definition a two-dimensional array is really a > one-dimensional array, each of whose elements is an array." I suppose, but not quite as much as in COBOL. As I understand it (never having actually written, or even compiled a program that I didn't write in COBOL) that it only allows for 1D arrays. If you want more than a 1D array, you have to use structures. That is, you can have an array of structures, where each structure member is also an array, but you can't have arrays of arrays. There is a PL/I feature, which I believe came from COBOL, that allows one to move the subscripts around between nesting levels. Instead of saying A(I).B(J).C(K), one is allowed to say A.B.C(I,J,K). So, it looks like a 3D array, but is actually an array of structures of array of structure of array of structure. In addition PL/I, and I believe also COBOL, allows one to omit nesting levels where the result isn't ambiguous, such that you can write C(I,J,K) without the A.B. qualifier, or maybe A.C(I,J,K) if it would be ambiguous without the A, but not with A. (PL/I does allow for more than 1D, but still has these features.) But C arrays that are declared like: int x[10][10]; act more like 2D arrays than arrays of arrays. Specifically, for arrays or arrays one should be able to make the subarrays of different lengths. On the other hand, a Java array: int [][] x=new int[10][10]; is really an array of 10 object references to 10 arrays. One can change elements of x[i] to reference other arrays: x[3]=new int[20]; and test the length of subarrays individually with x[i].length. The C array int x[10][10]; has 100 contiguous (at least as contiguous as int y[100]) elements, and can be cast to a 1D array and dereferenced as a 1D array. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-02-09 10:35 +0000 |
| Message-ID | <mba2gs$are$1@dont-email.me> |
| In reply to | #57161 |
On 09/02/2015 02:31, glen herrmannsfeldt wrote: > Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: >> Quote: "In C, by definition a two-dimensional array is really a >> one-dimensional array, each of whose elements is an array." > But C arrays that are declared like: > > int x[10][10]; > > act more like 2D arrays than arrays of arrays. AIUI, a 'proper' 2D array only allows you to access individual elements, as x[i][j], and not rows or columns, as x[i]. That's not much of a benefit! > On the other hand, a Java array: > > int [][] x=new int[10][10]; > > is really an array of 10 object references to 10 arrays. One can > change elements of x[i] to reference other arrays: > > x[3]=new int[20]; > > and test the length of subarrays individually with > > x[i].length. Java doesn't have pointers. At least not as an explicit part of the language. C can't make up it's mind whether pointers associated with arrays are explicit or not: in some places they are, in others they aren't. (Actually some people here can't make up their minds as to whether C even has arrays or not!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-02-09 13:57 +0000 |
| Message-ID | <mbaeca$muu$1@speranza.aioe.org> |
| In reply to | #57165 |
Bartc <bc@freeuk.com> wrote:
(snip, I wrote)
>> But C arrays that are declared like:
>> int x[10][10];
>> act more like 2D arrays than arrays of arrays.
> AIUI, a 'proper' 2D array only allows you to access individual
> elements, as x[i][j], and not rows or columns, as x[i].
> That's not much of a benefit!
I never heard that definition before.
Traditionally processors did things serially, so the only way to
access an array was element by element. The order of access might
be in question.
Unlike C, PL/I and newer versions of Fortran have array expressions.
You can use arrays in assignments such as:
X=Y;
or
X=3;
It gets interesting when you say:
X=X+X(10);
PL/I requires such to be processed element by element, in row-major
order, such that the new value of X(10) is used as soon as it changes.
Fortran requires that the result be "as if" the whole right side
is evaluated before the left side is changed. That is, the old value
is used for each.
Both PL/I and new Fortran allow for array cross-sections.
You can use whole rows or columns, such as:
Y(*,3)=4;
Y(3,*)=5;
The subroutine call mechanism for both allows using such as a
subroutine or function argument, even when the resulting array
section is non-continuous.
There is no suggestion in either PL/I or Fortran that arrays
are not 2D or higher.
(snip, I also wrote)
>> On the other hand, a Java array:
>> int [][] x=new int[10][10];
>> is really an array of 10 object references to 10 arrays. One can
>> change elements of x[i] to reference other arrays:
>> x[3]=new int[20];
>> and test the length of subarrays individually with
>> x[i].length.
> Java doesn't have pointers.
Java has object references which have some, but not all, of the
properties of C pointers.
> At least not as an explicit part of the language.
> C can't make up it's mind whether pointers associated with
> arrays are explicit or not: in some places they are, in others they
> aren't. (Actually some people here can't make up their minds as to
> whether C even has arrays or not!)
Java object references reference a whole object. Arrays are objects,
and array access is done as an object reference. There is no operation
like C pointer arithmetic. If you want to pass a subarray in Java,
you pass the reference to the whole array, and the information
needed to find the subarray.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-02-09 07:59 -0800 |
| Message-ID | <lna90nhy81.fsf@nuthaus.mib.org> |
| In reply to | #57165 |
Bartc <bc@freeuk.com> writes:
> On 09/02/2015 02:31, glen herrmannsfeldt wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>> Quote: "In C, by definition a two-dimensional array is really a
>>> one-dimensional array, each of whose elements is an array."
>
>> But C arrays that are declared like:
>>
>> int x[10][10];
>>
>> act more like 2D arrays than arrays of arrays.
I don't know what that's supposed to mean. A 2D array *is* an array of
arrays, nothing more, nothing less.
> AIUI, a 'proper' 2D array only allows you to access individual elements,
> as x[i][j], and not rows or columns, as x[i]. That's not much of a benefit!
I don't know what you mean by "proper".
A column of a 2D array is not contiguous, and is not an object. A row
of a 2D array is an array. Given 'int x[10][10];`, `x[i]` is a
perfectly valid expression of type `int[10]`. `&x[i]` is the address of
a row of `x`, and `sizeof x[i] == 10 * sizeof (int)`. Like any C array
expression, it decays to a pointer to its first element (i.e., to
`x[i][0]`) in most contexts.
[...]
> Java doesn't have pointers. At least not as an explicit part of the
> language. C can't make up it's mind whether pointers associated with
> arrays are explicit or not: in some places they are, in others they
> aren't. (Actually some people here can't make up their minds as to
> whether C even has arrays or not!)
If you think that C "can't make up its mind", that probably just means
that you don't understand it well enough. C's treatment of arrays and
pointers can be confusing, but it's consistent and unambiguous. Anyone
who thinks that C doesn't have arrays is quite simply wrong.
--
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]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-02-09 18:15 -0800 |
| Message-ID | <4b8f815f-bbc7-4415-946d-9f6ebd4cf181@googlegroups.com> |
| In reply to | #57183 |
On Monday, 9 February 2015 18:00:13 UTC+2, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > > > AIUI, a 'proper' 2D array only allows you to access individual elements, > > as x[i][j], and not rows or columns, as x[i]. That's not much of a benefit! > > I don't know what you mean by "proper". > > A column of a 2D array is not contiguous, and is not an object. A row > of a 2D array is an array. Given 'int x[10][10];`, `x[i]` is a > perfectly valid expression of type `int[10]`. `&x[i]` is the address of > a row of `x`, and `sizeof x[i] == 10 * sizeof (int)`. Like any C array > expression, it decays to a pointer to its first element (i.e., to > `x[i][0]`) in most contexts. May be above is important to emphasise for "Fortran guy". In Fortran the arrays are column-major while in C they are row-major. So in Fortran the columns are contiguous but in C the rows are contiguous.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-02-10 05:54 +0000 |
| Message-ID | <mbc6e5$3sg$1@speranza.aioe.org> |
| In reply to | #57208 |
Öö Tiib <ootiib@hot.ee> wrote: > On Monday, 9 February 2015 18:00:13 UTC+2, Keith Thompson wrote: (snip) (in C ...) >> A column of a 2D array is not contiguous, and is not an object. A row >> of a 2D array is an array. Given 'int x[10][10];`, `x[i]` is a >> perfectly valid expression of type `int[10]`. `&x[i]` is the >> address of a row of `x`, and `sizeof x[i] == 10 * sizeof (int)`. >> Like any C array expression, it decays to a pointer to its >> first element (i.e., to `x[i][0]`) in most contexts. > May be above is important to emphasise for "Fortran guy". In Fortran the > arrays are column-major while in C they are row-major. So in Fortran > the columns are contiguous but in C the rows are contiguous. But also Fortran (since Fortran 90) knows what to do with a non-contiguous array. You can pass a row or column to a called subroutine, which can then process it as a 1D array. (Though sometimes it is faster to make a contiguous copy and process the copy.) -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-02-09 16:17 +0000 |
| Message-ID | <87zj8n12ks.fsf@bsb.me.uk> |
| In reply to | #57165 |
Bartc <bc@freeuk.com> writes: > On 09/02/2015 02:31, glen herrmannsfeldt wrote: <snip> >> But C arrays that are declared like: >> >> int x[10][10]; >> >> act more like 2D arrays than arrays of arrays. > > AIUI, a 'proper' 2D array only allows you to access individual > elements, as x[i][j], and not rows or columns, as x[i]. That's not > much of a benefit! Languages with sophisticated support for arrays do permit access to both rows and columns, precisely because it is beneficial. Some permit access to contiguous multidimensional sub-arrays or other useful parts such as the diagonal or the upper and lower triangles. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-08 22:04 +0000 |
| Message-ID | <mb8mgf$8ef$1@dont-email.me> |
| In reply to | #57149 |
On 08/02/15 21:30, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 08/02/15 20:01, Bartc wrote: >>> On 08/02/2015 19:12, Keith Thompson wrote: >> <snip> >>>> >>>> Look at this piece of code: >>>> >>>> x = y + z; >>>> >>>> Any of x, y, and z could be either an integer or a floating-point >>>> object. In some languages, including C, they could be certain >>>> combinations of integers and pointers. >>> >>> Sure, but in the absence of any "*" prefix operators, you know there is >>> no pointer dereferencing going on. Not so with array indexing. >>> >>> With a[i][j], is that a direct, rectangular array, >> >> No such thing in C, unless you mean a rather long, very thin rectangle. >> >> a[i][j] means *(a[i] + j), which means *( *(a + i) + j) >> >> so you know for sure that there is some pointer dereferencing going on. >> >> <snip> > > Yes, but `a` could be defined as a 2-dimensional array (i.e., an array > of arrays): > > int a[10][10]; > int i = 5; > int j = 5; > a[i][j] = 42; > > The [] operator is defined to operate on a pointer (which must point to > an array element), and in this case there are two levels of an array > expression decaying to a pointer and being dereferenced. But Bartc is > correct in saying that given `a[i][j]`, `a` could have been defined as > an array of arrays (which can reasonably be called a rectangular array). We're tilting at windmills. As we both know and as you rightly say, an array in C is defined in terms of pointers (6.5.2.1). It is therefore necessarily true that an array of arrays is also ultimately defined in terms of pointers, and accessing an array element is isomorphic to dereferencing a pointer. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-02-08 14:57 -0800 |
| Message-ID | <lniofchuzw.fsf@nuthaus.mib.org> |
| In reply to | #57151 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> We're tilting at windmills. As we both know and as you rightly say, an
> array in C is defined in terms of pointers (6.5.2.1). It is therefore
> necessarily true that an array of arrays is also ultimately defined in
> terms of pointers, and accessing an array element is isomorphic to
> dereferencing a pointer.
No, an array is not defined in terms of pointers (6.2.5p20). I can
write
int arr[10][20];
and there's not a pointer in sight, either a pointer object or a pointer
value. (Pointer values will likely be created if I perform operations on
arr.)
The indexing operator, which requires an array object (explicitly or
implicitly created) to work properly, is of course defined in terms of
pointers. Arrays themselves are not.
--
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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-08 23:45 +0000 |
| Message-ID | <mb8sdt$1f0$1@dont-email.me> |
| In reply to | #57156 |
On 08/02/15 22:57, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > [...] >> We're tilting at windmills. As we both know and as you rightly say, an >> array in C is defined in terms of pointers (6.5.2.1). It is therefore >> necessarily true that an array of arrays is also ultimately defined in >> terms of pointers, and accessing an array element is isomorphic to >> dereferencing a pointer. > > No, an array is not defined in terms of pointers (6.2.5p20). My apologies for being insufficiently precise (i.e. wrong!). An array /access/ is defined in terms of pointers. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-02-09 02:53 +0000 |
| Message-ID | <mb97f7$2lt$1@speranza.aioe.org> |
| In reply to | #57151 |
Richard Heathfield <rjh@cpax.org.uk> wrote:
(snip)
> We're tilting at windmills. As we both know and as you rightly say, an
> array in C is defined in terms of pointers (6.5.2.1). It is therefore
> necessarily true that an array of arrays is also ultimately defined in
> terms of pointers, and accessing an array element is isomorphic to
> dereferencing a pointer.
OK, but say you do:
int a[3][3];
int (*b)[3]={a[0], a[1], a[3]};
You can now reference either
a[i][j] or b[i][j], but the code generated for a and b access
will be very different. a is accessed like a 2D array, where
b is accessed as an array of pointers to arrays.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-09 09:29 +0000 |
| Message-ID | <mb9ukq$sfe$1@dont-email.me> |
| In reply to | #57162 |
On 09/02/15 02:53, glen herrmannsfeldt wrote:
<snip>
>
> OK, but say you do:
>
> int a[3][3];
>
> int (*b)[3]={a[0], a[1], a[3]};
...you have an illegal access of a non-existent array, a[3]. But let's
assume you meant a[2].
>
> You can now reference either
>
> a[i][j] or b[i][j], but the code generated for a and b access
> will be very different. a is accessed like a 2D array, where
> b is accessed as an array of pointers to arrays.
a[i][j] is equivalent to * ( *(a + i) + j)
b[i][j] is equivalent to * ( *(b + i) + j)
Perhaps you would be kind enough to point out the difference?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-02-09 10:10 +0000 |
| Message-ID | <mba12c$5j4$1@dont-email.me> |
| In reply to | #57163 |
On 09/02/2015 09:29, Richard Heathfield wrote:
> On 09/02/15 02:53, glen herrmannsfeldt wrote:
>
> <snip>
>
>>
>> OK, but say you do:
>>
>> int a[3][3];
>>
>> int (*b)[3]={a[0], a[1], a[3]};
>
> ...you have an illegal access of a non-existent array, a[3]. But let's
> assume you meant a[2].
Actually the whole initialisation is illegal. b is a single pointer not
an array of 3.
>> You can now reference either
>>
>> a[i][j] or b[i][j], but the code generated for a and b access
>> will be very different. a is accessed like a 2D array, where
>> b is accessed as an array of pointers to arrays.
>
> a[i][j] is equivalent to * ( *(a + i) + j)
>
> b[i][j] is equivalent to * ( *(b + i) + j)
>
> Perhaps you would be kind enough to point out the difference?
This is exactly my point.
If trying to learn about how pointers work, it doesn't help that after
setting up your data structures either using or not using pointers, that
the resulting expressions to access them are exactly the same.
(Maybe then stick to pointers to scalars or structs for learning, where
the use of such data in expressions mirrors their declarations. Remember
that was the big deal about C's famously convoluted type-decl syntax?)
> Perhaps you would be kind enough to point out the difference?
The difference lies here, in the declarations:
>> int a[3][3];
>>
>> int (*b)[3];
And also in the code that is generated as glen said.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-09 11:24 +0000 |
| Message-ID | <mba5ca$m13$1@dont-email.me> |
| In reply to | #57164 |
On 09/02/15 10:10, Bartc wrote:
> On 09/02/2015 09:29, Richard Heathfield wrote:
>> On 09/02/15 02:53, glen herrmannsfeldt wrote:
>>
>> <snip>
>>
>>>
>>> OK, but say you do:
>>>
>>> int a[3][3];
>>>
>>> int (*b)[3]={a[0], a[1], a[3]};
>>
>> ...you have an illegal access of a non-existent array, a[3]. But let's
>> assume you meant a[2].
>
> Actually the whole initialisation is illegal. b is a single pointer not
> an array of 3.
So it is.
>
>>> You can now reference either
>>>
>>> a[i][j] or b[i][j], but the code generated for a and b access
>>> will be very different. a is accessed like a 2D array, where
>>> b is accessed as an array of pointers to arrays.
>>
>> a[i][j] is equivalent to * ( *(a + i) + j)
>>
>> b[i][j] is equivalent to * ( *(b + i) + j)
>>
>> Perhaps you would be kind enough to point out the difference?
>
> This is exactly my point.
Huh? A simple rule yields simple consequences, and this is somehow a
problem?
> If trying to learn about how pointers work, it doesn't help that after
> setting up your data structures either using or not using pointers, that
> the resulting expressions to access them are exactly the same.
I don't think this is any more difficult to understand than the fact that:
a = b + c;
has type double, whereas:
d = e + f;
has type int.
> (Maybe then stick to pointers to scalars or structs for learning, where
> the use of such data in expressions mirrors their declarations. Remember
> that was the big deal about C's famously convoluted type-decl syntax?)
The maxim that declaration reflects use is, at best, an ideal.
> > Perhaps you would be kind enough to point out the difference?
>
> The difference lies here, in the declarations:
>
> >> int a[3][3];
> >>
> >> int (*b)[3];
>
> And also in the code that is generated as glen said.
Surely that's up to the compiler? Compilers are not required to generate
code in such a way as to support your argument.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2015-02-09 17:36 +0000 |
| Message-ID | <slrn3vfsmdhs20.dok.ike@iceland.freeshell.org> |
| In reply to | #57163 |
On 2015-02-09, Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 09/02/15 02:53, glen herrmannsfeldt wrote:
>
><snip>
>
>>
>> OK, but say you do:
>>
>> int a[3][3];
>>
>> int (*b)[3]={a[0], a[1], a[3]};
>
> ...you have an illegal access of a non-existent array, a[3].
It's not illegal to have a pointer pointing just past the end of
an array. Of course such a pointer should not be dereferenced, but
that is not happening here.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-09 17:56 +0000 |
| Message-ID | <mbasb1$qnv$1@dont-email.me> |
| In reply to | #57189 |
On 09/02/15 17:36, Ike Naar wrote:
> On 2015-02-09, Richard Heathfield <rjh@cpax.org.uk> wrote:
>> On 09/02/15 02:53, glen herrmannsfeldt wrote:
>>
>><snip>
>>
>>>
>>> OK, but say you do:
>>>
>>> int a[3][3];
>>>
>>> int (*b)[3]={a[0], a[1], a[3]};
>>
>> ...you have an illegal access of a non-existent array, a[3].
>
> It's not illegal to have a pointer pointing just past the end of
> an array. Of course such a pointer should not be dereferenced, but
> that is not happening here.
Not my day, is it?
Mind you, it should be said (and I think has already been said) that in
fact b is a pointer to an array of three ints, not an array of three
pointers to int, so what we actually have here is a constraint violation
(6.5.16.1(1)) requiring a diagnostic message.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-02-09 10:51 +0000 |
| Message-ID | <87oap34atn.fsf@bsb.me.uk> |
| In reply to | #57162 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
> (snip)
>
>> We're tilting at windmills. As we both know and as you rightly say, an
>> array in C is defined in terms of pointers (6.5.2.1). It is therefore
>> necessarily true that an array of arrays is also ultimately defined in
>> terms of pointers, and accessing an array element is isomorphic to
>> dereferencing a pointer.
>
> OK, but say you do:
>
> int a[3][3];
>
> int (*b)[3]={a[0], a[1], a[3]};
That's two constraint violations! b is a scalar, not an aggregate, and
the type of the initialisers is int * not int (*)[3].
The (*b)[3] syntax makes me think you are thinking about pointers to
arrays. To make an array of pointers to the sub-arrays of a, you'd
write:
int (*b[3])[3] = {&a[0], &a[1], &a[2]};
but then
> You can now reference either
>
> a[i][j] or b[i][j],
is not true (you'd have to write (*b[i])[j] for access b), so you most
likely meant to say
int *b[3] = {a[0], a[1], a[2]};
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web