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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-02-09 11:51 +1300 |
| Message-ID | <cjq7j5F83mfU2@mid.individual.net> |
| In reply to | #57152 |
Malcolm McLean wrote: > On Sunday, February 8, 2015 at 7:21:00 PM UTC, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> You are using the word "array" in a manner that is quite inconsistent >> with the way the word is used by the C standard (and, as far as I can >> tell, by everyone else who posts here). >> >> Please don't do that. Perhaps you can invent another word for the >> concept you're trying to talk about. >> > Everyone else is wrong, as is the C standard. Along with every language standard I know and probably every programming book I have read. Care to cite an example of "correct" usage? > If the C standard uses a word wrongly, we need to point it out, especially > where the wrong use leads to confusion. The only confusion is the confusion you have introduced... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-02-08 15:02 -0800 |
| Message-ID | <lnegq0hur9.fsf@nuthaus.mib.org> |
| In reply to | #57152 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, February 8, 2015 at 7:21:00 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> You are using the word "array" in a manner that is quite inconsistent
>> with the way the word is used by the C standard (and, as far as I can
>> tell, by everyone else who posts here).
>>
>> Please don't do that. Perhaps you can invent another word for the
>> concept you're trying to talk about.
>>
> Everyone else is wrong, as is the C standard.
>
> If the C standard uses a word wrongly, we need to point it out, especially
> where the wrong use leads to confusion.
> The terms "buffer" and "array" have quite well-established meanings,
> I'm not using the words idiosyncratically.
I don't believe you.
Cite a reference other than your own writing that uses the word "array"
the way you do. Specifically, given:
int arr[10];
arr[0] = 10;
arr[1] = 20;
arr[2] = 30;
please cite a reference that states that elements 0, 1, and 2 of arr
constitute a 3-element "array", and that the 10 elements of arr do not
constitute a 10-element "array" (the latter is critical).
In this context, I consider the word "array" to be synonymous with the
phrase "array object". Do you? If not, what exactly is the difference?
--
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 | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-02-08 16:55 -0800 |
| Message-ID | <7uufdad245u251a7r74ledo8au0alvbqhb@4ax.com> |
| In reply to | #57152 |
On Sun, 8 Feb 2015 14:36:51 -0800 (PST), Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >On Sunday, February 8, 2015 at 7:21:00 PM UTC, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> You are using the word "array" in a manner that is quite inconsistent >> with the way the word is used by the C standard (and, as far as I can >> tell, by everyone else who posts here). >> >> Please don't do that. Perhaps you can invent another word for the >> concept you're trying to talk about. >> >Everyone else is wrong, as is the C standard. > >If the C standard uses a word wrongly, we need to point it out, especially >where the wrong use leads to confusion. >The terms "buffer" and "array" have quite well-established meanings, >I'm not using the words idiosyncratically. An array in C is quite well-defined. The fact a member of an array doesn't contain an initialized value doesn't exclude that member from that array. Furthermore, any member of an array can be initialized with any value at any time. By your own example every 10th member of your array of 1000 elements could be initialized with values or any number of members of index from 0 to 999. What would you say about an array, defined as you have defined it, that was automatically initialized with zeros in all members by the runtime before the application uses it? The array is clearly initialized with a human-sensible value, zero, and it is no longer a buffer by your own definition. One could initialize the first 10 members and then skip 100 elements and set a value for member 111. Certainly one cannot say that the first 10 elements are an array and member 111 isn't a member of that array. But you could, I am sure, but you will be wrong. A buffer, as defined in computer and programming disciplines is a contiguous region of memory or a hardware register(s) designed to store data as it is moved from one place to another. It is very clear that your usage previously cited defines an array as defined by the standard and not a buffer. An array can be /used/ as a buffer but that doesn't make it a foundation for saying the standard is wrong.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-02-09 03:24 -0800 |
| Message-ID | <507b368f-7ae8-410a-b7e6-e42f389fb2e3@googlegroups.com> |
| In reply to | #57160 |
On Monday, February 9, 2015 at 12:55:56 AM UTC, Geoff wrote:
>
> One could initialize the first 10 members and then skip 100 elements
> and set a value for member 111. Certainly one cannot say that the
> first 10 elements are an array and member 111 isn't a member of that
> array. But you could, I am sure, but you will be wrong.
>
By "array" we normally mean a data structure with members which can be
accessed by iterating through 1- N (or 0 to N-1). So basically the big sigma sum
notation in mathematics, Sigma (i=1, N) x_i /N is the mean.
You can have sparse arrays or arrays with missing members, but then they
need some other structure on top to make sense of the access, so normally
we call them "hash maps" or "look-up tables", stacks and trees might also
be implemented as a C array at a low level.
Of course you've got marginal cases, such as a 2D array defined for every
i, j except where i == j.
>
> A buffer, as defined in computer and programming disciplines is a
> contiguous region of memory or a hardware register(s) designed to
> store data as it is moved from one place to another. It is very clear
> that your usage previously cited defines an array as defined by the
> standard and not a buffer. An array can be /used/ as a buffer but that
> doesn't make it a foundation for saying the standard is wrong.
>
C doesn't make the array / buffer distinction very well. We can, for example,
set up a buffer and push a few integers into it, followed by a few floats,
followed by a few utf-8 characters. But C makes that slightly difficult
because of alignment issues. The language encourages use of buffers
which contain data elements all of the same type, which is what you
normally want in practice, and means people think of a buffer as an array
with uninitialised data in it. But "uninitialised data" is an oxymoron, which
doesn't matter, until it starts creating confusion.
int x[10] = {1, 2,3};
if(x[3] == 0)
printf("This compiler zero initialises arrays\n"):
is actually UB. You can't explain that if you think of a x as a 10 element array.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-09 11:56 +0000 |
| Message-ID | <mba784$t2g$1@dont-email.me> |
| In reply to | #57168 |
On 09/02/15 11:24, Malcolm McLean wrote:
<snip>
> int x[10] = {1, 2,3};
> if(x[3] == 0)
> printf("This compiler zero initialises arrays\n"):
>
> is actually UB. You can't explain that if you think of a x as a 10 element array.
I'll give it a try anyway.
x is an array of 10 int. It is partly-initialised, with elements 0, 1, 2
taking the values 1, 2, 3 respectively. Elements 3-9 remain indeterminate.
The comparison of x[3] with 0 invokes undefined behaviour because the
value of x[3] is indeterminate. This has nothing to do with the fact
that x[3] is an array member and everything to do with the fact that its
value is indeterminate.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-02-09 14:25 +0100 |
| Message-ID | <mbacel$h39$1@dont-email.me> |
| In reply to | #57172 |
On 09/02/15 12:56, Richard Heathfield wrote:
> On 09/02/15 11:24, Malcolm McLean wrote:
>
> <snip>
>
>> int x[10] = {1, 2,3};
>> if(x[3] == 0)
>> printf("This compiler zero initialises arrays\n"):
>>
>> is actually UB. You can't explain that if you think of a x as a 10
>> element array.
>
>
> I'll give it a try anyway.
>
> x is an array of 10 int. It is partly-initialised, with elements 0, 1, 2
> taking the values 1, 2, 3 respectively. Elements 3-9 remain indeterminate.
>
> The comparison of x[3] with 0 invokes undefined behaviour because the
> value of x[3] is indeterminate. This has nothing to do with the fact
> that x[3] is an array member and everything to do with the fact that its
> value is indeterminate.
>
That would be a perfectly good explanation, if Malcolm's claim of UB
were true. But writing "int x[10] = {1, 2, 3};" is exactly equivalent
to writing "int x[10] = {1, 2, 3, 0, 0, 0, 0, 0, 0, 0};", and reading
x[3] is well-defined as it has been initialised to 0.
(See section 6.7.9, paragraph 21 of N1570)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-09 14:00 +0000 |
| Message-ID | <mbaeh4$ot1$1@dont-email.me> |
| In reply to | #57174 |
On 09/02/15 13:25, David Brown wrote:
> On 09/02/15 12:56, Richard Heathfield wrote:
>> On 09/02/15 11:24, Malcolm McLean wrote:
>>
>> <snip>
>>
>>> int x[10] = {1, 2,3};
>>> if(x[3] == 0)
>>> printf("This compiler zero initialises arrays\n"):
>>>
>>> is actually UB. You can't explain that if you think of a x as a 10
>>> element array.
>>
>>
>> I'll give it a try anyway.
>>
>> x is an array of 10 int. It is partly-initialised, with elements 0, 1, 2
>> taking the values 1, 2, 3 respectively. Elements 3-9 remain indeterminate.
(No, Richard, they don't. See below.)
>>
>> The comparison of x[3] with 0 invokes undefined behaviour because the
>> value of x[3] is indeterminate. This has nothing to do with the fact
>> that x[3] is an array member and everything to do with the fact that its
>> value is indeterminate.
>>
>
> That would be a perfectly good explanation, if Malcolm's claim of UB
> were true.
And it is, so it is. (Except that it isn't. See below.)
> But writing "int x[10] = {1, 2, 3};" is exactly equivalent
> to writing "int x[10] = {1, 2, 3, 0, 0, 0, 0, 0, 0, 0};", and reading
> x[3] is well-defined as it has been initialised to 0.
That would be true if x were static-qualified (which it isn't)...
Or it could be at file scope. But it can't be at file scope, because it
is immediately followed by an 'if'...
>
> (See section 6.7.9, paragraph 21 of N1570)
>
...or it could be that I'm completely and utterly wrong. And the scary
thing is that I frequently take advantage of this extraordinarily useful
feature, so I should have known better. Sorry about that.
Here is the constraint:
"If there are fewer initializers in a brace-enclosed list than there are
elements or members of an aggregate, or fewer characters in a string
literal used to initialize an array of known size than there are
elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage
duration."
David 1, Richard 0. Hopefully, that's only a half-time score...
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-02-09 15:26 +0100 |
| Message-ID | <mbag0s$vq0$1@dont-email.me> |
| In reply to | #57177 |
On 09/02/15 15:00, Richard Heathfield wrote:
> On 09/02/15 13:25, David Brown wrote:
>> On 09/02/15 12:56, Richard Heathfield wrote:
>>> On 09/02/15 11:24, Malcolm McLean wrote:
>>>
>>> <snip>
>>>
>>>> int x[10] = {1, 2,3};
>>>> if(x[3] == 0)
>>>> printf("This compiler zero initialises arrays\n"):
>>>>
>>>> is actually UB. You can't explain that if you think of a x as a 10
>>>> element array.
>>>
>>>
>>> I'll give it a try anyway.
>>>
>>> x is an array of 10 int. It is partly-initialised, with elements 0, 1, 2
>>> taking the values 1, 2, 3 respectively. Elements 3-9 remain
>>> indeterminate.
>
> (No, Richard, they don't. See below.)
>
>>>
>>> The comparison of x[3] with 0 invokes undefined behaviour because the
>>> value of x[3] is indeterminate. This has nothing to do with the fact
>>> that x[3] is an array member and everything to do with the fact that its
>>> value is indeterminate.
>>>
>>
>> That would be a perfectly good explanation, if Malcolm's claim of UB
>> were true.
>
> And it is, so it is. (Except that it isn't. See below.)
>
>> But writing "int x[10] = {1, 2, 3};" is exactly equivalent
>> to writing "int x[10] = {1, 2, 3, 0, 0, 0, 0, 0, 0, 0};", and reading
>> x[3] is well-defined as it has been initialised to 0.
>
> That would be true if x were static-qualified (which it isn't)...
>
> Or it could be at file scope. But it can't be at file scope, because it
> is immediately followed by an 'if'...
>
>>
>> (See section 6.7.9, paragraph 21 of N1570)
>>
>
> ...or it could be that I'm completely and utterly wrong. And the scary
> thing is that I frequently take advantage of this extraordinarily useful
> feature, so I should have known better. Sorry about that.
>
> Here is the constraint:
>
> "If there are fewer initializers in a brace-enclosed list than there are
> elements or members of an aggregate, or fewer characters in a string
> literal used to initialize an array of known size than there are
> elements in the array, the remainder of the aggregate shall be
> initialized implicitly the same as objects that have static storage
> duration."
Yes, the key point is that if you have /any/ parts of the aggregate
initialised, then /all/ of the explicitly accessible parts are
initialised. (Padding and unnamed struct fields are not guaranteed to
be initialised - but they cannot be accessed by name anyway. They are
accessible via a char* pointer or memcpy, however. And unions add an
extra layer of complication, as usual.)
This is often used as a convenient way of zero-initialising local arrays
- "int x[10] = {0};" clears the array.
>
> David 1, Richard 0. Hopefully, that's only a half-time score...
>
In this thread, I am trying to be helpful rather than combative, so
there is no need to keep score here (but in the C99 vs. C89 subthread I
believe it was something like 8-1 to me :-)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-09 14:39 +0000 |
| Message-ID | <mbagqa$3ip$1@dont-email.me> |
| In reply to | #57178 |
On 09/02/15 14:26, David Brown wrote:
<snip>
> This is often used as a convenient way of zero-initialising local arrays
> - "int x[10] = {0};" clears the array.
Er, quite. (Hides head.) I found 45 occurrences of that construct in my
bignum library alone; 18 in my general-purpose library (surprisingly
low, actually); and dozens more elsewhere in my codebase. I even found 8
of them in a tiny little program I hacked together to generate random
name pairs.
>> David 1, Richard 0. Hopefully, that's only a half-time score...
>>
>
> In this thread, I am trying to be helpful rather than combative,
Likewise. And of course I don't really keep score. The above was
tongue-in-cheek.
> so
> there is no need to keep score here (but in the C99 vs. C89 subthread I
> believe it was something like 8-1 to me :-)
No, not really. Although C99 defines a ghastly mess, it doesn't define
"ghastly mess"(!), so there is no referee, and that means I can make up
my own score to suit myself. :-)
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-02-09 16:59 +0100 |
| Message-ID | <mbalg3$p8o$1@dont-email.me> |
| In reply to | #57179 |
On 09/02/15 15:39, Richard Heathfield wrote:
> On 09/02/15 14:26, David Brown wrote:
>
> <snip>
>
>> This is often used as a convenient way of zero-initialising local arrays
>> - "int x[10] = {0};" clears the array.
>
> Er, quite. (Hides head.) I found 45 occurrences of that construct in my
> bignum library alone; 18 in my general-purpose library (surprisingly
> low, actually); and dozens more elsewhere in my codebase. I even found 8
> of them in a tiny little program I hacked together to generate random
> name pairs.
>
>>> David 1, Richard 0. Hopefully, that's only a half-time score...
>>>
>>
>> In this thread, I am trying to be helpful rather than combative,
>
> Likewise. And of course I don't really keep score. The above was
> tongue-in-cheek.
>
I know - though we should probably add more smilies for the benefit of
those who don't use British English, and therefore have more trouble
spotting subtle humour :-)
>
>> so
>> there is no need to keep score here (but in the C99 vs. C89 subthread I
>> believe it was something like 8-1 to me :-)
>
> No, not really. Although C99 defines a ghastly mess, it doesn't define
> "ghastly mess"(!), so there is no referee, and that means I can make up
> my own score to suit myself. :-)
>
I am confident that the definition of a ghastly mess is in ISO 9000
somewhere - I'll get back to you once I've found it. In the meantime, I
recommend leaving comp.lang.c for a bit and enjoying the half-time
cheerleaders.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-02-09 16:01 +0000 |
| Message-ID | <54d8d8de.21291187@news.xs4all.nl> |
| In reply to | #57179 |
Richard Heathfield <rjh@cpax.org.uk> wrote: > On 09/02/15 14:26, David Brown wrote: > > > there is no need to keep score here (but in the C99 vs. C89 subthread I > > believe it was something like 8-1 to me :-) > > No, not really. Although C99 defines a ghastly mess, it doesn't define > "ghastly mess"(!), so there is no referee, and that means I can make up > my own score to suit myself. :-) YASamanthaAICMŁ5. I do hope this means that David is not your gentleman friend. Richard
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-02-09 13:39 +0000 |
| Message-ID | <mbad9n$k0c$1@speranza.aioe.org> |
| In reply to | #57172 |
Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 09/02/15 11:24, Malcolm McLean wrote:
> <snip>
>> int x[10] = {1, 2,3};
>> if(x[3] == 0)
>> printf("This compiler zero initialises arrays\n"):
>> is actually UB. You can't explain that if you think of a x
>> as a 10 element array.
> I'll give it a try anyway.
> x is an array of 10 int. It is partly-initialised, with elements 0, 1, 2
> taking the values 1, 2, 3 respectively. Elements 3-9 remain indeterminate.
Well, besides being UB, it doesn't necessarily do what it says.
You could be unlucky, and even on systems that don't initialize
to zero that element was zero.
> The comparison of x[3] with 0 invokes undefined behaviour because the
> value of x[3] is indeterminate. This has nothing to do with the fact
> that x[3] is an array member and everything to do with the fact that its
> value is indeterminate.
On the usual processors now, it is unlikely that any unusual effects
occur, other than that you don't know the value.
I don't know of any current systems, but there used to be ones where
it was possible to set the parity bits on memory such that a parity
error would occur on access.
Systems with ECC memory usually require a special process to initialize
the ECC bits. When writing only part of an ECC block, such as a byte
on word ECC, the memory system has to read and validate the existing
value, change part, and rewrite. That fails if the ECC bits aren't
valid. But the system should do all that before running user programs.
Anyway, there are good reasons for the standard to say that
it is UB, but it is rare on current systems.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-02-09 09:46 -0500 |
| Message-ID | <mbah6v$5ik$1@dont-email.me> |
| In reply to | #57175 |
On 02/09/2015 08:39 AM, glen herrmannsfeldt wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>> On 09/02/15 11:24, Malcolm McLean wrote:
>
>> <snip>
>
>>> int x[10] = {1, 2,3};
>>> if(x[3] == 0)
>>> printf("This compiler zero initialises arrays\n"):
>
>>> is actually UB. You can't explain that if you think of a x
>>> as a 10 element array.
>
>> I'll give it a try anyway.
>
>> x is an array of 10 int. It is partly-initialised, with elements 0, 1, 2
>> taking the values 1, 2, 3 respectively. Elements 3-9 remain indeterminate.
>
> Well, besides being UB, it doesn't necessarily do what it says.
I'm not surprised that Malcolm thought that the behavior was undefined,
but I was very surprised that Richard believed him.
> You could be unlucky, and even on systems that don't initialize
> to zero that element was zero.
Not initializing them to zero would render the implementation
non-conforming (6.7.9p21).
...
> Anyway, there are good reasons for the standard to say that
> it is UB, but it is rare on current systems.
What are those reasons? Do you think those reasons are good enough that
6.7.9p21 should be modified or removed?
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-09 14:50 +0000 |
| Message-ID | <mbahfa$6g1$1@dont-email.me> |
| In reply to | #57180 |
On 09/02/15 14:46, James Kuyper wrote: <snip> > > I'm not surprised that Malcolm thought that the behavior was undefined, > but I was very surprised that Richard believed him. So was I, as it turned out. -- 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-09 08:22 -0800 |
| Message-ID | <ln61bbhx6i.fsf@nuthaus.mib.org> |
| In reply to | #57175 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> On 09/02/15 11:24, Malcolm McLean wrote:
[...]
>>> int x[10] = {1, 2,3};
>>> if(x[3] == 0)
>>> printf("This compiler zero initialises arrays\n"):
[...]
>> The comparison of x[3] with 0 invokes undefined behaviour because the
>> value of x[3] is indeterminate. This has nothing to do with the fact
>> that x[3] is an array member and everything to do with the fact that its
>> value is indeterminate.
>
> On the usual processors now, it is unlikely that any unusual effects
> occur, other than that you don't know the value.
>
> I don't know of any current systems, but there used to be ones where
> it was possible to set the parity bits on memory such that a parity
> error would occur on access.
>
> Systems with ECC memory usually require a special process to initialize
> the ECC bits. When writing only part of an ECC block, such as a byte
> on word ECC, the memory system has to read and validate the existing
> value, change part, and rewrite. That fails if the ECC bits aren't
> valid. But the system should do all that before running user programs.
>
> Anyway, there are good reasons for the standard to say that
> it is UB, but it is rare on current systems.
As discussed, the remaining elements of x are actually initialized to 0.
But if they were uninitialized, an optimizing compiler could perform
code transformations based on the assumption that the program's behavior
is defined. Reading an uninitialized object can misbehave in ways that
go beyond just reading the arbitrary contents of that memory location.
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-02-09 13:24 +0000 |
| Message-ID | <mbace7$b8k$1@news.xmission.com> |
| In reply to | #57168 |
In article <507b368f-7ae8-410a-b7e6-e42f389fb2e3@googlegroups.com>, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >On Monday, February 9, 2015 at 12:55:56 AM UTC, Geoff wrote: >> >> One could initialize the first 10 members and then skip 100 elements >> and set a value for member 111. Certainly one cannot say that the >> first 10 elements are an array and member 111 isn't a member of that >> array. But you could, I am sure, but you will be wrong. >By "array" we normally mean a data structure with members which can be >accessed by iterating through 1- N (or 0 to N-1). So basically the big >sigma sum notation in mathematics, Sigma (i=1, N) x_i /N is the mean. Careful, Malcolm. If you keep this up, you're likely to give Kiki a heart attack. He can only take so much of this... And you don't really want his blood on your hands, do you? -- Religion is regarded by the common people as true, by the wise as foolish, and by the rulers as useful. (Seneca the Younger, 65 AD)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-02-09 16:03 +0000 |
| Message-ID | <8761bb2ht5.fsf@bsb.me.uk> |
| In reply to | #57168 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, February 9, 2015 at 12:55:56 AM UTC, Geoff wrote: >> >> One could initialize the first 10 members and then skip 100 elements >> and set a value for member 111. Certainly one cannot say that the >> first 10 elements are an array and member 111 isn't a member of that >> array. But you could, I am sure, but you will be wrong. >> > By "array" we normally mean a data structure with members which can be > accessed by iterating through 1- N (or 0 to N-1). So basically the big sigma sum > notation in mathematics, Sigma (i=1, N) x_i /N is the mean. That's not what is usually meant by an array. Neither the sum analogy nor the phrase "accessed by iterating through" capture the key point that an array provides roughly O(1) (in time) random access to elements by index -- usually a contiguous range of integers. (It may have been what you meant but other structures seem to meet the requirements you stated.) The index type and range (if applicable) are all up for grabs. > You can have sparse arrays or arrays with missing members, but then they > need some other structure on top to make sense of the access, so normally > we call them "hash maps" or "look-up tables", stacks and trees might also > be implemented as a C array at a low level. Or associative arrays. O(1) cost of access through some index type is enough to justify the name "array", albeit qualified. <snip> > C doesn't make the array / buffer distinction very well. Can you give some examples of those that do, or is this a failing shared by most programming languages? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-02-09 11:01 -0800 |
| Message-ID | <6bfaa415-d10a-4a1d-a001-ead96b92f11e@googlegroups.com> |
| In reply to | #57185 |
On Monday, February 9, 2015 at 4:03:43 PM UTC, Ben Bacarisse wrote: > > > C doesn't make the array / buffer distinction very well. > > Can you give some examples of those that do, or is this a failing shared > by most programming languages? > C++ has a widely used "vector" type, which most people think of as the C++ array. They've actually used the term "array" for a more restrictive type. A vector has a reserve() operation which sets the buffer size, and a size() access member which returns the number of actual initialised elements. A fault with C++ is that people often have to use the default constructor to create a null element, but technically a vector can't contain null, uninitialised, blocked or otherwise invalid elements. Matlab, which is not unusual in this respect, has a matrix type which doesn't accept garbage. Typically you initialise to zero or ones. You can of course use a matrix as a buffer, but the language discourages it, as operations typically operate on every element. You can access the genuine underlying buffers by using the C interface. Fortran is the opposite. Really it just has buffers. You can of course declare an array which is the same size as a buffer, but there's no way of generating an array of size determined at runtime, you pass in the buffer together with its size to subroutines, together with a count variable giving the number of elements actually used. However to be fair, Fortran programmers also talk loosely about arrays when they mean buffers. The buffer / array distinction is an issue with C because C doesn't allow dynamic construction of 2D contiguous arrays. So often it's necessary to pass in base pointer, width and height. However what you have is a 2D array. Alternatively, you can create an array of pointers and allocate each row separately. So now we've also got a 2D array, but the buffer structure is different.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-02-09 21:54 +0000 |
| Message-ID | <87lhk692do.fsf@bsb.me.uk> |
| In reply to | #57192 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, February 9, 2015 at 4:03:43 PM UTC, Ben Bacarisse wrote: >> >> > C doesn't make the array / buffer distinction very well. >> >> Can you give some examples of those that do, or is this a failing shared >> by most programming languages? >> > C++ has a widely used "vector" type, which most people think of as the C++ > array. They've actually used the term "array" for a more restrictive type. > > A vector has a reserve() operation which sets the buffer size, and a > size() access member which returns the number of actual initialised > elements. Well that does help explain your odd use of the terms. The phrase "array / buffer distinction" made me think that objects were one or the other, but it's odder than that. An MM-array is a portion of an MM-buffer that is marked as in use in some manner. Is that about it? > A fault with C++ is that people often have to use the > default constructor to create a null element, but technically a vector > can't contain null, uninitialised, blocked or otherwise invalid > elements. [Aside: I thought they could. std::vector "default constructs" elements when doing a resize() (or setting the size) and POD types like int have trivial default constructors that do nothing. Mind you, I am no C++ expert and there is some evidence that this is a hard matter to pin down and one that not been left alone in various language revisions.] <snip> > Fortran is the opposite. Really it just has buffers. You can of course > declare an array which is the same size as a buffer, but there's no > way of generating an array of size determined at runtime, you pass in > the buffer together with its size to subroutines, together with a > count variable giving the number of elements actually used. I can't follow this and it seems at odds with what I know about Fortran. Are you discounting allocated arrays? What about arrays declared like this: subroutine s(n) integer, dimension (n) :: array_with_runtime_size ... I'm missing the key thing that makes Fortran an example of making the array/buffer distinction where C does not, even it makes it by being at one end of the spectrum. > However to > be fair, Fortran programmers also talk loosely about arrays when they > mean buffers. > > The buffer / array distinction is an issue with C because C doesn't > allow dynamic construction of 2D contiguous arrays. That's puzzling. These may be more words in MM speak but using the usual meanings both int n, m; ... int darray[n][m]; and int (*dp)[m] = malloc(n * sizeof **dp); dynamically construct contiguous 2D arrays. > So often it's > necessary to pass in base pointer, width and height. However what you > have is a 2D array. Alternatively, you can create an array of pointers > and allocate each row separately. So now we've also got a 2D array, but > the buffer structure is different. I don't think your use of the terms is helping to make matters clear. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-02-09 19:22 -0800 |
| Message-ID | <ae429617-86b5-4011-9c80-df285bcb5ef3@googlegroups.com> |
| In reply to | #57202 |
On Monday, 9 February 2015 23:55:09 UTC+2, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Monday, February 9, 2015 at 4:03:43 PM UTC, Ben Bacarisse wrote:
> >>
> >> > C doesn't make the array / buffer distinction very well.
> >>
> >> Can you give some examples of those that do, or is this a failing shared
> >> by most programming languages?
> >>
> > C++ has a widely used "vector" type, which most people think of as the C++
> > array. They've actually used the term "array" for a more restrictive type.
> >
> > A vector has a reserve() operation which sets the buffer size, and a
> > size() access member which returns the number of actual initialised
> > elements.
>
> Well that does help explain your odd use of the terms. The phrase
> "array / buffer distinction" made me think that objects were one or the
> other, but it's odder than that. An MM-array is a portion of an
> MM-buffer that is marked as in use in some manner. Is that about it?
>
> > A fault with C++ is that people often have to use the
> > default constructor to create a null element, but technically a vector
> > can't contain null, uninitialised, blocked or otherwise invalid
> > elements.
>
> [Aside: I thought they could. std::vector "default constructs" elements
> when doing a resize() (or setting the size) and POD types like int have
> trivial default constructors that do nothing. Mind you, I am no C++
> expert and there is some evidence that this is a hard matter to pin down
> and one that not been left alone in various language revisions.]
Actually the initialization in C++ has been always head-ache ... and lately
they have tried to fix it but ... nah. It is always been that
the 'std::vector' "value-initializes" new elements when doing a 'resize()'.
What it means has changed twice somewhat during last 5 years. The effects
of value initialization are:
1) (until C++14) If T is a class type with at least one user-provided
constructor of any kind, the default constructor is called.
(since C++14) If T is a class type with no default constructor or with
a user-provided default constructor or with a deleted
default constructor, the object is default-initialized.
2) (until C++11) If T is an non-union class type without any user-provided
constructors, then every non-static data member and
base-class component of T is value-initialized.
(between C++11 & C++14) If T is an non-union class type without
any user-provided constructors, then the object is
zero-initialized and then the implicitly-declared
default constructor is called (unless it's trivial).
(since C++14) If T is a class type without a user-provided or
deleted default constructor (that is, it may be a class
with a defaulted default constructor or with an
implicitly-defined one) then the object is zero-initialized
and then it is default-initialized if it has a non-trivial
default constructor.
3) If T is an array type, each element of the array is value-initialized.
4) Otherwise, the object is zero-initialized.
So ... like you see. Basically if you want to achieve uninitialized
elements on 'std::vector::resize' then you need to gain it with 1) by
having user-provided default constructor for element that deliberately
leaves the members of element uninitialized. Plain new 'int's in 'vector'
have been always set to zero on 'resize'. I am not sure if that is
what Malcolm tried to say.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web