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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-17 01:12 +0100 |
| Message-ID | <87zim37rzr.fsf@bsb.me.uk> |
| In reply to | #94937 |
BartC <bc@freeuk.com> writes:
> 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.
The language gets in the way of what *you* want to do. The things *I*
want to do are very different, and if C gets in the way of them at all,
it'll be in very different ways.
> 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.
Yes, C structs are not what you want them to be. C won't change for
your project so complaining is very unlikely to be of any use.
However, all is not lost... you may be translating at the wrong level.
If I needed control over the alignment of data in a translated structure
I would output code a bit like this:
struct S {
char data[14];
#define a_of_S(s) (*(int16_t *)((s).data + 0))
#define b_of_S(s) (*(int64_t *)((s).data + 2))
#define c_of_S(s) (*(int32_t *)((s).data + 10))
};
Of course it will go wrong on some architectures, but presumably you
don't care about the ones where your source language's alignment is not
well supported (if at all).
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-17 01:56 +0100 |
| Message-ID | <nu17k5$je6$1@dont-email.me> |
| In reply to | #94949 |
On 17/10/2016 01:12, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> 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.
>
> The language gets in the way of what *you* want to do. The things *I*
> want to do are very different, and if C gets in the way of them at all,
> it'll be in very different ways.
Implementing another language on top of it with features that don't
exactly match those of C has a special set of problems. (Although C
probably copes better than if I wanted to implement C on top of mine!)
> However, all is not lost... you may be translating at the wrong level.
I tried at a lower level a few years ago. It might be possible to go
lower still (just have byte pointers and byte-arrays (or structs
containing one byte array) and do everything with casts).
But I like the idea of generating high-level and now much more readable
C. If something happens to the original source, I could restore it from
the intermediate C.
> If I needed control over the alignment of data in a translated structure
> I would output code a bit like this:
>
> struct S {
> char data[14];
> #define a_of_S(s) (*(int16_t *)((s).data + 0))
> #define b_of_S(s) (*(int64_t *)((s).data + 2))
> #define c_of_S(s) (*(int32_t *)((s).data + 10))
> };
>
> Of course it will go wrong on some architectures, but presumably you
> don't care about the ones where your source language's alignment is not
> well supported (if at all).
I'll have to study that some more as I don't understand it, although I
suspect it might be doing what I suggested above!
There's no problem with C's structs except I don't know what the offsets
will be. I don't know the full implications of not having the
information in my compiler, other than it would be a lot more work.
But at the minute the structs I manually create follow (from long
practice) natural alignment rules. So just removing the '#pragma
pack(1)' could work (it seemed to do so on the ARM).
[For fields of 2, 8 and 4 bytes, if they had to be in that order, then I
would add my own padding unless those offsets were stipulated. Where it
gets tricky are pointers, which can be either 4 or 8 bytes but you don't
know when you're designing the struct layout.]
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-17 14:27 -0700 |
| Message-ID | <962ef4db-515f-4d6c-8ebb-93f7f41692fc@googlegroups.com> |
| In reply to | #94937 |
On Sunday, October 16, 2016 at 4:17:40 PM UTC-5, Bart wrote: > 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. A translator could use compile-time assertions to confirm that structure elements get placed at the correct offsets. I wouldn't suggest using align(1) unless one needs to use things which aren't aligned properly for the target architecture, in which case a compiler will should be expected to generate the clunky code *which the architecture requires*. A more serious problem is it will be impossible to translate from a language into efficient C code if the language offers semantics which are supported by the target platform but not the C Standard. For example, on the vast majority of platforms, given any data pointer p, the bitwise representations of p and (void*)p will be identical. For languages which are confined to such platforms it can be very useful to have a "pointer to any pointer" type, but there's no clean way to translate code using such things into efficient C. Problems also arise if a function is supposed to store data in a way that can be read by outside code, but the source language doesn't have any concept of structure tags, integer types which have matching sizes and representations but aren't alias-compatible, etc.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-16 04:55 +0100 |
| Message-ID | <ntutnu$fag$1@dont-email.me> |
| In reply to | #94896 |
On 16/10/16 00:55, BartC wrote: <snip> > All I get from a C compiler is moan, moan, moan, Well, we know exactly how you feel, because all we ever get from /you/ is moan, moan, moan. -- 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-16 11:49 +0100 |
| Message-ID | <ntvlug$f95$1@dont-email.me> |
| In reply to | #94902 |
On 16/10/2016 04:55, Richard Heathfield wrote: > On 16/10/16 00:55, BartC wrote: > > <snip> > >> All I get from a C compiler is moan, moan, moan, > > Well, we know exactly how you feel, because all we ever get from /you/ > is moan, moan, moan. People should do more of it. Then perhaps we'd all be using simpler, smaller, faster languages and applications. Or perhaps not: in K&R2 p 122 5.12: /"C is sometimes castigated for the syntax of its declarations...it can be confusing..because declarations cannot be simply read left to right and parentheses are over-used."/ So they acknowledged the problem but did nothing about it (and a million people have had to suffer the consequences). At least, when I complain about hard-to-build applications then I try and make my own as simple to build as I possibly can. I try not to stipulate a compiler (most open sources seem to assume gcc). Nor an OS. I don't rely on obscure compile options. I don't use 'make'. I don't require MSYS to be downloaded, so I don't need bash, sed, m4, or dozen other such utilities. I don't even have dozens of assorted .c and .h files; just one .c file. The programs I've made available as C can literally be as easy to build as Hello, World. And it is possible to use a compiler as small as Tiny C. That hasn't been easy (partly because C compilers do moan a lot and they all have a different set of problems) but at least I've made the effort. (While, most things that I've moaned about with C itself, then you will find that I have solved those issues in my own languages. This is not a case of complaining about something that I don't have a clue about fixing. This is informed moaning!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-15 14:55 -0700 |
| Message-ID | <lninstgtu9.fsf@kst-u.example.com> |
| In reply to | #94874 |
BartC <bc@freeuk.com> writes:
> On 15/10/2016 19:11, Ben Bacarisse wrote:
[...]
>> 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.
I don't know what "extra level of indirection" you're talking about.
Given:
int buffer[1024];
int * const pointer = buffer;
both `&buffer` and `pointer` are expressions of pointer type. They
point to the same memory location, but they're of different types;
`int (*)[1000]` (pointer to array of 1000 ints) and `int*`.
I can't tell what point you're making.
> 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 are of course differences. `5848` is a constant and a constant
expression; `x` is neither, and is an lvalue. But when used in an
expression in a context that doesn't require an lvalue, both yield the
same value of the same type.
> 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.
Yes, we know that. The name of a const-qualified object is not a
constant expression.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-15 12:47 -0700 |
| Message-ID | <ln4m4diec6.fsf@kst-u.example.com> |
| 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.)
`pointer` is a pointer object whose value points to the initial element
of the array object `buffer`. One can *informally* think of it as
pointing to `buffer`, but it's better to be precise, especially in this
kind of discussion.
[...]
> 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.
No, you don't have to express it that way. When used in a context where
array-to-pointer conversion takes place, the expression `buffer` is
equivalent to `&buffer[0]`. If you want to explicitly refer to a
pointer to the initial element of `buffer`, `&buffer[0]` is less
ambiguous than `buffer`.
> 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.
You're allowed to think anything you like, but if you think `pointer`
points to the array object `buffer`, you're incorrect, or at least
imprecise.
--
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 Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-15 11:02 +0100 |
| Message-ID | <ntsuq8$jvu$1@dont-email.me> |
| In reply to | #94863 |
On 15/10/16 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.
Well, it's a const pointer to the first element in the array. If you
want a const pointer to the array, typedef is a good way to go:
typedef int t_buf[1024];
t_buf buffer = {0};
const t_buf *p = &buffer;
p is now quite definitely a const pointer to the array buffer.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-15 12:12 -0700 |
| Message-ID | <lnfunxifzt.fsf@kst-u.example.com> |
| In reply to | #94863 |
Richard Damon <Richard@Damon-Family.org> writes:
> 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.
Warning: Pedantic quibbling follows.
Strictly speaking `pointer` is const (read-only), not constant
(evaluated at compile time).
If you want to access the elements of `buffer`, then defining a
pointer to its element type is the way to go. If you literally
want a pointer to the buffer (assuming that "buffer" means "array
object"), you need a pointer to the array type:
const int (*p)[1000] = &buffer;
but that happens to be less useful.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-10-15 14:56 -0700 |
| Message-ID | <kfnvawt5l95.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #94863 |
Richard Damon <Richard@Damon-Family.org> writes:
> int buffer[1024][
>
> int * const pointer = buffer;
int *const foo = (int[1024]){ 0 };
(My comment is only about pointers and arrays, not "buffers"
or other unrelated notions.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-17 05:27 -0700 |
| Message-ID | <bcb9abf5-9bd8-428a-bd02-b0df4822b96f@googlegroups.com> |
| In reply to | #94863 |
On Saturday, October 15, 2016 at 3:09:38 AM UTC+1, Richard Damon wrote: > On 10/11/16 9:55 PM, Keith Thompson wrote: > > 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. > Yes, but you almost never need to do that. It's not something you are likely to see in any real code. The reason is that the identifier "buffer" is an alias for the identifier "pointer", to all intents and purposes, minus a few quirks which hardly matter and are glitches or infelicities in the C language anyway.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-17 08:41 -0700 |
| Message-ID | <lnmvi3f0ej.fsf@kst-u.example.com> |
| In reply to | #94967 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, October 15, 2016 at 3:09:38 AM UTC+1, Richard Damon wrote:
>> On 10/11/16 9:55 PM, Keith Thompson wrote:
>> 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.
>>
> Yes, but you almost never need to do that. It's not something you are
> likely to see in any real code. The reason is that the identifier
> "buffer" is an alias for the identifier "pointer", to all intents and
> purposes, minus a few quirks which hardly matter and are glitches or
> infelicities in the C language anyway.
No, "buffer" is the name of an array object, and "pointer" is the name
of a pointer object. The behavior of the expressions `sizeof buffer`
and `&buffer` are not "quirks which hardly matter". They are the result
of rules that are fundamental to a correct understanding of how arrays
and pointers work in C.
Please stop this nonsense..
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-17 10:18 -0700 |
| Message-ID | <b3ca3dd3-71ae-4151-a880-460ba7231dae@googlegroups.com> |
| In reply to | #94993 |
On Monday, October 17, 2016 at 4:41:45 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > No, "buffer" is the name of an array object, and "pointer" is the name > of a pointer object. The behavior of the expressions `sizeof buffer` > and `&buffer` are not "quirks which hardly matter". They are the result > of rules that are fundamental to a correct understanding of how arrays > and pointers work in C. > > Please stop this nonsense.. > You insist on seeing the world in crisp logic terms. It's something that a lot of Western engineers have trouble with, Japanese engineers much less. Objects are sometimes crisply nested, e.g. taxonomical groups for biological species, but much more often they have soft membership. There are infinite graduations between puddle, pond, lake and sea. I was surprised to learn that a Reliant Robin, which everyone refers to as a "three- wheeled car" is in fact legally a "motorbike". You can drive one with a bike licence. In fuzzy logic, we give things "set membership" values. Again, you tend to find that Westerners first make the joke "oh, fuzzy logic, I use it all the time", then they constantly confuse set membership with p-values. They've got real trouble with the concept. But fuzzy or soft rules work much better in many real situations than crisp rules. And they are often helpful in understanding how a system really works, though ultimately everything has to be "defuzzified" of course, the computer is ultimately digital after all.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-17 11:34 -0700 |
| Message-ID | <lnbmyig6yw.fsf@kst-u.example.com> |
| In reply to | #95002 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, October 17, 2016 at 4:41:45 PM UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> No, "buffer" is the name of an array object, and "pointer" is the name
>> of a pointer object. The behavior of the expressions `sizeof buffer`
>> and `&buffer` are not "quirks which hardly matter". They are the result
>> of rules that are fundamental to a correct understanding of how arrays
>> and pointers work in C.
>>
>> Please stop this nonsense..
>>
> You insist on seeing the world in crisp logic terms.
Yes, when possible (and only when possible).
> It's something that a lot of Western engineers have trouble with, Japanese
> engineers much less. Objects are sometimes crisply nested, e.g. taxonomical
> groups for biological species, but much more often they have soft membership.
> There are infinite graduations between puddle, pond, lake and sea. I was
> surprised to learn that a Reliant Robin, which everyone refers to as a "three-
> wheeled car" is in fact legally a "motorbike". You can drive one with a bike
> licence.
>
> In fuzzy logic, we give things "set membership" values. Again, you tend to
> find that Westerners first make the joke "oh, fuzzy logic, I use it all the time",
> then they constantly confuse set membership with p-values. They've got
> real trouble with the concept.
>
> But fuzzy or soft rules work much better in many real situations than crisp rules.
> And they are often helpful in understanding how a system really works,
> though ultimately everything has to be "defuzzified" of course, the computer
> is ultimately digital after all.
Blah blah fuzzy logic blah blah. And somehow this demonstrates that
arrays are really pointers?
Nope.
Some things are fuzzy. Whether a three-wheeled vehicle is a "motorbike"
or not depends entirely on how the word "motorbike" is defined.
There is no ambiguity about the question of whether arrays are really
pointers. They're not.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-18 08:05 +1300 |
| Message-ID | <e6kloiFsaonU3@mid.individual.net> |
| In reply to | #94967 |
On 10/18/16 01:27 AM, Malcolm McLean wrote: > On Saturday, October 15, 2016 at 3:09:38 AM UTC+1, Richard Damon wrote: >> On 10/11/16 9:55 PM, Keith Thompson wrote: >> >> 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. >> > Yes, but you almost never need to do that. It's not something you are likely to > see in any real code. It's something you get to see very often in "real code". Traversing a buffer is a far from uncommon activity. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-17 12:39 -0700 |
| Message-ID | <ln7f96g3y4.fsf@kst-u.example.com> |
| In reply to | #95012 |
Ian Collins <ian-news@hotmail.com> writes:
> On 10/18/16 01:27 AM, Malcolm McLean wrote:
>> On Saturday, October 15, 2016 at 3:09:38 AM UTC+1, Richard Damon wrote:
>>> On 10/11/16 9:55 PM, Keith Thompson wrote:
>>>
>>> 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.
>>>
>> Yes, but you almost never need to do that. It's not something you are likely to
>> see in any real code.
>
> It's something you get to see very often in "real code". Traversing a
> buffer is a far from uncommon activity.
`pointer` is a const pointer, not a pointer to a const target.
You can't use it to traverse `buffer`; `pointer++` is a constraint
violation. (You could use `pointer + offset` or `pointer[index]`,
but then you might as well use `buffer` rather than `pointer`.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-10-17 21:17 +0100 |
| Message-ID | <8760oqybkd.fsf@gmail.com> |
| In reply to | #95012 |
Ian Collins <ian-news@hotmail.com> writes: > On 10/18/16 01:27 AM, Malcolm McLean wrote: >> On Saturday, October 15, 2016 at 3:09:38 AM UTC+1, Richard Damon wrote: >>> On 10/11/16 9:55 PM, Keith Thompson wrote: >>> >>> 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. >>> >> Yes, but you almost never need to do that. It's not something you >> are likely to >> see in any real code. > > It's something you get to see very often in "real code". Traversing a > buffer is a far from uncommon activity. It'd be odd to do so with an immutable pointer though. You may as well use buffer directly, if you're not going to use the *ptr++ idiom.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-10-17 22:46 +0200 |
| Message-ID | <nu3dau$df1$1@dont-email.me> |
| In reply to | #95015 |
On 17/10/16 22:17, Gareth Owen wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 10/18/16 01:27 AM, Malcolm McLean wrote: >>> On Saturday, October 15, 2016 at 3:09:38 AM UTC+1, Richard Damon wrote: >>>> On 10/11/16 9:55 PM, Keith Thompson wrote: >>>> >>>> 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. >>>> >>> Yes, but you almost never need to do that. It's not something you >>> are likely to >>> see in any real code. >> >> It's something you get to see very often in "real code". Traversing a >> buffer is a far from uncommon activity. > > It'd be odd to do so with an immutable pointer though. You may as well > use buffer directly, if you're not going to use the *ptr++ idiom. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2016-10-18 14:06 +0300 |
| Message-ID | <20161018140635.81f4fac12937ae3f2433a451@g{oogle}mail.com> |
| In reply to | #95022 |
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? -- () 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-18 12:18 +0100 |
| Message-ID | <nu50cq$i7n$1@dont-email.me> |
| In reply to | #95050 |
On 18/10/16 12: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?
You'd have to work hard to make it a genuine problem. 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.
--
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]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web