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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2016-10-20 15:09 +0300 |
| Message-ID | <20161020150950.6520f8bcfe1ae290df9e7193@g{oogle}mail.com> |
| In reply to | #95051 |
Richard Heathfield:
>Anton Shepelev:
>>David Brown:
>>
>>>int * const pointer = p->q.r[2].s->buffer;
>>
>>I am often tempted to use such short-cuts, but do
>>they not bewray a design problem, viz. the viola-
>>tion of the Demeter principle?
>
>You'd have to work hard to make it a genuine prob-
>lem. For example, you could do this:
>
>int * const pointer = p->q.r[2].s->buffer;
>foo(p);
>/* is pointer still valid? Maybe, maybe not. */
>
>But if you're just doing something like:
>
>int * const pointer = p->q.r[2].s->buffer;
>int * const endptr = pointer + p->q.r[2].s->len;
>int sum = 0;
>while(pointer < endptr)
>{
> sum += *pointer++;
>}
>return sum;
>
>the temporary coupling doesn't cause any problems.
[did you mean temporal coupling?]
Thank you, Richard, but I fear you misunderstood my
question. I was referring to the Demeter principle,
which prohibits--or discourages--access to the in-
ternals of internals of the data immediately avail-
able in the current scope. For example, the use of
more than one '.' or '->' operator sequentially is a
violation, and the graver a one the longer the se-
quence.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-20 14:29 +0100 |
| Message-ID | <nuagr8$fv2$1@dont-email.me> |
| In reply to | #95090 |
On 20/10/16 13:09, Anton Shepelev wrote:
> Richard Heathfield:
>> Anton Shepelev:
>>> David Brown:
>>>
>>>> int * const pointer = p->q.r[2].s->buffer;
>>>
>>> I am often tempted to use such short-cuts, but do
>>> they not bewray a design problem, viz. the viola-
>>> tion of the Demeter principle?
>>
>> You'd have to work hard to make it a genuine prob-
>> lem. For example, you could do this:
>>
>> int * const pointer = p->q.r[2].s->buffer;
>> foo(p);
>> /* is pointer still valid? Maybe, maybe not. */
>>
>> But if you're just doing something like:
>>
>> int * const pointer = p->q.r[2].s->buffer;
>> int * const endptr = pointer + p->q.r[2].s->len;
>> int sum = 0;
>> while(pointer < endptr)
>> {
>> sum += *pointer++;
>> }
>> return sum;
>>
>> the temporary coupling doesn't cause any problems.
>
> [did you mean temporal coupling?]
No, I meant "temporary" - that is, the relationship between
p->q.r[2].s->buffer and the local pointer is short-lived, and harmless
as long as p->q.r[2].s->buffer doesn't get passed around (and thus
possibly changed) in the interim.
> Thank you, Richard, but I fear you misunderstood my
> question. I was referring to the Demeter principle,
> which prohibits--or discourages--access to the in-
> ternals of internals of the data immediately avail-
> able in the current scope. For example, the use of
> more than one '.' or '->' operator sequentially is a
> violation, and the graver a one the longer the se-
> quence.
But my point was that it is not a significant violation if it is
sufficiently short-lived that the absence of a genuine coupling problem
(as opposed to a merely theoretical one) can be readily confirmed.
--
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 | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-10-23 13:15 +0000 |
| Message-ID | <580cb76c.17194281@news.xs4all.nl> |
| In reply to | #95090 |
Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Thank you, Richard, but I fear you misunderstood my
> question. I was referring to the Demeter principle,
> which prohibits--or discourages--access to the in-
> ternals of internals of the data immediately avail-
> able in the current scope. For example, the use of
> more than one '.' or '->' operator sequentially is a
> violation, and the graver a one the longer the se-
> quence.
That sounds like the kind of principle which starts with the object of
making code more legible, then gets taken as a goal in itself, and ends
up requiring you to jump through hoops and resulting in _less_ legible
code, with superfluous "member-fetch" function calls all over the place
whose body consists of nothing more than "return object->member;".
Richard
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2016-11-06 16:17 +0300 |
| Message-ID | <20161106161709.f2bdabcc4dd0f1a027c68a58@gmail.com> |
| In reply to | #95161 |
Richard Bos to Anton Shepelev: > > Thank you, Richard, but I fear you misunderstood > > my question. I was referring to the Demeter > > principle, which prohibits--or discourages--ac- > > cess to the internals of internals of the data > > immediately avail- able in the current scope. > > For example, the use of more than one '.' or > > '->' operator sequentially is a violation, and > > the graver a one the longer the sequence. > > That sounds like the kind of principle which > starts with the object of making code more legi- > ble, then gets taken as a goal in itself, and ends > up requiring you to jump through hoops and result- > ing in _less_ legible code, with superfluous "mem- > ber-fetch" function calls all over the place whose > body consists of nothing more than "return ob- > ject->member;". No, I am not talking about data hiding or read-only member access. The Demeter principle states that one should talk to one's friends only, and not to friends of friends, even though they be available for the occasional chat. Technically speaking, each layer of abstraction shall interact only with the immediate underlying layer, even though deeper ones be partially exposed too. I believe the principle is orthogonal to data hiding and not limited to OOP. The having to write: int * const pointer = p->q.r[2].s->buffer may indicate that the code using pointer should be removed into a subroutine because otherwise it would shoot through several layers of abstraction as a polystrate petrified tree does though several geo- logical layers. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-07 11:21 -0800 |
| Message-ID | <87b6bf46-b63e-457c-991a-30a4710da046@googlegroups.com> |
| In reply to | #95920 |
On Sunday, November 6, 2016 at 7:17:10 AM UTC-6, Anton Shepelev wrote: > I believe the principle is orthogonal to data hiding > and not limited to OOP. The having to write: > > int * const pointer = p->q.r[2].s->buffer > > may indicate that the code using pointer should be > removed into a subroutine because otherwise it would > shoot through several layers of abstraction as a > polystrate petrified tree does though several geo- > logical layers. I think the issue would be clearer if languages' syntax better distinguished between data items and entities, and between references that encapsulate ownership, references which are held on behalf of the target's owner, and references which are held for one's own benefit. Fundamentally, I think what the PoD is most often warning about are cases in which a function uses another entity to encapsulate its own state, and other entities examine the state through that other entity without really involving the owner of that state. If the entity is being manipulated at the request of its owner, there's no problem; there's also no problem if code makes deep references to a immutable hierarchical data object since such objects don't encapsulate state--instead, such objects *are* state, encapsulated by mutable references to them. The problems arise when an object uses an entity to encapsulate state, and outside accesses to that entity cause the object to lose control of its own state.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-10-18 13:59 +0200 |
| Message-ID | <nu52qj$qed$1@dont-email.me> |
| In reply to | #95050 |
On 18/10/16 13:06, Anton Shepelev wrote: > David Brown: > >> Malcolm is correct that you would not often have a >> /const/ pointer to an array like this. You might >> do it if "pointer" is a shorter or clearer >> name -- so that you have if "buffer" was buried in >> a complex structure you write >> >> int * const pointer = p->q.r[2].s->buffer; >> >> and use "pointer" as a short-cut. > > I am often tempted to use such short-cuts, but do > they not bewray a design problem, viz. the violation > of the Demeter principle? > Short-cuts like this may well be an indication that you have more coupling between parts than you might want. But you could just be bending the rules a bit, rather than breaking them - without more context (and a less contrived example), it's hard to tell. Another situation when you might want this sort of thing is if you are using a compiler with poor optimisation - or a good compiler with optimisation disabled or limited for some reason. Given: int a = p->q.r[2].s->buffer[0]; int b = p->q.r[2].s->buffer[1]; I have worked with compilers that would read p from memory, then do all the offset calculations at run-time, before reading a. Then it would do the whole lot again to read b. But if it had: int * const pointer = p->q.r[2].s->buffer; int a = pointer[0]; int b = pointer[1]; it would only read p and do the calculations once. I am glad I don't have to deal with that particular old compiler these days - such "manual optimisations" are a pain. But it is another possible use for this kind of construct.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-18 14:32 +0100 |
| Message-ID | <nu588m$e2b$1@dont-email.me> |
| In reply to | #95052 |
On 18/10/2016 12:59, David Brown wrote: > On 18/10/16 13:06, Anton Shepelev wrote: >> I am often tempted to use such short-cuts, but do >> they not bewray a design problem, viz. the violation >> of the Demeter principle? > Short-cuts like this may well be an indication that you have more > coupling between parts than you might want. But you could just be > bending the rules a bit, rather than breaking them - without more > context (and a less contrived example), it's hard to tell. > > Another situation when you might want this sort of thing is if you are > using a compiler with poor optimisation - or a good compiler with > optimisation disabled or limited for some reason. > > Given: > > int a = p->q.r[2].s->buffer[0]; > int b = p->q.r[2].s->buffer[1]; > > I have worked with compilers that would read p from memory, then do all > the offset calculations at run-time, before reading a. Then it would do > the whole lot again to read b. But if it had: > > int * const pointer = p->q.r[2].s->buffer; > int a = pointer[0]; > int b = pointer[1]; > > it would only read p and do the calculations once. > > > I am glad I don't have to deal with that particular old compiler these > days - such "manual optimisations" are a pain. But it is another > possible use for this kind of construct. But having to write the long sub-expression twice is also a pain. There is readability to consider too (plus extra risk of typos as well as repetitive strain injury from all that typing). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-12 06:57 +0100 |
| Message-ID | <ntkjc3$t52$2@dont-email.me> |
| In reply to | #94756 |
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. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-12 10:25 +0100 |
| Message-ID | <ntkvhd$23l$1@dont-email.me> |
| In reply to | #94761 |
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. Actually, in an implementation, buff /is/ a constant (not const) pointer, or an 'immediate' address: int buff[1024]; // assume in file scope buff; might generate code like this: buff: resb 4096 # reserve 4096 bytes .... mov R0,buff # immediate load If you did want a constant pointer to a block of 1024 integers (I'll keep away from Malcolm's array/buffer thing), the ASM representation would be no different. What C has that ASM doesn't is being able to superimpose a type system that allows you to do 'sizeof buff', or writing buff[i] without specifying an index scale factor. It's a bit more high level. Enough to say that C has array objects, although it doesn't seem too keen about it: it appears to be happier manipulating pointers. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-12 13:14 +0100 |
| Message-ID | <ntl9do$3bb$1@dont-email.me> |
| In reply to | #94763 |
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. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-12 16:44 +0100 |
| Message-ID | <ntllov$gog$1@dont-email.me> |
| In reply to | #94764 |
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. If it doesn't have to be constant, then the following will do: int* buff = malloc(1024*sizeof(int)); Here you have a pointer to a block of ints, without an array in sight. But it doesn't stop everyone treating a construct as though it /was/ an array. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-12 16:53 +0100 |
| Message-ID | <ntlm8r$iou$1@dont-email.me> |
| In reply to | #94773 |
On 12/10/16 16:44, BartC wrote: > 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. 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"), they will need to define a constant pointer to a "block" of ints. The definition int buff[1024]; will not give them 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-12 18:37 +0100 |
| Message-ID | <ntlsd1$ak2$1@dont-email.me> |
| In reply to | #94775 |
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.
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.
Example: take one module in ASM:
segment .text
global buff
buff:
dd 1000
dd 2000
dd 3000
times 1021 dd 0
This defines a block of 1024 ints, the first three of which have been
initialised, and exports a label representing the start address of the
block.
And take another in C which imports the very same label:
#include <stdio.h>
extern int buff[1024];
int main(void) {
int i;
for (i=0; i<5; ++i)
printf("%d: %d\n",i,buff[i]);
}
Output:
0: 1000
1: 2000
2: 3000
3: 0
4: 0
Uncanny isn't it the way the two concepts seem to match up in just the
way I said.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-12 18:50 +0100 |
| Message-ID | <ntlt3v$d98$1@dont-email.me> |
| In reply to | #94781 |
On 12/10/16 18:37, BartC wrote: > 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. 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"? > 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, I think you may be mixing this group up with an assembly language or machine architecture group. C doesn't divide memory into 'bss' and 'text'. Nor does it require ints to be 4 bytes in size (although it certainly doesn't forbid it). So from a C language point of view there is no particular significance to your 4096. On one compiler, an array of 1024 ints may well take up 4096 bytes. On another, 2048. On another, 8192. On another, a mere 1024 (but what bytes they are!). -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-12 19:41 +0100 |
| Message-ID | <ntm04r$ot0$1@dont-email.me> |
| In reply to | #94783 |
On 12/10/2016 18:50, Richard Heathfield wrote: > On 12/10/16 18:37, BartC wrote: >> 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, > > I think you may be mixing this group up with an assembly language or > machine architecture group. C doesn't divide memory into 'bss' and > 'text'. C is quite low level but sometimes you want to work at a even lower and more transparent level. If you want to do that, and don't want the hassle of using ASM or some so-called high-level-assembly intermediates, then you need to think about how to represent your low-level task in terms of what is possible in C. Then it's not really helpful to put fingers in your ears, say la-la-la and pretend nothing in the world exists except what has been Written in the C standard. Nor is playing dumb and pretending you have no idea what a 'block of memory' might possibly be. > Nor does it require ints to be 4 bytes in size (although it > certainly doesn't forbid it). No but it makes posts a lot shorter if I don't have to keep saying that 'other sizes of int are available'. C running on typical desktop machines tend to have a int size of 4 bytes. And I'm only interesting in running C code for x86/x64/ARM and under Windows/Linux, for which all the compilers I've tried have sizeof(int) as 4. If you see 1024 ints/4096 bytes then a sizeof(int) as 4 is clearly being assumed. Using hard constants in an example makes it more obvious what is being illustrated. > So from a C language point of view there > is no particular significance to your 4096. On one compiler, an array of > 1024 ints may well take up 4096 bytes. On another, 2048. On another, > 8192. On another, a mere 1024 (but what bytes they are!). If you like pedanty, then an array of 1024 ints takes hardly any storage at all - in the compiler. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-12 20:18 +0100 |
| Message-ID | <ntm2ac$tr$1@dont-email.me> |
| In reply to | #94788 |
On 12/10/16 19:41, BartC wrote: > On 12/10/2016 18:50, Richard Heathfield wrote: >> On 12/10/16 18:37, BartC wrote: > >>> 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, >> >> I think you may be mixing this group up with an assembly language or >> machine architecture group. C doesn't divide memory into 'bss' and >> 'text'. > > C is quite low level but sometimes you want to work at a even lower and > more transparent level. That's fine. When you need to get that close to the machine, you just pop over to comp.arch and ask there. -- 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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-12 12:56 -0700 |
| Message-ID | <4f08136e-be79-44d0-bb58-6f4762da67f3@googlegroups.com> |
| In reply to | #94790 |
On Wednesday, October 12, 2016 at 2:19:02 PM UTC-5, Richard Heathfield wrote: > On 12/10/16 19:41, BartC wrote: > > C is quite low level but sometimes you want to work at a even lower and > > more transparent level. > > That's fine. When you need to get that close to the machine, you just > pop over to comp.arch and ask there. As much as some people chafe at the idea of C as "portable assembler", there are many situations in embedded/systems programming where behaviors and requirements are expressed as sequences of memory reads and writes, and the language designed by Dennis Ritchie functions very well at that abstraction level. While the Standard does not require compilers to operate at that abstraction level, it certainly allows it; when C89 was written, many compilers operated at that level 100% of the time or close to it. To suggest that code written at such levels "isn't C" doesn't seem very fair, given that the language was designed to operate much closer to that level than at the level many "modern" compilers operate.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-12 21:04 +0100 |
| Message-ID | <ntm4v3$bu4$1@dont-email.me> |
| In reply to | #94790 |
On 12/10/2016 20:18, Richard Heathfield wrote: > On 12/10/16 19:41, BartC wrote: >> On 12/10/2016 18:50, Richard Heathfield wrote: >>> On 12/10/16 18:37, BartC wrote: >> >>>> 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, >>> >>> I think you may be mixing this group up with an assembly language or >>> machine architecture group. C doesn't divide memory into 'bss' and >>> 'text'. >> >> C is quite low level but sometimes you want to work at a even lower and >> more transparent level. > > That's fine. When you need to get that close to the machine, you just > pop over to comp.arch and ask there. I'm not talking about a hardware level. Only about the usual stuff with bytes, words, blocks, direct and indirect addressing and so on which are near universal. I actually spend a lot of time working at a lower level than C, at a higher level, or just cutting right across it to get it to represent some task that might be defined in a different language. I wouldn't get anywhere if I just had to do everything exactly by the book or was only allowed to consider concepts mentioned in the C standard. Ironically, C likes to do things with blocks and pointers to blocks, that in my language is done properly with arrays and pointers to arrays! (A block is just a contiguous region of memory in case you still have no idea. I'm surprised you've never come across 'a block of memory' being used.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-12 14:18 -0700 |
| Message-ID | <lnh98hl10h.fsf@kst-u.example.com> |
| In reply to | #94793 |
BartC <bc@freeuk.com> writes:
[...]
> (A block is just a contiguous region of memory in case you still have no
> idea. I'm surprised you've never come across 'a block of memory' being
> used.)
That sounds like what C calls an "object". Why not just call it that?
The fact that you used a different word could suggest that you had some
subtle distinction in mind.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-12 15:12 -0700 |
| Message-ID | <8c412423-3c43-41d5-9156-cd4ac4b1ceb2@googlegroups.com> |
| In reply to | #94798 |
On Wednesday, October 12, 2016 at 4:17:53 PM UTC-5, Keith Thompson wrote: > That sounds like what C calls an "object". Why not just call it that? > The fact that you used a different word could suggest that you had some > subtle distinction in mind. In an effort to impose their aliasing rules, the C Standards overload the term "object" to refer not just to the storage, but its logical interpretation. In the days before C89, most compilers regarded storage as storage; writing to a float* would convert a floating-point value to a series of bytes and store those bytes consecutively in memory at the given address. Reading from an int* would read a sequence of consecutive bytes starting at the given address and convert them to an integer. Writing a float* wouldn't create a "float" object anywhere, and when code read an int* the compiler wouldn't care whether the storage represented an "int" object or was simply a sequence of accessible bytes. Overloading the term "object" to describe the means by which the bytes in memory had been set makes it necessary to have some other type-agnostic term to describe the storage itself. Do you have any better suggestion?
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web