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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-11 18:41 -0700 |
| Message-ID | <a112116d-6e6a-402e-8e36-f135d32b6279@googlegroups.com> |
| In reply to | #94754 |
On Wednesday, October 12, 2016 at 2:08:24 AM UTC+1, Keith Thompson wrote: > ram@zedat.fu-berlin.de (Stefan Ram) writes: > > Richard Heathfield <rjh@cpax.org.uk> writes: > >>There we will have to differ, then. Complete beginners should not be > >>told lies by their teachers. > > > > Complete beginners should not be told about pointers at all! > > > > I sometimes use l^Hsimplifications, when their benefit seems > > to be larger than the damage they cause. > > > > I explain early that the type of a string literal is > > »char*«, but I explain the »*« as follows: > > > > In »char*«, the »*« indicates a repetition of a > > character (»char«), that is a sequence of characters. > > > > This may even verge on being correct, just a little bit > > "abstract"¹. > > > > Addresses are then only treated much later in my course. > > I can understand the value of simplifications when teaching beginners. > > This, in my humble opinion, goes beyond that, in a very bad way. It > instills tempting but false ideas that could be difficult to untangle > when the student is ready to learn more. "*" does denote repetition in > some contexts (regular exressions), but not in any that are relevent > here. It reinforces the pervasive fallacy that arrays are really just > pointers. It is, in my opinion, deliberately misleading. > int buff[1024]; buff is a constant pointer to a buffer (which C mis-terms an "array") which contains enough space for 1024 integers. Except there's a little syntactical quirk. But that can be ignored for now.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-11 18:55 -0700 |
| Message-ID | <ln37k2miv9.fsf@kst-u.example.com> |
| In reply to | #94756 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, October 12, 2016 at 2:08:24 AM UTC+1, Keith Thompson wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> > Richard Heathfield <rjh@cpax.org.uk> writes:
>> >>There we will have to differ, then. Complete beginners should not be
>> >>told lies by their teachers.
>> >
>> > Complete beginners should not be told about pointers at all!
>> >
>> > I sometimes use l^Hsimplifications, when their benefit seems
>> > to be larger than the damage they cause.
>> >
>> > I explain early that the type of a string literal is
>> > »char*«, but I explain the »*« as follows:
>> >
>> > In »char*«, the »*« indicates a repetition of a
>> > character (»char«), that is a sequence of characters.
>> >
>> > This may even verge on being correct, just a little bit
>> > "abstract"¹.
>> >
>> > Addresses are then only treated much later in my course.
>>
>> I can understand the value of simplifications when teaching beginners.
>>
>> This, in my humble opinion, goes beyond that, in a very bad way. It
>> instills tempting but false ideas that could be difficult to untangle
>> when the student is ready to learn more. "*" does denote repetition in
>> some contexts (regular exressions), but not in any that are relevent
>> here. It reinforces the pervasive fallacy that arrays are really just
>> pointers. It is, in my opinion, deliberately misleading.
>>
> int buff[1024];
>
> buff is a constant pointer to a buffer (which C mis-terms an "array")
> which contains enough space for 1024 integers. Except there's a little
> syntactical quirk. But that can be ignored for now.
If you're trying to demonstrate the idea of being deliberate misleading,
well done.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-10-14 22:09 -0400 |
| Message-ID | <mdgMz.71127$uv1.64298@fx03.iad> |
| In reply to | #94757 |
On 10/11/16 9:55 PM, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> int buff[1024]; >> >> buff is a constant pointer to a buffer (which C mis-terms an "array") >> which contains enough space for 1024 integers. Except there's a little >> syntactical quirk. But that can be ignored for now. > > If you're trying to demonstrate the idea of being deliberate misleading, > well done. > IF you want a constant pointer to a 'buffer' of ints: int buffer[1024][ int * const pointer = buffer; pointer now IS a constant pointer to the array buffer. accessable int by int.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-15 10:51 +0100 |
| Message-ID | <ntsu63$ii0$1@dont-email.me> |
| In reply to | #94863 |
On 15/10/2016 03:09, Richard Damon wrote: > On 10/11/16 9:55 PM, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> int buff[1024]; >>> >>> buff is a constant pointer to a buffer (which C mis-terms an "array") >>> which contains enough space for 1024 integers. Except there's a little >>> syntactical quirk. But that can be ignored for now. >> >> If you're trying to demonstrate the idea of being deliberate misleading, >> well done. >> > > IF you want a constant pointer to a 'buffer' of ints: > > > int buffer[1024][ > > int * const pointer = buffer; > > > pointer now IS a constant pointer to the array buffer. accessable int by > int. No. 'pointer' is set up as the address of a location that /contains/ a pointer to buffer. It is not a pointer to buffer. (When both are at file scope.) Although when compiled with gcc, evaluation of 'pointer', thanks to the const attribute, is reduced into the evaluation of 'buffer', which is an immediate address. With several other compilers however, this doesn't happen. So it's not something that is guaranteed by the language; it's a perk that you might get with the right compiler. (Also C allows &pointer which wouldn't be meaningful with a true immediate pointer.) The nearest thing to a constant pointer to the buffer is 'buffer' itself. But in the language, you have to express it as the name of an array. I think this is what I said much further up the thread. It's just a question of whether it's allowable to think of it as a constant pointer to a block of integers rather than an array of integers. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-15 19:11 +0100 |
| Message-ID | <878ttp5vph.fsf@bsb.me.uk> |
| In reply to | #94864 |
BartC <bc@freeuk.com> writes: > On 15/10/2016 03:09, Richard Damon wrote: >> On 10/11/16 9:55 PM, Keith Thompson wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>> int buff[1024]; >>>> >>>> buff is a constant pointer to a buffer (which C mis-terms an "array") >>>> which contains enough space for 1024 integers. Except there's a little >>>> syntactical quirk. But that can be ignored for now. >>> >>> If you're trying to demonstrate the idea of being deliberate misleading, >>> well done. >>> >> >> IF you want a constant pointer to a 'buffer' of ints: >> >> >> int buffer[1024][ >> >> int * const pointer = buffer; >> >> >> pointer now IS a constant pointer to the array buffer. accessable int by >> int. > > No. 'pointer' is set up as the address of a location that /contains/ a > pointer to buffer. It is not a pointer to buffer. (When both are at > file scope.) Do you promise to complain, from now on, every time someone writes int x; and refers to x as an int by saying "no, it is set up as the address of a location that /contains/ an int"? If so, then your dogged consistency should be applauded. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-15 21:14 +0100 |
| Message-ID | <ntu2lr$gum$1@dont-email.me> |
| In reply to | #94868 |
On 15/10/2016 19:11, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 15/10/2016 03:09, Richard Damon wrote: >>> On 10/11/16 9:55 PM, Keith Thompson wrote: >>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>>> int buff[1024]; >>>>> >>>>> buff is a constant pointer to a buffer (which C mis-terms an "array") >>>>> which contains enough space for 1024 integers. Except there's a little >>>>> syntactical quirk. But that can be ignored for now. >>>> >>>> If you're trying to demonstrate the idea of being deliberate misleading, >>>> well done. >>>> >>> >>> IF you want a constant pointer to a 'buffer' of ints: >>> >>> >>> int buffer[1024][ >>> >>> int * const pointer = buffer; >>> >>> >>> pointer now IS a constant pointer to the array buffer. accessable int by >>> int. >> >> No. 'pointer' is set up as the address of a location that /contains/ a >> pointer to buffer. It is not a pointer to buffer. (When both are at >> file scope.) > > Do you promise to complain, from now on, every time someone writes > > int x; > > and refers to x as an int by saying "no, it is set up as the address of > a location that /contains/ an int"? If so, then your dogged consistency > should be applauded. That's not the same. You understand that in RD's example, and disregarding type, there is an extra level of indirection between the value of 'pointer' and the value of &buffer? That is before implementations apply optimisations: the language will have the extra indirection, the implementation may choose to by-pass it. This is similar to someone saying that use of the x in this declaration: const int x = 5848; is exactly the same as using an immediate integer value (eg. 5848). There is also an extra level of indirection, although compilers find it much easier to eliminate that in generated code. That doesn't change the fact that the two are treated differently in the language: int A[x]; // not allowed at filescope int B[5848]; // allowed &x; // allowed &5848; // not allowed case x: // not allowed case 5848: // allowed Compare the behaviour of the above with, say, one of my languages (but I'll illustrate it using C syntax): const int x = 5848; // does not result in extra indirection int A[x]; // allowed at file scope int B[5848]; // allowed &x; // not allowed &5858; // not allowed case x: // allowed case 5848: // allowed Notice the symmetry? C can get this behaviour using: enum (x = 5848}; but it just shows there is something fundamentally different between x as an enum, and x as a const int. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-15 22:33 +0100 |
| Message-ID | <87twcd47s4.fsf@bsb.me.uk> |
| In reply to | #94874 |
BartC <bc@freeuk.com> writes: > On 15/10/2016 19:11, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 15/10/2016 03:09, Richard Damon wrote: >>>> On 10/11/16 9:55 PM, Keith Thompson wrote: >>>>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>>>>> int buff[1024]; >>>>>> >>>>>> buff is a constant pointer to a buffer (which C mis-terms an "array") >>>>>> which contains enough space for 1024 integers. Except there's a little >>>>>> syntactical quirk. But that can be ignored for now. >>>>> >>>>> If you're trying to demonstrate the idea of being deliberate misleading, >>>>> well done. >>>>> >>>> >>>> IF you want a constant pointer to a 'buffer' of ints: >>>> >>>> >>>> int buffer[1024][ >>>> >>>> int * const pointer = buffer; >>>> >>>> >>>> pointer now IS a constant pointer to the array buffer. accessable int by >>>> int. >>> >>> No. 'pointer' is set up as the address of a location that /contains/ a >>> pointer to buffer. It is not a pointer to buffer. (When both are at >>> file scope.) >> >> Do you promise to complain, from now on, every time someone writes >> >> int x; >> >> and refers to x as an int by saying "no, it is set up as the address of >> a location that /contains/ an int"? If so, then your dogged consistency >> should be applauded. > > That's not the same. > > You understand that in RD's example, and disregarding type, there is > an extra level of indirection between the value of 'pointer' and the > value of &buffer? No, I don't understand that. What do you mean by it? What do you think the value of (void *)pointer == (void *)&buffer is? The casts just implement your "disregarding type" remark -- there are no other conversions or dereferences being done in that expression. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-15 23:13 +0100 |
| Message-ID | <ntu9m6$7pv$1@dont-email.me> |
| In reply to | #94881 |
On 15/10/2016 22:33, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> That's not the same.
>>
>> You understand that in RD's example, and disregarding type, there is
>> an extra level of indirection between the value of 'pointer' and the
>> value of &buffer?
>
> No, I don't understand that. What do you mean by it? What do you think
> the value of
>
> (void *)pointer == (void *)&buffer
>
> is? The casts just implement your "disregarding type" remark -- there
> are no other conversions or dereferences being done in that expression.
The types needed to be disregarded so that we don't have a pointer to T
on one hand and pointer to array of T on the other.
Your example however is similar to this:
int x = 89;
(int)x == (int)89
Clearly the values are the same, but there will usually be some storage
associated with x that there isn't with the value on the right. Even if
you throw in a const.
I don't know your background so perhaps you really don't understand what
happens at the low level. But take this example:
int buffer[1024]; // file scope
int * const pointer = buffer;
Now look what happens at the generated code, given 'int* p', for each of:
p = buffer;
p = pointer;
I will show the first or only instruction generated, all without
optimisations:
p = buffer; p = pointer;
gcc mov [p], buffer mov [p], buffer
Tiny C mov R, buffer mov R, [pointer]
Pelles C mov [p], buffer mov R, [pointer]
MSVC mov [p], buffer mov R, [pointer]
lccwin lea R, [buffer] mov R, [pointer]
Leaving aside gcc, all the compilers generate an extra memory access for
'p=pointer', to get the value stored inside 'pointer', which is that of
'buffer'.
And all compilers manage to use an immediate operand (so no extra memory
access) for 'p=buffer'. (LEA is a special instruction which evaluates
the address; it does not do the memory access.)
In the case of gcc, it has optimised the code even without being told.
There are also other processors than x86 which can have restrictions on
using immediate operands such that they might need to be stored in a
memory location anyway.
But given the the availability of both immediate and memory operands,
the natural way to implement the bit of C code above is with an
immediate operand for 'buffer' and a indirect memory operand for 'pointer'.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-15 15:34 -0700 |
| Message-ID | <lna8e5gs1o.fsf@kst-u.example.com> |
| In reply to | #94886 |
BartC <bc@freeuk.com> writes:
> On 15/10/2016 22:33, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> That's not the same.
>>>
>>> You understand that in RD's example, and disregarding type, there is
>>> an extra level of indirection between the value of 'pointer' and the
>>> value of &buffer?
>>
>> No, I don't understand that. What do you mean by it? What do you think
>> the value of
>>
>> (void *)pointer == (void *)&buffer
>>
>> is? The casts just implement your "disregarding type" remark -- there
>> are no other conversions or dereferences being done in that expression.
>
> The types needed to be disregarded so that we don't have a pointer to T
> on one hand and pointer to array of T on the other.
In other words, the types need to be disregarded so we can disregard the
types.
> Your example however is similar to this:
>
> int x = 89;
>
> (int)x == (int)89
>
> Clearly the values are the same, but there will usually be some storage
> associated with x that there isn't with the value on the right. Even if
> you throw in a const.
Yes, we know the difference between values and objects.
> I don't know your background so perhaps you really don't understand what
> happens at the low level. But take this example:
>
> int buffer[1024]; // file scope
>
> int * const pointer = buffer;
>
> Now look what happens at the generated code, given 'int* p', for each of:
>
> p = buffer;
> p = pointer;
The first involves an implicit array-to-pointer conversion. The second
doesn't; it simply copies a pointer value from one pointer object to
another.
> I will show the first or only instruction generated, all without
> optimisations:
The generated code is whatever is needed to implement the semantics.
> p = buffer; p = pointer;
>
> gcc mov [p], buffer mov [p], buffer
>
> Tiny C mov R, buffer mov R, [pointer]
>
> Pelles C mov [p], buffer mov R, [pointer]
>
> MSVC mov [p], buffer mov R, [pointer]
>
> lccwin lea R, [buffer] mov R, [pointer]
>
> Leaving aside gcc, all the compilers generate an extra memory access for
> 'p=pointer', to get the value stored inside 'pointer', which is that of
> 'buffer'.
And gcc doesn't (so presumably none of the others really have to), but I
guess we can ignore anything that doesn't support your point.
[...]
I'm still not sure what point you're making. Can you try again
referring only to C semantics?
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-16 00:37 +0100 |
| Message-ID | <ntueio$khq$1@dont-email.me> |
| In reply to | #94889 |
On 15/10/2016 23:34, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> The types needed to be disregarded so that we don't have a pointer to T >> on one hand and pointer to array of T on the other. > > In other words, the types need to be disregarded so we can disregard the > types. And if I hadn't mentioned disregarding them, you would have been certain to make exactly that point! Actually I think you bring it up anyway.... > The generated code is whatever is needed to implement the semantics. > >> p = buffer; p = pointer; >> >> gcc mov [p], buffer mov [p], buffer >> >> Tiny C mov R, buffer mov R, [pointer] >> >> Pelles C mov [p], buffer mov R, [pointer] >> >> MSVC mov [p], buffer mov R, [pointer] >> >> lccwin lea R, [buffer] mov R, [pointer] >> >> Leaving aside gcc, all the compilers generate an extra memory access for >> 'p=pointer', to get the value stored inside 'pointer', which is that of >> 'buffer'. > > And gcc doesn't (so presumably none of the others really have to), but I > guess we can ignore anything that doesn't support your point. But, for what earthly reason would all those other compilers waste time generating unnecessary memory accesses? Could it possibly be that there is, in fact, a significant difference between 'buffer' and 'pointer'? That some compilers can optimise out the difference is not relevant. The semantics of a language cannot be conditional on the behaviour of certain compilers. Take this code: char* p ="ABC"; char c; c = *p; It looks to me that it takes pointer p and dereferences it to get at the value it points to. Agree, yes? Now suppose that gcc can optimise this so that it can just do the equivalent of: c = 'A'; Does that mean there is no dereference after all in that fragment of code? Because some compilers may not do that optimisation. Or there isn't a compiler at all if you're just looking at it. Or something changes so that the dereference becomes necessary. My code examples were anyway explaining to Ben what I meant by extra indirection. But C seems to be annoyingly fond of hiding as much indirection and dereferencing as possible, and that's even without compilers doing their part as well! So, is there actually an extra memory access when using 'p=pointer' compared with 'p=buffer' or not? Or does no-one actually care? Experience with arrays and functions suggest no one does. One problem is this: const int a = b; a; Does this involve a memory access or not? The answer is that you simply can't tell. Sometimes it will, sometimes it won't, sometimes it depends on how clever the compiler is. And it depends also on b. (And we haven't even considered the capabilities of the hardware.) But IN GENERAL, such a construct will allocate storage, it will have b put in it, and accessing 'a' involves reading that location. That's a model you can use as a starting point, before you drag in compilers, optimisers and various weird hardware. Then, IN GENERAL, my 'pointer' example will involve one extra memory access compared with 'buffer'. And it is in this general mode that we write the code, before we go anywhere near a compiler or an actual machine. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-16 01:00 +0100 |
| Message-ID | <87oa2l40y8.fsf@bsb.me.uk> |
| In reply to | #94886 |
BartC <bc@freeuk.com> writes: > On 15/10/2016 22:33, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> That's not the same. >>> >>> You understand that in RD's example, and disregarding type, there is >>> an extra level of indirection between the value of 'pointer' and the >>> value of &buffer? >> >> No, I don't understand that. What do you mean by it? What do you think >> the value of >> >> (void *)pointer == (void *)&buffer >> >> is? The casts just implement your "disregarding type" remark -- there >> are no other conversions or dereferences being done in that expression. > > The types needed to be disregarded so that we don't have a pointer to > T on one hand and pointer to array of T on the other. > > Your example however is similar to this: > > int x = 89; > > (int)x == (int)89 > > Clearly the values are the same, but there will usually be some > storage associated with x that there isn't with the value on the > right. Even if you throw in a const. Yes, that's why I gave that example. You said that there is an extra level of indirection between the /value/ of pointer and the /value/ of &buffer. How can two values which, when suitably converted, are the same have a level of indirection between them? That's all I'm asking here. Obviously you are using the term "indirection" in a different way to me, and it's not just that one is an object and the other a value since you rejected that explanation of your words and the re-worded it explicitly in terms of the value of both expressions. > I don't know your background so perhaps you really don't understand > what happens at the low level. I know what's going on. That's why I offered the value/object explanation as being what you meant, but you rejected that and explicitly re-worded it in terms of the values of two expressions. > But take this example: > > int buffer[1024]; // file scope > > int * const pointer = buffer; > > Now look what happens at the generated code, given 'int* p', for each of: > > p = buffer; > p = pointer; > > I will show the first or only instruction generated, all without > optimisations: > > p = buffer; p = pointer; > > gcc mov [p], buffer mov [p], buffer > > Tiny C mov R, buffer mov R, [pointer] > > Pelles C mov [p], buffer mov R, [pointer] > > MSVC mov [p], buffer mov R, [pointer] > > lccwin lea R, [buffer] mov R, [pointer] > > Leaving aside gcc, all the compilers generate an extra memory access > for 'p=pointer', to get the value stored inside 'pointer', which is > that of 'buffer'. This is the object/value distinction. Every time someone inadvertently states that after int x = 42; int *pointer = &x; that "x is a pointer" you must laboriously explain that, "no 'pointer' is set up as the address of a location that /contains/ an int". However your recent clarification seems to argue against this explanation, and you did in fact reject it. The /value/ of pointer and the /value/ of &buffer are the same (provided they can be compared at all). So, to be absolutely clear, I don't object to you making this point: || No, 'pointer' is set up as the address of a location that /contains/ || a pointer to buffer. provided you make it everywhere else. But I disagree that the /value/ of pointer and the /value/ of &buffer have a level of indirection between them. Obtaining the value of pointer may (or may not) involve accessing an object but the value, once obtained, is the same as the value of &buffer (suitably converted). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-17 17:48 +0100 |
| Message-ID | <nu2vc6$nef$1@dont-email.me> |
| In reply to | #94897 |
On 16/10/2016 01:00, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> p = buffer; p = pointer;
>>
>> gcc mov [p], buffer mov [p], buffer
>>
>> Tiny C mov R, buffer mov R, [pointer]
>>
>> Pelles C mov [p], buffer mov R, [pointer]
>>
>> MSVC mov [p], buffer mov R, [pointer]
>>
>> lccwin lea R, [buffer] mov R, [pointer]
>>
>> Leaving aside gcc, all the compilers generate an extra memory access
>> for 'p=pointer', to get the value stored inside 'pointer', which is
>> that of 'buffer'.
>
> This is the object/value distinction.
I glossed over this at first reading as I assumed you were right.
But this wasn't quite my point, which was about the differences between
the expressions in the first and second columns here, given the
declarations on the right:
23; x; // int x = 23;
x; *p; // int* p = &x;
&x; p;
The second column involves an extra layer of indirection (not
withstanding that some implementations may remove that level if they
think they can optimise it out, or that certain hardware may impose an
extra level on the left due to instruction set limitations. In the pure
model of how a language works, there /will/ be an extra layer.)
The following example is different: both columns have the same rank:
23; y; // enum {y = 23};
while here, C generates a lot of confusion:
23; z; // const int z = 23;
because the behaviour is sometimes like x above and sometimes like y.
(I don't know what other people think about 'value' and 'object', but I
distinguish between values stored in named objects or at the end of a
pointer, from those that are intermediate values in expressions such as
results of operations or function calls. The latter can't have & in
front of them (although I suspect some hairy C implementations will
allow it).
In the case of named constants (C's enums come close to these) then
those are classed with those intermediate values as they don't exist
anywhere unless occurring in an expression.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-17 20:09 +0100 |
| Message-ID | <87r37e7pyh.fsf@bsb.me.uk> |
| In reply to | #94998 |
BartC <bc@freeuk.com> writes: > On 16/10/2016 01:00, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> p = buffer; p = pointer; >>> >>> gcc mov [p], buffer mov [p], buffer >>> >>> Tiny C mov R, buffer mov R, [pointer] >>> >>> Pelles C mov [p], buffer mov R, [pointer] >>> >>> MSVC mov [p], buffer mov R, [pointer] >>> >>> lccwin lea R, [buffer] mov R, [pointer] >>> >>> Leaving aside gcc, all the compilers generate an extra memory access >>> for 'p=pointer', to get the value stored inside 'pointer', which is >>> that of 'buffer'. >> >> This is the object/value distinction. > > I glossed over this at first reading as I assumed you were right. > > But this wasn't quite my point, which was about the differences > between the expressions in the first and second columns here, given > the declarations on the right: > > 23; x; // int x = 23; > x; *p; // int* p = &x; > &x; p; > > The second column involves an extra layer of indirection I don't think you got what I meant by object/value distinction -- I'm sure a made hash of explaining it. But that's fine. There's little to be gained by us understanding each other and, since no one else is reading this thread anymore, I don't think whatever you mean by "an extra level of indirection" is going to cause anyone any (else) any confusion. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-15 23:55 +0100 |
| Message-ID | <ntuc41$e89$1@dont-email.me> |
| In reply to | #94881 |
On 15/10/2016 22:33, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> You understand that in RD's example, and disregarding type, there is
>> an extra level of indirection between the value of 'pointer' and the
>> value of &buffer?
>
> No, I don't understand that. What do you mean by it?
I didn't realise my language was up to it, but it can define true
constant pointers (to fixed addresses anyway):
const ref byte p = ref byte(0xC000) # NOT C
byte a
a = p^
This generates this C:
a = *49152;
While a non-constant pointer would result in:
char * p = 49152;
a = *p;
It shows that C can have constant pointers, but like named integer
literals, it has the same issues with named constant pointers (or
pointer literals, although such pointers would normally refer to some
symbol not a hardcoded address).
Of course C can struggle through and there are any number of ways of
achieving a constant pointer without the indirection:
#define p 0xC000
enum {p = 0xC000}; // this might work, if value is in range
char * const p = 0xC000 // hope the compiler will optimise it
*p;
but they're all beating around the bush because the language simply
doesn't allow you to express exactly what you mean in a way in a
completely general way.
[0xC000 was the address of the memory-mapped video in the first graphics
board I developed. I can't remember what crude language I used but
perhaps a good way of dealing with that would be:
byte display[16384] @ 0xC000;
rather than pointers.]
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-15 16:19 -0700 |
| Message-ID | <ln60otgpym.fsf@kst-u.example.com> |
| In reply to | #94890 |
BartC <bc@freeuk.com> writes:
> On 15/10/2016 22:33, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> You understand that in RD's example, and disregarding type, there is
>>> an extra level of indirection between the value of 'pointer' and the
>>> value of &buffer?
>>
>> No, I don't understand that. What do you mean by it?
>
> I didn't realise my language was up to it, but it can define true
> constant pointers (to fixed addresses anyway):
>
> const ref byte p = ref byte(0xC000) # NOT C
> byte a
>
> a = p^
>
> This generates this C:
>
> a = *49152;
That's a constraint violation. Is your intent to translate your
language to valid C?
> While a non-constant pointer would result in:
>
> char * p = 49152;
>
> a = *p;
>
> It shows that C can have constant pointers, but like named integer
> literals, it has the same issues with named constant pointers (or
> pointer literals, although such pointers would normally refer to some
> symbol not a hardcoded address).
>
> Of course C can struggle through and there are any number of ways of
> achieving a constant pointer without the indirection:
>
> #define p 0xC000
The value of p is an integer, not a pointer.
> enum {p = 0xC000}; // this might work, if value is in range
Again, that's an integer.
> char * const p = 0xC000 // hope the compiler will optimise it
And a constraint violation.
Perhaps what you're looking for is
char *const p = (const char*)0xC000;
but p still isn't a constant expression.
> *p;
>
> but they're all beating around the bush because the language simply
> doesn't allow you to express exactly what you mean in a way in a
> completely general way.
C does have expressions that are *address constants* (N1570 6.6p9).
It doesn't have a good way of naming them; an identifier (other than
a macro name or an enumerator with the value 0) cannot be an address
constant, even if it's the name of a const object initialized to
an address constant.
[...]
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-16 00:55 +0100 |
| Message-ID | <ntufko$n8c$1@dont-email.me> |
| In reply to | #94891 |
On 16/10/2016 00:19, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 15/10/2016 22:33, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>>> You understand that in RD's example, and disregarding type, there is >>>> an extra level of indirection between the value of 'pointer' and the >>>> value of &buffer? >>> >>> No, I don't understand that. What do you mean by it? >> >> I didn't realise my language was up to it, but it can define true >> constant pointers (to fixed addresses anyway): >> >> const ref byte p = ref byte(0xC000) # NOT C >> byte a >> >> a = p^ >> >> This generates this C: >> >> a = *49152; > > That's a constraint violation. Is your intent to translate your > language to valid C? That's a mistake. I've recently dropped most casts from generated C. That's one that needs to stay in. (Why is it ever so much easier to generate native code than C? All I get from a C compiler is moan, moan, moan, plus having to jump through myriad hoops that don't even exist with native code.) Anyway, your objections are mostly about types; I must have forgotten to mention about disregarding them! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-16 01:11 +0100 |
| Message-ID | <87inst40h0.fsf@bsb.me.uk> |
| In reply to | #94896 |
BartC <bc@freeuk.com> writes: <snip> > (Why is it ever so much easier to generate native code than C? All I > get from a C compiler is moan, moan, moan, plus having to jump through > myriad hoops that don't even exist with native code.) I know this is rhetorical but I fear there may be people who will be taken in by your rhetoric. The answer involves many reasons. Perhaps the most significant is the C was never designed to be the target of a compiler, but many modern instruction sets were. C was designed to help you write correct code by telling you when you've done something odd like dereference a floating point number (what you call moaning). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-16 22:17 +0100 |
| Message-ID | <nu0qoo$g77$1@dont-email.me> |
| In reply to | #94898 |
On 16/10/2016 01:11, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
> <snip>
>> (Why is it ever so much easier to generate native code than C? All I
>> get from a C compiler is moan, moan, moan, plus having to jump through
>> myriad hoops that don't even exist with native code.)
>
> I know this is rhetorical but I fear there may be people who will be
> taken in by your rhetoric. The answer involves many reasons. Perhaps
> the most significant is the C was never designed to be the target of a
> compiler, but many modern instruction sets were. C was designed to help
> you write correct code by telling you when you've done something odd
> like dereference a floating point number (what you call moaning).
Unfortunately there aren't really any portable languages suitable for
compiler targets (I think there was one called C- or C--, now dead, and
there's the ultra-complex llvm which is completely impractical).
C is about the nearest.
But there are loads of problems other than shutting up compilers' errors
and warnings; the language just gets in the way of what you're trying to
do. Here's the most recent problem:
A translator converting a struct might need to know, for its own
purposes, the widths and offsets of all members of the struct. But a C
compiler uses its own algorithms for aligning or padding that the source
translator can guess but can't determine for sure.
To get around this, it might emit '#pragma(1)' so that the C compiler
will place elements at known offsets.
That works. Unless you compile with gcc on ARM where the following source:
#pragma(1)
typedef struct {int tag} S;
S* p;
p -> tag = 1;
which generates code that stores that '1' a byte at a time (with a
massive performance hit). Because it thinks p is misaligned. No amount
of alignment control options appear to shift its stubbornness.
So, now what? Such a problem simply does not occur with a lower level
language; it just does what it's told!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-16 23:11 +0100 |
| Message-ID | <nu0tu9$q83$1@dont-email.me> |
| In reply to | #94937 |
On 16/10/2016 22:17, BartC wrote: > To get around this, it might emit '#pragma(1)' so that the C compiler > will place elements at known offsets. > #pragma(1) Those should be '#pragma pack(1)'s in case anyone is wondering what I'm on about. It eliminates padding bytes inside structs. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-10-16 19:55 -0400 |
| Message-ID | <ErUMz.58038$fI2.34642@fx36.iad> |
| In reply to | #94941 |
On 10/16/16 6:11 PM, BartC wrote: > On 16/10/2016 22:17, BartC wrote: > >> To get around this, it might emit '#pragma(1)' so that the C compiler >> will place elements at known offsets. > >> #pragma(1) > > Those should be '#pragma pack(1)'s in case anyone is wondering what I'm > on about. It eliminates padding bytes inside structs. > I think it also sets the alignment requirements of the structure to 1, which is why you got the slowdown you saw, it didn't optimize enough to see that in THAT situation the int element was properly aligned (It might not even look for that, as it would normally only affect 'toy' programs).
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web