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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-08 11:37 +0000 |
| Message-ID | <87il2zrxtn.fsf@bsb.me.uk> |
| 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.
It's spin, because the term is emotive. "Cluttering up" is how you feel
about it. The phrase is just a mildly pejorative one about appearances.
There's no substance there. To make a technical point you would have to
explain how, for example,
struct item *items;
...
n_elements = get_number_of_items(...);
items = malloc(n_elements * sizeof *items);
...
is technically better than
n_elements = get_number_of_items(...);
struct item *items = malloc(n_elements * sizeof *items);
I've explained (more than once) how I find reasoning about the direct
initialise at first use style easier with fewer distractions.
> 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.
I agree. That's one big win for languages like Haskell with
sophisticated type inference. But the discussion (here) should be about
C where the disagreement is only about where to put the declaration.
> 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) {...}
That's not a related example. No one is suggesting anything remotely
like this.
This is why I keep asking if you have some political (or PR) background.
There is no reason at all to present an example where type information
is removed from the function prototype because no one is suggesting
that. It's a straw-man that you can argue against where, presumably,
you don't want to argue in favour of splitting the declaration away from
the point of first use.
> 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.
That's fine. I have other concerns that I feel trump rather subjective
notions of aesthetics.
>>>>> 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.
Avoiding incorrect use of technical terms never gets in the way of
writing clear and easy to understand explanations. Quite the reverse.
If you try to explain C's notions of scope and linkage by mixing them up
into terms like "global variables" you can only sow confusion.
But you rather like that:
> Apparently both 'typedef' and 'static' are forms of 'linkage'. But no
> identifiers declared with those will ever be linked to anything!
You /could/ explain what the term linkage means in relation to C
identifiers, but your preference is rarely to help people understand.
You'd rather just make a snide remark: "look, the C standard uses an
ordinary English word in a way that is not normal!".
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-08 12:10 +0000 |
| Message-ID | <uq2gav$1uvp4$1@dont-email.me> |
| In reply to | #382089 |
On 08/02/2024 11:37, Ben Bacarisse wrote: > bart <bc@freeuk.com> writes: > >> That sounds like your opinion against mine. It's nothing to do with spin, >> whatever that means. > > It's spin, because the term is emotive. "Cluttering up" is how you feel > about it. The phrase is just a mildly pejorative one about appearances. > There's no substance there. To make a technical point you would have to > explain how, for example, > > struct item *items; > ... > n_elements = get_number_of_items(...); > items = malloc(n_elements * sizeof *items); > ... > > is technically better than > > n_elements = get_number_of_items(...); > struct item *items = malloc(n_elements * sizeof *items); > > I've explained (more than once) how I find reasoning about the direct > initialise at first use style easier with fewer distractions. > items = malloc(n_elements * sizeof *items); is shorter than struct item *items = malloc(n_elements * sizeof *items); and that is an objective statement about which there can be no dispute. -- 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-08 13:24 +0100 |
| Message-ID | <uq2h63$1v5v8$1@dont-email.me> |
| In reply to | #382093 |
On 08/02/2024 13:10, Malcolm McLean wrote: > On 08/02/2024 11:37, Ben Bacarisse wrote: >> bart <bc@freeuk.com> writes: >> >>> That sounds like your opinion against mine. It's nothing to do with >>> spin, >>> whatever that means. >> >> It's spin, because the term is emotive. "Cluttering up" is how you feel >> about it. The phrase is just a mildly pejorative one about appearances. >> There's no substance there. To make a technical point you would have to >> explain how, for example, >> >> struct item *items; >> ... >> n_elements = get_number_of_items(...); >> items = malloc(n_elements * sizeof *items); >> ... >> >> is technically better than >> >> n_elements = get_number_of_items(...); >> struct item *items = malloc(n_elements * sizeof *items); >> >> I've explained (more than once) how I find reasoning about the direct >> initialise at first use style easier with fewer distractions. >> > items = malloc(n_elements * sizeof *items); > > is shorter than > > struct item *items = malloc(n_elements * sizeof *items); > > and that is an objective statement about which there can be no dispute. > But that is not the comparison. struct item *items = malloc(n_elements * sizeof *items); is shorter than: struct item *items; items = malloc(n_elements * sizeof *items); You have to define the variable somewhere. Doing so when you initialise it when you first need it, is, without doubt, objectively shorter. Opinions may differ on whether it is clearer, or "cluttered", but which is shorter is not in doubt. (What relevance that might have, is much more in doubt.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-08 13:03 +0000 |
| Message-ID | <uq2jec$1vg9n$2@dont-email.me> |
| In reply to | #382096 |
On 08/02/2024 12:24, David Brown wrote: > On 08/02/2024 13:10, Malcolm McLean wrote: >> On 08/02/2024 11:37, Ben Bacarisse wrote: >>> bart <bc@freeuk.com> writes: >>> >>>> That sounds like your opinion against mine. It's nothing to do with >>>> spin, >>>> whatever that means. >>> >>> It's spin, because the term is emotive. "Cluttering up" is how you feel >>> about it. The phrase is just a mildly pejorative one about appearances. >>> There's no substance there. To make a technical point you would have to >>> explain how, for example, >>> >>> struct item *items; >>> ... >>> n_elements = get_number_of_items(...); >>> items = malloc(n_elements * sizeof *items); >>> ... >>> >>> is technically better than >>> >>> n_elements = get_number_of_items(...); >>> struct item *items = malloc(n_elements * sizeof *items); >>> >>> I've explained (more than once) how I find reasoning about the direct >>> initialise at first use style easier with fewer distractions. >>> >> items = malloc(n_elements * sizeof *items); >> >> is shorter than >> >> struct item *items = malloc(n_elements * sizeof *items); >> >> and that is an objective statement about which there can be no dispute. >> > > But that is not the comparison. > > struct item *items = malloc(n_elements * sizeof *items); > > is shorter than: > > struct item *items; > items = malloc(n_elements * sizeof *items); > > You have to define the variable somewhere. Doing so when you initialise > it when you first need it, is, without doubt, objectively shorter. > Opinions may differ on whether it is clearer, or "cluttered", but which > is shorter is not in doubt. (What relevance that might have, is much > more in doubt.) > Sure. But it doesn't look like that. The first line is squirrelled away at the top and you don't read it. Of course you can say that you now don't now know that items is a pointer to the right type of structure, and so the shortening makes it harder rather than easier to understand. But the claim that the second one is more "cluttered" is fair. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-08 13:17 +0000 |
| Message-ID | <uq2k9f$1vnhi$1@dont-email.me> |
| In reply to | #382096 |
On 08/02/2024 12:24, David Brown wrote:
> On 08/02/2024 13:10, Malcolm McLean wrote:
>> On 08/02/2024 11:37, Ben Bacarisse wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>>> That sounds like your opinion against mine. It's nothing to do with
>>>> spin,
>>>> whatever that means.
>>>
>>> It's spin, because the term is emotive. "Cluttering up" is how you feel
>>> about it. The phrase is just a mildly pejorative one about appearances.
>>> There's no substance there. To make a technical point you would have to
>>> explain how, for example,
>>>
>>> struct item *items;
>>> ...
>>> n_elements = get_number_of_items(...);
>>> items = malloc(n_elements * sizeof *items);
>>> ...
>>>
>>> is technically better than
>>>
>>> n_elements = get_number_of_items(...);
>>> struct item *items = malloc(n_elements * sizeof *items);
>>>
>>> I've explained (more than once) how I find reasoning about the direct
>>> initialise at first use style easier with fewer distractions.
>>>
>> items = malloc(n_elements * sizeof *items);
>>
>> is shorter than
>>
>> struct item *items = malloc(n_elements * sizeof *items);
>>
>> and that is an objective statement about which there can be no dispute.
>>
>
> But that is not the comparison.
>
> struct item *items = malloc(n_elements * sizeof *items);
>
> is shorter than:
>
> struct item *items;
> items = malloc(n_elements * sizeof *items);
>
> You have to define the variable somewhere. Doing so when you initialise
> it when you first need it, is, without doubt, objectively shorter.
> Opinions may differ on whether it is clearer, or "cluttered", but which
> is shorter is not in doubt. (What relevance that might have, is much
> more in doubt.)
>
>
If you want to isolate the executable code then you'd write it like this:
struct item *items;
...
items = malloc(n_elements * sizeof *items);
That code is now cleaner. It also doesn't have that somewhat confusing
(partly due to spacing) '... *items = malloc ...' which makes it look
like an indirect assignment to a pointer called 'item' (compounded by
that '*items' term as the sizeof operand).
It doesn't have the distracting juxtasposition in 'item * items'.
If there was a subsequence assignment to 'items':
items = malloc(n_elements * sizeof *items);
...
items = malloc(m_elements * sizeof *items);
the two look the same; you don't have one pushed over to the right. (I
was able to copy&paste with only a small tweak.)
If I decided I didn't need that first assignment, I don't now need to
transfer that declaration to the next use.
If the assinment is within a nested block, but I decide it needs to be
visible outside the block, I don't need to refactor; it is already visible.
If I decided to change the type of 'items', it's easier if it's at the
top; perhaps there are related variables whose types need changing.
This is especially the case if I have 'aitems' and 'bitems' of the same
type:
struct item *aitems, *bitems;
* I don't need a separate declaration for each
* I can instantly see they are the same type without needing to infer
* I can change the type of both in one place; they can't get out of step
Shall I go on?
Did you see my post where I established that C programs typically have
only 3 locals per function on average?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-08 16:52 +0100 |
| Message-ID | <uq2tbi$21cs3$1@dont-email.me> |
| In reply to | #382102 |
On 08/02/2024 14:17, bart wrote: > On 08/02/2024 12:24, David Brown wrote: >> On 08/02/2024 13:10, Malcolm McLean wrote: >>> On 08/02/2024 11:37, Ben Bacarisse wrote: >>>> bart <bc@freeuk.com> writes: >>>> >>>>> That sounds like your opinion against mine. It's nothing to do with >>>>> spin, >>>>> whatever that means. >>>> >>>> It's spin, because the term is emotive. "Cluttering up" is how you >>>> feel >>>> about it. The phrase is just a mildly pejorative one about >>>> appearances. >>>> There's no substance there. To make a technical point you would >>>> have to >>>> explain how, for example, >>>> >>>> struct item *items; >>>> ... >>>> n_elements = get_number_of_items(...); >>>> items = malloc(n_elements * sizeof *items); >>>> ... >>>> >>>> is technically better than >>>> >>>> n_elements = get_number_of_items(...); >>>> struct item *items = malloc(n_elements * sizeof *items); >>>> >>>> I've explained (more than once) how I find reasoning about the direct >>>> initialise at first use style easier with fewer distractions. >>>> >>> items = malloc(n_elements * sizeof *items); >>> >>> is shorter than >>> >>> struct item *items = malloc(n_elements * sizeof *items); >>> >>> and that is an objective statement about which there can be no dispute. >>> >> >> But that is not the comparison. >> >> struct item *items = malloc(n_elements * sizeof *items); >> >> is shorter than: >> >> struct item *items; >> items = malloc(n_elements * sizeof *items); >> >> You have to define the variable somewhere. Doing so when you >> initialise it when you first need it, is, without doubt, objectively >> shorter. Opinions may differ on whether it is clearer, or "cluttered", >> but which is shorter is not in doubt. (What relevance that might >> have, is much more in doubt.) >> >> > > If you want to isolate the executable code then you'd write it like this: > > struct item *items; > ... > items = malloc(n_elements * sizeof *items); > Yes - /if/ you want to do this. But I don't see a reason to make such a distinction - I see no benefit in "isolating the executable code". Both lines are essential parts of the program, they are used together, and IMHO they belong together. I appreciate that you prefer to keep them separate. I believe the arguments for keeping them separate are far weaker than the arguments for declaring and defining variables only when you are ready to use them, and within the smallest practical scope. > That code is now cleaner. That is an opinion, and no more than that. > It also doesn't have that somewhat confusing > (partly due to spacing) '... *items = malloc ...' which makes it look > like an indirect assignment to a pointer called 'item' (compounded by > that '*items' term as the sizeof operand). I personally put spaces on either side of the "*", whether the declaration is separate or not. But spacing habits are /definitely/ a matter of personal preference. (And I'd also typedef the struct, which is again a personal preference.) > > It doesn't have the distracting juxtasposition in 'item * items'. > > If there was a subsequence assignment to 'items': > > items = malloc(n_elements * sizeof *items); > ... > items = malloc(m_elements * sizeof *items); > > the two look the same; you don't have one pushed over to the right. (I > was able to copy&paste with only a small tweak.) Agreed - but it is not something you actually have very often. I can accept that there are occasions when the particular format of the code or repetitive patterns would make the code clearer to have a single declaration at the top and multiple assignments like this. But it is not a common situation. I am quite happy for general rules to be overridden on a case-by-case basis if it significantly improves clarity. > This is especially the case if I have 'aitems' and 'bitems' of the same > type: > > struct item *aitems, *bitems; A trick to writing clear and maintainable code is not to do that. It is very rare IME that it is a good idea with multiple declarations on one line, and it is never a good thing if there are pointers, arrays, or other bits and pieces involved. So if the only benefit from "only declare your variables when you have an initial value" is that you never again write such multiple declaration lines, then it would be a good thing. > > * I don't need a separate declaration for each That doesn't matter when the declaration is part of the initialisation. > > * I can instantly see they are the same type without needing to infer > No, you can't. You have to look further up the function and find it in the list of variables. With the declare and initialise pattern, the type is right there in the relevant code - not elsewhere. > * I can change the type of both in one place; they can't get out of step > And you have to re-arrange things if you want to change the type of just one of them. > Shall I go on? > No. We've heard all these arguments before. They are not new. I don't think the points are worthless, I simply think they are not nearly enough to sway the balance. > Did you see my post where I established that C programs typically have > only 3 locals per function on average? I ignored that one. I can't reply to everything!
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-08 17:17 +0000 |
| Message-ID | <87plx6ri37.fsf@bsb.me.uk> |
| In reply to | #382093 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On 08/02/2024 11:37, Ben Bacarisse wrote: >> bart <bc@freeuk.com> writes: >> >>> That sounds like your opinion against mine. It's nothing to do with spin, >>> whatever that means. >> It's spin, because the term is emotive. "Cluttering up" is how you feel >> about it. The phrase is just a mildly pejorative one about appearances. >> There's no substance there. To make a technical point you would have to >> explain how, for example, >> struct item *items; >> ... >> n_elements = get_number_of_items(...); >> items = malloc(n_elements * sizeof *items); >> ... >> is technically better than >> n_elements = get_number_of_items(...); >> struct item *items = malloc(n_elements * sizeof *items); >> I've explained (more than once) how I find reasoning about the direct >> initialise at first use style easier with fewer distractions. >> > items = malloc(n_elements * sizeof *items); > > is shorter than > > struct item *items = malloc(n_elements * sizeof *items); > > and that is an objective statement about which there can be no > dispute. Yes, but is it relevant or even interesting? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-02-09 14:50 -0800 |
| Message-ID | <86il2x5k1s.fsf@linuxsc.com> |
| In reply to | #382089 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: [some previous material removed or summarized] > 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: >>>> >>>>>> [on choosing between declaring local variables always at the >>>>>> start of a function, before any statements, or declaring >>>>>> local variables throughout the body of a function, usually >>>>>> with an initializing declaration at the point of first use; >>>>>> an all-at-the-top style gives a single place to look for >>>>>> all locals used in the function body] >>>>> >>>>> 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. > > It's spin, because the term is emotive. "Cluttering up" is how > you feel about it. The phrase is just a mildly pejorative one > about appearances. There's no substance there. To make a > technical point you would have to explain how, for example, > > struct item *items; > ... > n_elements = get_number_of_items(...); > items = malloc(n_elements * sizeof *items); > ... > > is technically better than > > n_elements = get_number_of_items(...); > struct item *items = malloc(n_elements * sizeof *items); > > I've explained (more than once) how I find reasoning about > the direct initialise at first use style easier with fewer > distractions. I would like to offer another perspective here. First let me state some personal preferences without giving any whys or wherefores. I mostly put declarations at the start of a compound statement, before any statements in the same block. I'm not absolutely opposed to writing declarations "between statements", but in most cases I don't if there is a reasonable way to avoid it. I usually declare variables in the most-nested compound statement that works. I'm not entirely rigorous about it. In most cases I write initializing declarations for variables that are not subsequently modified. For other variables it varies (no pun intended), but typically such variables are declared without an initializer. When writing for() statements, sometimes I use the declaring form for the first clause, but most of the time I don't. I am strongly biased in favor of keeping function bodies short. To put some numbers on that, 25 lines for almost all functions, 40 lines for longer functions, and 60 lines for all functions (with the qualifier that longer than 60 lines is not categorically excluded, but there needs to be a compelling argument that observing the 60-line bound is not feasible). Those numbers are of course meant as upper bounds, and not as being typical or representative. I strongly prefer code that looks clean. The word "clean" here means lots of different things, but "easy on the eyes" might be a good capsule summary. That said, the measure is not purely visual: it's also important that the code be semantically clean, but that idea is even harder to define than visual appearance. (Amusing aside: as it happens I recently wrote a function whose body consisted of 25 initializing declarations, followed by four one-line imperative statements and then a single simple return statement.) Now here are some explanations. Short functions are easier to understand than long functions. Conversely, functions that are, say, longer than a single page are very likely to be more difficult to comprehend. A corollary to this relationship is that long functions need to be cleaner than short functions: a short function body can bend or break style rules without losing too much understandability, but long function bodies tend to become harder to understand much faster if they aren't fastidious in hewing to good style aesthetics. In choosing where to put declarations, I find that I have a different mindset when reading declarations than when reading executable statements. (Yes I know initializing declarations are executable but I think everyone knows what I mean.) Switching between those two mindsets, even though it may be subconscious, requires some amount of mental effort, so it's mentally easier (for me anyway) when reading code to keep declarations and statements separate. I often will put in a blank line after the declarations and before the statements, especially in the outermost block of a function. The blank line both makes it easier to find the dividing point between the two regimes and also gives a kind of mental cue to (maybe make it easier to) switch from one mindset to the other. Another concern is uniformity. Putting declarations at top of block always works; trying to declare at the point of first use sometimes doesn't. Similarly using the expression form of for() always works, but trying to use declaration-style for()s sometimes doesn't. Being completely uniform is not an absolute requirement, or even a super high priority, but it does exert a slight pressure in the direction of choosing top-of-block declarations rather than being mixed in with executable statements. I should say explicitly that the above statements, and indeed I think all the statements in this posting, are relating only my own reactions and assessments, and for sure other people may have different reactions and assessments, and there is no contradiction in that. Each person has his or her own central nervous system, and how different people react can vary a lot from person to person. An example I like to give about myself is I am partially colorblind, so things like putting keywords in a different color are in many cases worse than useless for me, no matter how helpful they may be for other people. Now I would like to offer some views on the earlier discussions. First, I don't think what bart is advocating is completely without merit. His position is more strict than my own, but certainly there is some overlap. Second, I think there is also some merit in the declare-at-first-use style, especially when such a declaration includes initialization and the variable being declared is never changed after the declaration. I don't use this style all the time but there are instances where it clearly does better than the alternatives. Third, what I think is the key difference between my choices and the other styles debated is that, at least in this domain, my approach is less dogmatic and more pragmatic. Along this particular axis flexibility is key. (Having said that, I should add that I cannot envision ever completely abandoning initializing-declarations.) Fourth, I would not describe the notion that "declarations clutter up [non-declaration statements]" as spin. Don't get me wrong, there are plenty of things that certain people say that I /do/ think of as spin, but in my view this isn't one of them. Also let me add that I share your frustration that some people don't make more of an effort to express themselves in more objective ways. In this case though I think what is being voiced is a good faith effort to express a personal reaction and not a disingenuous and artificially negative statement made purely to rile people up (which I guess is my own rough translation of the word "spin"). Wwll, I guess that's all. My thanks to everyone for their attention. I hope y'all have gotten some value from my musings.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-07 12:44 +0000 |
| Message-ID | <upvtvi$1e5or$1@dont-email.me> |
| In reply to | #381958 |
On 07/02/2024 10:47, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On 07/02/2024 07:54, David Brown wrote:
>>> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote:
>>>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote:
>>>>
>>>>> They reuse "temp" variables instead of making new ones.
>>>>
>>>> I like to limit the scope of my temporary variables. In C, this is as
>>>> easy
>>>> as sticking a pair of braces around a few statements.
>>> Generally, you want to have the minimum practical scope for your local
>>> variables. It's rare that you need to add braces just to make a scope
>>> for a variable - usually you have enough braces in loops or conditionals
>>> - but it happens.
>>>
>> The two common patterns are to give each variable the minimum scope, or to
>> decare all variables at the start of the function and give them all
>> function scope.
>
> The term "function scope" has a specific meaning in C. Only labels have
> function scope. I know you are not very interested in using exact
> terms, but some people might like to know the details.
>
To explain this, if we have
void function(void)
{
int i;
for (i = 0; i < 10;; i++)
dosomething();
if ( condition)
{
int i;
for (i = 0; i < 11; i++)
dosomething();
if (i == 10)
/* always false */
}
}
The first i is not in scope when we test for i == 10 and the test will
be false. So "fucntion scope" isn't the term.
However if we have this:
void fucntion(void)
{
label:
dosomething();
if (condition)
{
label:
dosomething();
}
got label:
}
Then it is a error. Both labels are in scope and that isn't allowed.
> Since you want to argue for the peculiar (but common) practice of giving
> names the largest possible scope (without altering their linkage) you
> need a term for the outer-most block scope, but "function scope" is
> taken.
>
So "function scope" isn't the correct term. So we need another. I expect
that at this point someone will jump in and say it must be "Malcolm
scope". As you say, it's common enough to need a term for it.
>> The case for minimum scope is the same as the case for scope itself.
>
> Someone might well misinterpret the term "minimum scope" since it would
> require adding lots of otherwise redundant braces. I *think* you mean
> declaring names at the point of first use. The resulting scope is not
> minimum because it often extends beyond the point of last use.
>
Yes, I don't mean literally the minimum scope that would be possible by
artificially ending a block when a variable is used for the last time.
No one would do that. I mean that the variable is either declared at
point of first use or, if this isn't allowed because of the C version,
at the top of the block in which it is used. But also that variables are
not reused if in fact the value is discarded between statements or
especially between blocks.
> Other people, not familiar with" modern" C, might interpret the term to
> mean declaring names at the top of the inner-most appropriate block.
>
Top of the block or point of first use?
>> The
>> variable is accessible where it is used and not elsewhere, which makes it
>> less likely it will be used in error, and means there are fewer names to
>> understand.
>
> The case for declaration at first use is much stronger than this. It
> almost always allows for a meaningful initialisation at the same point,
> so the initialisation does not need to be hunted down a checked. For
> me, this is a big win. (Yes, some people then insist on a dummy
> initialisation when the proper one isn't know, but that's a fudge that
> is, to my mind, even worse.)
>
If you go for top of block and you don't have a value, you either
intialise, usually to zero, or leave it wild. Neither is ideal. But it
rarely makes a big difference. However if you go for policy two, all the
variables are either given initial values at the top of the function or
they are not given initial values at the top of the function,and so you
can easily check, and ensure that all the initial values are consistent
woth each other.
>
> We could call it outer-most block scope rather than re-use a term with
> an existing, but different, technical meaning.
>
The variable has scope within the function, within the whole of the
function, and the motive is that the function is the natural unit of
thought. So I think we need the word "function".
>> However I use a lot of C++ these
>> days, and in C++ local scope is often better, and in some cases even
>> necessary. So I find that I'm tending to use local scope in C more.
>
> Interesting. Is it just that using C++ has given you what you would
> think of as a bad habit in C, or has using C++ led you to see that your
> old preference was not the best one?
>
Not sure. If I thought it was a terrible habit of course I wouldn't do
it. I do think it makes the code look a little bit less clear. But it's
slightly easier to write and hack, which is why I do it.
--
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 14:49 +0100 |
| Message-ID | <uq01pn$1erim$1@dont-email.me> |
| In reply to | #381964 |
On 07/02/2024 13:44, Malcolm McLean wrote:
> On 07/02/2024 10:47, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On 07/02/2024 07:54, David Brown wrote:
>>>> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote:
>>>>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote:
>>>>>
>>>>>> They reuse "temp" variables instead of making new ones.
>>>>>
>>>>> I like to limit the scope of my temporary variables. In C, this is as
>>>>> easy
>>>>> as sticking a pair of braces around a few statements.
>>>> Generally, you want to have the minimum practical scope for your local
>>>> variables. It's rare that you need to add braces just to make a scope
>>>> for a variable - usually you have enough braces in loops or
>>>> conditionals
>>>> - but it happens.
>>>>
>>> The two common patterns are to give each variable the minimum scope,
>>> or to
>>> decare all variables at the start of the function and give them all
>>> function scope.
>>
>> The term "function scope" has a specific meaning in C. Only labels have
>> function scope. I know you are not very interested in using exact
>> terms, but some people might like to know the details.
>>
> To explain this, if we have
>
> void function(void)
> {
> int i;
>
> for (i = 0; i < 10;; i++)
> dosomething();
> if ( condition)
> {
> int i;
>
> for (i = 0; i < 11; i++)
> dosomething();
> if (i == 10)
> /* always false */
> }
> }
>
> The first i is not in scope when we test for i == 10 and the test will
> be false. So "fucntion scope" isn't the term.
"Function scope" is not the term, because - as has been explained to you
- "function scope" has a specific meaning in C, and this is not it.
Everyone can figure out what you are trying to say - you mean the
outermost block scope of the function. It's just block scope, as normal.
(By the way, you do know that Thunderbird has a pretty good spell
checker? I don't want to get hung up on this, and don't want to start a
new branch or argument, but avoiding the silly typos in your posts would
improve them.)
>
> However if we have this:
>
> void fucntion(void)
> {
> label:
> dosomething();
> if (condition)
> {
> label:
> dosomething();
> }
> got label:
> }
>
> Then it is a error. Both labels are in scope and that isn't allowed.
Yes, that's because labels have function scope in C.
>
>> Since you want to argue for the peculiar (but common) practice of giving
>> names the largest possible scope (without altering their linkage) you
>> need a term for the outer-most block scope, but "function scope" is
>> taken.
>>
> So "function scope" isn't the correct term. So we need another. I expect
> that at this point someone will jump in and say it must be "Malcolm
> scope". As you say, it's common enough to need a term for it.
>
We don't need a new term. We have the terms in the C standards. Block
scope is fine.
Note that there is another very big difference between "function scope"
and "block scope". Labels in function scope are in scope within the
function, even before they are declared. For identifiers in block
scope, their scope does not start until they are declared.
>
>>> The case for minimum scope is the same as the case for scope itself.
>>
>> Someone might well misinterpret the term "minimum scope" since it would
>> require adding lots of otherwise redundant braces. I *think* you mean
>> declaring names at the point of first use. The resulting scope is not
>> minimum because it often extends beyond the point of last use.
>>
>
> Yes, I don't mean literally the minimum scope that would be possible by
> artificially ending a block when a variable is used for the last time.
> No one would do that. I mean that the variable is either declared at
> point of first use or, if this isn't allowed because of the C version,
> at the top of the block in which it is used. But also that variables are
> not reused if in fact the value is discarded between statements or
> especially between blocks.
>
>> Other people, not familiar with" modern" C, might interpret the term to
>> mean declaring names at the top of the inner-most appropriate block.
>>
> Top of the block or point of first use?
In C90, you have to declare your variables before any statements within
the block. In C99, you can intermingle declarations and statements.
Thus even in C90, you can still have top of block declarations.
>>> The
>>> variable is accessible where it is used and not elsewhere, which
>>> makes it
>>> less likely it will be used in error, and means there are fewer names to
>>> understand.
>>
>> The case for declaration at first use is much stronger than this. It
>> almost always allows for a meaningful initialisation at the same point,
>> so the initialisation does not need to be hunted down a checked. For
>> me, this is a big win. (Yes, some people then insist on a dummy
>> initialisation when the proper one isn't know, but that's a fudge that
>> is, to my mind, even worse.)
>>
> If you go for top of block and you don't have a value, you either
> intialise, usually to zero, or leave it wild. Neither is ideal.
Leaving it uninitialised is /much/ better, unless you are using weak
tools or don't know how to use them properly. (There can be
circumstances where code is too complex for compilers to be sure that a
variable is never used uninitialised, and you might find it appropriate
to give a dummy initialisation in that case. But such cases are rare.)
Even better, of course, is not to declare the variable at all until you
have something sensible to put in it. (And then consider making it
"const" if it does not change.)
> But it
> rarely makes a big difference. However if you go for policy two, all the
> variables are either given initial values at the top of the function or
> they are not given initial values at the top of the function,and so you
> can easily check, and ensure that all the initial values are consistent
> woth each other.
>
If you declare your variables when you have a value for them, then the
initial values are all clear and consistent, and have no artificial
values, and in many cases, they never change. Having your variables
unchanging makes code /much/ easier to understand and check for correctness.
>>
>> We could call it outer-most block scope rather than re-use a term with
>> an existing, but different, technical meaning.
>>
> The variable has scope within the function, within the whole of the
> function, and the motive is that the function is the natural unit of
> thought. So I think we need the word "function".
No, we don't. And no, the scope is /not/ the entire function.
>
>>> However I use a lot of C++ these
>>> days, and in C++ local scope is often better, and in some cases even
>>> necessary. So I find that I'm tending to use local scope in C more.
>>
>> Interesting. Is it just that using C++ has given you what you would
>> think of as a bad habit in C, or has using C++ led you to see that your
>> old preference was not the best one?
>>
>
> Not sure. If I thought it was a terrible habit of course I wouldn't do
> it. I do think it makes the code look a little bit less clear. But it's
> slightly easier to write and hack, which is why I do it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-07 16:13 +0000 |
| Message-ID | <87a5octfqd.fsf@bsb.me.uk> |
| In reply to | #381964 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 07/02/2024 10:47, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On 07/02/2024 07:54, David Brown wrote:
>>>> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote:
>>>>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote:
>>>>>
>>>>>> They reuse "temp" variables instead of making new ones.
>>>>>
>>>>> I like to limit the scope of my temporary variables. In C, this is as
>>>>> easy
>>>>> as sticking a pair of braces around a few statements.
>>>> Generally, you want to have the minimum practical scope for your local
>>>> variables. It's rare that you need to add braces just to make a scope
>>>> for a variable - usually you have enough braces in loops or conditionals
>>>> - but it happens.
>>>>
>>> The two common patterns are to give each variable the minimum scope, or to
>>> decare all variables at the start of the function and give them all
>>> function scope.
>> The term "function scope" has a specific meaning in C. Only labels have
>> function scope. I know you are not very interested in using exact
>> terms, but some people might like to know the details.
>>
> To explain this, if we have
What is the "this" that you are explaining?
> void function(void)
> {
> int i;
>
> for (i = 0; i < 10;; i++)
> dosomething();
> if ( condition)
> {
> int i;
>
> for (i = 0; i < 11; i++)
> dosomething();
> if (i == 10)
> /* always false */
> }
> }
>
> The first i is not in scope when we test for i == 10 and the test will be
> false. So "fucntion scope" isn't the term.
"function scope" is not the term because only labels have function
scope. This example does not explain anything about the term
"functions scope" -- even why it's the wrong term.
> However if we have this:
>
> void fucntion(void)
> {
> label:
> dosomething();
> if (condition)
> {
> label:
> dosomething();
> }
> got label:
(you mean "goto label;")
> }
>
> Then it is a error. Both labels are in scope and that isn't allowed.
The key thing about the scope of labels is that they can be used before
that are defined:
int *f(int *p)
{
if (!p) goto error:
...
error:
return p;
}
>> Since you want to argue for the peculiar (but common) practice of giving
>> names the largest possible scope (without altering their linkage) you
>> need a term for the outer-most block scope, but "function scope" is
>> taken.
>>
> So "function scope" isn't the correct term. So we need another. I expect
> that at this point someone will jump in and say it must be "Malcolm
> scope". As you say, it's common enough to need a term for it.
I see no reason not to call it "the outer-most block scope".
>>> The case for minimum scope is the same as the case for scope itself.
>> Someone might well misinterpret the term "minimum scope" since it would
>> require adding lots of otherwise redundant braces. I *think* you mean
>> declaring names at the point of first use. The resulting scope is not
>> minimum because it often extends beyond the point of last use.
>
> Yes, I don't mean literally the minimum scope that would be possible by
> artificially ending a block when a variable is used for the last time. No
> one would do that. I mean that the variable is either declared at point of
> first use or, if this isn't allowed because of the C version, at the top of
> the block in which it is used. But also that variables are not reused if in
> fact the value is discarded between statements or especially between
> blocks.
>
>> Other people, not familiar with" modern" C, might interpret the term to
>> mean declaring names at the top of the inner-most appropriate block.
>>
> Top of the block or point of first use?
I don't know what you are asking. I was trying to point out these two
possible meanings for "minimum scope".
>>> The
>>> variable is accessible where it is used and not elsewhere, which makes it
>>> less likely it will be used in error, and means there are fewer names to
>>> understand.
>> The case for declaration at first use is much stronger than this. It
>> almost always allows for a meaningful initialisation at the same point,
>> so the initialisation does not need to be hunted down a checked. For
>> me, this is a big win. (Yes, some people then insist on a dummy
>> initialisation when the proper one isn't know, but that's a fudge that
>> is, to my mind, even worse.)
>>
> If you go for top of block and you don't have a value, you either
> intialise, usually to zero, or leave it wild. Neither is ideal. But it
> rarely makes a big difference. However if you go for policy two, all the
> variables are either given initial values at the top of the function or
> they are not given initial values at the top of the function,and so you can
> easily check, and ensure that all the initial values are consistent woth
> each other.
What?
>> We could call it outer-most block scope rather than re-use a term with
>> an existing, but different, technical meaning.
>>
> The variable has scope within the function, within the whole of the
> function, and the motive is that the function is the natural unit of
> thought. So I think we need the word "function".
You need the word function. I don't.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-07 08:21 -0800 |
| Message-ID | <877cjgi6tb.fsf@nosuchdomain.example.com> |
| In reply to | #381964 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 07/02/2024 10:47, Ben Bacarisse wrote:
[...]
>> Since you want to argue for the peculiar (but common) practice of giving
>> names the largest possible scope (without altering their linkage) you
>> need a term for the outer-most block scope, but "function scope" is
>> taken.
>>
> So "function scope" isn't the correct term. So we need another. I
> expect that at this point someone will jump in and say it must be
> "Malcolm scope". As you say, it's common enough to need a term for it.
Please, no, not "Malcolm scope". That's the kind of thing that gets
suggested as a last resort, or as a joke, when you insist on using
existing terminology with your own idiosyncratic meaning.
"Outermost block scope" is a clear and correct description of what
you're talking about. Though what you're probably talking about is
outermost block scope before any statements. Or just "at the top of the
function definition".
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-07 14:01 +0100 |
| Message-ID | <upvuv7$1ebl4$1@dont-email.me> |
| In reply to | #381952 |
On 07/02/2024 09:59, Malcolm McLean wrote:
> On 07/02/2024 07:54, David Brown wrote:
>> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote:
>>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote:
>>>
>>>> They reuse "temp" variables instead of making new ones.
>>>
>>> I like to limit the scope of my temporary variables. In C, this is as
>>> easy
>>> as sticking a pair of braces around a few statements.
>>
>> Generally, you want to have the minimum practical scope for your local
>> variables. It's rare that you need to add braces just to make a scope
>> for a variable - usually you have enough braces in loops or
>> conditionals - but it happens.
>>
> The two common patterns are to give each variable the minimum scope, or
> to decare all variables at the start of the function and give them all
> function scope.
>
> The case for minimum scope is the same as the case for scope itself. The
> variable is accessible where it is used and not elsewhere, which makes
> it less likely it will be used in error, and means there are fewer names
> to understand.
>
It makes code simpler, clearer, easier to reuse, easier to see that it
is correct, and easier to see if there is an error. It is very much
easier for automatic tools (static warnings) to spot issues.
> However there are also strong arguments for ducntion scope.
Not in my experience and in my opinion.
> A function
> is a natural unit.
True, but irrelevant.
> Adn all the varibales used in that unit are listed
> together and, ideally, commented.
In reality, not commented. And if commented, then commented incorrectly.
Rather than trying to write vague comments to say what something is how
it is used, it is better to write the code so that it is clear. Giving
variables appropriate names is part of that. For the most part, I'd say
if you think a variable needs a comment, your code is not clear enough
or has poor structure.
It is /massively/ simpler and clearer to write :
for (int i = 0; i < 10; i++) { ... }
than
int i;
/* ... big gap ... */
for (i = 0; i < 10; i++) { ... }
It doesn't help if you have "int loop_index;" or add a comment to the
variable definition. Putting it at the loop itself is better.
> So at a glance you can see what is in
> scope and what is being operated on. And there are only three levels of
> scope. A varibale is global, or it is file scope, or it is scoped to the
> function.
Every block is a new scope. Function scope in C is only for labels.
>
> I tend to prefer function scope for C. However I use a lot of C++ these
> days, and in C++ local scope is often better, and in some cases even
> necessary. So I find that I'm tending to use local scope in C more.
>
I hate having to work with code written in long-outdated "declare
everything at the top of the function" style. I realise style and
experience are subjective, but I have not seen any code or any argument
that has led me to doubt my preferences.
[toc] | [prev] | [next] | [standalone]
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-02-07 13:21 +0000 |
| Message-ID | <uq0054$1ei8m$1@dont-email.me> |
| In reply to | #381967 |
On 07/02/2024 13:01, David Brown wrote:
> On 07/02/2024 09:59, Malcolm McLean wrote:
>> On 07/02/2024 07:54, David Brown wrote:
>>> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote:
>>>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote:
>>>>
>>>>> They reuse "temp" variables instead of making new ones.
>>>>
>>>> I like to limit the scope of my temporary variables. In C, this is
>>>> as easy
>>>> as sticking a pair of braces around a few statements.
>>>
>>> Generally, you want to have the minimum practical scope for your
>>> local variables. It's rare that you need to add braces just to make
>>> a scope for a variable - usually you have enough braces in loops or
>>> conditionals - but it happens.
>>>
>> The two common patterns are to give each variable the minimum scope,
>> or to decare all variables at the start of the function and give them
>> all function scope.
>>
>> The case for minimum scope is the same as the case for scope itself.
>> The variable is accessible where it is used and not elsewhere, which
>> makes it less likely it will be used in error, and means there are
>> fewer names to understand.
>>
>
> It makes code simpler, clearer, easier to reuse, easier to see that it
> is correct, and easier to see if there is an error. It is very much
> easier for automatic tools (static warnings) to spot issues.
>
>> However there are also strong arguments for ducntion scope.
>
> Not in my experience and in my opinion.
>
>> A function is a natural unit.
>
> True, but irrelevant.
>
>> Adn all the varibales used in that unit are listed together and,
>> ideally, commented.
>
> In reality, not commented. And if commented, then commented incorrectly.
>
> Rather than trying to write vague comments to say what something is how
> it is used, it is better to write the code so that it is clear. Giving
> variables appropriate names is part of that. For the most part, I'd say
> if you think a variable needs a comment, your code is not clear enough
> or has poor structure.
>
> It is /massively/ simpler and clearer to write :
>
> for (int i = 0; i < 10; i++) { ... }
>
> than
>
> int i;
>
> /* ... big gap ... */
>
> for (i = 0; i < 10; i++) { ... }
>
> It doesn't help if you have "int loop_index;" or add a comment to the
> variable definition. Putting it at the loop itself is better.
>
>
>> So at a glance you can see what is in scope and what is being operated
>> on. And there are only three levels of scope. A varibale is global, or
>> it is file scope, or it is scoped to the function.
>
> Every block is a new scope. Function scope in C is only for labels.
>
>>
>> I tend to prefer function scope for C. However I use a lot of C++
>> these days, and in C++ local scope is often better, and in some cases
>> even necessary. So I find that I'm tending to use local scope in C more.
>>
We could have 'malcolm-scope' ?!
(sorry :) )
>
> I hate having to work with code written in long-outdated "declare
> everything at the top of the function" style. I realise style and
> experience are subjective, but I have not seen any code or any argument
> that has led me to doubt my preferences.
>
>
>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-07 13:42 +0000 |
| Message-ID | <uq01cd$1ep7n$1@dont-email.me> |
| In reply to | #381967 |
On 07/02/2024 13:01, David Brown wrote:
> On 07/02/2024 09:59, Malcolm McLean wrote:
>>
>> The case for minimum scope is the same as the case for scope itself.
>> The variable is accessible where it is used and not elsewhere, which
>> makes it less likely it will be used in error, and means there are
>> fewer names to understand.
>>
>
> It makes code simpler, clearer, easier to reuse, easier to see that it
> is correct, and easier to see if there is an error. It is very much
> easier for automatic tools (static warnings) to spot issues.
>
This is all true, but only in way. Whilst it's easier to see that there
are errors in one way, because you have to look at a smaller section of
code, it's harder in others, for example because that small section is
more cluttered. From experience with automatic tools, they give too many
false warnings for correct code, and then programmers often rewrite the
code less clearly to suppress the warning.
>> However there are also strong arguments for ducntion scope.
>
> Not in my experience and in my opinion.
>
That's not a legitimate response. The correct thing to say is "you have
given a argment there but I don't think it is strong one". Unless you
are claiming to be experieenced in arguing with people over scope, and I
donlt think that is what yiu mean to say,
>> A function is a natural unit.
>
> True, but irrelevant.
>
>> Adn all the varibales used in that unit are listed together and,
>> ideally, commented.
>
> In reality, not commented. And if commented, then commented incorrectly.
>
Variable names mean something. The classic name for a variable is "x".
This usually means either "the value that is given" or "the horizontal
value on an axis". But it can of ciurse mean "a value which we shall
calculate that doesn;t have an abvous other name", or even maybe, "the
nunber of times the letter "x" appears in the data. It depnds on
context. However the imprtant thing is that x should always mean the
same thing within the same function. So if it's a real on the horizontal
axis of a graph, we don't also use "x" for an integer we need to
factorise, in the same function. And if it isn't clear, (x is such a
strong convention that it seldom needs a comment), we need to say how
"x" is being used and what it means in that function. Function and not
block is the unit for that.
>
> Rather than trying to write vague comments to say what something is how
> it is used, it is better to write the code so that it is clear. Giving
> variables appropriate names is part of that. For the most part, I'd say
> if you think a variable needs a comment, your code is not clear enough
> or has poor structure.
>
I prefer short variable names because it is the mathematical convention
and because it makes complex expressions easier to read. But of course
then they can't be as meaningful. So to use a short name and add a
comment is reasonable way to achieve both goals.
>
> It is /massively/ simpler and clearer to write :
>
> for (int i = 0; i < 10; i++) { ... }
>
> than
>
> int i;
>
> /* ... big gap ... */
>
> for (i = 0; i < 10; i++) { ... }
>
> It doesn't help if you have "int loop_index;" or add a comment to the
> variable definition. Putting it at the loop itself is better.
>
This pattern is quite common in C.
for (i = 0; i < N; i++)
if (x[i] == 0)
break;
if (i == N) /* no zero found */
So you can't scope the counter to the loop.
i is always a loop index. Usually I just out one at the top so it is
hanging around and handy.
>
>
> I hate having to work with code written in long-outdated "declare
> everything at the top of the function" style. I realise style and
> experience are subjective, but I have not seen any code or any argument
> that has led me to doubt my preferences.
>
I quite often work with code which was written a very long time ago and
is still useful. That's one of the big strengths of C. It is subjective
however. It's not about making life easier for the compiler. It's about
what is clearer. That depends on the way people read code and think
about it, and that won't necessarily be the same for every person.
--
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 16:17 +0100 |
| Message-ID | <uq06v3$1fohr$1@dont-email.me> |
| In reply to | #381970 |
On 07/02/2024 14:42, Malcolm McLean wrote:
> On 07/02/2024 13:01, David Brown wrote:
>> On 07/02/2024 09:59, Malcolm McLean wrote:
>>>
>>> The case for minimum scope is the same as the case for scope itself.
>>> The variable is accessible where it is used and not elsewhere, which
>>> makes it less likely it will be used in error, and means there are
>>> fewer names to understand.
>>>
>>
>> It makes code simpler, clearer, easier to reuse, easier to see that it
>> is correct, and easier to see if there is an error. It is very much
>> easier for automatic tools (static warnings) to spot issues.
>>
> This is all true, but only in way. Whilst it's easier to see that there
> are errors in one way, because you have to look at a smaller section of
> code, it's harder in others, for example because that small section is
> more cluttered.
No, it is not - unless you write it very badly.
> From experience with automatic tools, they give too many
> false warnings for correct code, and then programmers often rewrite the
> code less clearly to suppress the warning.
You need to use good tools, and you need to know how to use them. It is
unfortunately the case that some people are poor programmers - they
write bad code, and they don't know how to get the best from their tools.
But is that an excuse for /you/ not to write the best code you can, in
the clearest and most maintainable manner, using the best practical
tools to help catch any errors?
>>> However there are also strong arguments for ducntion scope.
>>
>> Not in my experience and in my opinion.
>>
> That's not a legitimate response. The correct thing to say is "you have
> given a argment there but I don't think it is strong one".
My experience and opinion is that there are no strong arguments in
favour of "all declarations at the top of the function." That is what I
meant to say, and it is a legitimate response.
> Unless you
> are claiming to be experieenced in arguing with people over scope, and I
> donlt think that is what yiu mean to say,
>
/Please/ get a spell checker! Or type more carefully.
>>> A function is a natural unit.
>>
>> True, but irrelevant.
>>
>>> Adn all the varibales used in that unit are listed together and,
>>> ideally, commented.
>>
>> In reality, not commented. And if commented, then commented incorrectly.
>>
> Variable names mean something. The classic name for a variable is "x".
> This usually means either "the value that is given" or "the horizontal
> value on an axis". But it can of ciurse mean "a value which we shall
> calculate that doesn;t have an abvous other name", or even maybe, "the
> nunber of times the letter "x" appears in the data. It depnds on
> context. However the imprtant thing is that x should always mean the
> same thing within the same function.
No.
The important thing is that the purpose of a variable should be clear
within its scope and use. It is completely artificial to suggest it
should be consistent within a function - you could equally well say it
should be consistent within a file, or within a block.
> >
>> Rather than trying to write vague comments to say what something is
>> how it is used, it is better to write the code so that it is clear.
>> Giving variables appropriate names is part of that. For the most
>> part, I'd say if you think a variable needs a comment, your code is
>> not clear enough or has poor structure.
>>
> I prefer short variable names because it is the mathematical convention
> and because it makes complex expressions easier to read. But of course
> then they can't be as meaningful. So to use a short name and add a
> comment is reasonable way to achieve both goals.
Or, far better, use small scopes and then variables can have short names
without comments and be clear.
>>
>> It is /massively/ simpler and clearer to write :
>>
>> for (int i = 0; i < 10; i++) { ... }
>>
>> than
>>
>> int i;
>>
>> /* ... big gap ... */
>>
>> for (i = 0; i < 10; i++) { ... }
>>
>> It doesn't help if you have "int loop_index;" or add a comment to the
>> variable definition. Putting it at the loop itself is better.
>>
> This pattern is quite common in C.
>
> for (i = 0; i < N; i++)
> if (x[i] == 0)
> break;
> if (i == N) /* no zero found */
>
If you need to do that, you need a bigger scope for "i". But it would
be insane to use worse code style for 95% of your loops for the 5% (or
less) that need this.
> So you can't scope the counter to the loop.
>
> i is always a loop index. Usually I just out one at the top so it is
> hanging around and handy.
Laziness is not good.
> >
>>
>> I hate having to work with code written in long-outdated "declare
>> everything at the top of the function" style. I realise style and
>> experience are subjective, but I have not seen any code or any
>> argument that has led me to doubt my preferences.
>>
> I quite often work with code which was written a very long time ago and
> is still useful. That's one of the big strengths of C. It is subjective
> however. It's not about making life easier for the compiler. It's about
> what is clearer. That depends on the way people read code and think
> about it, and that won't necessarily be the same for every person.
>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-07 21:34 +0000 |
| Message-ID | <uq0t1b$1jgqa$5@dont-email.me> |
| In reply to | #381967 |
On Wed, 7 Feb 2024 14:01:27 +0100, David Brown wrote:
> It makes code simpler, clearer, easier to reuse, easier to see that it
> is correct, and easier to see if there is an error. It is very much
> easier for automatic tools (static warnings) to spot issues.
Here’s an example of how granular I like to make my scopes:
struct pollfd topoll[MAX_WATCHES + 1];
int total_timeout = -1; /* to begin with */
for (int i = 0; i < nr_watches; ++i)
{
DBusWatch * const watch = watches[i];
struct pollfd * const entry = topoll + i;
entry->fd = dbus_watch_get_unix_fd(watch);
entry->events = 0; /* to begin with */
if (dbus_watch_get_enabled(watch))
{
const int flags = dbus_watch_get_flags(watch);
if ((flags & DBUS_WATCH_READABLE) != 0)
{
entry->events |= POLLIN | POLLERR;
} /*if*/
if ((flags & DBUS_WATCH_WRITABLE) != 0)
{
entry->events |= POLLOUT | POLLERR;
} /*if*/
} /*if*/
} /*for*/
{
struct pollfd * const entry = topoll + nr_watches;
entry->fd = notify_receive_pipe;
entry->events = POLLIN;
}
for (int i = 0; i < nr_timeouts; ++i)
{
DBusTimeout * const timeout = timeouts[i];
if (dbus_timeout_get_enabled(timeout))
{
const int interval = dbus_timeout_get_interval(timeout);
if (total_timeout < 0 or total_timeout > interval)
{
total_timeout = interval;
} /*if*/
} /*if*/
} /*for*/
const long timeout_start = get_milliseconds();
bool got_io;
{
const int sts = poll(topoll, nr_watches + 1, total_timeout);
fprintf(stderr, "poll returned status %d\n", sts);
if (sts < 0)
{
perror("doing poll");
die();
} /*if*/
got_io = sts > 0;
}
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-07 16:21 +0000 |
| Message-ID | <96OwN.308692$7sbb.3759@fx16.iad> |
| In reply to | #381952 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On 07/02/2024 07:54, David Brown wrote: >> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote: >>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote: >>> >>>> They reuse "temp" variables instead of making new ones. >>> >>> I like to limit the scope of my temporary variables. In C, this is as >>> easy >>> as sticking a pair of braces around a few statements. >> >> Generally, you want to have the minimum practical scope for your local >> variables. It's rare that you need to add braces just to make a scope >> for a variable - usually you have enough braces in loops or conditionals >> - but it happens. >> >The two common patterns are to give each variable the minimum scope, or >to decare all variables at the start of the function and give them all >function scope. > >The case for minimum scope is the same as the case for scope itself. The >variable is accessible where it is used and not elsewhere, which makes >it less likely it will be used in error, and means there are fewer names >to understand. And it means the compiler can re-use the local storage (if any was allocated) for subsequent minimal scope variables (or even same scope if the compiler knows the original variable is never used again), so long as the address of the variable isn't taken.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-02-08 13:26 +0200 |
| Message-ID | <20240208132657.00004a9a@yahoo.com> |
| In reply to | #381996 |
On Wed, 07 Feb 2024 16:21:25 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >On 07/02/2024 07:54, David Brown wrote: > >> On 07/02/2024 00:23, Lawrence D'Oliveiro wrote: > >>> On Tue, 6 Feb 2024 09:44:20 +0100, David Brown wrote: > >>> > >>>> They reuse "temp" variables instead of making new ones. > >>> > >>> I like to limit the scope of my temporary variables. In C, this > >>> is as easy > >>> as sticking a pair of braces around a few statements. > >> > >> Generally, you want to have the minimum practical scope for your > >> local variables. It's rare that you need to add braces just to > >> make a scope for a variable - usually you have enough braces in > >> loops or conditionals > >> - but it happens. > >> > >The two common patterns are to give each variable the minimum scope, > >or to decare all variables at the start of the function and give > >them all function scope. > > > >The case for minimum scope is the same as the case for scope itself. > >The variable is accessible where it is used and not elsewhere, which > >makes it less likely it will be used in error, and means there are > >fewer names to understand. > > And it means the compiler can re-use the local storage (if any was > allocated) for subsequent minimal scope variables (or even same scope > if the compiler knows the original variable is never used again), > so long as the address of the variable isn't taken. That's completely orthogonal to the scope of declaration, at least as long as compiler is not completely idiotic.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-07 10:04 +0000 |
| Message-ID | <874jekvbdh.fsf@bsb.me.uk> |
| In reply to | #381948 |
David Brown <david.brown@hesbynett.no> writes: > Making some "temp" variables and re-using them was also common for some > people in idiomatic C90 code, where all your variables are declared at the > top of the function. The comma suggests (I think) that it is C90 that mandates that all one's variables are declared at the top of the function. But that's not the case (as I am sure you know). The other reading -- that this is done in idiomatic C90 code -- is also something that I'd question, but not something that I'd want to argue. I comment just because there seems to be a myth that "old C" had to have all the declarations at the top of a function. That was true once, but so long ago as to be irrelevant. Even K&R C allowed declarations at the top of a compound statement. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web