Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #150711 > unrolled thread
| Started by | Geoff <geoff@invalid.invalid> |
|---|---|
| First post | 2020-03-21 19:51 -0700 |
| Last post | 2020-03-27 08:02 -0700 |
| Articles | 20 on this page of 111 — 20 participants |
Back to article view | Back to comp.lang.c
Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-21 19:51 -0700
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 03:31 +0000
Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-21 23:17 -0700
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 12:00 +0000
Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 08:57 -0700
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 16:20 +0000
Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 14:02 -0700
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 21:26 +0000
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-22 10:25 +0100
Re: Comma operator in for() statements Richard Damon <Richard@Damon-Family.org> - 2020-03-22 08:27 -0400
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 16:31 +0000
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 00:33 -0400
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 12:23 +0000
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 05:47 -0700
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 14:17 +0000
Re: Comma operator in for() statements felix@palmen-it.de (Felix Palmen) - 2020-03-22 15:55 +0100
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 15:01 +0000
Re: Comma operator in for() statements felix@palmen-it.de (Felix Palmen) - 2020-03-22 16:05 +0100
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 16:46 +0000
Re: Comma operator in for() statements felix@palmen-it.de (Felix Palmen) - 2020-03-22 18:14 +0100
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 11:42 -0700
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-22 22:03 +0000
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 23:51 -0700
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-23 14:37 +0000
Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 08:41 -0700
Re: Comma operator in for() statements Guillaume <message@bottle.org> - 2020-03-23 16:53 +0100
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-23 16:31 +0000
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-23 16:48 +0000
Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 09:53 -0700
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-23 18:59 +0100
Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 11:23 -0700
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-23 19:51 +0000
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-23 14:28 -0700
Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 13:09 -0700
Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 13:20 -0700
Re: Comma operator in for() statements scott@slp53.sl.home (Scott Lurndal) - 2020-03-23 20:26 +0000
Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 13:55 -0700
Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 15:43 -0700
Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 16:27 -0700
Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 17:13 -0700
Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 21:11 -0700
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-24 00:19 +0000
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-24 10:30 +0100
Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-24 03:07 -0700
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-24 11:37 +0100
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-24 11:18 +0000
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-24 13:23 +0100
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-24 14:53 +0000
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-25 10:35 +0100
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-25 11:12 +0000
Re: Comma operator in for() statements Ike Naar <ike@sdf.lonestar.org> - 2020-03-26 19:21 +0000
Re: Comma operator in for() statements luser droog <luser.droog@gmail.com> - 2020-03-24 21:22 -0700
Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 06:46 -0700
Re: Comma operator in for() statements luser droog <luser.droog@gmail.com> - 2020-03-28 01:01 -0700
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-28 11:26 +0000
Re: Comma operator in for() statements luser droog <luser.droog@gmail.com> - 2020-03-28 14:22 -0700
Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 08:12 -0700
Re: Comma operator in for() statements luser droog <luser.droog@gmail.com> - 2020-04-02 12:21 -0700
Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 19:43 -0700
Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-24 12:56 -0700
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-24 23:44 +0000
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-23 17:10 -0700
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-24 10:17 +0100
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-23 18:13 +0000
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-23 09:32 -0700
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-23 19:06 +0100
Re: Comma operator in for() statements Richard Damon <Richard@Damon-Family.org> - 2020-03-23 13:23 -0400
Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 10:33 -0700
Re: Comma operator in for() statements Guillaume <message@bottle.org> - 2020-03-23 18:34 +0100
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-23 18:18 +0000
Re: Comma operator in for() statements Ike Naar <ike@sdf.lonestar.org> - 2020-03-23 22:29 +0000
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-23 23:13 +0000
Re: Comma operator in for() statements richard@cogsci.ed.ac.uk (Richard Tobin) - 2020-03-22 15:17 +0000
Re: Comma operator in for() statements nobody@example.org (Scott) - 2020-03-22 16:16 +0000
Re: Comma operator in for() statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-23 07:22 -0700
Re: Comma operator in for() statements Guillaume <message@bottle.org> - 2020-03-25 15:10 +0100
Re: Comma operator in for() statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-25 15:18 +0000
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 16:27 +0000
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 15:07 -0400
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 11:33 -0700
Re: Comma operator in for() statements Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-03-24 20:25 +0300
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-24 23:25 +0000
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-25 01:55 +0000
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-25 11:01 +0000
Re: Comma operator in for() statements Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-03-25 14:59 +0300
Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 07:42 -0700
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-27 14:51 +0000
Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 19:20 -0700
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-24 20:01 -0400
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-25 02:05 +0000
Re: Comma operator in for() statements Bart <bc@freeuk.com> - 2020-03-25 15:13 +0000
Re: Comma operator in for() statements Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-03-25 15:05 +0300
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-25 10:04 -0400
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-22 14:49 +0100
Re: Comma operator in for() statements Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-03-22 09:24 -0600
Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 14:51 -0700
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 20:13 -0400
Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-23 12:16 -0700
Re: Comma operator in for() statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-23 13:16 -0700
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-23 17:16 -0400
Re: Comma operator in for() statements scott@slp53.sl.home (Scott Lurndal) - 2020-03-23 22:40 +0000
Re: Comma operator in for() statements Guillaume <message@bottle.org> - 2020-03-22 17:31 +0100
Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 12:28 -0700
Re: Comma operator in for() statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-03-22 15:35 -0400
Re: Comma operator in for() statements Geoff <geoff@invalid.invalid> - 2020-03-22 13:43 -0700
Re: Comma operator in for() statements Les Cargill <lcargill99@comcast.com> - 2020-03-22 13:50 -0500
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 19:25 +0000
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-22 21:52 +0100
Re: Comma operator in for() statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-03-22 21:15 +0000
Re: Comma operator in for() statements David Brown <david.brown@hesbynett.no> - 2020-03-23 09:17 +0100
Re: Comma operator in for() statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 08:02 -0700
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-03-23 21:11 -0700 |
| Message-ID | <87sghypf2e.fsf@nosuchdomain.example.com> |
| In reply to | #150789 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> The ship has sailed, and now you'd have to support old style for loops
> for a very long time, for backwards compatibility.
Probably pretty much forever, or at least as long as the language can
reasonably be called "C". Removing C's existing for loop is just not a
possibility. I was talking only about the possibility of adding a more
restricted loop construct. C++'s range-based for statement might be an
inspiration (of course C still fully supports the existing for statement
it inherited from C).
> But if we were
> designing C from scratch, we could reasonably have a less flexible
> for loop. If people want complex conditions rather than simple iteration,
> usually over an array, they can use "while".
I disagree. The flexibility of C's existing for loop is an advantage.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-03-24 00:19 +0000 |
| Message-ID | <umceG.1220$om7.531@fx27.ams1> |
| In reply to | #150787 |
On 23/03/2020 23:27, Keith Thompson wrote:
>
> Bart has objected here to having to write "i" three times in
>
> for (i = 0; i < N; i++)
>
> He does have a bit of a point, since writing "j" rather than "i" is a
> plausible error that a compiler is unlikely to catch.
>
> That could be addressed with a macro:
>
> #define BARTFOR(var, lower, upper) for (var = (first), var < (last); var++)
> ...
> BARTFOR(i, 0, N)
>
> I wouldn't use it myself, but I probably would if it were a standard
> language feature.
When I was writing my only substantial (20Kloc) program in actual C**, I
used these macros:
#define TO(i,x) for (i=x; i; --i)
#define FOR(i,a,b) for (i=a; i<=b; ++i)
#define FORD(i,a,b) for (i=a; i>=b; --i)
(** Well, actual C is not quite right, as I used a thin syntax wrapper
just thick enough to require a translation to real C. Example:
https://github.com/sal55/langs/blob/master/dxfns.cc
which looks like a funny hybrid between C and my syntax. The translator
turned the .cc file into a .c file, and a .cl file containing function
prototypes.
I later decided to use a proper language.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-03-24 10:30 +0100 |
| Message-ID | <r5ck0i$e8$1@dont-email.me> |
| In reply to | #150787 |
On 24/03/2020 00:27, Keith Thompson wrote:
>
> If somebody came up with a more restrictive kind of loop that covered
> most cases and was less error-prone, I might not object to adding it to
> a future version of the language -- *in addition to* C's existing for
> loop, not replacing it.
>
If I were to choose something to add to the for-loop syntax, I'd like:
for (const int i = 0; i < N; i++) {
...
}
to have the same meaning as:
for (const int i = 0; i < N; i++) {
const int i_ = i;
const int i = i_;
...
}
The first version is currently a constraint violation since it tries to
increment a variable that is declared "const". I'm not sure if that
means the syntax here could be re-used to get the effect I am looking
for. If not, I suppose an alternative syntax could be found.
The idea here is to lock the loop variable inside the loop, so that it
can only be changed in the iterator part of the for-statement.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-03-24 03:07 -0700 |
| Message-ID | <75d21016-17a7-479b-913b-ed96ba471ed6@googlegroups.com> |
| In reply to | #150793 |
On Tuesday, 24 March 2020 09:31:08 UTC, David Brown wrote:
> On 24/03/2020 00:27, Keith Thompson wrote:
>
> >
> > If somebody came up with a more restrictive kind of loop that covered
> > most cases and was less error-prone, I might not object to adding it to
> > a future version of the language -- *in addition to* C's existing for
> > loop, not replacing it.
> >
>
> If I were to choose something to add to the for-loop syntax, I'd like:
>
> for (const int i = 0; i < N; i++) {
> ...
> }
>
> to have the same meaning as:
>
> for (const int i = 0; i < N; i++) {
> const int i_ = i;
> const int i = i_;
> ...
> }
>
>
> The first version is currently a constraint violation since it tries to
> increment a variable that is declared "const". I'm not sure if that
> means the syntax here could be re-used to get the effect I am looking
> for. If not, I suppose an alternative syntax could be found.
>
> The idea here is to lock the loop variable inside the loop, so that it
> can only be changed in the iterator part of the for-statement.
>
You also need to prevent the loop body messing with N. It's unlikely
you can const qualify N in the outer scope, since it will be calculated
there.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-03-24 11:37 +0100 |
| Message-ID | <r5cnt2$qo5$2@dont-email.me> |
| In reply to | #150794 |
On 24/03/2020 11:07, Malcolm McLean wrote:
> On Tuesday, 24 March 2020 09:31:08 UTC, David Brown wrote:
>> On 24/03/2020 00:27, Keith Thompson wrote:
>>
>>>
>>> If somebody came up with a more restrictive kind of loop that covered
>>> most cases and was less error-prone, I might not object to adding it to
>>> a future version of the language -- *in addition to* C's existing for
>>> loop, not replacing it.
>>>
>>
>> If I were to choose something to add to the for-loop syntax, I'd like:
>>
>> for (const int i = 0; i < N; i++) {
>> ...
>> }
>>
>> to have the same meaning as:
>>
>> for (const int i = 0; i < N; i++) {
>> const int i_ = i;
>> const int i = i_;
>> ...
>> }
>>
>>
>> The first version is currently a constraint violation since it tries to
>> increment a variable that is declared "const". I'm not sure if that
>> means the syntax here could be re-used to get the effect I am looking
>> for. If not, I suppose an alternative syntax could be found.
>>
>> The idea here is to lock the loop variable inside the loop, so that it
>> can only be changed in the iterator part of the for-statement.
>>
> You also need to prevent the loop body messing with N. It's unlikely
> you can const qualify N in the outer scope, since it will be calculated
> there.
>
It is highly likely that you can const qualify N, precisely because it
is calculated outside the loop (or it is fixed in the first place):
const int N = calc_no_of_whatsits();
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-03-24 11:18 +0000 |
| Message-ID | <87y2rq0zmy.fsf@bsb.me.uk> |
| In reply to | #150793 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/03/2020 00:27, Keith Thompson wrote:
>
>>
>> If somebody came up with a more restrictive kind of loop that covered
>> most cases and was less error-prone, I might not object to adding it to
>> a future version of the language -- *in addition to* C's existing for
>> loop, not replacing it.
>>
>
> If I were to choose something to add to the for-loop syntax, I'd like:
>
> for (const int i = 0; i < N; i++) {
> ...
> }
>
> to have the same meaning as:
>
> for (const int i = 0; i < N; i++) {
> const int i_ = i;
> const int i = i_;
> ...
> }
You accidentally left the first const in there. This is a case where I
like multiple declarators in one declaration because of the close
relationship between them:
for (int i = 0; i < N; i++) {
const int i_ = i, i = i_;
...
}
I note that if C had "syntax" macros like Lisp, you could define such
constructs in the language itself.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-03-24 13:23 +0100 |
| Message-ID | <r5cu3i$7ee$1@dont-email.me> |
| In reply to | #150796 |
On 24/03/2020 12:18, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 24/03/2020 00:27, Keith Thompson wrote:
>>
>>>
>>> If somebody came up with a more restrictive kind of loop that covered
>>> most cases and was less error-prone, I might not object to adding it to
>>> a future version of the language -- *in addition to* C's existing for
>>> loop, not replacing it.
>>>
>>
>> If I were to choose something to add to the for-loop syntax, I'd like:
>>
>> for (const int i = 0; i < N; i++) {
>> ...
>> }
>>
>> to have the same meaning as:
>>
>> for (const int i = 0; i < N; i++) {
>> const int i_ = i;
>> const int i = i_;
>> ...
>> }
>
> You accidentally left the first const in there.
Just checking you are awake! :-)
> This is a case where I
> like multiple declarators in one declaration because of the close
> relationship between them:
>
> for (int i = 0; i < N; i++) {
> const int i_ = i, i = i_;
> ...
> }
One line is arguably better than two lines, but it would be better still
if it could be baked into the for loop somehow.
>
> I note that if C had "syntax" macros like Lisp, you could define such
> constructs in the language itself.
>
#define FIXATE(v) typeof(v) FIX##__LINE__ = (v); \
typeof(v) v = FIX##__LINE__
Now all we need is gcc's useful "typeof" extension added to the C standards!
This would be even better if another enhancement were made in C, one
that I think could be useful in several circumstances. I'd like to be
able to re-define a variable within the same block, so that :
{
int x = 123;
...
int x = 234;
...
}
would be valid, and treated as:
{
int x = 123;
...
{
int x = 234;
...
}
}
That would allow you to "FIXATE" a variable declared earlier in the same
block.
And for a final enhancement, I'd suggest that if a variable definition
refers to its own identifier in its initialiser, and that identifier is
in scope from before the definition, then the earlier identifier's value
is used.
Currently, if you write:
int x = 123;
{
const int x = x;
}
then the second "x" has an unspecified value because the initialiser
uses the newly defined "x" rather than the existing one. I'd like the
specified value here be the value of the existing x.
(I'm fairly certain that there would be complications in all these
suggestions - I haven't made any study of more advanced cases.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-03-24 14:53 +0000 |
| Message-ID | <87mu85249a.fsf@bsb.me.uk> |
| In reply to | #150797 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/03/2020 12:18, Ben Bacarisse wrote:
<cut>
>> for (int i = 0; i < N; i++) {
>> const int i_ = i, i = i_;
>> ...
>> }
<cut>
>> I note that if C had "syntax" macros like Lisp, you could define such
>> constructs in the language itself.
>>
>
> #define FIXATE(v) typeof(v) FIX##__LINE__ = (v); \
> typeof(v) v = FIX##__LINE__
>
> Now all we need is gcc's useful "typeof" extension added to the C
> standards!
You maybe happy with that, but it's not what I meant. Hardly worth
pursuing because C will stick with textual rather than syntactic
macros.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-03-25 10:35 +0100 |
| Message-ID | <r5f8l1$s1a$1@dont-email.me> |
| In reply to | #150801 |
On 24/03/2020 15:53, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 24/03/2020 12:18, Ben Bacarisse wrote:
> <cut>
>>> for (int i = 0; i < N; i++) {
>>> const int i_ = i, i = i_;
>>> ...
>>> }
> <cut>
>>> I note that if C had "syntax" macros like Lisp, you could define such
>>> constructs in the language itself.
>>>
>>
>> #define FIXATE(v) typeof(v) FIX##__LINE__ = (v); \
>> typeof(v) v = FIX##__LINE__
>>
>> Now all we need is gcc's useful "typeof" extension added to the C
>> standards!
>
> You maybe happy with that, but it's not what I meant. Hardly worth
> pursuing because C will stick with textual rather than syntactic
> macros.
>
My understanding of LISP is quite minimal, but I do appreciate at least
that its macros are part of the language rather than textual. You
perhaps mean that with syntax macros, it would be possible to make a
"forconst" loop statement that is just like "for" except that iteration
variables would be "const" inside the loop. If so, then I agree that
that would be a nice concept - and I agree it will not happen in C. (I
also think it would open the risk of a world of chaos of personalised C
programming where code becomes unreadable to others.)
I guess the nearest we will see is if metaclasses make it into C++. But
that is getting off-topic.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-03-25 11:12 +0000 |
| Message-ID | <87r1xgzo0j.fsf@bsb.me.uk> |
| In reply to | #150821 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/03/2020 15:53, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 24/03/2020 12:18, Ben Bacarisse wrote:
>> <cut>
>>>> for (int i = 0; i < N; i++) {
>>>> const int i_ = i, i = i_;
>>>> ...
>>>> }
>> <cut>
>>>> I note that if C had "syntax" macros like Lisp, you could define such
>>>> constructs in the language itself.
>>>>
>>>
>>> #define FIXATE(v) typeof(v) FIX##__LINE__ = (v); \
>>> typeof(v) v = FIX##__LINE__
>>>
>>> Now all we need is gcc's useful "typeof" extension added to the C
>>> standards!
>>
>> You maybe happy with that, but it's not what I meant. Hardly worth
>> pursuing because C will stick with textual rather than syntactic
>> macros.
>>
>
> My understanding of LISP is quite minimal, but I do appreciate at
> least that its macros are part of the language rather than textual.
> You perhaps mean that with syntax macros, it would be possible to make
> a "forconst" loop statement that is just like "for" except that
> iteration variables would be "const" inside the loop.
Yup.
> If so, then I
> agree that that would be a nice concept - and I agree it will not
> happen in C. (I also think it would open the risk of a world of chaos
> of personalised C programming where code becomes unreadable to
> others.)
... which C's macros avoid of course!
Every abstraction hides information and allows code to work at, in some
very vague sense, a higher level. They all have the potential to make
the code either easier of harder to follow.
By the way, "syntax macros" was not a good term. I should probably have
said something like "syntax aware macros" but even that's a bit woolly.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2020-03-26 19:21 +0000 |
| Message-ID | <slrn3ocor7q06c.8h8.ike@sdf.lonestar.org> |
| In reply to | #150797 |
On 2020-03-24, David Brown <david.brown@hesbynett.no> wrote:
> [...] I'd like to be
> able to re-define a variable within the same block, so that :
>
> {
> int x = 123;
> ...
> int x = 234;
> ...
> }
>
> would be valid, and treated as:
>
> {
> int x = 123;
> ...
> {
> int x = 234;
> ...
> }
> }
>
> That would allow you to "FIXATE" a variable declared earlier in the same
> block.
Using the same name for different things makes code harder to comprehend.
It may also introduce subtle errors when the code is refactored.
Imagine
int x = 123; /* definition x.1 */
foo(x); /* assumes x means x.1 */
/* ... long stretch of code not using x ... */
int x = 234; /* definition x.2 */
bar(x); /* assumes x means x.2 */
/* ... long stretch of code not using x ... */
zap(x); /* assumes x means x.2 */
Now suppose bar(x) is no longer needed, so the code is refactored
and the definition of x.2 and the bar(x) call are removed, not
realizing there's the zap(x) call futher down the line:
int x = 123; /* definition x.1 */
foo(x); /* assumes x means x.1 */
/* ... long stretch of code not using x ... */
/* ... long stretch of code not using x ... */
zap(x); /* assumes x means x.2, but now it means x.1; Whoops! */
> And for a final enhancement, I'd suggest that if a variable definition
> refers to its own identifier in its initialiser, and that identifier is
> in scope from before the definition, then the earlier identifier's value
> is used.
>
> Currently, if you write:
>
> int x = 123;
> {
> const int x = x;
> }
>
> then the second "x" has an unspecified value because the initialiser
> uses the newly defined "x" rather than the existing one. I'd like the
> specified value here be the value of the existing x.
>
> (I'm fairly certain that there would be complications in all these
> suggestions - I haven't made any study of more advanced cases.)
Again, using the same name for different things makes code harder to comprehend,
and, in my opinion, should be avoided when possible.
I think gcc even has a warning for this kind of thing (-Wshadow).
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2020-03-24 21:22 -0700 |
| Message-ID | <27ca29d7-392f-443a-be90-097ed390a674@googlegroups.com> |
| In reply to | #150796 |
On Tuesday, March 24, 2020 at 6:18:53 AM UTC-5, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
> > On 24/03/2020 00:27, Keith Thompson wrote:
> >
> >>
> >> If somebody came up with a more restrictive kind of loop that covered
> >> most cases and was less error-prone, I might not object to adding it to
> >> a future version of the language -- *in addition to* C's existing for
> >> loop, not replacing it.
> >>
> >
> > If I were to choose something to add to the for-loop syntax, I'd like:
> >
> > for (const int i = 0; i < N; i++) {
> > ...
> > }
> >
> > to have the same meaning as:
> >
> > for (const int i = 0; i < N; i++) {
> > const int i_ = i;
> > const int i = i_;
> > ...
> > }
>
> You accidentally left the first const in there. This is a case where I
> like multiple declarators in one declaration because of the close
> relationship between them:
>
> for (int i = 0; i < N; i++) {
> const int i_ = i, i = i_;
> ...
> }
>
> I note that if C had "syntax" macros like Lisp, you could define such
> constructs in the language itself.
>
I've tried to shake the habit of seeing macros everywhere,
but this is getting to the length where a macro might be an
appropriate way to use this idiom.
#define FOR_UP(IDX, INI, LIM, BODY) \
for( int IDX ## __LINE__ = (INI); \
IDX ## __LINE__ < (LIM); \
++ IDX ## __LINE__ ){ \
int const IDX = IDX ## __LINE__; \
BODY; \
}
//...
int a[] = { 2, 3, 4 };
int sum = 0;
FOR_UP( i, 0, sizeof a/sizeof*a, sum += a[i] )
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-03-27 06:46 -0700 |
| Message-ID | <864ku9ap29.fsf@linuxsc.com> |
| In reply to | #150820 |
luser droog <luser.droog@gmail.com> writes:
> [how to make for() variables be const]
>
> I've tried to shake the habit of seeing macros everywhere,
> but this is getting to the length where a macro might be an
> appropriate way to use this idiom.
>
> #define FOR_UP(IDX, INI, LIM, BODY) \
> for( int IDX ## __LINE__ = (INI); \
> IDX ## __LINE__ < (LIM); \
> ++ IDX ## __LINE__ ){ \
> int const IDX = IDX ## __LINE__; \
> BODY; \
> }
Maybe so but this macro isn't it.
(1) Type of iteration variable should be a parameter,
not fixed.
(2) The usage '## __LINE__' doesn't work.
(3) The "test" and "increment" should both be more
general.
(4) Perhaps most important, the loop body should
not be a parameter. Ick and double ick.
Challenge: write a macro definition that addresses each
of the above concerns. Specifically with regard to point
(4), the macro expansion should act like a 'for(...)'
prefix, so the loop body statement comes after the macro
call, eg,
P_FOR( int, i, 0, < 10, ++ ){
sum += a[i];
}
(Yes there are hints there for some of the other points.)
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2020-03-28 01:01 -0700 |
| Message-ID | <1e31345c-84a7-4dcd-b0a4-8024bf91acbf@googlegroups.com> |
| In reply to | #150856 |
On Friday, March 27, 2020 at 8:46:17 AM UTC-5, Tim Rentsch wrote:
> luser droog <luser.droog@gmail.com> writes:
>
> > [how to make for() variables be const]
> >
> > I've tried to shake the habit of seeing macros everywhere,
> > but this is getting to the length where a macro might be an
> > appropriate way to use this idiom.
> >
> > #define FOR_UP(IDX, INI, LIM, BODY) \
> > for( int IDX ## __LINE__ = (INI); \
> > IDX ## __LINE__ < (LIM); \
> > ++ IDX ## __LINE__ ){ \
> > int const IDX = IDX ## __LINE__; \
> > BODY; \
> > }
>
> Maybe so but this macro isn't it.
>
> (1) Type of iteration variable should be a parameter,
> not fixed.
>
> (2) The usage '## __LINE__' doesn't work.
>
> (3) The "test" and "increment" should both be more
> general.
>
> (4) Perhaps most important, the loop body should
> not be a parameter. Ick and double ick.
>
> Challenge: write a macro definition that addresses each
> of the above concerns. Specifically with regard to point
> (4), the macro expansion should act like a 'for(...)'
> prefix, so the loop body statement comes after the macro
> call, eg,
>
> P_FOR( int, i, 0, < 10, ++ ){
> sum += a[i];
> }
>
> (Yes there are hints there for some of the other points.)
You are right of course. I tried a number of variations to
try to paste the line number but nothing worked. Handling the
basic parts is relatively straightforward but for the issue
of providing the index as a const-qualified variable.
So here's what I came up with that gcc accepts.
#include <stdio.h>
#define VALUE(X) X
#define PASTE(X,Y) X ## Y
#define XPASTE(X,y) PASTE(VALUE(X),VALUE(Y))
//#define UNIQUE(X) PASTE(X,VALUE(__LINE__))
#define UNIQUE(X) X ## _ /*dam torpedoes*/
#define P_FOR( TYPE, IDX, INI, TEST, INC ) \
for( TYPE UNIQUE(IDX) = (INI); UNIQUE(IDX) TEST; UNIQUE(IDX) INC ) \
for( TYPE once = 1; once; ) \
for( TYPE const IDX = UNIQUE(IDX); once; once = 0 )
int main( void ){
int a[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int sum = 0;
P_FOR( int, i, 0, < 10, ++ ){
sum += a[i];
}
printf("%d\n", sum );
}
I don't understand why pasting the line number is so difficult.
Probably my mental model of the preprocessor is not detailed enough.
$ cpp -P mac.c # with include commented out
int main( void ){
int a[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int sum = 0;
for( int i_ = (0); i_ < 10; i_ ++ ) for( int once = 1; once; ) for( int const i = i_; once; once = 0 ){
sum += a[i];
}
printf("%d\n", sum );
}
$ make mac
cc mac.c -o mac
$ ./mac
45
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-03-28 11:26 +0000 |
| Message-ID | <87blogwwi6.fsf@bsb.me.uk> |
| In reply to | #150874 |
luser droog <luser.droog@gmail.com> writes: <cut> > I don't understand why pasting the line number is so difficult. > Probably my mental model of the preprocessor is not detailed enough. In general, if you find that ## is pasting an un-expanded macro name you will need to add another macro "call": #define UNIQUE(x) UNIQUE_(x, __LINE__) #define UNIQUE_(x, line) PASTE(x, line) #define PASTE(t1, t2) t1 ## t2 int UNIQUE(i); int UNIQUE(i); -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2020-03-28 14:22 -0700 |
| Message-ID | <3d13c9c6-5788-4f7b-ae9a-10f36aa07a19@googlegroups.com> |
| In reply to | #150878 |
On Saturday, March 28, 2020 at 6:26:49 AM UTC-5, Ben Bacarisse wrote:
> luser droog <luser.droog@gmail.com> writes:
> <cut>
> > I don't understand why pasting the line number is so difficult.
> > Probably my mental model of the preprocessor is not detailed enough.
>
> In general, if you find that ## is pasting an un-expanded macro name you
> will need to add another macro "call":
>
> #define UNIQUE(x) UNIQUE_(x, __LINE__)
> #define UNIQUE_(x, line) PASTE(x, line)
> #define PASTE(t1, t2) t1 ## t2
>
> int UNIQUE(i);
> int UNIQUE(i);
>
Thanks. Now it does the thing.
//#include <stdio.h>
#define UNIQUE(x) UNIQUE_(PASTE(x, _), __LINE__)
#define UNIQUE_(x, line) PASTE(x, line)
#define PASTE(t1, t2) t1 ## t2
#define P_FOR( TYPE, IDX, INI, TEST, INC ) \
for( TYPE UNIQUE(IDX) = (INI); UNIQUE(IDX) TEST; UNIQUE(IDX) INC ) \
for( int once = 1; once; ) \
for( TYPE const IDX = UNIQUE(IDX); once; once = 0 )
int UNIQUE(i);
int UNIQUE(i);
int main( void ){
int a[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int sum = 0;
P_FOR( int, i, 0, < 10, ++ ){
sum += a[i];
--i;
}
printf("%d\n", sum );
}
$ cpp -P mac.c
int i_12;
int i_13;
int main( void ){
int a[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int sum = 0;
for( int i_19 = (0); i_19 < 10; i_19 ++ ) for( int once = 1; once; ) for( int const i = i_19; once; once = 0 ){
sum += a[i];
--i;
}
printf("%d\n", sum );
}
$ !m
make mac
cc mac.c -o mac
mac.c: In function ‘main’:
mac.c:21:5: error: decrement of read-only variable ‘i’
21 | --i;
| ^~
mac.c:24:3: warning: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration]
24 | printf("%d\n", sum );
| ^~~~~~
mac.c:24:3: warning: incompatible implicit declaration of built-in function ‘printf’
mac.c:1:1: note: include ‘<stdio.h>’ or provide a declaration of ‘printf’
+++ |+#include <stdio.h>
1 | //#include <stdio.h>
make: *** [<builtin>: mac] Error 1
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-02 08:12 -0700 |
| Message-ID | <86wo6x6hwa.fsf@linuxsc.com> |
| In reply to | #150898 |
luser droog <luser.droog@gmail.com> writes: > On Saturday, March 28, 2020 at 6:26:49 AM UTC-5, Ben Bacarisse wrote: > >> luser droog <luser.droog@gmail.com> writes: >> <cut> >> >>> I don't understand why pasting the line number is so difficult. >>> Probably my mental model of the preprocessor is not detailed enough. >> >> In general, if you find that ## is pasting an un-expanded macro name you >> will need to add another macro "call": >> >> #define UNIQUE(x) UNIQUE_(x, __LINE__) >> #define UNIQUE_(x, line) PASTE(x, line) >> #define PASTE(t1, t2) t1 ## t2 >> >> int UNIQUE(i); >> int UNIQUE(i); > > Thanks. Now it does the thing. > > //#include <stdio.h> > > #define UNIQUE(x) UNIQUE_(PASTE(x, _), __LINE__) > #define UNIQUE_(x, line) PASTE(x, line) > #define PASTE(t1, t2) t1 ## t2 > > #define P_FOR( TYPE, IDX, INI, TEST, INC ) \ > for( TYPE UNIQUE(IDX) = (INI); UNIQUE(IDX) TEST; UNIQUE(IDX) INC ) \ > for( int once = 1; once; ) \ > for( TYPE const IDX = UNIQUE(IDX); once; once = 0 ) Good work. A few suggestions for you - * Give 'UNIQUE(IDX)' as an argument to a subsidiary macro call, so the value is determined in only one place. Besides liking the definition being more factored, I don't want to rely on __LINE__ being the same when the macro is invoked from different physical source lines. * The variable 'once' is probably better as UNIQUE( IDX ## _once ). * See if you can write a solution that uses only two for()'s instead of three.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2020-04-02 12:21 -0700 |
| Message-ID | <91a4ce3a-e744-4fd9-87c3-ca6f50d7ac89@googlegroups.com> |
| In reply to | #150956 |
On Thursday, April 2, 2020 at 10:12:47 AM UTC-5, Tim Rentsch wrote:
> luser droog <luser.droog@gmail.com> writes:
>
> > //#include <stdio.h>
> >
> > #define UNIQUE(x) UNIQUE_(PASTE(x, _), __LINE__)
> > #define UNIQUE_(x, line) PASTE(x, line)
> > #define PASTE(t1, t2) t1 ## t2
> >
> > #define P_FOR( TYPE, IDX, INI, TEST, INC ) \
> > for( TYPE UNIQUE(IDX) = (INI); UNIQUE(IDX) TEST; UNIQUE(IDX) INC ) \
> > for( int once = 1; once; ) \
> > for( TYPE const IDX = UNIQUE(IDX); once; once = 0 )
>
> Good work. A few suggestions for you -
>
> * Give 'UNIQUE(IDX)' as an argument to a subsidiary macro call, so
> the value is determined in only one place. Besides liking the
> definition being more factored, I don't want to rely on __LINE__
> being the same when the macro is invoked from different physical
> source lines.
>
> * The variable 'once' is probably better as UNIQUE( IDX ## _once ).
>
> * See if you can write a solution that uses only two for()'s
> instead of three.
It took me a good while to understand the first suggestion, but now
that I have, yes, it's so much nicer with the extra macro.
//#include <stdio.h>
#define UNIQUE(x) UNIQUE_(PASTE(x, _), __LINE__)
#define UNIQUE_(x, line) PASTE(x, line)
#define PASTE(t1, t2) t1 ## t2
#define M_FOR( type, idx, ini, test, inc, iter, once ) \
for( type iter = ini, once = 1; iter test; iter inc ) \
for( type const idx = iter; once; once = 0 )
#define P_FOR( type, idx, ini, test, inc ) \
M_FOR( type, idx, ini, test, inc, UNIQUE(idx), UNIQUE(idx ## _once ) )
int UNIQUE(i);
int UNIQUE(i);
int main( void ){
int a[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int sum = 0;
P_FOR( int, i, 0, < 10, ++ ){
sum += a[i];
//--i;
}
struct list {
int value;
struct list *next;
} *head = 0;
//P_FOR( struct list *, node, head, , =node->next ) sum += node->value;
printf("%d\n", sum );
}
$ !c
cpp -P mac.c
int i_25;
int i_26;
int main( void ){
int a[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int sum = 0;
for( int i_32 = 0, i_once_32 = 1; i_32 < 10; i_32 ++ ) for( int const i = i_32; i_once_32; i_once_32 = 0 ){
sum += a[i];
}
struct list {
int value;
struct list *next;
} *head = 0;
printf("%d\n", sum );
}
I can't see an easy way to make it work with a linked list or
other uses of a for loop. One problem is the pointerness gets
lost after the comma in the declarator, so the 'once' variable
is trying to be a struct object. The compiler said it wants
a scalar value there. Second, in the increment expression,
the iterator variable is not available by name. So there's no
way to make the "=node->next" expression.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-02 19:43 -0700 |
| Message-ID | <86wo6xnvak.fsf@linuxsc.com> |
| In reply to | #150963 |
luser droog <luser.droog@gmail.com> writes:
> On Thursday, April 2, 2020 at 10:12:47 AM UTC-5, Tim Rentsch wrote:
>
>> luser droog <luser.droog@gmail.com> writes:
>>
>>> //#include <stdio.h>
>>>
>>> #define UNIQUE(x) UNIQUE_(PASTE(x, _), __LINE__)
>>> #define UNIQUE_(x, line) PASTE(x, line)
>>> #define PASTE(t1, t2) t1 ## t2
>>>
>>> #define P_FOR( TYPE, IDX, INI, TEST, INC ) \
>>> for( TYPE UNIQUE(IDX) = (INI); UNIQUE(IDX) TEST; UNIQUE(IDX) INC ) \
>>> for( int once = 1; once; ) \
>>> for( TYPE const IDX = UNIQUE(IDX); once; once = 0 )
>>
>> Good work. A few suggestions for you -
>>
>> * Give 'UNIQUE(IDX)' as an argument to a subsidiary macro call, so
>> the value is determined in only one place. Besides liking the
>> definition being more factored, I don't want to rely on __LINE__
>> being the same when the macro is invoked from different physical
>> source lines.
>>
>> * The variable 'once' is probably better as UNIQUE( IDX ## _once ).
>>
>> * See if you can write a solution that uses only two for()'s
>> instead of three.
>
> It took me a good while to understand the first suggestion, but now
> that I have, yes, it's so much nicer with the extra macro.
>
> //#include <stdio.h>
>
> #define UNIQUE(x) UNIQUE_(PASTE(x, _), __LINE__)
> #define UNIQUE_(x, line) PASTE(x, line)
> #define PASTE(t1, t2) t1 ## t2
>
> #define M_FOR( type, idx, ini, test, inc, iter, once ) \
> for( type iter = ini, once = 1; iter test; iter inc ) \
> for( type const idx = iter; once; once = 0 )
>
> #define P_FOR( type, idx, ini, test, inc ) \
> M_FOR( type, idx, ini, test, inc, UNIQUE(idx), UNIQUE(idx ## _once ) )
This way doesn't quite work - the inner loop is run only for
the first iteration of the outer loop. You need to be a bit
more clever with the once initialization.
> [...]
> struct list {
> int value;
> struct list *next;
> } *head = 0;
>
> //P_FOR( struct list *, node, head, , =node->next ) sum += node->value;
>
> printf("%d\n", sum );
> }
> I can't see an easy way to make it work with a linked list or
> other uses of a for loop. One problem is the pointerness gets
> lost after the comma in the declarator, so the 'once' variable
> is trying to be a struct object. The compiler said it wants
> a scalar value there.
Good point. From this perspective three for() statements is
more flexible than two for() statements.
> Second, in the increment expression,
> the iterator variable is not available by name. So there's no
> way to make the "=node->next" expression.
One way would be for the argument for 'inc' be a macro name, and
have the expansion call 'inc( iter )'. A small number of
pre-defined macros would suffice to handle the common cases,
while still giving a way of covering unusual cases not yet
thought of.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-03-24 12:56 -0700 |
| Message-ID | <87o8slplwd.fsf@nosuchdomain.example.com> |
| In reply to | #150793 |
David Brown <david.brown@hesbynett.no> writes:
> On 24/03/2020 00:27, Keith Thompson wrote:
>> If somebody came up with a more restrictive kind of loop that covered
>> most cases and was less error-prone, I might not object to adding it to
>> a future version of the language -- *in addition to* C's existing for
>> loop, not replacing it.
>>
>
> If I were to choose something to add to the for-loop syntax, I'd like:
>
> for (const int i = 0; i < N; i++) {
> ...
> }
>
> to have the same meaning as:
>
> for (const int i = 0; i < N; i++) {
> const int i_ = i;
> const int i = i_;
> ...
> }
>
>
> The first version is currently a constraint violation since it tries
> to increment a variable that is declared "const". I'm not sure if
> that means the syntax here could be re-used to get the effect I am
> looking for. If not, I suppose an alternative syntax could be found.
>
> The idea here is to lock the loop variable inside the loop, so that it
> can only be changed in the iterator part of the for-statement.
There is precedent for something similar in Ada. An Ada for loop can
look like this, for example:
for I in 1..10 loop
-- ...
end loop;
I is local to each iteration of the loop, and is treated as read-only.
Ada's for loops don't have the flexibility of C's.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web