Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94683 > unrolled thread
| Started by | MehdiAmini <atorrses@gmail.com> |
|---|---|
| First post | 2016-10-10 15:51 +0000 |
| Last post | 2016-10-10 15:11 -0700 |
| Articles | 20 on this page of 183 — 24 participants |
Back to article view | Back to comp.lang.c
C Programming Tutorial on Youtube MehdiAmini <atorrses@gmail.com> - 2016-10-10 15:51 +0000
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-10 17:14 +0100
Re: C Programming Tutorial on Youtube Real Troll <real.troll@trolls.com> - 2016-10-10 13:25 -0400
Re: C Programming Tutorial on Youtube "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-10 11:06 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-10 22:18 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-10 16:29 -0700
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-11 00:07 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-11 08:36 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-11 09:51 -0700
Re: C Programming Tutorial on Youtube jameskuyper@verizon.net - 2016-10-11 07:09 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-11 09:48 -0700
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-11 10:10 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-11 11:54 -0700
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-11 08:13 -0400
Re: C Programming Tutorial on Youtube jameskuyper@verizon.net - 2016-10-11 07:49 -0700
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-11 12:28 -0400
Re: C Programming Tutorial on Youtube jameskuyper@verizon.net - 2016-10-11 09:51 -0700
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-11 21:02 -0400
Re: C Programming Tutorial on Youtube David Brown <david.brown@hesbynett.no> - 2016-10-13 14:48 +0200
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-13 10:20 -0400
Re: C Programming Tutorial on Youtube "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-15 12:18 -0400
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-15 16:47 -0400
Re: C Programming Tutorial on Youtube jameskuyper@verizon.net - 2016-10-15 14:31 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-15 15:21 -0700
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-15 22:47 -0400
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-16 05:19 +0100
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-16 08:37 -0400
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-16 17:59 +0100
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-16 15:48 -0400
Re: C Programming Tutorial on Youtube Anton Shepelev <anton.txt@gmail.com> - 2016-10-17 00:27 +0300
Re: C Programming Tutorial on Youtube "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-16 17:42 -0400
Re: C Programming Tutorial on Youtube Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-17 10:23 +0300
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 09:07 -0400
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-16 18:28 -0400
Re: C Programming Tutorial on Youtube James Kuyper <jameskuyper@verizon.net> - 2016-10-17 10:08 -0400
Re: C Programming Tutorial on Youtube Gareth Owen <gwowen@gmail.com> - 2016-10-17 17:51 +0100
Re: C Programming Tutorial on Youtube Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-18 13:29 +0300
Re: C Programming Tutorial on Youtube Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-18 13:24 +0300
Re: C Programming Tutorial on Youtube "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-16 13:29 -0400
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-16 18:36 +0100
Re: C Programming Tutorial on Youtube luser droog <luser.droog@gmail.com> - 2016-10-16 11:39 -0700
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-16 15:54 -0400
Re: C Programming Tutorial on Youtube jameskuyper@verizon.net - 2016-10-16 15:38 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-16 23:53 +0100
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-16 19:40 -0400
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-17 06:31 +0100
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 09:09 -0400
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-17 14:16 +0100
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-16 19:40 -0400
Re: C Programming Tutorial on Youtube jameskuyper@verizon.net - 2016-10-16 19:23 -0700
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-16 22:33 -0400
Re: C Programming Tutorial on Youtube "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-10-16 20:09 -0700
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 09:13 -0400
Re: C Programming Tutorial on Youtube David Brown <david.brown@hesbynett.no> - 2016-10-17 10:58 +0200
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 09:14 -0400
Re: C Programming Tutorial on Youtube James Kuyper <jameskuyper@verizon.net> - 2016-10-17 07:44 -0400
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-17 13:22 +0100
Re: C Programming Tutorial on Youtube Gareth Owen <gwowen@gmail.com> - 2016-10-17 17:55 +0100
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 09:22 -0400
Re: C Programming Tutorial on Youtube jameskuyper@verizon.net - 2016-10-17 08:32 -0700
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 17:21 -0400
Re: C Programming Tutorial on Youtube jameskuyper@verizon.net - 2016-10-17 16:07 -0700
Re: C Programming Tutorial on Youtube Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-17 21:00 -0400
Re: C Programming Tutorial on Youtube luser droog <luser.droog@gmail.com> - 2016-10-17 21:49 -0700
Re: C Programming Tutorial on Youtube James Kuyper <jameskuyper@verizon.net> - 2016-10-18 10:45 -0400
Re: C Programming Tutorial on Youtube David Brown <david.brown@hesbynett.no> - 2016-10-17 10:55 +0200
Re: C Programming Tutorial on Youtube Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-10-17 16:01 -0700
Re: C Programming Tutorial on Youtube "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-17 19:29 -0400
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-18 00:33 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-18 08:41 +0100
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-18 01:54 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-18 08:28 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-11 10:05 -0700
Re: C Programming Tutorial on Youtube supercat@casperkitty.com - 2016-10-11 11:12 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-11 11:52 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-11 12:18 -0700
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-11 22:15 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-11 14:40 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-11 23:45 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-11 18:08 -0700
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-11 18:41 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-11 18:55 -0700
Re: C Programming Tutorial on Youtube Richard Damon <Richard@Damon-Family.org> - 2016-10-14 22:09 -0400
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-15 10:51 +0100
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-15 19:11 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-15 21:14 +0100
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-15 22:33 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-15 23:13 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-15 15:34 -0700
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-16 00:37 +0100
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-16 01:00 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-17 17:48 +0100
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-17 20:09 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-15 23:55 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-15 16:19 -0700
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-16 00:55 +0100
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-16 01:11 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-16 22:17 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-16 23:11 +0100
Re: C Programming Tutorial on Youtube Richard Damon <Richard@Damon-Family.org> - 2016-10-16 19:55 -0400
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-17 01:12 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-17 01:56 +0100
Re: C Programming Tutorial on Youtube supercat@casperkitty.com - 2016-10-17 14:27 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-16 04:55 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-16 11:49 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-15 14:55 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-15 12:47 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-15 11:02 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-15 12:12 -0700
Re: C Programming Tutorial on Youtube Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-15 14:56 -0700
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-17 05:27 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-17 08:41 -0700
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-17 10:18 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-17 11:34 -0700
Re: C Programming Tutorial on Youtube Ian Collins <ian-news@hotmail.com> - 2016-10-18 08:05 +1300
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-17 12:39 -0700
Re: C Programming Tutorial on Youtube Gareth Owen <gwowen@gmail.com> - 2016-10-17 21:17 +0100
Re: C Programming Tutorial on Youtube David Brown <david.brown@hesbynett.no> - 2016-10-17 22:46 +0200
Re: C Programming Tutorial on Youtube Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-18 14:06 +0300
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-18 12:18 +0100
Re: C Programming Tutorial on Youtube Anton Shepelev <anton.txt@g{oogle}mail.com> - 2016-10-20 15:09 +0300
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-20 14:29 +0100
Re: C Programming Tutorial on Youtube raltbos@xs4all.nl (Richard Bos) - 2016-10-23 13:15 +0000
Re: C Programming Tutorial on Youtube Anton Shepelev <anton.txt@gmail.com> - 2016-11-06 16:17 +0300
Re: C Programming Tutorial on Youtube supercat@casperkitty.com - 2016-11-07 11:21 -0800
Re: C Programming Tutorial on Youtube David Brown <david.brown@hesbynett.no> - 2016-10-18 13:59 +0200
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-18 14:32 +0100
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 06:57 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-12 10:25 +0100
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 13:14 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-12 16:44 +0100
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 16:53 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-12 18:37 +0100
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 18:50 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-12 19:41 +0100
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 20:18 +0100
Re: C Programming Tutorial on Youtube supercat@casperkitty.com - 2016-10-12 12:56 -0700
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-12 21:04 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-12 14:18 -0700
Re: C Programming Tutorial on Youtube supercat@casperkitty.com - 2016-10-12 15:12 -0700
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-13 01:49 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-13 09:55 +0100
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-13 02:09 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-13 10:35 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-13 08:23 -0700
Re: C Programming Tutorial on Youtube Gareth Owen <gwowen@gmail.com> - 2016-10-13 18:49 +0100
Re: C Programming Tutorial on Youtube "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-12 10:52 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-12 12:06 -0700
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-12 19:41 +0100
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-13 01:59 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-13 10:34 +0100
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-13 13:08 +0100
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-13 05:22 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-13 13:29 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-13 08:31 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-13 08:31 -0700
Re: C Programming Tutorial on Youtube Gareth Owen <gwowen@gmail.com> - 2016-10-13 18:57 +0100
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-13 19:26 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-13 08:27 -0700
Re: C Programming Tutorial on Youtube Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-15 15:09 -0700
Re: C Programming Tutorial on Youtube Gareth Owen <gwowen@gmail.com> - 2016-10-16 16:45 +0100
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-16 16:51 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-13 12:04 +0100
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-13 13:17 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-13 14:17 +0100
Re: C Programming Tutorial on Youtube Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-13 20:14 +0100
Re: C Programming Tutorial on Youtube BartC <bc@freeuk.com> - 2016-10-13 22:00 +0100
Re: C Programming Tutorial on Youtube Richard Damon <Richard@Damon-Family.org> - 2016-10-12 08:14 -0400
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-12 05:28 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 13:30 +0100
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 13:59 +0100
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-12 08:47 -0700
Re: C Programming Tutorial on Youtube "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-12 05:29 -0700
Re: C Programming Tutorial on Youtube Keith Thompson <kst-u@mib.org> - 2016-10-12 08:31 -0700
Re: C Programming Tutorial on Youtube Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-11 18:29 -0700
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 06:55 +0100
Re: C Programming Tutorial on Youtube Gareth Owen <gwowen@gmail.com> - 2016-10-12 17:54 +0100
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 18:09 +0100
Re: C Programming Tutorial on Youtube "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-12 13:46 -0400
Re: C Programming Tutorial on Youtube Richard Heathfield <rjh@cpax.org.uk> - 2016-10-12 18:54 +0100
Re: C Programming Tutorial on Youtube luser droog <luser.droog@gmail.com> - 2016-10-12 13:46 -0700
Re: C Programming Tutorial on Youtube "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-10 18:01 -0400
Re: C Programming Tutorial on Youtube supercat@casperkitty.com - 2016-10-10 15:11 -0700
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-13 01:49 -0700 |
| Message-ID | <622d88c0-fb42-4667-a6f1-db81a25ff23f@googlegroups.com> |
| In reply to | #94783 |
On Wednesday, October 12, 2016 at 6:50:16 PM UTC+1, Richard Heathfield wrote: > > It hardly matters. If you don't mean an array, then it's beyond > guessing, wild or otherwise. And if you do mean an array, why not say > "array"? > Generally, by "array" people mean "array of data", which clearly isn't the case here - we have no data. You can say that uninitialised memory is an "array of int objects" if you want, but that's pretty confusing also. C doesn't set up objects, a memory buffer is treated as containing objects of the type pointed to. "int objects" are just "memory which can hold an int". So if you imagine the data as soldiers, and the memory as the parade ground, the int objects are the little squares on the parade ground where the soldiers can stand. Sometimes it might be helpful to have that image in mind.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-13 09:55 +0100 |
| Message-ID | <ntni50$4f1$1@dont-email.me> |
| In reply to | #94800 |
On 13/10/16 09:49, Malcolm McLean wrote: > On Wednesday, October 12, 2016 at 6:50:16 PM UTC+1, Richard Heathfield wrote: >> >> It hardly matters. If you don't mean an array, then it's beyond >> guessing, wild or otherwise. And if you do mean an array, why not say >> "array"? >> > Generally, by "array" people mean "array of data", Stop right there. This is comp.lang.c, where "array" is a technical term with a highly specialised meaning. If you want to assign another meaning to the word "array", you do so at the risk of confusing some of your readership and alienating the rest of it. You would do better to stop making up meanings for existing technical terms. If you must have these new meanings, make up new words to describe them. If the meanings are useful, the words will catch on. -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-13 02:09 -0700 |
| Message-ID | <12152302-7b25-4052-aac9-fb87f2a38659@googlegroups.com> |
| In reply to | #94801 |
On Thursday, October 13, 2016 at 9:55:22 AM UTC+1, Richard Heathfield wrote: > On 13/10/16 09:49, Malcolm McLean wrote: > > On Wednesday, October 12, 2016 at 6:50:16 PM UTC+1, Richard Heathfield wrote: > >> > >> It hardly matters. If you don't mean an array, then it's beyond > >> guessing, wild or otherwise. And if you do mean an array, why not say > >> "array"? > >> > > Generally, by "array" people mean "array of data", > > Stop right there. This is comp.lang.c, where "array" is a technical term > with a highly specialised meaning. If you want to assign another meaning > to the word "array", you do so at the risk of confusing some of your > readership and alienating the rest of it. > > You would do better to stop making up meanings for existing technical > terms. If you must have these new meanings, make up new words to > describe them. If the meanings are useful, the words will catch on. > "array" is a technical term for a data structure. "Data" means, "what is given", what ultimately has its source in something from outside the system, either hardcoded in or read from an external connection. structure means a logical arrangment with rules for access, and essentially a synonym for "graph". However arrays are such degenerate graphs that we normally special-case them and don't think of them as "graphs". However it's maybe useful to think of integers (ints and size_ts) as special efficient ways of describing the edges of a graph which is an array, and the constant pointer as the root.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-13 10:35 +0100 |
| Message-ID | <ntnkfm$bfh$2@dont-email.me> |
| In reply to | #94803 |
On 13/10/16 10:09, Malcolm McLean wrote: > On Thursday, October 13, 2016 at 9:55:22 AM UTC+1, Richard Heathfield wrote: >> On 13/10/16 09:49, Malcolm McLean wrote: >>> On Wednesday, October 12, 2016 at 6:50:16 PM UTC+1, Richard Heathfield wrote: >>>> >>>> It hardly matters. If you don't mean an array, then it's beyond >>>> guessing, wild or otherwise. And if you do mean an array, why not say >>>> "array"? >>>> >>> Generally, by "array" people mean "array of data", >> >> Stop right there. This is comp.lang.c, where "array" is a technical term >> with a highly specialised meaning. If you want to assign another meaning >> to the word "array", you do so at the risk of confusing some of your >> readership and alienating the rest of it. >> >> You would do better to stop making up meanings for existing technical >> terms. If you must have these new meanings, make up new words to >> describe them. If the meanings are useful, the words will catch on. >> > "array" is a technical term for a data structure. In C, it has a more specialised meaning. This is comp.lang.c, where C's definitions take precedence. Please try to get used to the idea. -- 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 | 2016-10-13 08:23 -0700 |
| Message-ID | <ln8ttsl1bm.fsf@kst-u.example.com> |
| In reply to | #94800 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, October 12, 2016 at 6:50:16 PM UTC+1, Richard Heathfield wrote:
>> It hardly matters. If you don't mean an array, then it's beyond
>> guessing, wild or otherwise. And if you do mean an array, why not say
>> "array"?
>>
> Generally, by "array" people mean "array of data", which clearly isn't
> the case here - we have no data. You can say that uninitialised memory
> is an "array of int objects" if you want, but that's pretty confusing
> also. C doesn't set up objects, a memory buffer is treated as
> containing objects of the type pointed to.
Malcolm, please stop this nonsense.
An array object is an object of array type. It is an array object
whether it's been initialized or not.
I've asked you before to show an example of someone using the word
"array" the way you do, and you have failed to do so. (I'm not asking
again.)
You are the *only* person who uses the word "array" in this particular
incorrect sense, and I'm getting tired of having to point it out.
Feel free to use the term "Malcolm-array" if you like -- or just
"initialized array object", or perhaps what you mean is "array value".
> "int objects" are just "memory which can hold an int". So if you
> imagine the data as soldiers, and the memory as the parade ground, the
> int objects are the little squares on the parade ground where the
> soldiers can stand. Sometimes it might be helpful to have that image
> in mind.
No, it's not helpful at all.
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-10-13 18:49 +0100 |
| Message-ID | <87d1j4kukx.fsf@gmail.com> |
| In reply to | #94825 |
Keith Thompson <kst-u@mib.org> writes: >> "int objects" are just "memory which can hold an int". So if you >> imagine the data as soldiers, and the memory as the parade ground, the >> int objects are the little squares on the parade ground where the >> soldiers can stand. Sometimes it might be helpful to have that image >> in mind. > > No, it's not helpful at all. Actually, this metaphor produced Richard's magnificent "Buffer-low Soldier" joke, and so it is directly responsible for the sol highpoint of Malcolm's contribution to this newsgroup, and his idiosyncratic views on Computer Science terminology.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-10-12 10:52 -0700 |
| Message-ID | <ccbcf092-72a8-48ab-b172-56e6ebb36e43@googlegroups.com> |
| In reply to | #94781 |
Bart wrote: > Uncanny isn't it the way the two concepts seem to match > up in just the way I said. You are definitely correct in implementation, but the way C works is in abstract concepts which are abstracted from hardware. As such, a strict C view will never cojoin the two forms, even though they are completely married into one in practice. It's even kind of silly with the C view to recognize the buff[1024] by its sizeof operation, because under that model, buff[0] would reference the 0..1023 elements, and buff[1] would refence the 1024..2047 elements. We all know it's not like that, but [n] accesses data relative to &buff[0] in all cases, same as a pointer. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-12 12:06 -0700 |
| Message-ID | <lnpon5l74i.fsf@kst-u.example.com> |
| In reply to | #94781 |
BartC <bc@freeuk.com> writes:
> On 12/10/2016 16:53, Richard Heathfield wrote:
>> On 12/10/16 16:44, BartC wrote:
>
>>> So? Someone might want to have a constant pointer to a block of ints.
>>
>> Non sequitur. int buff[1024] is not a constant pointer to a block of
>> ints. If someone wants a constant pointer to what you call a "block" of
>> ints (and it isn't clear to me what you mean by a "block"),
>
> Make a wild guess.
>
> they will
>> need to define a constant pointer to a "block" of ints. The definition
>> int buff[1024]; will not give them that.
>
> We're talking about a contiguous sequence of 4096 bytes in what might be
> called 'bss' or 'text' memory, depending whether it's initialised, the
> starting address of which is fixed at link or load time.
Bss? Text? What are those? (That's rhetorical, don't bother
answering.)
Those are mechanisms used by some implementations to *implement* C
semantics.
If you want to introduce a new learner to C by discussing how C source
code is mapped to lower level concepts, you can do that. I personally
don't think it's the best approach.
C source specifies *behavior*. Generated machine code is a tool used to
implement that behavior.
> This is what 'int buff[1024]' in C gives you, which is exactly the same
> thing, when you get down to fundamentals, as a constant pointer to a
> block of 1024 ints.
No, it's not a pointer to a block. It *is* the block. It happens to be
easy to construct a pointer value that points to the beginning of that
block.
If you define
int n = 42;
it's nearly as easy to construct a pointer value that points to
that int object, but I don't think anyone would suggest that "n"
is, when you get down to fundamentals, a constant pointer.
[...]
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-12 19:41 +0100 |
| Message-ID | <87shs18l6f.fsf@bsb.me.uk> |
| In reply to | #94773 |
BartC <bc@freeuk.com> writes: > On 12/10/2016 13:14, Richard Heathfield wrote: >> On 12/10/16 10:25, BartC wrote: >>> On 12/10/2016 06:57, Richard Heathfield wrote: >>>> On 12/10/16 02:41, Malcolm McLean wrote: >>>> <snip> >>>>> int buff[1024]; >>>>> >>>>> buff is a constant pointer >>>> >>>> Wrong. It is an array of 1024 int objects. >>> >>> Within the constraints of C. >> >> Right. Check the newsgroup title. > > So? Someone might want to have a constant pointer to a block of > ints. Then the closest they can get to it is the above. In what way would that person be unhappy with a C array of ints, a pointer value to the first of which is so readily available? Are you just arguing about the words? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-13 01:59 -0700 |
| Message-ID | <dc569750-5e3a-4d58-96f8-7d7eba9b963f@googlegroups.com> |
| In reply to | #94787 |
On Wednesday, October 12, 2016 at 7:41:21 PM UTC+1, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > > In what way would that person be unhappy with a C array of ints, a > pointer value to the first of which is so readily available? Are you > just arguing about the words? > C could have said that instead of char buff[1024]; set_up_a_nice_string(buff, 1024); one must write char buff[1024]; set_up_a_nice_string(&buff[0], 1024); and indeed we need to use that method in the unusual case of wanting our nice string to start at index 1. But it didn't. buff is a constant character pointer, except for the odd little quirk which is mainly undesireable in real code anyway. You can argue about whether sizeof buff is more or less likely to break than 1024 (is it more likely that someone will change the buffer size without checking the rest of the function, or that they will change buff to live in dynamic memory without checking the rest of the function?) , the rest of the syntax for passing arrays rather than pointers to the first value is unnecessary, little-used and best avoided.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-13 10:34 +0100 |
| Message-ID | <ntnkdn$bfh$1@dont-email.me> |
| In reply to | #94802 |
On 13/10/16 09:59, Malcolm McLean wrote: > On Wednesday, October 12, 2016 at 7:41:21 PM UTC+1, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> > >> In what way would that person be unhappy with a C array of ints, a >> pointer value to the first of which is so readily available? Are you >> just arguing about the words? >> > C could have said that instead of > > char buff[1024]; > > set_up_a_nice_string(buff, 1024); > > one must write > > char buff[1024]; > > set_up_a_nice_string(&buff[0], 1024); > > and indeed we need to use that method in the unusual case of wanting our > nice string to start at index 1. > But it didn't. buff is a constant character pointer, No, it isn't. It's an array, for Pete's sake. We already covered that. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-13 13:08 +0100 |
| Message-ID | <871szk8n9o.fsf@bsb.me.uk> |
| In reply to | #94802 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, October 12, 2016 at 7:41:21 PM UTC+1, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> > >> In what way would that person be unhappy with a C array of ints, a >> pointer value to the first of which is so readily available? Are you >> just arguing about the words? >> > C could have said that instead of > > char buff[1024]; > > set_up_a_nice_string(buff, 1024); > > one must write > > char buff[1024]; > > set_up_a_nice_string(&buff[0], 1024); > > and indeed we need to use that method in the unusual case of wanting our > nice string to start at index 1. > But it didn't. Quite. > buff is a constant character pointer, except for the odd little > quirk which is mainly undesireable in real code anyway. No it isn't is constant character pointer. It is an expression with array type that is not an lvalue. I find it strange how many people want to pretend otherwise. The conversion to a pointer in not complicated to explain. It's much easier than trying to explain what things like &buff and m[i][j] mean if there are no expressions with array type in C. > You can argue about whether sizeof buff is more or less likely to > break than 1024 (is it more likely that someone will change the buffer > size without checking the rest of the function, or that they will > change buff to live in dynamic memory without checking the rest of the > function?) , the rest of the syntax for passing arrays rather than > pointers to the first value is unnecessary, little-used and best > avoided. You can't pass an array so there is no need to avoid any syntax. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-13 05:22 -0700 |
| Message-ID | <fa7f2af3-db8d-4b5d-a508-84012777ec63@googlegroups.com> |
| In reply to | #94813 |
On Thursday, October 13, 2016 at 1:08:27 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > You can argue about whether sizeof buff is more or less likely to > > break than 1024 (is it more likely that someone will change the buffer > > size without checking the rest of the function, or that they will > > change buff to live in dynamic memory without checking the rest of the > > function?) , the rest of the syntax for passing arrays rather than > > pointers to the first value is unnecessary, little-used and best > > avoided. > > You can't pass an array so there is no need to avoid any syntax. > Course you can. Just not by value.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-13 13:29 +0100 |
| Message-ID | <ntnumm$eni$1@dont-email.me> |
| In reply to | #94817 |
On 13/10/16 13:22, Malcolm McLean wrote: > On Thursday, October 13, 2016 at 1:08:27 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >>> You can argue about whether sizeof buff is more or less likely to >>> break than 1024 (is it more likely that someone will change the buffer >>> size without checking the rest of the function, or that they will >>> change buff to live in dynamic memory without checking the rest of the >>> function?) , the rest of the syntax for passing arrays rather than >>> pointers to the first value is unnecessary, little-used and best >>> avoided. >> >> You can't pass an array so there is no need to avoid any syntax. >> > > Course you can. Just not by value. And since "by value" is the *only* way you can pass an argument in C, that means you can't pass arrays. -- 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 | 2016-10-13 08:31 -0700 |
| Message-ID | <lnvawwjmdu.fsf@kst-u.example.com> |
| In reply to | #94817 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, October 13, 2016 at 1:08:27 PM UTC+1, Ben Bacarisse wrote:
[...]
>> You can't pass an array so there is no need to avoid any syntax.
>
> Course you can. Just not by value.
Malcolm, please stop this nonsense.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-13 08:31 -0700 |
| Message-ID | <lnzim8jmet.fsf@kst-u.example.com> |
| In reply to | #94813 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
>> char buff[1024];
[...]
>> buff is a constant character pointer, except for the odd little
>> quirk which is mainly undesireable in real code anyway.
>
> No it isn't is constant character pointer. It is an expression with
> array type that is not an lvalue.
What do you mean it's not an lvalue?
"buff" is the name of an array object. When used as an expression (a
primary-expression), it certainly is an lvalue; it designates an object.
Like any expression of array type, it may or may not be "converted"
("adjusted" would have been clearer) to an expression of pointer type,
which is not an lvalue.
[...]
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-10-13 18:57 +0100 |
| Message-ID | <878ttsku7w.fsf@gmail.com> |
| In reply to | #94827 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > [...] >>> char buff[1024]; > [...] >>> buff is a constant character pointer, except for the odd little >>> quirk which is mainly undesireable in real code anyway. >> >> No it isn't is constant character pointer. It is an expression with >> array type that is not an lvalue. > > What do you mean it's not an lvalue? He means "modifiable lvalue". A natural mistake to make if your approximate mnemonic for l-value is "Can go on the left side of an = sign", which is the source of the name, if not technically correct in C.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-13 19:26 +0100 |
| Message-ID | <87bmyo6r6y.fsf@bsb.me.uk> |
| In reply to | #94827 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > [...] >>> char buff[1024]; > [...] >>> buff is a constant character pointer, except for the odd little >>> quirk which is mainly undesireable in real code anyway. >> >> No it isn't is constant character pointer. It is an expression with >> array type that is not an lvalue. > > What do you mean it's not an lvalue? Sorry, I mean that it's not a modifiable lvalue. I wanted to explain why people think of it as "constant" but missed out the crucial word! <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-13 08:27 -0700 |
| Message-ID | <ln4m4gl15a.fsf@kst-u.example.com> |
| In reply to | #94802 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> char buff[1024];
[...]
> buff is a constant character pointer, except for the odd little
> quirk which is mainly undesireable in real code anyway.
Malcolm, please stop this nonsense. buff is an array
object. It is not a pointer. Perhaps you could call it a
Malcolm-constant-character-pointer.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-10-15 15:09 -0700 |
| Message-ID | <kfnr37h5knm.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #94826 |
Keith Thompson <kst-u@mib.org> writes: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > [...] >> char buff[1024]; > > [...] > >> buff is a constant character pointer, except for the odd little >> quirk which is mainly undesireable in real code anyway. > > Malcolm, please stop this nonsense. buff is an array > object. It is not a pointer. Perhaps you could call it a > Malcolm-constant-character-pointer. What I find really bothersome is not his holding a completely bizarro worldview, but his stubborn insistence that other people either hold the same worldview or are mistaken. Add to that the frosting on the cake that AFAICT no one other than he does hold the same worldview. The height of ignorance, or the height of arrogance? It's hard to say which.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web