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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-05 04:06 +0000 |
| Message-ID | <mauq74$684$1@dont-email.me> |
| In reply to | #56960 |
On 05/02/15 03:41, jeffkrob16@gmail.com wrote: <snip> > With pointers being abstract as they are (passing addresses & not values), Er, what? NO! Who told you that? Pointers are VALUES, and C is pass-by-value. You always pass values in C. An address value is still a value. This is REALLY important. If you don't get this right, your mental model of the interaction between pointers and functions will be a complete mess. Pointers are values. Addresses are values. C functions take values. Always. -- 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-05 10:36 +0000 |
| Message-ID | <mavh2f$72t$1@dont-email.me> |
| In reply to | #56961 |
On 05/02/2015 04:06, Richard Heathfield wrote: > On 05/02/15 03:41, jeffkrob16@gmail.com wrote: > <snip> > > > With pointers being abstract as they are (passing addresses & not > values), > > Er, what? NO! Who told you that? > > Pointers are VALUES, and C is pass-by-value. You always pass values in > C. An address value is still a value. This is REALLY important. If you > don't get this right, your mental model of the interaction between > pointers and functions will be a complete mess. > > Pointers are values. Addresses are values. C functions take values. Always. If you need to use "*" or "->" on a parameter to get at the value you're really interested in, then I think it's reasonable to say that that value has effectively been via an address or reference. But then C has this crazy thing where you can use [] on a parameter to get at the values of an array's elements without needing to use "*". How has that array (ie. the data in all the elements) been passed? It's definitely not by value! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-05 10:59 +0000 |
| Message-ID | <mavidk$be0$1@dont-email.me> |
| In reply to | #56968 |
On 05/02/15 10:36, Bartc wrote:
> On 05/02/2015 04:06, Richard Heathfield wrote:
<snip>
>>
>> Pointers are values. Addresses are values. C functions take values. Always.
>
> If you need to use "*" or "->" on a parameter to get at the value you're
> really interested in, then I think it's reasonable to say that that
> value has effectively been via an address or reference.
I think it's unwise to think in that way. Firstly, it adds no value(!),
and secondly, it can lead to confusion, especially if it becomes
embedded in one's thinking before one really understands pointers. The
reason for this is simple: it lends to pointers a mystique that is
inappropriate and unhelpful to the learning process. It suggests that
something special is happening, and then never quite explains what that
special something is. If we stick to the unquestionable truth that
pointers are values, all becomes a lot clearer a lot quicker.
> But then C has this crazy thing where you can use [] on a parameter to
> get at the values of an array's elements without needing to use "*". How
> has that array (ie. the data in all the elements) been passed? It's
> definitely not by value!
The array has not been passed at all. The value of the first element's
address has been passed. This is *so* important.
Imagine somebody wants to give you a house. They could just load it onto
a big truck and deliver it to you, but it's a lot easier for all
concerned if they just tell you where it is and let you go there
yourself. In other words, they give you a scrap of paper with the
address written on it.
If they want to give you a whole row of houses, they don't have to give
you the address of each one. They only need tell you the address of the
first one, and either (a) they tell you how many houses you can have, or
(b) there is some convention in place that tells you where your houses
stop (e.g. right up until the end of the road).
(a) corresponds to: fgets(buf, sizeof buf, stdin), and (b) corresponds
to puts("my string").
Introducing a false distinction into C's parameter-passing mechanism may
be helpful to you personally (although frankly I don't see it myself),
but it is not helpful in general to people who are trying to learn the
language.
--
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-05 11:03 +0000 |
| Message-ID | <mavimg$k7h$1@speranza.aioe.org> |
| In reply to | #56968 |
Bartc <bc@freeuk.com> wrote:
> On 05/02/2015 04:06, Richard Heathfield wrote:
>> On 05/02/15 03:41, jeffkrob16@gmail.com wrote:
>> <snip>
>>> With pointers being abstract as they are (passing addresses & not
>> values),
>> Er, what? NO! Who told you that?
>> Pointers are VALUES, and C is pass-by-value. You always pass values in
>> C. An address value is still a value. This is REALLY important. If you
>> don't get this right, your mental model of the interaction between
>> pointers and functions will be a complete mess.
(snip)
> If you need to use "*" or "->" on a parameter to get at the value you're
> really interested in, then I think it's reasonable to say that that
> value has effectively been via an address or reference.
If you don't change the local copy of the pointer, then it works
in a similar way to call by reference. The fact that you need *,
[], or -> isn't the distinguising factor.
> But then C has this crazy thing where you can use [] on a parameter to
> get at the values of an array's elements without needing to use "*". How
> has that array (ie. the data in all the elements) been passed? It's
> definitely not by value!
Consider:
int f(int n, int *x) {
int y[]={2, 4, 6, 8, 10};
if(n<5) x=y;
return x[n];
}
Once you change the local copy, which previously held the passed
pointer, you can't explain it as pass by reference anymore.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-02-05 12:30 +0000 |
| Message-ID | <87mw4sa6cc.fsf@bsb.me.uk> |
| In reply to | #56968 |
Bartc <bc@freeuk.com> writes: > On 05/02/2015 04:06, Richard Heathfield wrote: >> On 05/02/15 03:41, jeffkrob16@gmail.com wrote: >> <snip> >> >> > With pointers being abstract as they are (passing addresses & not >> values), >> >> Er, what? NO! Who told you that? >> >> Pointers are VALUES, and C is pass-by-value. You always pass values in >> C. An address value is still a value. This is REALLY important. If you >> don't get this right, your mental model of the interaction between >> pointers and functions will be a complete mess. >> >> Pointers are values. Addresses are values. C functions take values. Always. > > If you need to use "*" or "->" on a parameter to get at the value > you're really interested in, then I think it's reasonable to say that > that value has effectively been via an address or reference. I go much further. I'd say it is absolutely the right way to say it. And not just "effectively", but actually. The desired value has been obtained via an address. That way you can be clear that C always passes by value. Some of the values that are passed (those that are address or pointer values) are use to access *other* objects (better than saying values). > But then C has this crazy thing where you can use [] on a parameter to > get at the values of an array's elements without needing to use > "*". How has that array (ie. the data in all the elements) been > passed? It's definitely not by value! The array has not been passed, so asking the question is certain to confuse the learner no matter how you answer it. Better to explain that (a) C always passes by value; (b) arrays convert to pointers in almost every case; and (c) a[b] means *(a+b). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-05 12:46 +0000 |
| Message-ID | <mavomg$369$1@dont-email.me> |
| In reply to | #56978 |
On 05/02/15 12:30, Ben Bacarisse wrote:
<snip>
> and (c) a[b] means *(a+b).
...which leads us directly to one of the silly-but-harmless things about C:
x = array[0];
=>
x = *(array + 0);
=> by the commutativity of addition:
x = *(0 + array);
=>
x = 0[array];
Good for IOCCC stuff, but probably not much else. On the other hand, I
have seen struct arrays dealt with in this way. Instead of:
mystructobject.myfirstint[myarrayindex] = whatever();
mystructobject.mysecondint[myarrayindex] = whatever();
mystructobject.myfirstdouble[myarrayindex] = whatever();
you do:
myarrayindex[mystructobject.myfirstint] = whatever();
myarrayindex[mystructobject.mysecondint] = whatever();
myarrayindex[mystructobject.myfirstdouble] = whatever();
(Personally, I'm not convinced that this is easier to read.)
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-05 12:49 +0000 |
| Message-ID | <mavork$369$2@dont-email.me> |
| In reply to | #56980 |
Correction: On 05/02/15 12:46, Richard Heathfield wrote: > On 05/02/15 12:30, Ben Bacarisse wrote: > > <snip> > > On the other hand, I > have seen struct arrays dealt with in this way. Instead of: > > mystructobject.myfirstint[myarrayindex] = whatever(); > mystructobject.mysecondint[myarrayindex] = whatever(); > mystructobject.myfirstdouble[myarrayindex] = whatever(); These should have read: mystructobject[myarrayindex].myfirstint = whatever(); mystructobject[myarrayindex].mysecondint = whatever(); mystructobject[myarrayindex].myfirstdouble = whatever(); > > you do: > > myarrayindex[mystructobject.myfirstint] = whatever(); > myarrayindex[mystructobject.mysecondint] = whatever(); > myarrayindex[mystructobject.myfirstdouble] = whatever(); and myarrayindex[mystructobject].myfirstint = whatever(); myarrayindex[mystructobject].mysecondint = whatever(); myarrayindex[mystructobject].myfirstdouble = whatever(); but I'm still not convinced. -- 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 | hormelfree@gmail.com |
|---|---|
| Date | 2015-02-05 15:08 -0800 |
| Message-ID | <259bbdf1-155b-4e6a-ae37-6c48bce574b6@googlegroups.com> |
| In reply to | #56968 |
On Thursday, February 5, 2015 at 2:36:44 AM UTC-8, Bart wrote: > On 05/02/2015 04:06, Richard Heathfield wrote: > > On 05/02/15 03:41, jeffkrob16@gmail.com wrote: > > <snip> > > > > > With pointers being abstract as they are (passing addresses & not > > values), > > > > Er, what? NO! Who told you that? > > > > Pointers are VALUES, and C is pass-by-value. You always pass values in > > C. An address value is still a value. This is REALLY important. If you > > don't get this right, your mental model of the interaction between > > pointers and functions will be a complete mess. > > > > Pointers are values. Addresses are values. C functions take values. Always. > > If you need to use "*" or "->" on a parameter to get at the value you're > really interested in, then I think it's reasonable to say that that > value has effectively been via an address or reference. > > But then C has this crazy thing where you can use [] on a parameter to > get at the values of an array's elements without needing to use "*". How > has that array (ie. the data in all the elements) been passed? It's > definitely not by value! > Please don't confuse him with the facts or logic, that's not the "C" way...(the "C" way is call a "reference" a "value", or in general, do everything as upside-down, sideways, cross-eyed, and counter-intuitive as possible) --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-02-05 08:48 -0800 |
| Message-ID | <lnwq3wl2x6.fsf@nuthaus.mib.org> |
| In reply to | #56961 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 05/02/15 03:41, jeffkrob16@gmail.com wrote:
> <snip>
> > With pointers being abstract as they are (passing addresses & not
> values),
>
> Er, what? NO! Who told you that?
>
> Pointers are VALUES, and C is pass-by-value. You always pass values in
> C. An address value is still a value. This is REALLY important. If you
> don't get this right, your mental model of the interaction between
> pointers and functions will be a complete mess.
>
> Pointers are values. Addresses are values. C functions take values. Always.
To elaborate on that a bit:
Suppose you have
void func1(int param);
void func2(int *param);
int var = 42;
Calling `func1(var)` passes the *value* of `var`, which happens to be 42.
Calling `func2(&var)` does not pass the value of `var`, but it does pass
a value. The value it passes is the result of evaluating the expression
`&var`; it's a value that's of type `int*`.
Some languages other than C permit passing arguments by reference.
Passing the address of an object is how you *implement*
pass-by-reference in C.
C does not have pass-by-reference as a language feature. You can
implement pass-by-reference in C by passing pointers (and the pointers
are of course passed by value).
Quite similarly, C does not have linked lists as a language feature.
You can implement linked lists in C using pointers.
--
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 | hormelfree@gmail.com |
|---|---|
| Date | 2015-02-05 15:16 -0800 |
| Message-ID | <4fed2f64-8ef6-4c4c-8333-0a6b40e9c236@googlegroups.com> |
| In reply to | #56961 |
On Wednesday, February 4, 2015 at 8:06:40 PM UTC-8, Richard Heathfield wrote: > On 05/02/15 03:41, jeffkrob16@gmail.com wrote: > <snip> > > > With pointers being abstract as they are (passing addresses & not > values), > > Er, what? NO! Who told you that? > > Pointers are VALUES, and C is pass-by-value. You always pass values in > C. An address value is still a value. This is REALLY important. If you > don't get this right, your mental model of the interaction between > pointers and functions will be a complete mess. > > Pointers are values. Addresses are values. C functions take values. Always. > In this whole obfuscatory rant, you missed the headline obfuscatory point: pointers are not addresses (well, you WERE trying to confuse the OP, weren't you?)... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-02-05 23:35 +0000 |
| Message-ID | <mb0uml$cpk$1@dont-email.me> |
| In reply to | #57032 |
On 05/02/15 23:16, hormelfree@gmail.com wrote: > On Wednesday, February 4, 2015 at 8:06:40 PM UTC-8, Richard Heathfield wrote: >> On 05/02/15 03:41, jeffkrob16@gmail.com wrote: >> <snip> >> >> > With pointers being abstract as they are (passing addresses & not >> values), >> >> Er, what? NO! Who told you that? >> >> Pointers are VALUES, and C is pass-by-value. You always pass values in >> C. An address value is still a value. This is REALLY important. If you >> don't get this right, your mental model of the interaction between >> pointers and functions will be a complete mess. >> >> Pointers are values. Addresses are values. C functions take values. Always. >> > In this whole obfuscatory rant, Actually, I truly believe that it is the spurious introduction of "pass by reference" into C discussions that is obfuscatory. Pointers are much easier to understand if you don't confuse the issue with apparent magic. > you missed the headline obfuscatory > point: pointers are not addresses (well, you WERE trying to confuse the > OP, weren't you?)... The Standard defines a pointer type as describing an object whose value provides a reference to an entity of the referenced type. It goes on to say that a "pointer type derived from the referenced type T is sometimes called ``pointer to T''. So a pointer is a type. The Standard further defines the unary operator & as returning the address of its operand. "If the operand has type ``type'', the result has type ``pointer to type''. So objects have addresses, which are assignable to pointer types. If you can store 1 in an int, it is reasonable to call 1 an int. Likewise, if you can store an address in a pointer, it is reasonable to call an address a pointer. If you think the above is in some way unreasonable, please do point out why. Thank you. -- 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 | hormelfree@gmail.com |
|---|---|
| Date | 2015-02-07 12:11 -0800 |
| Message-ID | <cfd3ec21-b939-4cdf-8134-44b18d561222@googlegroups.com> |
| In reply to | #57034 |
On Thursday, February 5, 2015 at 3:35:29 PM UTC-8, Richard Heathfield wrote: > On 05/02/15 23:16, hormelfree@gmail.com wrote: > > On Wednesday, February 4, 2015 at 8:06:40 PM UTC-8, Richard Heathfield wrote: > >> On 05/02/15 03:41, jeffkrob16@gmail.com wrote: > >> <snip> > >> > >> > With pointers being abstract as they are (passing addresses & not > >> values), > >> > >> Er, what? NO! Who told you that? > >> > >> Pointers are VALUES, and C is pass-by-value. You always pass values in > >> C. An address value is still a value. This is REALLY important. If you > >> don't get this right, your mental model of the interaction between > >> pointers and functions will be a complete mess. > >> > >> Pointers are values. Addresses are values. C functions take values. Always. > >> > > In this whole obfuscatory rant, > > Actually, I truly believe that it is the spurious introduction of "pass > by reference" into C discussions that is obfuscatory. Pointers are much > easier to understand if you don't confuse the issue with apparent magic. > C pointers are NEVER easy to understand or work with... > > you missed the headline obfuscatory > > point: pointers are not addresses (well, you WERE trying to confuse the > > OP, weren't you?)... > > The Standard defines a pointer type as describing an object whose value > provides a reference to an entity of the referenced type. It goes on to > say that a "pointer type derived from the referenced type T is sometimes > called ``pointer to T''. So a pointer is a type. > Yup. What could be simpler? Why all the confusion? I do believe that a lot of confusion about "C" could be reduced by actually reading the standard (this is true of most programming languages). Note carefully I said "reduced", not eliminated, and of course, reading the standard is only slightly less painful than reading the sun... > The Standard further defines the unary operator & as returning the > address of its operand. "If the operand has type ``type'', the result > has type ``pointer to type''. So objects have addresses, which are > assignable to pointer types. If you can store 1 in an int, it is > reasonable to call 1 an int. Likewise, if you can store an address in a > pointer, it is reasonable to call an address a pointer. > Wow, you're wrong, but it was fun making you say something all wrong and stupid like that. I'll probably wait a few months before I re-bait my hook here again, let the taste of the barb be removed from your mouth... I mean, you do realize you are directly contradicting other statements you've mad on this topic? > If you think the above is in some way unreasonable, please do point out > why. Thank you. > It's as unreasonable to say a pointer is an address as it is to say it's kind of like a reference...not really that unreasonable, unless you've gone a big rant about saying it's a reference is a crime against humanity... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-02-07 12:22 -0800 |
| Message-ID | <2d553976-5abe-47d3-85f6-e98c261c6aa8@googlegroups.com> |
| In reply to | #57115 |
On Saturday, February 7, 2015 at 8:11:50 PM UTC, horme...@gmail.com wrote: > > C pointers are NEVER easy to understand or work with... > In my case it was "What's that funny multiplication symbol? Oh, it's the indirection operator". Pointers are pretty easy if you're used to the idea of writing directly to memory - the pitfalls are choice of the multiplication operator, array / pointer / malloc equivalence, and the funny structure syntax, and the fact that the same symbol is used to declare and dereference a pointer. The second is the only feature with deep consequences.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-02-07 22:03 +0000 |
| Message-ID | <mb6239$unr$1@dont-email.me> |
| In reply to | #57116 |
On 07/02/2015 20:22, Malcolm McLean wrote:
> On Saturday, February 7, 2015 at 8:11:50 PM UTC, horme...@gmail.com wrote:
>>
>> C pointers are NEVER easy to understand or work with...
>>
> In my case it was "What's that funny multiplication symbol? Oh, it's the
> indirection operator".
> Pointers are pretty easy if you're used to the idea of writing directly
> to memory - the pitfalls are choice of the multiplication operator,
> array / pointer / malloc equivalence, and the funny structure syntax,
> and the fact that the same symbol is used to declare and dereference
> a pointer. The second is the only feature with deep consequences.
C does deal with pointers in quirky ways which doesn't help people
trying to understand what's going on. For example, take these two arrays:
[100]int a;
int *b = malloc(sizeof(int)*100);
One is a clearly a 'direct' array, the other is indirect and accessed
via an extra pointer. Yet the code you'd write is exactly the same:
a[i] and b[i] to access element i.
f(a) and f(b) to pass the array (or what counts as passing an array in
C, ie. a pointer to the element type) to a function.
p=a and p=b to copy the 'array' to an int* pointer.
This is confusing! About the only thing that is different is that
sizeof(a) gives you 400, and sizeof(b) gives 4 (when ints and pointer
are both size 4).
Then C goes and pulls the same trick with function pointers:
void fn(int a) {} // a normal direct function
void (*fnptr)(int); // an indirect function via a pointer
Both are called exactly the same way:
fn(10) and fnptr(10)
However, add an extra pointer level:
void (**fnptrptr)(int);
and now you do need to explicitly dereference:
(*fnptrptr)(10);
But then you discover that (*fnptr)(10) also works: the same syntax, but
one uses one pointer level, the other two. Investigate further, and you
find that:
(******************************************fnptr)(10);
also works just as well! What on earth's going on?
Yes, using pointers can take some getting used to, but so does the way
that C has chosen to deal with them. (It's probably good overall that it
works this way, because the syntax for doing explicit dereferencing in C
is clumsy, enough that "->" was introduced to try and struct accessing.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-02-07 14:47 -0800 |
| Message-ID | <b949b660-f439-44bb-a709-2dd90c42c43b@googlegroups.com> |
| In reply to | #57118 |
On Saturday, February 7, 2015 at 10:04:18 PM UTC, Bart wrote: > > C does deal with pointers in quirky ways which doesn't help people > trying to understand what's going on. For example, take these two arrays: > > [100]int a; > int *b = malloc(sizeof(int)*100); > > One is a clearly a 'direct' array, the other is indirect and accessed > via an extra pointer. Yet the code you'd write is exactly the same: > > a[i] and b[i] to access element i. > The way to think of it is int a[100]; /* buffer on stack */ int *b = malloc(sizeof(int) * 100); /* buffer on heap */ a and b are largely interchangeable, except for sizeof() and reallocation / freeing. Neither creates an array. An array has data in it. It's not uncommon for C programs to contain arrays which are smaller than the buffers used to hold them. > > However, add an extra pointer level: > > void (**fnptrptr)(int); > > and now you do need to explicitly dereference: > > (*fnptrptr)(10); > > But then you discover that (*fnptr)(10) also works: the same syntax, but > one uses one pointer level, the other two. Investigate further, and you > find that: > > (******************************************fnptr)(10); > > also works just as well! What on earth's going on? > I wasn't aware of that quirk, though I was of course aware that the undesireable fnptr(10) syntax is allowed in place of (*fnptr)(10); I can't remember when I last used a pointer to a function pointer, as opposed to a pointer to a structure with function pointer members.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-02-07 17:15 -0800 |
| Message-ID | <lnfvahjja3.fsf@nuthaus.mib.org> |
| In reply to | #57119 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, February 7, 2015 at 10:04:18 PM UTC, Bart wrote:
>> C does deal with pointers in quirky ways which doesn't help people
>> trying to understand what's going on. For example, take these two arrays:
>>
>> [100]int a;
>> int *b = malloc(sizeof(int)*100);
>>
>> One is a clearly a 'direct' array, the other is indirect and accessed
>> via an extra pointer. Yet the code you'd write is exactly the same:
>>
>> a[i] and b[i] to access element i.
>>
> The way to think of it is
>
> int a[100]; /* buffer on stack */
> int *b = malloc(sizeof(int) * 100); /* buffer on heap */
>
> a and b are largely interchangeable, except for sizeof() and
> reallocation / freeing.
>
> Neither creates an array. An array has data in it. It's not uncommon
> for C programs to contain arrays which are smaller than the buffers
> used to hold them.
You seem to be using the word "array" in a way that's very different
from the way I use it, and from the way the standard uses it.
An *array object* may or may not contain well-defined data. The
declaration
a[100];
causes an array object, with a size of 100*sizeof(int) bytes, to be
created. The object's initial value is indeterminate.
int *b = malloc(sizeof(int) * 100);
causes an array object of the same size to be created as a side effect
of the evaluation of the initialization expression (unless it fails),
and causes b to point to the first element of that array object.
The standard uses the word "buffer" only in the context of I/O.
You seem to be saying that `int a[100];` creates a 100-element "buffer",
and that only the portion of that buffer that's been initialized
constitutes an "array". I don't believe I've ever seen the word "array"
used in that way. I suggest you at least make it clear that you're
using the word in an unconventional manner.
[...]
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-02-08 17:22 +1300 |
| Message-ID | <cjo6krF83mfU1@mid.individual.net> |
| In reply to | #57119 |
Malcolm McLean wrote: > On Saturday, February 7, 2015 at 10:04:18 PM UTC, Bart wrote: >> >> C does deal with pointers in quirky ways which doesn't help people >> trying to understand what's going on. For example, take these two arrays: >> >> [100]int a; >> int *b = malloc(sizeof(int)*100); >> >> One is a clearly a 'direct' array, the other is indirect and accessed >> via an extra pointer. Yet the code you'd write is exactly the same: >> >> a[i] and b[i] to access element i. >> > The way to think of it is > > int a[100]; /* buffer on stack */ > int *b = malloc(sizeof(int) * 100); /* buffer on heap */ > > a and b are largely interchangeable, except for sizeof() and > reallocation / freeing. > > Neither creates an array. An array has data in it. Eh? They both contain data. Indeterminate data, but data none the less. > It's not uncommon > for C programs to contain arrays which are smaller than the buffers > used to hold them. I can't say I've ever seen one. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-02-08 02:47 -0800 |
| Message-ID | <3cc47e2a-4e16-42d5-b72a-f72e23bc99bf@googlegroups.com> |
| In reply to | #57131 |
On Sunday, February 8, 2015 at 4:23:00 AM UTC, Ian Collins wrote: > Malcolm McLean wrote: > > > Neither creates an array. An array has data in it. > > Eh? They both contain data. Indeterminate data, but data none the less. > Data is what is given, that is, measurements or information from some source external to the program, though possibly hard-coded into it. So if we do #define MAX_EMPLOYEES 1000 struct employee payroll[MAX_EMPLOYEES]; int Nemployees; but in fact we only have ten employees on our payroll, we only have ten salary data points. The other 990 structures in the buffer have fields which, as it happens, C will allow you to read using the identifier "salary", but they do not contain salaries in cents per month. The standard writers aren't really concerned with the difference between a buffer and an array, the purpose of the standard is to constrain the behaviour of the compiler, not to make distinctions between programs which produce human-meaningful output and programs which produce human-nonsense output.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-02-08 11:20 -0800 |
| Message-ID | <lny4o8i50s.fsf@nuthaus.mib.org> |
| In reply to | #57132 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, February 8, 2015 at 4:23:00 AM UTC, Ian Collins wrote:
>> Malcolm McLean wrote:
>> > Neither creates an array. An array has data in it.
>>
>> Eh? They both contain data. Indeterminate data, but data none the less.
>>
> Data is what is given, that is, measurements or information from some
> source external to the program, though possibly hard-coded into it.
> So if we do
>
> #define MAX_EMPLOYEES 1000
> struct employee payroll[MAX_EMPLOYEES];
> int Nemployees;
>
> but in fact we only have ten employees on our payroll, we only have
> ten salary data points. The other 990 structures in the buffer have
> fields which, as it happens, C will allow you to read using the
> identifier "salary", but they do not contain salaries in cents per
> month.
>
> The standard writers aren't really concerned with the difference
> between a buffer and an array, the purpose of the standard is to
> constrain the behaviour of the compiler, not to make distinctions
> between programs which produce human-meaningful output and programs
> which produce human-nonsense output.
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.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-02-08 14:36 -0800 |
| Message-ID | <7fc0036a-112b-45e1-94c5-f54536464ef3@googlegroups.com> |
| In reply to | #57143 |
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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web