Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94083 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-09-26 14:31 +0100 |
| Last post | 2016-10-15 13:46 -0700 |
| Articles | 20 on this page of 154 — 22 participants |
Back to article view | Back to comp.lang.c
Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 14:31 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 15:45 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:22 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 16:31 +0200
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:05 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 00:42 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 09:50 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 18:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 12:28 +0100
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 04:36 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 05:31 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 14:00 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 07:48 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:36 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 10:38 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 19:47 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:25 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:26 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 13:10 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 13:22 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 14:13 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 01:15 +0100
Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-10-08 10:42 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 11:36 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 14:25 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 15:05 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:29 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 17:21 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 16:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:58 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:15 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:27 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 20:09 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:16 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 21:28 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 01:19 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 01:36 +0100
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-08 09:32 -0700
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-09 03:44 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:07 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 12:12 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:37 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 13:57 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 14:32 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 20:00 +0100
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-09 13:14 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 22:54 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-15 14:40 -0700
Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 10:37 -0400
Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 07:52 -0700
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 09:10 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 10:48 -0700
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 16:21 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:15 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:12 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:20 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:32 -0700
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 14:45 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:12 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 15:26 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 08:00 -0700
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:49 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 17:30 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 21:12 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:09 +0200
Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 13:32 -0700
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 23:14 +0200
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:47 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:13 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 01:18 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:41 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 02:01 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:41 -0700
Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-09-27 01:41 +0100
Re: Why I use gcc jameskuyper@verizon.net - 2016-09-26 18:15 -0700
Re: Why I use gcc Gareth Owen <gwowen@gmail.com> - 2016-09-27 20:59 +0100
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 21:50 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 06:26 -0700
Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-27 23:23 +0000
Re: Why I use gcc Noob <root@127.0.0.1> - 2016-10-08 00:12 +0200
Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 23:11 -0400
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 10:58 +0100
Re: Why I use gcc jameskuyper@verizon.net - 2016-10-08 07:07 -0700
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 21:44 -0700
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 09:48 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:22 +0100
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 13:52 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 14:47 +0200
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 15:18 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:38 +0100
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:21 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:17 +0200
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:52 -0700
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-09-30 02:00 -0500
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:18 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:46 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 09:11 -0700
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 13:33 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:13 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 15:30 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 08:29 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:11 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 21:43 +0100
Re: Why I use gcc raltbos@xs4all.nl (Richard Bos) - 2016-09-30 17:50 +0000
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:04 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:39 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:49 +0100
Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 11:39 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:56 +0100
Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:15 -0700
Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-28 08:55 +0200
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:11 +0200
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:04 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 11:39 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-10 07:32 -0700
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-10 16:17 +0100
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-10 21:09 -0500
Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-11 04:18 +0100
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 10:56 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:08 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 13:36 +0100
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 06:20 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 14:29 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 09:31 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 19:38 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-11 12:23 -0700
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-11 23:19 +0200
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 23:26 +0100
Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-12 09:01 +0200
Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 08:55 -0700
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-12 10:52 -0700
Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 12:34 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-12 13:18 -0700
Re: Why I use gcc luser droog <luser.droog@gmail.com> - 2016-10-12 13:24 -0700
Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-13 13:31 -0600
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 03:00 -0700
Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-16 04:46 -0600
Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 04:05 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 12:28 -0700
Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-11 13:24 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 21:28 +0100
Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-11 20:43 +0000
Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-11 23:40 -0500
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:40 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:19 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 09:08 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:04 +0100
Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 10:39 -0700
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 11:25 -0700
Re: Why I use gcc Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-10 17:05 -0400
Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 14:46 -0700
Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-15 13:39 +0100
Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-15 13:40 -0700
Re: Why I use gcc already5chosen@yahoo.com - 2016-10-15 13:46 -0700
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-09 12:12 +0100 |
| Message-ID | <87lgxxvkrw.fsf@bsb.me.uk> |
| In reply to | #94608 |
Thiago Adams <thiago.adams@gmail.com> writes: <snip> > In most of cases I initialize together with declaration. > > int i = 0; > int j = 0; > int k = GetSize(something); > > I think this would be very confuse: > > int i = 0, k = GetSize(something), j = 1; > > So the first style works in all places well. I like having multiple declatators, especially when there is a logical connection between the objects, so to get a buffer and two pointers I might write struct some_tag buffer[SIZE], *start = buffer, *end = (&buffer)[1]; and the type appears in only one place. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-09 12:37 +0100 |
| Message-ID | <ntda4n$g2v$1@dont-email.me> |
| In reply to | #94657 |
On 09/10/2016 12:12, Ben Bacarisse wrote: > Thiago Adams <thiago.adams@gmail.com> writes: > <snip> >> In most of cases I initialize together with declaration. >> >> int i = 0; >> int j = 0; >> int k = GetSize(something); >> >> I think this would be very confuse: >> >> int i = 0, k = GetSize(something), j = 1; >> >> So the first style works in all places well. > > I like having multiple declatators, especially when there is a logical > connection between the objects, so to get a buffer and two pointers I > might write > > > struct some_tag buffer[SIZE], *start = buffer, *end = (&buffer)[1]; > > and the type appears in only one place. It took me quite a few seconds to grasp what was happening here. The connection here is between start and end: they have the same type, and point into the same object. The connection with buffer is tangential: struct some_tag buffer[SIZE]; struct some_tag *start = buffer, *end = (&buffer)[1]); However in this case, I think separating them all out is clearer: struct some_tag buffer[SIZE]; struct some_tag *start = buffer; struct some_tag *end = (&buffer)[1]; (It took me additional seconds to understand the (&buffer)[1] bit. Apparently it points to just past the end of the array, and means the same as &buffer[SIZE]. What is harder to understand is how the type, which appears to involve a pointer to the whole struct array, eventually coalesces into a pointer to one element of the array. Doubtless some subtle rendering of C's pointer/array rules. But it means I would probably write those last two lines as: struct some_tag *start = &buffer[0]; struct some_tag *end = &buffer[SIZE]; This way there is symmetry, the equivalance is clearer, and there is less head-scratching.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-09 13:57 +0100 |
| Message-ID | <878ttxvfx9.fsf@bsb.me.uk> |
| In reply to | #94659 |
BartC <bc@freeuk.com> writes: > On 09/10/2016 12:12, Ben Bacarisse wrote: >> Thiago Adams <thiago.adams@gmail.com> writes: >> <snip> >>> In most of cases I initialize together with declaration. >>> >>> int i = 0; >>> int j = 0; >>> int k = GetSize(something); >>> >>> I think this would be very confuse: >>> >>> int i = 0, k = GetSize(something), j = 1; >>> >>> So the first style works in all places well. >> >> I like having multiple declatators, especially when there is a logical >> connection between the objects, so to get a buffer and two pointers I >> might write >> >> >> struct some_tag buffer[SIZE], *start = buffer, *end = (&buffer)[1]; >> >> and the type appears in only one place. > > It took me quite a few seconds to grasp what was happening here. The > connection here is between start and end: they have the same type, and > point into the same object. The connection with buffer is tangential: No, the connection is central to why I'd write like that. The pointer point into (and "just past") buffer. If they did not, I'd probably use separate declarations. > struct some_tag buffer[SIZE]; > struct some_tag *start = buffer, *end = (&buffer)[1]); (syntax error) > However in this case, I think separating them all out is clearer: > > struct some_tag buffer[SIZE]; > struct some_tag *start = buffer; > struct some_tag *end = (&buffer)[1]; > > (It took me additional seconds to understand the (&buffer)[1] > bit. Apparently it points to just past the end of the array, and means > the same as &buffer[SIZE]. > > What is harder to understand is how the type, which appears to involve > a pointer to the whole struct array, eventually coalesces into a > pointer to one element of the array. Yes, you've bought into your own confusion so that is not surprising. If you don't think there are any expressions with array values, you will have some trouble with things like this. > Doubtless some subtle rendering > of C's pointer/array rules. But it means I would probably write those > last two lines as: > > struct some_tag *start = &buffer[0]; > struct some_tag *end = &buffer[SIZE]; > > This way there is symmetry, the equivalance is clearer, and there is > less head-scratching.) Fine, but I prefer not to repeat the size and the type. By the way, what level comprehension do you typically target when writing C and how did you come to decide on that level? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-09 14:32 +0100 |
| Message-ID | <ntdgsq$74f$1@dont-email.me> |
| In reply to | #94661 |
On 09/10/2016 13:57, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> Doubtless some subtle rendering
>> of C's pointer/array rules. But it means I would probably write those
>> last two lines as:
>>
>> struct some_tag *start = &buffer[0];
>> struct some_tag *end = &buffer[SIZE];
>>
>> This way there is symmetry, the equivalance is clearer, and there is
>> less head-scratching.)
>
> Fine, but I prefer not to repeat the size and the type.
Isn't that the purpose of defining a name such as SIZE? Anyway from the
reader's point of view repetition makes it clearer (than a gimmick such
as (&buffer)[1] or using sizeof buffer/sizeof buffer[0], or even
buffer+SIZE)
[In my language, I'd have to write either &buffer[buffer.len], repeating
the name, or &buffer[$], which uses a gimmick. And they only work when
the lower bound is zero. So not satisfactory either.]
Regarding repeating the type, you can use Tim's technique:
struct some_tag *start = &buffer[0],
*end = &buffer[SIZE];
> By the way, what level comprehension do you typically target when
> writing C and how did you come to decide on that level?
Probably lower than an expert such as you. Most aren't as comfortable
with 'horizontally' structured code such as Lisp or Haskell as you are.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-09 20:00 +0100 |
| Message-ID | <87wphhtkjw.fsf@bsb.me.uk> |
| In reply to | #94663 |
BartC <bc@freeuk.com> writes: > On 09/10/2016 13:57, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> Doubtless some subtle rendering >>> of C's pointer/array rules. But it means I would probably write those >>> last two lines as: >>> >>> struct some_tag *start = &buffer[0]; >>> struct some_tag *end = &buffer[SIZE]; >>> >>> This way there is symmetry, the equivalance is clearer, and there is >>> less head-scratching.) >> >> Fine, but I prefer not to repeat the size and the type. > > Isn't that the purpose of defining a name such as SIZE? I still prefer not to repeat it; then I don't have to check that both places use the same name. > Anyway from > the reader's point of view repetition makes it clearer (than a gimmick > such as (&buffer)[1] or using sizeof buffer/sizeof buffer[0], or even > buffer+SIZE) Which reader? This is always the problem I have. How low should one go? In the end, I usually just write for me since I can't see any other reasonable level to pitch at. > [In my language, I'd have to write either &buffer[buffer.len], > repeating the name, or &buffer[$], which uses a gimmick. And they only > work when the lower bound is zero. So not satisfactory either.] > > Regarding repeating the type, you can use Tim's technique: > > struct some_tag *start = &buffer[0], > *end = &buffer[SIZE]; That's what I wrote (except I used a different expression for end). To be clear, I was making no remarks about layout -- add or remove newlines or spaces as your preferred style requires -- my comment was about my preference for multiple declarators in a declaration. >> By the way, what level comprehension do you typically target when >> writing C and how did you come to decide on that level? > > Probably lower than an expert such as you. Most aren't as comfortable > with 'horizontally' structured code such as Lisp or Haskell as you > are. OK, but how does one choose? It's a real question. You, presumably, don't write code you consider to be hard for others to read, so how do you go about deciding? For me, the simplest solution is to write for oneself and hope that comments, good structure and choice of identifies -- along with willingness to look at a reference every now and then -- will get most readers by. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-09 13:14 -0700 |
| Message-ID | <d8d00dbc-8097-4456-b9e2-1fc10a16f56c@googlegroups.com> |
| In reply to | #94675 |
On Sunday, October 9, 2016 at 8:00:12 PM UTC+1, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > > >> By the way, what level comprehension do you typically target when > >> writing C and how did you come to decide on that level? > > > > Probably lower than an expert such as you. Most aren't as comfortable > > with 'horizontally' structured code such as Lisp or Haskell as you > > are. > > OK, but how does one choose? It's a real question. You, presumably, > don't write code you consider to be hard for others to read, so how do > you go about deciding? For me, the simplest solution is to write for > oneself and hope that comments, good structure and choice of identifies > -- along with willingness to look at a reference every now and then -- > will get most readers by. > The question is, where is the real complexity? What are you trying to achieve, and which part expresses the essential, irreducible, difficult step or idea? Now you must communicate that, and it's not necessarily going to be easy. But once you have communicated that, it should be job done. The choice of programming constructs shouldn't place extra difficulties in the path of a reader or maintaining programming trying to follow and understand what you have done.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-09 22:54 +0100 |
| Message-ID | <nteeag$icm$1@dont-email.me> |
| In reply to | #94675 |
On 09/10/2016 20:00, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Probably lower than an expert such as you. Most aren't as comfortable >> with 'horizontally' structured code such as Lisp or Haskell as you >> are. > > OK, but how does one choose? It's a real question. You, presumably, > don't write code you consider to be hard for others to read, so how do > you go about deciding? For me, the simplest solution is to write for > oneself and hope that comments, good structure and choice of identifies > -- along with willingness to look at a reference every now and then -- > will get most readers by. Most coding I've done has had to be processed with my own compilers. Since they've always had omissions, bugs, things I've never got round to adding, or features which I've simply forgotten whether they're in or whether they work, I tend to code conservatively. Using solid, reliable, obvious features. Coding in C is an extra challenge since IMO the syntax can easily obfuscate the code. So perhaps I make an extra effort there. I don't assume everyone knows all operator precedences for example. One thing I can say: if I need to set up a pointer to one past the end of an array, I would never have thought of using your method. If I had thought of it, then I would never have used it. The simplest way might well be 'end = start+SIZE' if we go back to your example. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-10-15 14:40 -0700 |
| Message-ID | <kfnzim55m0s.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #94663 |
BartC <bc@freeuk.com> writes: > On 09/10/2016 13:57, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> > [...] > > Regarding repeating the type, you can use Tim's technique: > > struct some_tag *start = &buffer[0], > *end = &buffer[SIZE]; If you're going to give it a name, you should call it Bart's technique, since after all your earlier remark in this area was posted before mine. I was just expanding on your example. Furthermore I would not write code the way you have written it above. Personally, I don't see a reason to give any name to patterns similar to this one, as the pattern shown here is a fairly obvious one and surely predates any usenet discussion of it (or any other usenet discussion for that matter). By the way, don't make the mistake of thinking that someone pointing something out is the same as liking, using, suggesting, recommending, or advocating whatever it was. My posting elsethread was only an observation.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-10-07 10:37 -0400 |
| Message-ID | <nt8bv7$ran$1@dont-email.me> |
| In reply to | #94551 |
On 10/07/2016 08:31 AM, Thiago Adams wrote: > On Wednesday, September 28, 2016 at 2:39:14 PM UTC-3, Bart wrote: > ... >> >> (However the same syntax doesn't work for __declspec(dllimport), which >> still has to be in the (1) format above. >> >> Now I just have to rewrite my C-type-spec generator to incorporate an >> internal attribute as well as a name, and take heed of these different >> rules. >> >> The code generator doesn't know what C compiler is to be used, but it >> will know whether one of __stdcall or __declspec is needed, and it looks >> like there could be a common syntax subset that is acceptable across all >> compilers.) > > > What is this "my C-type-spec generator" ? What it does? > > By coincidence I was searching for grammar of these calling conventions. > Where they go in the grammar? Similar of type-qualifier? Calling conventions are implementation-specific, and would be documented by the specific implementations that support them. The same is true of the keywords used for describing calling conventions. The C standard only describes what the results of calling a function are - it doesn't impose any requirements or restrictions on how function calls are implemented, so long as they achieve those results. Given that fact, it would not be appropriate for the C standard to define keywords for specifying the calling convention that should be used - any such keywords would carry the incorrect implication that only calling conventions that can be accurately described by one of the available keywords are allowed.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-07 07:52 -0700 |
| Message-ID | <0c163ab5-a74c-4492-92c5-66cbf1f4ce07@googlegroups.com> |
| In reply to | #94553 |
On Friday, October 7, 2016 at 9:37:52 AM UTC-5, James Kuyper wrote: > The C standard only describes what the results of calling a function are > - it doesn't impose any requirements or restrictions on how function > calls are implemented, so long as they achieve those results. Given that > fact, it would not be appropriate for the C standard to define keywords > for specifying the calling convention that should be used - any such > keywords would carry the incorrect implication that only calling > conventions that can be accurately described by one of the available > keywords are allowed. It would be far more useful to have a set of recommendations which makers of C implementations should abide when practical, and for which implementations should document deviations when not practical, than to have a standard which classifies programs into "strictly conforming" and everything else, and which promises that any conforming implementation that fails to run a strictly- conforming program without UB must claim that its exeeded some implementation limit that the implementation need not define. The general failure to recognize things which should be supported when practical is a major shortcoming of the C Standard, since it makes it necessary for code to include kludgery to work around the limitations of rare obsolete platforms upon which it would never need to run.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-10-07 09:10 -0700 |
| Message-ID | <abc3115c-bb62-46ac-b7f0-88fb2b7da6df@googlegroups.com> |
| In reply to | #94555 |
On Friday, October 7, 2016 at 10:53:43 AM UTC-4, supe...@casperkitty.com wrote: > On Friday, October 7, 2016 at 9:37:52 AM UTC-5, James Kuyper wrote: > > The C standard only describes what the results of calling a function are > > - it doesn't impose any requirements or restrictions on how function > > calls are implemented, so long as they achieve those results. Given that > > fact, it would not be appropriate for the C standard to define keywords > > for specifying the calling convention that should be used - any such > > keywords would carry the incorrect implication that only calling > > conventions that can be accurately described by one of the available > > keywords are allowed. > > It would be far more useful to have a set of recommendations which makers of > C implementations should abide when practical, and for which implementations > should document deviations when not practical, That would be a bad idea. It would give the false impression that the standard was recommending those things, something the standard is not intended to do, and which the committee has no desire to do. It mandates things and prohibits things, but (almost) never specifies preferences among the possibilities that are allowed (in standard 683 pages long, there are 20 short recommended practice sections - this is not the norm). Some idiots like you might read those preferences and write code which falsely relies upon those things being mandatory, without bothering to check whether they're supported by the particular implementations they need the code to work on, and then they would come whining to this newsgroup about the failure of their unjustified assumptions. > The general failure to recognize things which should be supported when > practical is ... one of the key strengths of the C standard - since it avoids unnecessarily specifying things, it allows a wide variety of implementation schemes, making it one of the most widely implemented languages on the planet. ... > ... since it makes it > necessary for code to include kludgery to work around the limitations of > rare obsolete platforms upon which it would never need to run. All you have to do to justify omitting such unnecessary code is to document the fact that it doesn't need to run on such platforms.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-07 10:48 -0700 |
| Message-ID | <d8359968-67e6-477b-bd8e-5cc164c5f6e0@googlegroups.com> |
| In reply to | #94558 |
On Friday, October 7, 2016 at 11:10:27 AM UTC-5, james...@verizon.net wrote:
> That would be a bad idea. It would give the false impression that the standard
> was recommending those things, something the standard is not intended to do,
> and which the committee has no desire to do. It mandates things and prohibits
> things, but (almost) never specifies preferences among the possibilities that
> are allowed (in standard 683 pages long, there are 20 short recommended practice
> sections - this is not the norm).
Actually, there is a large "recommended" section--the entire annex
concerning floating-point. While the Standard doesn't "recommend" that
implementations should support the features in that annex when practical,
I think there is a clear implication that they should.
Still, if one looks at most other standards for things there are a lot of
recommendations, generally marked with the words "SHOULD" or "SHOULD NOT"
in all-caps. In many cases, the volume of "SHOULD" and "SHOULD NOT" is
comparable to the volume of "MUST" and "MUST NOT".
The range of platforms, and tasks to be performed upon them, for which it
would be useful to write programs in a language which is substantially
equivalent to the one defined by the Standard is extremely vast. If 25%
of programs would benefit from a feature or behavioral guarantee which could
be cheaply supported on 75% of implementations, but would be impractical on
25%, and if most of the platforms which couldn't support the feature would
not be capable of usefully running the programs that would benefit from it,
then which would be more helpful:
1. A Standard which mandates support for the feature, and is therefore
inapplicable to the 25% of platforms that can't support it.
2. A Standard which says nothing about the feature, and therefore requires
that programmers either be constrained by limitations of platforms that
they are not targeting, or hope that their compiler supports features
that their platform could readily support, but which the Standard says
nothing about.
3. A Standard that recommends that implementations support the feature
when practical, but allows the 25% of platforms that can't support the
feature to be conforming provided they document their lack of support
and define macros programs can use to refuse compilation on them.
No matter what requirements on imposes or does not impose on conforming C
implementations, the set of tasks that will be achievable on all conforming
C implementations will be much smaller than the set of tasks for which one
could require that every C implementation at its option either perform the
task successfully (without UB) or indicate, via implementation-defined means,
an inability/refusal to do so. Giving implementations the latter option
will increase the number of implementations that can conform usefully to
the Standard, the number of tasks that can be performed without any risk of
UB on any conforming implementation, and the usefulness of the Standard as
a whole.
>Some idiots like you might read those
> preferences and write code which falsely relies upon those things being
> mandatory, without bothering to check whether they're supported by the
> particular implementations they need the code to work on, and then they would
> come whining to this newsgroup about the failure of their unjustified
> assumptions.
If the Standard requires that every implementation which does not support a
particular feature must define a macro indicating its lack of support, that
will avoid ambiguity:
- An implementation which fails to support a feature without defining the
indicated macro will be non-conforming; even in cases where it would be
impractical for an implementation to comply with all of the requirements
of the Standard, there wouldn't be any reason for any but the most
resource-constrained compilers to fail to define the appropriate macros.
- A program which relies upon features without testing any of the feature-
not-supported macros will not be selectively-conforming. Except in cases
where source code is subject to severe size restrictions, there wouldn't
be any good reason for it to not test availability of features it uses
(likely as part of a project-wide include file).
If a loose behavioral guarantee would allow an algorithm to be expressed
in a way allowing more efficient implementation than would otherwise be
possible, and if implementations for a platform would have to go out of
their way to behave in a fashion inconsistent with that guarantee, does
it make sense to require programmers to write needlessly inefficient code?
Many programs need heuristic functions that will identify 100% of
interesting candidates while maximizing the rate at which uninteresting
candidates are rejected. If a simple implementation of a function will
have precisely defined behavior for all interesting candidates and the
vast majority of uninteresting ones, and if the platform's "natural"
behavior would in no case do anything worse than yielding false positives,
being able to let the platform's natural behaviors "just happen" may
allow the code to be much more efficient than if the programmer had to
add additional boundary checks.
> > ... since it makes it
> > necessary for code to include kludgery to work around the limitations of
> > rare obsolete platforms upon which it would never need to run.
>
> All you have to do to justify omitting such unnecessary code is to document the fact that it doesn't need to run on such platforms.
The problem is that not that it won't run on such platforms, but it may
get broken by aggressive implementations even on platforms which should
support the desired behavior at near-zero cost. For example, if a function
is required to return 1 when w*x and y*z are both within the range of "int"
and w*x+l1<y*z+l2, 0 when those values are within the range of "int" but
the inequality is false, and return either 0 or 1 in all other cases, code
generation may be most efficient if the compiler has the option to at its
leisure either use a 32x32->32 multiply and sign extension or a 32x32->64
multiply. Modern compilers, however, may infer that x and y will never have
any value that would cause an overflow even though code wouldn't care about
what value the multiply yields in the overflow case.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-10-07 16:21 -0700 |
| Message-ID | <5a9313aa-07e7-4e82-8b72-52d121ac02a3@googlegroups.com> |
| In reply to | #94564 |
On Friday, October 7, 2016 at 1:48:28 PM UTC-4, supe...@casperkitty.com wrote: > On Friday, October 7, 2016 at 11:10:27 AM UTC-5, james...@verizon.net wrote: > > That would be a bad idea. It would give the false impression that the > > standard was recommending those things, something the standard is not > > intended to do, and which the committee has no desire to do. It mandates > > things and prohibits things, but (almost) never specifies preferences > > among the possibilities that are allowed (in standard 683 pages long, > > there are 20 short recommended practice sections - this is not the norm). > > Actually, there is a large "recommended" section--the entire annex > concerning floating-point. While the Standard doesn't "recommend" that > implementations should support the features in that annex when practical, > I think there is a clear implication that they should. That implication exists entirely in your mind; it's not present in the standard itself. An implementation targeted at users who don't have any need for floating point support is free to implement floating point operations so inaccurately as to be useless, while still remaining conforming. The standard is NOT intended to discourage such an implementation. An implementation targeting users who want to use a particular floating point standard that is not IEC 60559 is allowed, even if it's running on a system which has hardware support for IEC 60559 - even though supporting the other standard might require software emulation. If someone's running a ground-based simulator for a space probe using an obscure alternative standard, they might really appreciate a compiler with such a feature, even if it's an inefficient emulation (there's a military standard for 48-bit floating point format that used to be quite common in space probes, including the civilian satellites I deal with, and I've personally had to deal with that format - though only in the context of needing to decode it, not because I needed to simulate 48-bit FP operations). What floating point standard (if any) should be supported is a matter of QoI, outside the intended scope of the C standard, however much you might prefer that it be inside the scope. ... > >Some idiots like you might read those > > preferences and write code which falsely relies upon those things being > > mandatory, without bothering to check whether they're supported by the > > particular implementations they need the code to work on, and then they would > > come whining to this newsgroup about the failure of their unjustified > > assumptions. > > If the Standard requires that every implementation which does not support a > particular feature must define a macro indicating its lack of support, that > will avoid ambiguity: I've no objection to a few such macros, with a limited range of values. However, - most of the contexts in which you've made such a suggestion it would require dozens of macros, some of which have hundreds of possible values, to cover the full range of freedom allowed by the standard. I think that requiring an implementation to document such things is a better way to deal with such things. Restricting the freedom of implementations sufficiently to make a small number of macros with a small number of possible values be sufficient is another way to deal with that issue, one that you would probably approve of - but I do not. It's your suggestion that the standard recommend a particular choice that I'm objecting to here. ... > > > ... since it makes it > > > necessary for code to include kludgery to work around the limitations of > > > rare obsolete platforms upon which it would never need to run. > > > > All you have to do to justify omitting such unnecessary code is to > > document the fact that it doesn't need to run on such platforms. > > The problem is that not that it won't run on such platforms, but it may > get broken by aggressive implementations even on platforms which should > support the desired behavior at near-zero cost. For example, if a function > is required to return 1 when w*x and y*z are both within the range of "int" > and w*x+l1<y*z+l2, 0 when those values are within the range of "int" but > the inequality is false, and return either 0 or 1 in all other cases, code > generation may be most efficient if the compiler has the option to at its > leisure either use a 32x32->32 multiply and sign extension or a 32x32->64 > multiply. Modern compilers, however, may infer that x and y will never have > any value that would cause an overflow even though code wouldn't care about > what value the multiply yields in the overflow case. An platform where the speed of the two operations are sufficiently different to provide an incentive for implementations to perform such an optimization is, effectively, one that actually has the features you've declared obsolete, though not necessarily in as extreme a form as the platforms that originally justified allowing for that option.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-08 11:15 -0700 |
| Message-ID | <d0795715-9ea0-4521-a705-1f81382c50f3@googlegroups.com> |
| In reply to | #94576 |
On Friday, October 7, 2016 at 6:24:00 PM UTC-5, james...@verizon.net wrote:
> On Friday, October 7, 2016 at 1:48:28 PM UTC-4, supercat wrote:
> > Actually, there is a large "recommended" section--the entire annex
> > concerning floating-point. While the Standard doesn't "recommend" that
> > implementations should support the features in that annex when practical,
> > I think there is a clear implication that they should.
>
> That implication exists entirely in your mind; it's not present in the
> standard itself. An implementation targeted at users who don't have any need
> for floating point support is free to implement floating point operations so
> inaccurately as to be useless, while still remaining conforming. The standard
> is NOT intended to discourage such an implementation.
Of course not. That's why I said "when practical".
> An implementation
> targeting users who want to use a particular floating point standard that is
> not IEC 60559 is allowed, even if it's running on a system which has hardware
> support for IEC 60559 - even though supporting the other standard might
> require software emulation.
If an implementation's customers need floating-point semantics which are
incompatible with the features of Annex F, that would make it impractical
to support Annex F while meeting those customers' needs.
> What floating point standard (if any) should be supported is a matter of QoI,
> outside the intended scope of the C standard, however much you might prefer
> that it be inside the scope.
The choice of whether to support Annex F is a QOI issue. Any conforming
implementation that support's Annex F guarantees would be just as conforming
if its predefined macros were changed to deny support for such guarantees.
Since Annex F would often require implementations to do something they might
not otherwise do, is there any reason to expect any implementation to expend
such effort rather than simply defining a macro indicating no support, if
there weren't an implication that support was desirable when practical?
> I've no objection to a few such macros, with a limited range of values.
> However, - most of the contexts in which you've made such a suggestion it
> would require dozens of macros, some of which have hundreds of possible
> values, to cover the full range of freedom allowed by the standard. I think
> that requiring an implementation to document such things is a better way to
> deal with such things. Restricting the freedom of implementations
> sufficiently to make a small number of macros with a small number of possible
> values be sufficient is another way to deal with that issue, one that you
> would probably approve of - but I do not.
The number of different values that should be available for feature-report
macros should depend upon the extent to which one wants to be able to allow
compilers which support a subset of possible guarantees to report those that
they do support, rather than merely declining to promise any.
For example, given "uint16_t foo[283][16],r; uint8_t x,y;", there are
different things the design of a compiler might usefully guarantee about
attempts to evaluate "r=foo[x][y];" in cases where y is greater than 15:
* Some might guarantee that r will receive foo[x+y/16][y % 16].
* Others might guarantee that r will receive some Unspecified Value.
* Others might guarantee that r might receive an quasi-Indeterminate
Value which is guaranteed not to be a trap representation but might
behave non-deterministically.
* Others might not be able to guarantee anything.
If code has an array "uint16_t mask[256];" whose last 240 elements are--
unbeknownst to the compiler--always going to be zero, the expression
"foo[x][y] & mask[y]" will behave predictably for all values of x and y
if a compiler can offer any of the first three guarantees above. It
should not cost a compiler much of anything to offer just the third
guarantee, but it would be sufficient to eliminate a conditional test
from what would otherwise be written: y>=16 ? 0 : foo[x][y]& mask. Since
a conditional test would likely block vectorization, and a compiler would
be unable to omit the test if it is specified in the source, being able
to omit the test in source code could enable a better-than-2x speedup.
If an implementation guaranteed for intN_T and uintN_t type, applying an
explicit cast to any Indeterminate Value would yield an Unspecified Value
(generally a cheap guarantee to support) even the weakest guarantee about
the out-of-bounds array read would suffice to let programmers do anything
they could do given a stronger guarantee, making the stronger guarantees
unnecessary, but given code which was written for compilers that offered
stronger guarantees, being able to request stronger guarantees would be
easier than adjusting code so as to require only the weaker ones.
Given how much compilers and implementations have diverged over the last 25
years, being able to request/offer differing levels of guarantees would
maximize the number of compiler/program combinations that could be used
directly as-is.
> It's your suggestion that the standard recommend a particular choice that I'm
> objecting to here.
The nature of recommendations is that if there would be a good reason for an
implementation to do something else, the implementation would be free to
do that something else. Why do you object to the idea that implementations
should endeavor to behave in popular fashion in cases where there isn't any
good reason to do otherwise?
> > The problem is that not that it won't run on such platforms, but it may
> > get broken by aggressive implementations even on platforms which should
> > support the desired behavior at near-zero cost. For example, if a function
> > is required to return 1 when w*x and y*z are both within the range of "int"
> > and w*x+l1<y*z+l2, 0 when those values are within the range of "int" but
> > the inequality is false, and return either 0 or 1 in all other cases, code
> > generation may be most efficient if the compiler has the option to at its
> > leisure either use a 32x32->32 multiply and sign extension or a 32x32->64
> > multiply. Modern compilers, however, may infer that x and y will never have
> > any value that would cause an overflow even though code wouldn't care about
> > what value the multiply yields in the overflow case.
>
> An platform where the speed of the two operations are sufficiently different
> to provide an incentive for implementations to perform such an optimization
> is, effectively, one that actually has the features you've declared obsolete,
> though not necessarily in as extreme a form as the platforms that originally
> justified allowing for that option.
If neither speed nor error-trapping is important, compilers should just
behave in simple and straightforward fashion like they did in the 1980s
and 1990s. On versions of the 32-bit ARM platform that support zero-cost
conditional skip operations, the cost of optimal code to sum together many
32-bit numbers with overflow checking would be essentially the same as the
cost without such checking, but performing a 64-bit summation would be twice
as slow. On 64-bit platforms, computing a 64-bit sum in a 64-bit register
would likely be just as fast as computing a 32-bit sum without overflow, but
adding overflow checking to each step would impose a major speed penalty.
I'm not sure why you think either kind of platform is obsolete.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-07 17:12 +0100 |
| Message-ID | <nt8hgp$gjg$1@dont-email.me> |
| In reply to | #94553 |
On 07/10/2016 15:37, James Kuyper wrote: > On 10/07/2016 08:31 AM, Thiago Adams wrote: >> On Wednesday, September 28, 2016 at 2:39:14 PM UTC-3, Bart wrote: >> ... >>> >>> (However the same syntax doesn't work for __declspec(dllimport), which >>> still has to be in the (1) format above. >>> >>> Now I just have to rewrite my C-type-spec generator to incorporate an >>> internal attribute as well as a name, and take heed of these different >>> rules. >>> >>> The code generator doesn't know what C compiler is to be used, but it >>> will know whether one of __stdcall or __declspec is needed, and it looks >>> like there could be a common syntax subset that is acceptable across all >>> compilers.) >> >> >> What is this "my C-type-spec generator" ? What it does? >> >> By coincidence I was searching for grammar of these calling conventions. >> Where they go in the grammar? Similar of type-qualifier? > > > Calling conventions are implementation-specific, and would be documented > by the specific implementations that support them. The same is true of > the keywords used for describing calling conventions. > > The C standard only describes what the results of calling a function are > - it doesn't impose any requirements or restrictions on how function > calls are implemented, so long as they achieve those results. It standard doesn't need to do anything other than acknowledge that implementation-defined attributes might exist. Then it can help by stipulating where those attributes can go. It doesn't need to know what they are, what they do, or which keywords are chosen. At the minute, I know that most commonly such an attribute, when applied to a function type, goes immediately to the left of the function name. But if that happens to work with a range of compilers, it seems to be by chance. In the case of a pointer-to-function it goes immediately to the left of the * denoting that pointer. I don't know what happens with pointer to pointer to function; hopefully it will never come up. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-07 12:20 -0700 |
| Message-ID | <lnvax4otjc.fsf@kst-u.example.com> |
| In reply to | #94559 |
BartC <bc@freeuk.com> writes:
[...]
> It standard doesn't need to do anything other than acknowledge that
> implementation-defined attributes might exist.
>
> Then it can help by stipulating where those attributes can go. It
> doesn't need to know what they are, what they do, or which keywords are
> chosen.
[...]
C++ (starting with C++11, I think) defines a syntax for attributes:
[[ attribute_name ]]
There are only a handful of language-defined attributes, but
implementation-defined attributes are permitted (perhaps even
encouraged).
I wouldn't mind seeing C adopt something similar or perhaps identical.
--
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 | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-10-07 12:32 -0700 |
| Message-ID | <c1c065f2-0b0b-4ad4-91ca-1775fee2d39b@googlegroups.com> |
| In reply to | #94566 |
On Friday, October 7, 2016 at 4:19:12 PM UTC-3, Keith Thompson wrote: > BartC writes: > [...] > > It standard doesn't need to do anything other than acknowledge that > > implementation-defined attributes might exist. > > > > Then it can help by stipulating where those attributes can go. It > > doesn't need to know what they are, what they do, or which keywords are > > chosen. > [...] > > C++ (starting with C++11, I think) defines a syntax for attributes: > > [[ attribute_name ]] > > There are only a handful of language-defined attributes, but > implementation-defined attributes are permitted (perhaps even > encouraged). > > I wouldn't mind seeing C adopt something similar or perhaps identical. Yes. http://en.cppreference.com/w/cpp/language/attributes Some of them are just tips for static analyzers [[fallthrough]]
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-26 14:45 +0100 |
| Message-ID | <nsb8po$ogk$1@dont-email.me> |
| In reply to | #94083 |
On 26/09/16 14:31, BartC wrote: > I normally generate my own native code for my projects but often > translate to C source and use gcc -O3 for a bit of extra speed. In comp.lang.c, it hardly matters. > But I sometimes like to generate C anyway so that the project is in a > form that can be compiled by anyone. That's the kind of C we discuss here. > In that case I prefer not to have > to stipulate which C compiler should be used. They don't make it easy > however! Well, just write in ISO C, and you're fine. <lots of non-ISO C stuff snipped> > This means if I distribute a project as C source code, I will need to > recommend gcc to compile it. Or Tiny C. Or just write it in ISO C, and ship it without any recommendation needed. Let them use whatever conforming implementation they like. Just a thought. -- 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-09-26 15:12 +0100 |
| Message-ID | <nsbabq$vc7$1@dont-email.me> |
| In reply to | #94085 |
On 26/09/2016 14:45, Richard Heathfield wrote: > On 26/09/16 14:31, BartC wrote: >> This means if I distribute a project as C source code, I will need to >> recommend gcc to compile it. Or Tiny C. > > Or just write it in ISO C, and ship it without any recommendation > needed. Let them use whatever conforming implementation they like. If the C needs to call Windows (or a C function is a callback function called from Windows), then things like __stdcall and __declspec(dllimport) appear to be necessary. And they also appear to be recognised by all six C compilers I use (including clang when it worked), but they can't seem to agree on the syntax! Usually such code is in OS-specific modules. There are other modules for Linux (which I haven't played with much), and others for a neutral 'OS' which doesn't have such calls at all (to do with dynamic access to .dll/.so files) but that limits what the application can do. My projects are usually language implementations and a distribution for a neutral OS might do for simple tests but for real work a Windows or Linux version is needed (so that, for example, it can load msvcrt.dll or libc.so.7 or whatever to allow C runtime functions to be called by dynamic programs.) But even with the neutral OS version, there are all those strange errors I'm getting which means I can't test a C compiler. If I can't test it, then I can't have it in the list of compilers my project has been built with. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-09-26 15:26 +0100 |
| Message-ID | <nsbb6b$2hm$1@dont-email.me> |
| In reply to | #94086 |
On 26/09/16 15:12, BartC wrote: > On 26/09/2016 14:45, Richard Heathfield wrote: >> On 26/09/16 14:31, BartC wrote: > >>> This means if I distribute a project as C source code, I will need to >>> recommend gcc to compile it. Or Tiny C. >> >> Or just write it in ISO C, and ship it without any recommendation >> needed. Let them use whatever conforming implementation they like. > > If the C needs to call Windows (or a C function is a callback function > called from Windows), then things like __stdcall and > __declspec(dllimport) appear to be necessary. If you have to ship platform-specific code, you're going to hit platform-specific problems that have platform-specific solutions best discussed in platform-specific newsgroups. -- 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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web