Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #381780 > unrolled thread
| Started by | bart <bc@freeuk.com> |
|---|---|
| First post | 2024-02-05 01:09 +0000 |
| Last post | 2024-02-05 23:29 +0000 |
| Articles | 20 on this page of 133 — 16 participants |
Back to article view | Back to comp.lang.c
What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-05 01:09 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 05:58 +0000
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 22:49 -0800
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 07:03 +0000
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 23:51 -0800
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 23:52 -0800
Re: What I've learned in comp.lang.c Jan van den Broek <balglaas@dds.nl> - 2024-02-05 08:36 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-05 18:23 +0200
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-05 18:32 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-05 20:53 +0100
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 20:53 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 09:44 +0100
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-06 01:03 -0800
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-06 13:41 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 13:08 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 23:23 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 08:54 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 08:59 +0000
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 10:47 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 11:04 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:21 +0100
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 14:24 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:30 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 15:36 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 18:05 +0000
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 18:26 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 19:53 +0000
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:38 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 00:29 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:37 +0100
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 22:52 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 01:13 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 02:09 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 03:07 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 14:17 +0000
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 16:02 -0800
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-09 00:48 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 08:53 +0100
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 21:55 -0800
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 13:01 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:37 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:10 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 13:24 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 13:03 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 13:17 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 16:52 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 17:17 +0000
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-09 14:50 -0800
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 12:44 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:49 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 16:13 +0000
Re: What I've learned in comp.lang.c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 08:21 -0800
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:01 +0100
Re: What I've learned in comp.lang.c Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-07 13:21 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 13:42 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 16:17 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:34 +0000
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 16:21 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-08 13:26 +0200
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 10:04 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 14:51 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 15:30 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 15:45 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:44 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 00:33 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 01:30 +0000
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 01:38 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 02:21 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 03:07 +0000
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:45 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:15 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 13:29 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:55 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 09:02 +0100
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-08 16:09 +0000
Re: What I've learned in comp.lang.c Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-08 16:28 +0000
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 17:13 +0000
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 17:53 -0800
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-05 19:02 +0200
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 23:28 +0000
Re: What I've learned in comp.lang.c Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-05 23:40 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-06 01:46 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 09:54 +0100
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 16:03 -0800
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 16:06 -0800
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-06 09:50 +0100
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-06 01:01 -0800
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 23:24 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 08:56 +0100
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-07 12:09 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 15:03 +0100
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 16:25 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 21:49 +0100
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-07 13:04 -0800
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-07 23:37 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-08 08:52 +0100
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-09 15:55 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 15:29 +0100
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-09 16:52 +0200
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 17:22 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 07:18 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-10 17:11 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 21:23 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-11 14:01 +0100
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:41 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 02:18 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-07 09:30 +0100
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 09:04 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 23:24 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 01:46 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 02:50 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 11:08 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-08 13:10 +0200
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 17:48 +0000
Re: What I've learned in comp.lang.c Michael S <already5chosen@yahoo.com> - 2024-02-08 21:30 +0200
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-08 20:39 +0000
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-08 13:39 -0800
Re: What I've learned in comp.lang.c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 14:18 -0800
Re: What I've learned in comp.lang.c gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-08 22:29 +0000
Re: What I've learned in comp.lang.c "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-08 14:43 -0800
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-09 09:12 +0100
Re: What I've learned in comp.lang.c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-04 23:36 -0800
Re: What I've learned in comp.lang.c scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 14:52 +0000
Re: What I've learned in comp.lang.c gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-05 22:58 +0000
Re: What I've learned in comp.lang.c Jim Jackson <jj@franjam.org.uk> - 2024-02-05 18:01 +0000
Re: What I've learned in comp.lang.c Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 08:29 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 01:35 +0000
Re: What I've learned in comp.lang.c Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 02:26 +0000
Re: What I've learned in comp.lang.c bart <bc@freeuk.com> - 2024-02-07 10:47 +0000
Re: What I've learned in comp.lang.c Dan Purgert <dan@djph.net> - 2024-02-05 11:03 +0000
Re: What I've learned in comp.lang.c David Brown <david.brown@hesbynett.no> - 2024-02-05 13:15 +0100
Re: What I've learned in comp.lang.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-05 14:09 +0000
Re: What I've learned in comp.lang.c Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 23:29 +0000
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-07 14:21 +0100 |
| Message-ID | <uq005i$1egld$1@dont-email.me> |
| In reply to | #381960 |
On 07/02/2024 12:04, bart wrote: > On 07/02/2024 10:47, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >>> However there are also strong arguments for function scope. A >>> function is a >>> natural unit. And all the variables used in that unit are listed >>> together >>> and, ideally, commented. So at a glance you can see what is in scope and >>> what is being operated on. [typos fixed] >> >> You should not need an inventory of what's being operated on. Any >> function so complex that I can't tell immediately what declaration >> corresponds to which name needs to be re-written. > > But if you keep functions small, eg. the whole body is visible at the > same time, then there is less need for declarations to clutter up the > code. They can go at the top, so that you can literally can just glance > there. > With a small enough function, the benefits of minimum practical scope (or "define on first use") are reduced, but not removed. The perceived benefits of "declare everything at the start of the function" disappear entirely. >>> And there are only three levels of scope. A >>> varibale is global, or it is file scope, or it is scoped to the >>> function. > >> You are mixing up scope and lifetime. C has no "global scope". A name >> may have external linkage (which is probably what you are referring to), >> but that is not directly connected to its scope. > > Funny, I use the same definitions of scope: > For discussions of C, it's best to use the well-defined C terms for scope and lifetime. Other languages may use different terms.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-07 14:24 +0000 |
| Message-ID | <uq03qr$1f2sh$2@dont-email.me> |
| In reply to | #381969 |
On 07/02/2024 13:21, David Brown wrote: > On 07/02/2024 12:04, bart wrote: >> Funny, I use the same definitions of scope: >> > > For discussions of C, it's best to use the well-defined C terms for > scope and lifetime. Other languages may use different terms. Many of the terms used in the C grammar remind me exactly of the 'twisty little passages' variations from the original text Adventure game. In my program, I choose to use identifiers that make more sense to me, and that match my view of how the language works.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-07 21:30 +0100 |
| Message-ID | <uq0pa1$1j1v4$1@dont-email.me> |
| In reply to | #381977 |
On 07/02/2024 15:24, bart wrote: > On 07/02/2024 13:21, David Brown wrote: >> On 07/02/2024 12:04, bart wrote: > >>> Funny, I use the same definitions of scope: >>> >> >> For discussions of C, it's best to use the well-defined C terms for >> scope and lifetime. Other languages may use different terms. > > Many of the terms used in the C grammar remind me exactly of the 'twisty > little passages' variations from the original text Adventure game. > > In my program, I choose to use identifiers that make more sense to me, > and that match my view of how the language works. > OK, I suppose. But if you want to talk about C with other people, it makes sense to use the same terms they are using, in the same way. I can certainly agree that there are bits of the C standards that are not as clear as I would like. The definitions of scope are not one of those parts.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-07 15:36 +0000 |
| Message-ID | <87h6ikthg4.fsf@bsb.me.uk> |
| In reply to | #381960 |
bart <bc@freeuk.com> writes: > On 07/02/2024 10:47, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >>> However there are also strong arguments for function scope. A function is a >>> natural unit. And all the variables used in that unit are listed together >>> and, ideally, commented. So at a glance you can see what is in scope and >>> what is being operated on. [typos fixed] >> You should not need an inventory of what's being operated on. Any >> function so complex that I can't tell immediately what declaration >> corresponds to which name needs to be re-written. > > But if you keep functions small, eg. the whole body is visible at the same > time, then there is less need for declarations to clutter up the code. They > can go at the top, so that you can literally can just glance there. Declarations don't clutter up the code, just as the code does not clutter up the declarations. That's just your own spin on the matter. They are both important parts of a C program. >>> And there are only three levels of scope. A >>> varibale is global, or it is file scope, or it is scoped to the >>> function. > >> You are mixing up scope and lifetime. C has no "global scope". A name >> may have external linkage (which is probably what you are referring to), >> but that is not directly connected to its scope. > > Funny, I use the same definitions of scope: You can use any definition you like, provided you don't insit that other use your own terms. I was just pointing out that the problems associated with using the wrong terms in a public post. I'll cut the text where you use the wrong terms, because there is nothing to be gained from correcting your usage. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-07 18:05 +0000 |
| Message-ID | <uq0gpd$1hiun$1@dont-email.me> |
| In reply to | #381988 |
On 07/02/2024 15:36, Ben Bacarisse wrote:
> bart <bc@freeuk.com> writes:
>
>> On 07/02/2024 10:47, Ben Bacarisse wrote:
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>>> However there are also strong arguments for function scope. A function is a
>>>> natural unit. And all the variables used in that unit are listed together
>>>> and, ideally, commented. So at a glance you can see what is in scope and
>>>> what is being operated on. [typos fixed]
>>> You should not need an inventory of what's being operated on. Any
>>> function so complex that I can't tell immediately what declaration
>>> corresponds to which name needs to be re-written.
>>
>> But if you keep functions small, eg. the whole body is visible at the same
>> time, then there is less need for declarations to clutter up the code. They
>> can go at the top, so that you can literally can just glance there.
>
> Declarations don't clutter up the code, just as the code does not
> clutter up the declarations. That's just your own spin on the matter.
> They are both important parts of a C program.
That sounds like your opinion against mine. It's nothing to do with
spin, whatever that means.
I would argue however that it you take a clear, cleanly written
language-neutral algorithm, and then introduce type annotations /within/
that code rather than segragated, then it is no longer quite as clear or
as clean looking.
As a related example, suppose you had this function:
void F(int a, double* b) {...}
All the parameters are specified with their names and types at the top.
Now imagine if only the names were given, but the types specified only
at their first usage within the body:
void F(a, b) {...}
Now you no longer have an instant picture of the interface to the
function. The declarations could also be shadowed within the body, so
you can't tell whether a definition for 'a' refers to a parameter
without checking for definitions in an outer scope.
Imagine further than even the parameter names were specified within the
body ...
I /like/ having a summary of both parameters and locals at the top. I
/like/ code looking clean, and as aligned as possible (some decls will
push code to the right). I /like/ knowing that there is only one
instance of a variable /abc/, and it is the one at the top.
So it might be my opinion but also my preference.
>>>> And there are only three levels of scope. A
>>>> varibale is global, or it is file scope, or it is scoped to the
>>>> function.
>>
>>> You are mixing up scope and lifetime. C has no "global scope". A name
>>> may have external linkage (which is probably what you are referring to),
>>> but that is not directly connected to its scope.
>>
>> Funny, I use the same definitions of scope:
>
> You can use any definition you like, provided you don't insit that other
> use your own terms. I was just pointing out that the problems
> associated with using the wrong terms in a public post.
>
> I'll cut the text where you use the wrong terms, because there is
> nothing to be gained from correcting your usage.
That's a shame. I think there is something to be gained by not sticking
slavishly to what the C standard says (which very few people will study)
and using more colloquial terms or ones that more can relate to.
Apparently both 'typedef' and 'static' are forms of 'linkage'. But no
identifiers declared with those will ever be linked to anything!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-07 18:26 +0000 |
| Message-ID | <2XPwN.343243$xHn7.179601@fx14.iad> |
| In reply to | #382002 |
bart <bc@freeuk.com> writes:
>On 07/02/2024 15:36, Ben Bacarisse wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> On 07/02/2024 10:47, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>>> However there are also strong arguments for function scope. A function is a
>>>>> natural unit. And all the variables used in that unit are listed together
>>>>> and, ideally, commented. So at a glance you can see what is in scope and
>>>>> what is being operated on. [typos fixed]
>>>> You should not need an inventory of what's being operated on. Any
>>>> function so complex that I can't tell immediately what declaration
>>>> corresponds to which name needs to be re-written.
>>>
>>> But if you keep functions small, eg. the whole body is visible at the same
>>> time, then there is less need for declarations to clutter up the code. They
>>> can go at the top, so that you can literally can just glance there.
>>
>> Declarations don't clutter up the code, just as the code does not
>> clutter up the declarations. That's just your own spin on the matter.
>> They are both important parts of a C program.
>
>
>That sounds like your opinion against mine. It's nothing to do with
>spin, whatever that means.
>
>I would argue however that it you take a clear, cleanly written
>language-neutral algorithm, and then introduce type annotations /within/
>that code rather than segragated, then it is no longer quite as clear or
>as clean looking.
>
>As a related example, suppose you had this function:
>
> void F(int a, double* b) {...}
>
>All the parameters are specified with their names and types at the top.
>Now imagine if only the names were given,
Now imagine if the moon was made from green cheese. It's just as
likely, and neither are C.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-07 19:53 +0000 |
| Message-ID | <uq0n4g$1imkd$1@dont-email.me> |
| In reply to | #382004 |
On 07/02/2024 18:26, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>> On 07/02/2024 15:36, Ben Bacarisse wrote
>>> Declarations don't clutter up the code, just as the code does not
>>> clutter up the declarations. That's just your own spin on the matter.
>>> They are both important parts of a C program.
>>
>>
>> That sounds like your opinion against mine. It's nothing to do with
>> spin, whatever that means.
>>
>> I would argue however that it you take a clear, cleanly written
>> language-neutral algorithm, and then introduce type annotations /within/
>> that code rather than segragated, then it is no longer quite as clear or
>> as clean looking.
>>
>> As a related example, suppose you had this function:
>>
>> void F(int a, double* b) {...}
>>
>> All the parameters are specified with their names and types at the top.
>> Now imagine if only the names were given,
>
> Now imagine if the moon was made from green cheese. It's just as
> likely, and neither are C.
It's perfectly possible as an extension. Old C had something similar
that was halfway there.
But it was a hypothetical illustration to elicit a response to this
question: would it make harder to easier to understand what the function
is doing?
Because it is related to whether the locals used by a function are
declared all at the top, or buried within the code at random places.
BTW I've just done a quick survey of some codebases; functions tend to
have 3 local variables on average.
Is really worth spreading them out in nested block scopes?
Here is a histogram for tcc.c: the first column is how many locals, and
the second is how many functions with that number:
0 161
1 118
2 73
3 42
4 29
5 15
6 12
7 14
8 11
9 6
10 9
11 6
12 3
13 5
14 3
16 4
17 1
18 2
19 2
20 1
21 2
25 1
27 1
31 1
32 1
33 1
35 1
In one of my own programs, 92% of functions have 6 locals or fewer. (The
figures includes extra temporary locals created as part of the
transpilation to C.)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-07 21:38 +0000 |
| Message-ID | <uq0t7q$1jgqa$6@dont-email.me> |
| In reply to | #382008 |
On Wed, 7 Feb 2024 19:53:53 +0000, bart wrote: > BTW I've just done a quick survey of some codebases; functions tend to > have 3 local variables on average. > > Is really worth spreading them out in nested block scopes? If you write “average” functions, you know what the answer is. Some of us don’t write “average” functions.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-08 00:29 +0000 |
| Message-ID | <uq178e$1l7dv$1@dont-email.me> |
| In reply to | #382032 |
On 07/02/2024 21:38, Lawrence D'Oliveiro wrote: > On Wed, 7 Feb 2024 19:53:53 +0000, bart wrote: > >> BTW I've just done a quick survey of some codebases; functions tend to >> have 3 local variables on average. >> >> Is really worth spreading them out in nested block scopes? > > If you write “average” functions, you know what the answer is. > > Some of us don’t write “average” functions. Most functions are short and trivial. But those functions tend to be easy to understnad and unlikely to have bugs. What matters is how you write the longer functions. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-07 21:37 +0100 |
| Message-ID | <uq0pmc$1j1v4$2@dont-email.me> |
| In reply to | #382002 |
On 07/02/2024 19:05, bart wrote: > That's a shame. I think there is something to be gained by not sticking > slavishly to what the C standard says (which very few people will study) > and using more colloquial terms or ones that more can relate to. There is something to be said for explaining the technical terms from the C standards in more colloquial language to make it easier for others to understand. There is nothing at all to be said for using C standard terms in clearly and obviously incorrect ways. That's just going to confuse these non-standard-reading C programmers when they try to find out more, no matter where they look for additional information. > > Apparently both 'typedef' and 'static' are forms of 'linkage'. But no > identifiers declared with those will ever be linked to anything! Could you point to the paragraph of the C standards that justifies that claim? Or are you perhaps mixing things up? (I can tell you the correct answer, with references, if you are stuck - but I'd like to give you the chance to show off your extensive C knowledge first.)
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-07 22:52 +0000 |
| Message-ID | <uq11j7$1kemh$1@dont-email.me> |
| In reply to | #382016 |
On 07/02/2024 20:37, David Brown wrote:
> On 07/02/2024 19:05, bart wrote:
>
>> That's a shame. I think there is something to be gained by not
>> sticking slavishly to what the C standard says (which very few people
>> will study) and using more colloquial terms or ones that more can
>> relate to.
>
> There is something to be said for explaining the technical terms from
> the C standards in more colloquial language to make it easier for others
> to understand. There is nothing at all to be said for using C standard
> terms in clearly and obviously incorrect ways. That's just going to
> confuse these non-standard-reading C programmers when they try to find
> out more, no matter where they look for additional information.
>
>>
>> Apparently both 'typedef' and 'static' are forms of 'linkage'. But no
>> identifiers declared with those will ever be linked to anything!
>
> Could you point to the paragraph of the C standards that justifies that
> claim? Or are you perhaps mixing things up? (I can tell you the
> correct answer, with references, if you are stuck - but I'd like to give
> you the chance to show off your extensive C knowledge first.)
* The standard talks a lot about Linkage but there are no specific
lexical elements for those.
* Instead the standard uses lexical elements called 'storage-class
specifiers' to control what kind of linkage is applied to identifiers
* Because of this association, I use 'linkage symbol' to refer to those
particular tokens
* The tokens include 'typedef extern static'
6.2.2p3 says: "If the declaration of a file scope identifier for an
object or a function contains the storageclass specifier static, the
identifier has internal linkage."
So it talks about statics as having linkage of some kind. What did I
say? I said statics will never be linked to anything.
6.6.2p6 excludes typedefs (by omission). Or rather it says they have 'no
linkage', which is one of the three kinds of linkage (external,
internal, none).
So as far as I can see, statics and typedef are still lumped in to the
class of entities that have a form of linkage, and are part of the set
of tokens that control linkage.
---------------------------------------------------
This is to me is all a bit mixed up. Much as you dislike other languages
being brought in, they can give an enlightening perspective.
So for me, linking applies to all named entities that occupy memory, and
that have global/export scope.
But global/export scope applies also to all other named entities,
whether they occupy memory or not. I can show that here in in this chart:
M Scope? M Link? C Linkage?
Function names Y Y Y (internal/external)
Variable names Y Y Y (internal/external)
Enum names Y N ??
Named constants Y N --
Type names Y N Y (none)
Macro names Y N ??
Module names Y N --
(Type names include C's struct tags. Enum tags are not listed.)
In the M language, ALL user identifiers declared at file scope can be
imported and exported automatically by the language across modules.
This is the primary control method for visibility.
There is a special mechanism to import into a program/library, or export
from one. This is the only place linkage comes up, where those names
need to appear in EXE, DLL and OBJ file formats. Only functions and
variables (entities that have an address) are involved.
In the C column, ?? are identifiers that usually can't apppear in a
declaration with a storage class. And -- is for things not meaningful in C.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-08 01:13 +0000 |
| Message-ID | <20240207164047.820@kylheku.com> |
| In reply to | #382037 |
On 2024-02-07, bart <bc@freeuk.com> wrote:
> * The standard talks a lot about Linkage but there are no specific
> lexical elements for those.
Yes; linkage doesn't have a dedicated phrase element in the syntax.
> * Instead the standard uses lexical elements called 'storage-class
> specifiers' to control what kind of linkage is applied to identifiers
Yes. "storage-class specifier" is just a syntactic category, a "part of
speech" of C.
Not everything that is syntactically a "storage class specifier"
determines the kind of storage for an object.
It's not really a great situation and it has gotten worse with the
introduction of new storage class keywords for alignment and whatnot.
> * Because of this association, I use 'linkage symbol' to refer to those
> particular tokens
Your one term for everything is equally flawed and just gratuitously
different.
> * The tokens include 'typedef extern static'
> 6.2.2p3 says: "If the declaration of a file scope identifier for an
> object or a function contains the storageclass specifier static, the
> identifier has internal linkage."
Yes. If it's a function it has no storage class. If it's an object
at file scope, its storage duration is static. The concept of storage
class doesn't apply to anything at file scope, in other words.
The syntax is instead abused for determining linkage.
> So it talks about statics as having linkage of some kind. What did I
> say? I said statics will never be linked to anything.
file scope statics have internal linkage for the reason that they
are allowed to be multiply defined. You're thining of linkage as some
object-file-level resolution mechanism.
In C, linkage just refers to the situation when multiple declarations of
an identifier are permitted, and refer to a single entity according
to some rule.
At file scope "static int x;" has linkage because you can
have a situation like this:
things liek this:
static int x; // declaration / tentative definition
void foo(void)
{
int x;
{
extern int x; // links to the file scope static
}
}
static int x; // declaration / tentative definition
static int x = 42; // definition
The linkage is internal because all these occurrences of x do not
refer to a file scope x in another translation unit.
This internal linkage is not necessarily handled by a linker. Since it
happens in one translation unit, the compiler can take care of it so
that the resulting object file has resolved all the internal linkage;
then the linkage of multiple translation units into a single program
only deals with external linkage. That can make external linkage appear
more "real".
> 6.6.2p6 excludes typedefs (by omission). Or rather it says they have 'no
> linkage', which is one of the three kinds of linkage (external,
> internal, none).
>
> So as far as I can see, statics and typedef are still lumped in to the
> class of entities that have a form of linkage, and are part of the set
> of tokens that control linkage.
No; typedef is just the "part of C speech" called "storage class
specifier". When a declaration has "typedef" storage class, it's
understood as defining a typedef name in that scope: file scope
or lexical.
The phrase element called "storage class" serves as a general "command
verb" kind of thing in the declaration (which may be omitted).
It should be renamed accordingly. Maybe "declaration kind" or
"declaration category" or "declaration class" or what have you.
Mainly, get rid of the word "storage".
Good names for entities are important. Sometimes the systems we use
don't get them right.
The naming of "storage class" is less important than the multiple
meanings of static and whatnot. Unlike grammar terminology, that can't
be fixed without breaking programs.
> This is to me is all a bit mixed up. Much as you dislike other languages
> being brought in, they can give an enlightening perspective.
Right, nobody here knows anything outside of C, or can think outside of
the C box, except for you.
You're the newsgroup's Prometheus.
The vultures eat your liver daily and everything.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-08 02:09 +0000 |
| Message-ID | <uq1d3t$1m1tc$1@dont-email.me> |
| In reply to | #382057 |
On 08/02/2024 01:13, Kaz Kylheku wrote: > On 2024-02-07, bart <bc@freeuk.com> wrote: >> This is to me is all a bit mixed up. Much as you dislike other languages >> being brought in, they can give an enlightening perspective. > > Right, nobody here knows anything outside of C, or can think outside of > the C box, except for you. Well, quite. AFAIK, nobody here HAS (1) used a comparable language to C; (2) over such a long term; (3) which they have invented themselves; (4) have implemented themselves; (5) is similar enough to C yet different enough in how it works to give that perspective. See, I gave an interesting comparison of how my module scheme works orthogonally across all kinds of entities, compared with the confusing mess of C, and you shut down that view. You're never in a million years going to admit that my language has some good points are you? Exactly as I said in my OP. So what's the rule here, that people can only think INSIDE the C box? Is the point of this group only to show off your master knowledge of C, or the ins and outs of 300 kinds of Linux systems?
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-08 03:07 +0000 |
| Message-ID | <20240207185645.15@kylheku.com> |
| In reply to | #382065 |
On 2024-02-08, bart <bc@freeuk.com> wrote: > On 08/02/2024 01:13, Kaz Kylheku wrote: >> On 2024-02-07, bart <bc@freeuk.com> wrote: > >>> This is to me is all a bit mixed up. Much as you dislike other languages >>> being brought in, they can give an enlightening perspective. >> >> Right, nobody here knows anything outside of C, or can think outside of >> the C box, except for you. > > Well, quite. AFAIK, nobody here HAS (1) used a comparable language to C; > (2) over such a long term; (3) which they have invented themselves; (4) > have implemented themselves; (5) is similar enough to C yet different > enough in how it works to give that perspective. You've taken a perspective is not transferrable to others. If one can only see something after using your own invention for many years, and other people don't have that same invention and implementation experience, then they just cannot see what you see. You cannot teach (2) through (4), just like a basketball coach cannot teach a player to be seven foot tall. > See, I gave an interesting comparison of how my module scheme works > orthogonally across all kinds of entities, compared with the confusing > mess of C, and you shut down that view. > > You're never in a million years going to admit that my language has some > good points are you? Exactly as I said in my OP. I have no idea what it is; I've not seen the reference manual / spec, and even if I did, I wouldn't have implemented it myself and used it for a long time, so I don't have the right perspective. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-08 14:17 +0000 |
| Message-ID | <uq2np1$20cdn$1@dont-email.me> |
| In reply to | #382069 |
On 08/02/2024 03:07, Kaz Kylheku wrote: > On 2024-02-08, bart <bc@freeuk.com> wrote: >> On 08/02/2024 01:13, Kaz Kylheku wrote: >>> On 2024-02-07, bart <bc@freeuk.com> wrote: >> >>>> This is to me is all a bit mixed up. Much as you dislike other languages >>>> being brought in, they can give an enlightening perspective. >>> >>> Right, nobody here knows anything outside of C, or can think outside of >>> the C box, except for you. >> >> Well, quite. AFAIK, nobody here HAS (1) used a comparable language to C; >> (2) over such a long term; (3) which they have invented themselves; (4) >> have implemented themselves; (5) is similar enough to C yet different >> enough in how it works to give that perspective. > > You've taken a perspective is not transferrable to others. > > If one can only see something after using your own invention for many > years, and other people don't have that same invention and > implementation experience, then they just cannot see what you see. > > You cannot teach (2) through (4), just like a basketball coach cannot > teach a player to be seven foot tall. > >> See, I gave an interesting comparison of how my module scheme works >> orthogonally across all kinds of entities, compared with the confusing >> mess of C, and you shut down that view. >> >> You're never in a million years going to admit that my language has some >> good points are you? Exactly as I said in my OP. > > I have no idea what it is; You can't understand the concept of having local/exported/imported attributes apply to any kind of top-level identifier? C is just an incredible mess when it comes to this. If you can at least see how it ought to be done, it can be easier to see how to apply that to C. For example (here I'm using English pseudo-code if you can't stomach my using examples from a real, working, tested language): Local int A static int A; Import int B [extern] int B; // do not initialise Export int C [extern] int C; // can initialise Local typedef int D typedef int D; Import typedef int E typedef int E; // in shared header, or duplicate Export typedef int F typedef int F; // in shared header Local #define G #define G It's poor. 'extern' is generally optional. There is weak separation between imported and exported names. It's often not clear which module, if any, 'owns' a entity that uses resources such as code or data memory. Often any entity that is imported or exported has two declarations: one inside the module (if it's a defined function, or initialised variable), and a declaration-only in a shared header. A typedef like E may be shared across 3 modules (by arranging for them all to see the same definition), but you can also have a different typedef 'E' shared across 4 other modules. If a module includes a header that defines typedef E, it can't shadow that at file-scope with a different E, only inside a function (which will allow one million different E's). If a module wants to use headers from all those 7 headers mentioned, than that E will clash. C allows you to have multiple declarations of many of these entities visible in the same module. You can mix up static and extern versions provided they're in a certain order. Did I say it was an incredible mess? Anyway, very little of this is actually to do with 'linking'; that is more to do with implementation. See, you can take a idealised model of how this stuff ought to work, and from that see how to emulate the needs in C. And also see where C has weak points, of which there are many.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-08 16:02 -0800 |
| Message-ID | <867cje7ber.fsf@linuxsc.com> |
| In reply to | #382065 |
bart <bc@freeuk.com> writes: > You're never in a million years going to admit that my language > has some good points are you? Where can I get a user manual for it?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-09 00:48 +0000 |
| Message-ID | <uq3so5$28lqh$1@dont-email.me> |
| In reply to | #382145 |
On 09/02/2024 00:02, Tim Rentsch wrote: > bart <bc@freeuk.com> writes: > >> You're never in a million years going to admit that my language >> has some good points are you? > > Where can I get a user manual for it? Why? I haven't read a language manual since the 1980s. I can still appreciate interesting ideas another language might have, or even just ideas in isolation. This is just churlishness.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-09 08:53 +0100 |
| Message-ID | <uq4ll3$2hive$1@dont-email.me> |
| In reply to | #382147 |
On 09/02/2024 01:48, bart wrote: > On 09/02/2024 00:02, Tim Rentsch wrote: >> bart <bc@freeuk.com> writes: >> >>> You're never in a million years going to admit that my language >>> has some good points are you? >> >> Where can I get a user manual for it? > > Why? I haven't read a language manual since the 1980s. > It's perhaps uncommon to read entire language manuals, but it is extremely common to read parts, and use other parts for reference. I have read large parts of the C standards from C99 to C23. More relevantly here is the tools manuals - I have read much of the gcc manual (and the manuals for ld, as, and make), and re-read parts that change for new versions. For all the C compilers I have used in my professional work, I have read at least the parts covering compatibility, flags, options, C standard versions, and extensions. I expect I read more manuals than most developers, but it would be inconceivable for me to use a language tool seriously if it did not have a manual that I could at least refer to as needed. > I can still appreciate interesting ideas another language might have, or > even just ideas in isolation. Sure. > > This is just churlishness. > I can't speak for Tim's motives, but for my own part, the lack of good documentation and specifications would rule out a language or compiler for my use on anything beyond play and experimentation.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-10 21:55 -0800 |
| Message-ID | <86o7cn4kai.fsf@linuxsc.com> |
| In reply to | #382147 |
bart <bc@freeuk.com> writes: > On 09/02/2024 00:02, Tim Rentsch wrote: > >> bart <bc@freeuk.com> writes: >> >>> You're never in a million years going to admit that my language >>> has some good points are you? >> >> Where can I get a user manual for it? > > Why? Because having at least some kind of user manual is a sine qua non of any programming language that is meant to be taken seriously. Any language that doesn't is nothing more than a toy or pet project. Furthermore, you may expect that no one will shower your language with praise if all they ever hear is you bragging about it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-08 13:01 +0100 |
| Message-ID | <uq2fqt$1uvma$1@dont-email.me> |
| In reply to | #382037 |
On 07/02/2024 23:52, bart wrote: > On 07/02/2024 20:37, David Brown wrote: >> On 07/02/2024 19:05, bart wrote: >> >>> That's a shame. I think there is something to be gained by not >>> sticking slavishly to what the C standard says (which very few people >>> will study) and using more colloquial terms or ones that more can >>> relate to. >> >> There is something to be said for explaining the technical terms from >> the C standards in more colloquial language to make it easier for >> others to understand. There is nothing at all to be said for using C >> standard terms in clearly and obviously incorrect ways. That's just >> going to confuse these non-standard-reading C programmers when they >> try to find out more, no matter where they look for additional >> information. >> >>> >>> Apparently both 'typedef' and 'static' are forms of 'linkage'. But no >>> identifiers declared with those will ever be linked to anything! >> >> Could you point to the paragraph of the C standards that justifies >> that claim? Or are you perhaps mixing things up? (I can tell you the >> correct answer, with references, if you are stuck - but I'd like to >> give you the chance to show off your extensive C knowledge first.) > > * The standard talks a lot about Linkage but there are no specific > lexical elements for those. > > * Instead the standard uses lexical elements called 'storage-class > specifiers' to control what kind of linkage is applied to identifiers > > * Because of this association, I use 'linkage symbol' to refer to those > particular tokens So I was correct that you were mixing things up, and can't provide a reference in the C standards? You are correct that there are no lexical elements that explicitly control linkage, and that storage-class specifiers can affect linking. That does not mean linkage is determined solely by storage-class specifiers, nor does it mean all storage-class specifiers affect linkage. They cover related, but separate concepts. (It's a bit like scope and lifetime - they are related, but they are not the same thing.) > > * The tokens include 'typedef extern static' They also include _Thread_local, auto and register. And pay attention to 6.7.1p5 : """ The typedef specifier is called a "storage-class specifier" for syntactic convenience only; """ > > 6.2.2p3 says: "If the declaration of a file scope identifier for an > object or a function contains the storageclass specifier static, the > identifier has internal linkage." > > So it talks about statics as having linkage of some kind. What did I > say? I said statics will never be linked to anything. They have "internal linkage". This means they are allocated space (in ram for objects, code space for functions) by the linker, but static symbols from one translation unit do not link to the same names from other units. This is distinct from "external linkage", where space is allocated, identical symbols from different units are linked together, you must have no more than one definition (but you can have multiple declarations), and the definition and declarations must match in type. And it is distinct from "no linkage" - things that are not involved in the linking process, and have no connection between the identifier and an item in memory (code or data). Things like typedef names, non-static local variables, struct tags, and macro names are amongst the things that have no linkage. So static objects, with internal linkage, /are/ linked - the use of the identifier in the source code is linked to the linker-allocated memory address (relative or absolute, depending on the kind of linking and kind of target). > > 6.6.2p6 excludes typedefs (by omission). Or rather it says they have 'no > linkage', which is one of the three kinds of linkage (external, > internal, none). It is not by omission - it is covered in 6.2.2p6. > > So as far as I can see, statics and typedef are still lumped in to the > class of entities that have a form of linkage, and are part of the set > of tokens that control linkage. No, you are mistaken. But I can understand how you got it wrong, and I hope my post here can help clear it up. Your mixup stems from a limited view of "linking". You are viewing the term to mean something like "linking identical global identifiers from different units so that they refer to the same object". That is part of the process, but it /also/ means "linking identifiers and references with code or data memory areas". That applies equally to static data (with C "internal linkage") as to "global" data (with "external linkage") - but it does /not/ apply to things with "no linkage". > > --------------------------------------------------- > > This is to me is all a bit mixed up. Much as you dislike other languages > being brought in, they can give an enlightening perspective. They can't give much help with terms unless they are established languages, and even then the terms can vary significantly between languages. This is about your misunderstanding of the term "linkage" - at most, references to your language could illustrate what you have got wrong. But I think that has already been established and does not need extra help. > > So for me, linking applies to all named entities that occupy memory, Yes. > and > that have global/export scope. No. It is that extra restriction here that is wrong. (And "global scope" is a /really/ bad term to use. Scope is about when an identifier is visible in a program, and is not the same as linkage or lifetime. I know what you are trying to say here, but it is not an accurate term.)
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web