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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-07 14:13 -0700 |
| Message-ID | <lnint3q2um.fsf@kst-u.example.com> |
| In reply to | #94571 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, October 7, 2016 at 5:10:15 PM UTC-3, Keith Thompson wrote:
>> Thiago Adams writes:
>> > On Friday, October 7, 2016 at 3:47:54 PM UTC-3, Bart wrote:
>> >
>> >> (On page 122 actually.) That section acknowledges that there are
>> >> problems and goes on to demonstrate what may be an early version of
>> >> Cdecl. That is, a program that converts to and from C declarations. It
>> >> doesn't suggest a way of making it easier for for humans! Not without
>> >> using some artificial aid.
>> >
>> > Yes.. I think strange declarations should be style warnings!
>> >
>> > int i, f(), (*f2)(), *p, a[1];
>> > typedef int i, k;
>> >
>> > I don't use more than one declarator in my code.
>>
>> Not a bad policy.
>>
>> > I never do this:
>> >
>> > int i, k;
>> >
>> > struct X
>> > {
>> > int i, k;
>> > }
>>
>> Why not? i and k probably aren't very good names, but struct member
>> names are in their own namespace; there's no real opportunity to confuse
>> the variable i with the struct member i.
>
> The sample was not about scope..was about multiple declarators.
Oh, I see. So you were contrasting
struct X { int i, k; };
vs.
struct X { int i; int k; };
(lines joined for brevity). Never mind, carry on.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-08 01:15 +0100 |
| Message-ID | <nt9dps$iea$1@dont-email.me> |
| In reply to | #94568 |
On 07/10/2016 20:26, Thiago Adams wrote: > On Friday, October 7, 2016 at 3:47:54 PM UTC-3, Bart wrote: > >> (On page 122 actually.) That section acknowledges that there are >> problems and goes on to demonstrate what may be an early version of >> Cdecl. That is, a program that converts to and from C declarations. It >> doesn't suggest a way of making it easier for for humans! Not without >> using some artificial aid. > > Yes.. I think strange declarations should be style warnings! > > int i, f(), (*f2)(), *p, a[1]; > typedef int i, k; > > I don't use more than one declarator in my code. That's one of those features of C that must have seemed a good idea at the time. I /think/ your example above is declaring: * An int * A function returning int (presumably this is an extern or forward declaration) * A pointer to a function * A pointer to an int * An array of int And all on the same line that starts with 'int', even though 'int' is the primary type of only one of those five declarations. (The 'int' comes to the fore with the others only when you call the function, dereference the pointer, or index the array.) That's clearly unwise, but I can't see the problem with: int i, j, k; where i, j, k are of exactly the same type and which might be grouped together because they have something else in common (all being indices for example). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2016-10-08 10:42 +0100 |
| Message-ID | <ntaf2c$pqq$1@dont-email.me> |
| In reply to | #94577 |
On 08/10/2016 01:15, BartC wrote: > On 07/10/2016 20:26, Thiago Adams wrote: >> On Friday, October 7, 2016 at 3:47:54 PM UTC-3, Bart wrote: >> >>> (On page 122 actually.) That section acknowledges that there are >>> problems and goes on to demonstrate what may be an early version of >>> Cdecl. That is, a program that converts to and from C declarations. It >>> doesn't suggest a way of making it easier for for humans! Not without >>> using some artificial aid. >> >> Yes.. I think strange declarations should be style warnings! >> >> int i, f(), (*f2)(), *p, a[1]; >> typedef int i, k; >> >> I don't use more than one declarator in my code. > > That's one of those features of C that must have seemed a good idea at > the time. > > I /think/ your example above is declaring: > > * An int > * A function returning int (presumably this is an extern or forward > declaration) > * A pointer to a function ... returning an int? > * A pointer to an int > * An array of int An array of one int? > And all on the same line that starts with 'int', even though 'int' is > the primary type of only one of those five declarations. (The 'int' > comes to the fore with the others only when you call the function, > dereference the pointer, or index the array.) > > That's clearly unwise, but I can't see the problem with: > > int i, j, k; > > where i, j, k are of exactly the same type and which might be grouped > together because they have something else in common (all being indices > for example). For my own use (not for C) I came up with a syntax which consistently put the declarations on the left and the identifiers on the right. But it wasn't as compact as C declarations. -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-08 11:36 +0100 |
| Message-ID | <ntai65$ddq$1@dont-email.me> |
| In reply to | #94589 |
On 08/10/2016 10:42, James Harris wrote:
> On 08/10/2016 01:15, BartC wrote:
>> On 07/10/2016 20:26, Thiago Adams wrote:
>>> Yes.. I think strange declarations should be style warnings!
>>>
>>> int i, f(), (*f2)(), *p, a[1];
>>> typedef int i, k;
>>>
>>> I don't use more than one declarator in my code.
>>
>> That's one of those features of C that must have seemed a good idea at
>> the time.
>>
>> I /think/ your example above is declaring:
>>
>> * An int
>> * A function returning int (presumably this is an extern or forward
>> declaration)
>> * A pointer to a function
>
> ... returning an int?
I guess so, because the type on the left is what you get after you use
each name in an expression in the form that is used in the declaration
(that was the big idea behind it). These all yield an int value:
i;
f(); // can also be written (*f)()
(*f2)(); // can also be written f2() (or (**f2()))
*p; // can also be written p[0] or *(p+0)
a[0]; // can also be written a[i] or *(a+i)
So they can be written in myriad different ways anyway. But if written
like this:
i; // yields int type
f; // yields pointer to function
f2; // yields pointer to function
p; // yields pointer to int
a; // yields pointer to int
the resulting type is usually not an int.
>> * A pointer to an int
>> * An array of int
>
> An array of one int?
Yes. The way I'd write these in my language has the primary type (what
goes on the left) corresponding more to the second block above rather
than the first. I think that's more intuitive:
int i
function f:int # (this declares a function not a type)
ref function:int f2
ref int p
[1]int a # ('a' yields array not pointer)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-08 14:25 +0100 |
| Message-ID | <8737k7x9ac.fsf@bsb.me.uk> |
| In reply to | #94592 |
BartC <bc@freeuk.com> writes:
> On 08/10/2016 10:42, James Harris wrote:
>> On 08/10/2016 01:15, BartC wrote:
>>> On 07/10/2016 20:26, Thiago Adams wrote:
>
>>>> Yes.. I think strange declarations should be style warnings!
>>>>
>>>> int i, f(), (*f2)(), *p, a[1];
>>>> typedef int i, k;
>>>>
>>>> I don't use more than one declarator in my code.
>>>
>>> That's one of those features of C that must have seemed a good idea at
>>> the time.
>>>
>>> I /think/ your example above is declaring:
>>>
>>> * An int
>>> * A function returning int (presumably this is an extern or forward
>>> declaration)
>>> * A pointer to a function
>>
>> ... returning an int?
Yes.
> I guess so, because the type on the left is what you get after you use
> each name in an expression in the form that is used in the declaration
> (that was the big idea behind it). These all yield an int value:
>
> i;
> f(); // can also be written (*f)()
Can also be written (&f)(), (**f)(), (&*&f)() and (***&*&f)(). (I hope
at least one of these will add to you sense of wonder at C.).
> (*f2)(); // can also be written f2() (or (**f2()))
Can also be written (*&f)(), (*&*f)() and in many other ways but not all
the ones above.
> *p; // can also be written p[0] or *(p+0)
Or 0[p], *(p+1-1) (but not always as *(p+2-2) though *(p+(2-2)) is
fine). Other possibilities include (-1)[p+1] (but but not 1[p-1]),
(&*p)[0] and (*&p)[0].
> a[0]; // can also be written a[i] or *(a+i)
Can also be... no, I won't go on. You get the idea -- that there are
equivalent expressions is not, of itself, interesting. What's
interesting is that you don't like some (or all) of these.
> So they can be written in myriad different ways anyway. But if written
> like this:
>
> i; // yields int type
> f; // yields pointer to function
> f2; // yields pointer to function
> p; // yields pointer to int
> a; // yields pointer to int
True provided you want to hide what's happening. The primary expression
'f' is a function designator and 'a' is an expression with array type.
> the resulting type is usually not an int.
>
>>> * A pointer to an int
>>> * An array of int
>>
>> An array of one int?
>
> Yes. The way I'd write these in my language
<snip>
> [1]int a # ('a' yields array not pointer)
And in C. The bit you don't like is what happens next, not the meaning
of the primary expression 'a'.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-08 15:05 +0100 |
| Message-ID | <ntauf8$ld2$1@dont-email.me> |
| In reply to | #94596 |
On 08/10/2016 14:25, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 08/10/2016 10:42, James Harris wrote:
>>> On 08/10/2016 01:15, BartC wrote:
>>>> On 07/10/2016 20:26, Thiago Adams wrote:
>>
>>>>> Yes.. I think strange declarations should be style warnings!
>>>>>
>>>>> int i, f(), (*f2)(), *p, a[1];
>>>>> typedef int i, k;
>>>>>
>>>>> I don't use more than one declarator in my code.
>>>>
>>>> That's one of those features of C that must have seemed a good idea at
>>>> the time.
>>>>
>>>> I /think/ your example above is declaring:
>>>>
>>>> * An int
>>>> * A function returning int (presumably this is an extern or forward
>>>> declaration)
>>>> * A pointer to a function
>>>
>>> ... returning an int?
>
> Yes.
>
>> I guess so, because the type on the left is what you get after you use
>> each name in an expression in the form that is used in the declaration
>> (that was the big idea behind it). These all yield an int value:
>>
>> i;
>> f(); // can also be written (*f)()
>
> Can also be written (&f)(), (**f)(), (&*&f)() and (***&*&f)(). (I hope
> at least one of these will add to you sense of wonder at C.).
>
>> (*f2)(); // can also be written f2() (or (**f2()))
>
> Can also be written (*&f)(), (*&*f)() and in many other ways but not all
> the ones above.
>
>> *p; // can also be written p[0] or *(p+0)
>
> Or 0[p], *(p+1-1) (but not always as *(p+2-2) though *(p+(2-2)) is
> fine). Other possibilities include (-1)[p+1] (but but not 1[p-1]),
> (&*p)[0] and (*&p)[0].
>
>> a[0]; // can also be written a[i] or *(a+i)
>
> Can also be... no, I won't go on. You get the idea -- that there are
> equivalent expressions is not, of itself, interesting.
You're missing my point, perhaps deliberately.
C type declarations are the way they are because of the 'declaration
mirrors use' rule. I showed that such names are not always written, as
terms, the way they appear in the declaration. You don't need to drag in
silly examples.
Single level function pointers usually ARE written as fp() rather than
(*fp)().
Pointers to T often ARE written as as T[i] rather than *T.
While T[N] arrays are NEVER actually accessed as T[N] (as that would be
a bounds error).
Then there are all the unadorned names that I also listed (ie. f, f2, p
and a in the above examples) which yield types that are different from
headlining 'int' type that appears on the left.
>> So they can be written in myriad different ways anyway. But if written
>> like this:
>>
>> i; // yields int type
>> f; // yields pointer to function
>> f2; // yields pointer to function
>> p; // yields pointer to int
>> a; // yields pointer to int
>
> True provided you want to hide what's happening. The primary expression
> 'f' is a function designator and 'a' is an expression with array type.
Nonsense.
If I pass 'f2' to a function or assign to something else then I'm
passing or assigning a function pointer, not an int.
If I pass 'a' to a function, or assign it to something else, then I'm
passing or assigning a pointer to int, not an int.
But even the 'function designator' or 'array expression' are not ints,
which is my objection. The C type syntax gives undue prominence to the
wrong end of the type!
>> Yes. The way I'd write these in my language
> <snip>
>> [1]int a # ('a' yields array not pointer)
>
> And in C. The bit you don't like is what happens next, not the meaning
> of the primary expression 'a'.
I don't think so. If I write (in my language):
[N]int a, b
b := a
then the contents of b are copied to a. If I try the same in C:
int a[N], b[N];
b = a;
then I get an error. One or both sides isn't an array. It doesn't really
matter to the user if one of the expressions /might/ possibly have array
type for some transient period just before it gets transformed into
something else, as that's not helpful!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-08 16:29 +0100 |
| Message-ID | <ntb3d5$6nt$1@dont-email.me> |
| In reply to | #94597 |
On 08/10/2016 15:05, BartC wrote:
> On 08/10/2016 14:25, Ben Bacarisse wrote:
>> And in C. The bit you don't like is what happens next, not the meaning
>> of the primary expression 'a'.
>
> I don't think so. If I write (in my language):
>
> [N]int a, b
>
> b := a
>
> then the contents of b are copied to a.
I meant from a to b. I haven't given a perverse meaning to ":="...
That translates to this C:
memcpy(&b, &a, 48);
when N is 12.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-08 17:21 +0100 |
| Message-ID | <87lgxyx14q.fsf@bsb.me.uk> |
| In reply to | #94603 |
BartC <bc@freeuk.com> writes: > On 08/10/2016 15:05, BartC wrote: >> On 08/10/2016 14:25, Ben Bacarisse wrote: > >>> And in C. The bit you don't like is what happens next, not the meaning >>> of the primary expression 'a'. >> >> I don't think so. If I write (in my language): >> >> [N]int a, b >> >> b := a >> >> then the contents of b are copied to a. > > I meant from a to b. I haven't given a perverse meaning to ":="... > > That translates to this C: > > memcpy(&b, &a, 48); > > when N is 12. Or, since a and b clearly name array objects, memcpy(&b, &a, sizeof a); (I say clearly both because of the context which has been lost, but also because of the &s in the call.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-08 16:39 +0100 |
| Message-ID | <87vax2x32a.fsf@bsb.me.uk> |
| In reply to | #94597 |
BartC <bc@freeuk.com> writes:
> On 08/10/2016 14:25, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 08/10/2016 10:42, James Harris wrote:
>>>> On 08/10/2016 01:15, BartC wrote:
>>>>> On 07/10/2016 20:26, Thiago Adams wrote:
>>>
>>>>>> Yes.. I think strange declarations should be style warnings!
>>>>>>
>>>>>> int i, f(), (*f2)(), *p, a[1];
>>>>>> typedef int i, k;
>>>>>>
>>>>>> I don't use more than one declarator in my code.
>>>>>
>>>>> That's one of those features of C that must have seemed a good idea at
>>>>> the time.
>>>>>
>>>>> I /think/ your example above is declaring:
>>>>>
>>>>> * An int
>>>>> * A function returning int (presumably this is an extern or forward
>>>>> declaration)
>>>>> * A pointer to a function
>>>>
>>>> ... returning an int?
>>
>> Yes.
>>
>>> I guess so, because the type on the left is what you get after you use
>>> each name in an expression in the form that is used in the declaration
>>> (that was the big idea behind it). These all yield an int value:
>>>
>>> i;
>>> f(); // can also be written (*f)()
>>
>> Can also be written (&f)(), (**f)(), (&*&f)() and (***&*&f)(). (I hope
>> at least one of these will add to you sense of wonder at C.).
>>
>>> (*f2)(); // can also be written f2() (or (**f2()))
>>
>> Can also be written (*&f)(), (*&*f)() and in many other ways but not all
>> the ones above.
>>
>>> *p; // can also be written p[0] or *(p+0)
>>
>> Or 0[p], *(p+1-1) (but not always as *(p+2-2) though *(p+(2-2)) is
>> fine). Other possibilities include (-1)[p+1] (but but not 1[p-1]),
>> (&*p)[0] and (*&p)[0].
>>
>>> a[0]; // can also be written a[i] or *(a+i)
>>
>> Can also be... no, I won't go on. You get the idea -- that there are
>> equivalent expressions is not, of itself, interesting.
>
> You're missing my point, perhaps deliberately.
No, I think I get you point very well.
> C type declarations are the way they are because of the 'declaration
> mirrors use' rule. I showed that such names are not always written, as
> terms, the way they appear in the declaration. You don't need to drag
> in silly examples.
Quite. By showing even more silly examples I wanted to point out that
you were doing exactly that. What's the point of showing *(p+0) in
relation to that rule? The 'rule' does not say that every equivalent
expression can be worked back into a declaration. If it did, showing
*(p+0) be a nice counter-example, but as it is it is simply an
expression equivalent to the one the rule it talking about: *p.
> Single level function pointers usually ARE written as fp() rather than
> (*fp)().
>
> Pointers to T often ARE written as as T[i] rather than *T.
And they ARE also written according to the supposed 'rule'. If your
point is simply that the 'rule' is not a good or useful one (due to
forms that don't match the declaration being used so very often) then I
would agree, but *(p+0) has nothing to do with that. I gave even
sillier examples to show that these are all "uses" that were always
considered to have nothing to do with the "declaration follows use"
rule.
> While T[N] arrays are NEVER actually accessed as T[N] (as that would
> be a bounds error).
>
> Then there are all the unadorned names that I also listed (ie. f, f2,
> p and a in the above examples) which yield types that are different
> from headlining 'int' type that appears on the left.
>
>>> So they can be written in myriad different ways anyway. But if written
>>> like this:
>>>
>>> i; // yields int type
>>> f; // yields pointer to function
>>> f2; // yields pointer to function
>>> p; // yields pointer to int
>>> a; // yields pointer to int
>>
>> True provided you want to hide what's happening. The primary expression
>> 'f' is a function designator and 'a' is an expression with array type.
>
> Nonsense.
No, it's true, and I'm finding it hard to believe that you don't know it
to be true. The primary expression 'a' is of array type and this is the
only reasonable way to explain to people what '&a' and 'sizeof a' mean.
I've read and reread what you go on to say and I think you are not
addressing what I said but rather making the point that you don't like
the fact that int comes first. As a result, I've removed my comments on
what follows because I think it's saying something I have no beef
with -- your dislike of the syntax.
> If I pass 'f2' to a function or assign to something else then I'm
> passing or assigning a function pointer, not an int.
>
> If I pass 'a' to a function, or assign it to something else, then I'm
> passing or assigning a pointer to int, not an int.
>
> But even the 'function designator' or 'array expression' are not ints,
> which is my objection.
>
> The C type syntax gives undue prominence to the
> wrong end of the type!
Ah, well, you are welcome to dislike the syntax. I would expect nothing
less, but try to reduce the amount of smoke and mirrors when describing
the simple fact that you don't like it.
>>> Yes. The way I'd write these in my language
>> <snip>
>>> [1]int a # ('a' yields array not pointer)
>>
>> And in C. The bit you don't like is what happens next, not the meaning
>> of the primary expression 'a'.
>
> I don't think so. If I write (in my language):
>
> [N]int a, b
>
> b := a
>
> then the contents of b are copied to a. If I try the same in C:
>
> int a[N], b[N];
>
> b = a;
>
> then I get an error. One or both sides isn't an array.
The definition of the language has nothing to say about this construct
except that it's a constraint violation and must be diagnosed. After
that, since it's undefined, anything can happen. Maybe the arrays will
be assigned? C does not care.
To avoid any misunderstanding, I'm talking about your "One or both sides
isn't an array". There is no way to answer that because the construct
is undefined in C and so the rules about what is and it not a expression
of array type and what might or might not be converted no longer apply.
> It doesn't
> really matter to the user if one of the expressions /might/ possibly
> have array type for some transient period just before it gets
> transformed into something else, as that's not helpful!
But it is essential to giving the clearest explanation of what is
already something a lot of people seem to find confusing. The simplest
(and only correct) explanation of what C does is to explain that 'a' is
an expression of array type and that, in all cases except for those we
all know about, it gets converted to a pointer to its first element.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-08 16:58 +0100 |
| Message-ID | <ntb521$cbf$1@dont-email.me> |
| In reply to | #94604 |
On 08/10/2016 16:39, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> The C type syntax gives undue prominence to the >> wrong end of the type! > > Ah, well, you are welcome to dislike the syntax. It's not just me, although I'm probably more vocal about it than anyone else in this group. K&R2 p122 (as briefly referenced earlier on) makes the same point. Their solution was a helper utility (rather than fix language that might have been a better idea, and easier in the 1980s than now). My personal solution was to superimpose a different language. But both are workarounds to something that seems to be generally agreed to be broken. >> It doesn't >> really matter to the user if one of the expressions /might/ possibly >> have array type for some transient period just before it gets >> transformed into something else, as that's not helpful! > > But it is essential to giving the clearest explanation of what is > already something a lot of people seem to find confusing. The simplest > (and only correct) explanation of what C does is to explain that 'a' is > an expression of array type and that, in all cases except for those we > all know about, it gets converted to a pointer to its first element. I don't agree. In C, an array name gets converted to a pointer. Except in a couple of instances that are so different from most terms and general-purpose operators that you usually come across in an expression, that it is probably not worth acknowledging that they are bone fide expression terms at all. The exceptions are &a and sizeof a. But the latter also lets you write sizeof T. Yet T cannot appear in an expression by itself (only as a cast). So they are off the wall enough then you might as well treat these array-value-type instances as something that only relevant as & and sizeof operands. They are not to be considered as general purpose expression terms. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-08 21:15 +0100 |
| Message-ID | <87d1jawqah.fsf@bsb.me.uk> |
| In reply to | #94606 |
BartC <bc@freeuk.com> writes: > On 08/10/2016 16:39, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: <snip> >>> It doesn't >>> really matter to the user if one of the expressions /might/ possibly >>> have array type for some transient period just before it gets >>> transformed into something else, as that's not helpful! >> >> But it is essential to giving the clearest explanation of what is >> already something a lot of people seem to find confusing. The simplest >> (and only correct) explanation of what C does is to explain that 'a' is >> an expression of array type and that, in all cases except for those we >> all know about, it gets converted to a pointer to its first element. > > I don't agree. In C, an array name gets converted to a pointer. Except > in a couple of instances that are so different from most terms and > general-purpose operators that you usually come across in an > expression, that it is probably not worth acknowledging that they are > bone fide expression terms at all. By all means think of it that way to yourself. The trouble is that you say things here that are not correct, and I think that needs pointing out. I've seen lots of attempts to explain parts of C in supposedly simpler terms than those used in the language definition, but don't recall ever seeing a correct one. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-08 11:27 -0700 |
| Message-ID | <f1f4af5c-728f-4ad6-a4c8-6607248f5632@googlegroups.com> |
| In reply to | #94597 |
On Saturday, October 8, 2016 at 9:05:51 AM UTC-5, Bart wrote:
> C type declarations are the way they are because of the 'declaration
> mirrors use' rule.
Unfortunately, declaration no longer follows use once initializers are added
to the mix, since what is assigned to is not the expresison-like thing
containing the variable, but rather the value itself. Consider:
typedef unsigned *puint;
void test1(void *vp)
{
puint *p = vp;
*p = vp;
}
The declaration of p and use of p look very similar, but their behavior is
very different. The declaration looks like it writes to *p, but it doesn't--
it actually writes to "p" itself. The usage, however, does write to *p.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-08 20:09 +0100 |
| Message-ID | <ntbg89$kvu$1@dont-email.me> |
| In reply to | #94611 |
On 08/10/2016 19:27, supercat@casperkitty.com wrote:
> On Saturday, October 8, 2016 at 9:05:51 AM UTC-5, Bart wrote:
>> C type declarations are the way they are because of the 'declaration
>> mirrors use' rule.
>
> Unfortunately, declaration no longer follows use once initializers are added
> to the mix, since what is assigned to is not the expresison-like thing
> containing the variable, but rather the value itself. Consider:
>
> typedef unsigned *puint;
> void test1(void *vp)
> {
> puint *p = vp;
> *p = vp;
> }
>
> The declaration of p and use of p look very similar, but their behavior is
> very different. The declaration looks like it writes to *p, but it doesn't--
> it actually writes to "p" itself. The usage, however, does write to *p.
Thanks, another one for my collection of quirks.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-08 21:16 +0100 |
| Message-ID | <87a8eewq95.fsf@bsb.me.uk> |
| In reply to | #94612 |
BartC <bc@freeuk.com> writes:
> On 08/10/2016 19:27, supercat@casperkitty.com wrote:
>> On Saturday, October 8, 2016 at 9:05:51 AM UTC-5, Bart wrote:
>>> C type declarations are the way they are because of the 'declaration
>>> mirrors use' rule.
>>
>> Unfortunately, declaration no longer follows use once initializers are added
>> to the mix, since what is assigned to is not the expresison-like thing
>> containing the variable, but rather the value itself. Consider:
>>
>> typedef unsigned *puint;
>> void test1(void *vp)
>> {
>> puint *p = vp;
>> *p = vp;
>> }
>>
>> The declaration of p and use of p look very similar, but their behavior is
>> very different. The declaration looks like it writes to *p, but it doesn't--
>> it actually writes to "p" itself. The usage, however, does write to
>> *p.
You (supercat) are ascribing too much to this little phrase; it refers
only the form, and so it *does* apply here: the form of the declaration
(*p) does indeed follow that of the use (*p). (Of course the "use" in
the declaration, by definition, will have the form of the declaration.)
> Thanks, another one for my collection of quirks.
No, it appears to be a misunderstanding. In this case the declaration
does resemble the use.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-08 21:28 +0100 |
| Message-ID | <ntbkt2$5fk$1@dont-email.me> |
| In reply to | #94617 |
On 08/10/2016 21:16, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 08/10/2016 19:27, supercat@casperkitty.com wrote:
>>> On Saturday, October 8, 2016 at 9:05:51 AM UTC-5, Bart wrote:
>>>> C type declarations are the way they are because of the 'declaration
>>>> mirrors use' rule.
>>>
>>> Unfortunately, declaration no longer follows use once initializers are added
>>> to the mix, since what is assigned to is not the expresison-like thing
>>> containing the variable, but rather the value itself. Consider:
>>>
>>> typedef unsigned *puint;
>>> void test1(void *vp)
>>> {
>>> puint *p = vp;
>>> *p = vp;
>>> }
>>>
>>> The declaration of p and use of p look very similar, but their behavior is
>>> very different. The declaration looks like it writes to *p, but it doesn't--
>>> it actually writes to "p" itself. The usage, however, does write to
>>> *p.
>
> You (supercat) are ascribing too much to this little phrase; it refers
> only the form, and so it *does* apply here: the form of the declaration
> (*p) does indeed follow that of the use (*p). (Of course the "use" in
> the declaration, by definition, will have the form of the declaration.)
>
>> Thanks, another one for my collection of quirks.
>
> No, it appears to be a misunderstanding. In this case the declaration
> does resemble the use.
When the use involves dereferencing the pointer. Anyway, too late, it's
already been added to my list.
It you see:
*p = 0;
at the top of a screen, you will think it dereferences p. Then you
scroll the page down one line and see:
T
*p = 0;
and realise there is no dereference (and that it is not a regular
assignment). That is quite a dramatic difference between the two.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-09 01:19 +0100 |
| Message-ID | <87y41yv0fl.fsf@bsb.me.uk> |
| In reply to | #94619 |
BartC <bc@freeuk.com> writes:
> On 08/10/2016 21:16, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 08/10/2016 19:27, supercat@casperkitty.com wrote:
>>>> On Saturday, October 8, 2016 at 9:05:51 AM UTC-5, Bart wrote:
>>>>> C type declarations are the way they are because of the 'declaration
>>>>> mirrors use' rule.
>>>>
>>>> Unfortunately, declaration no longer follows use once initializers are added
>>>> to the mix, since what is assigned to is not the expresison-like thing
>>>> containing the variable, but rather the value itself. Consider:
>>>>
>>>> typedef unsigned *puint;
>>>> void test1(void *vp)
>>>> {
>>>> puint *p = vp;
>>>> *p = vp;
>>>> }
>>>>
>>>> The declaration of p and use of p look very similar, but their behavior is
>>>> very different. The declaration looks like it writes to *p, but it doesn't--
>>>> it actually writes to "p" itself. The usage, however, does write to
>>>> *p.
>>
>> You (supercat) are ascribing too much to this little phrase; it refers
>> only the form, and so it *does* apply here: the form of the declaration
>> (*p) does indeed follow that of the use (*p). (Of course the "use" in
>> the declaration, by definition, will have the form of the declaration.)
>>
>>> Thanks, another one for my collection of quirks.
>>
>> No, it appears to be a misunderstanding. In this case the declaration
>> does resemble the use.
>
> When the use involves dereferencing the pointer. Anyway, too late,
> it's already been added to my list.
Provided you keep it to yourself, you can add anything to your list.
> It you see:
>
> *p = 0;
>
> at the top of a screen, you will think it dereferences p.
Why would you think that? Since we know that the form of a declaration
(technically a declarator) resembles the form of its use, you can't tell
by looking at that part which is which.
> Then you
> scroll the page down one line and see:
>
> T
> *p = 0;
>
> and realise there is no dereference (and that it is not a regular
> assignment). That is quite a dramatic difference between the two.
Yes, a huge difference. Just not the exception you seemed to think it
is. But I suspect you've moved on from "declaration resembles use".
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-09 01:36 +0100 |
| Message-ID | <ntc3d1$k3s$1@dont-email.me> |
| In reply to | #94639 |
On 09/10/2016 01:19, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Then you >> scroll the page down one line and see: >> >> T >> *p = 0; >> >> and realise there is no dereference (and that it is not a regular >> assignment). That is quite a dramatic difference between the two. > > Yes, a huge difference. Just not the exception you seemed to think it > is. But I suspect you've moved on from "declaration resembles use". It's part of it. The 'declaration follows use' idea, a lot of people think is flawed. Why /would/ you want a declaration that can be mistaken for part of an expression, with potentially serious consequences, as happens in my example? Keep them distinct! It was a silly idea really, it has caused a lot of trouble for everyone, makes the language harder, and it's just a shame it's persisted so long. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-10-08 09:32 -0700 |
| Message-ID | <72eec67f-1e75-40df-8b23-48a90d8f3db6@googlegroups.com> |
| In reply to | #94577 |
On Friday, October 7, 2016 at 9:15:16 PM UTC-3, Bart wrote: ... > That's clearly unwise, but I can't see the problem with: > > int i, j, k; > > where i, j, k are of exactly the same type and which might be grouped > together because they have something else in common (all being indices > for example). 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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-10-09 03:44 -0700 |
| Message-ID | <kfnfuo594zr.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #94608 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, October 7, 2016 at 9:15:16 PM UTC-3, Bart wrote:
> ...
>> That's clearly unwise, but I can't see the problem with:
>>
>> int i, j, k;
>>
>> where i, j, k are of exactly the same type and which might be grouped
>> together because they have something else in common (all being indices
>> for example).
>
> 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;
One needn't write only one declarator per declaration to write
only one declarator per line:
int
i = 0,
k = GetSize(something),
j = 1;
In some cases there is a benefit to factoring several related
declarators so the type is written only once rather than it
having to be written -- and more importantly, occur in the
source code -- many times.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-09 12:07 +0100 |
| Message-ID | <ntd8ck$af4$1@dont-email.me> |
| In reply to | #94654 |
On 09/10/2016 11:44, Tim Rentsch wrote: > Thiago Adams <thiago.adams@gmail.com> writes: >> I think this would be very confuse: >> >> int i = 0, k = GetSize(something), j = 1; > > One needn't write only one declarator per declaration to write > only one declarator per line: > > int > i = 0, > k = GetSize(something), > j = 1; I thought that I was stretching plausibility a little when I wrote the following example: > [If] you see: > > *p = 0; > > at the top of a screen, you will think it dereferences p. Then you > scroll the page down one line and see: > > T > *p = 0; > > and realise there is no dereference (and that it is not a regular > assignment). That is quite a dramatic difference between the two. Perhaps I wasn't so much after all! -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web