Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #133735 > unrolled thread
| Started by | skybuck2000@hotmail.com |
|---|---|
| First post | 2018-08-13 12:53 -0700 |
| Last post | 2018-10-10 18:24 -0700 |
| Articles | 20 on this page of 354 — 27 participants |
Back to article view | Back to comp.lang.c
>< swap operator skybuck2000@hotmail.com - 2018-08-13 12:53 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-08-13 16:05 -0400
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-13 13:46 -0700
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-08-14 11:19 +0300
Re: >< swap operator skybuck2000@hotmail.com - 2018-08-14 06:16 -0700
Re: >< swap operator bart4858@gmail.com - 2018-08-14 07:50 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-14 16:59 +0200
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-08-14 10:46 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-14 20:03 +0200
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-08-14 11:37 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-14 21:16 +0200
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-14 11:32 -0700
Re: >< swap operator bart4858@gmail.com - 2018-08-14 16:24 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-08-15 11:32 +0200
Re: >< swap operator skybuck2000@hotmail.com - 2018-10-01 07:46 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 05:20 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 13:58 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 14:08 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 09:16 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-02 15:35 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 09:43 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 10:51 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 09:08 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 15:26 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 10:52 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 17:57 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 13:27 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 11:52 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 20:48 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 15:56 -0400
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:05 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 13:26 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 21:36 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 13:47 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 11:14 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:37 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 22:02 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 17:16 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 11:25 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-03 10:52 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 14:29 +0200
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-03 05:52 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 21:31 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 16:47 -0400
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 03:43 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 22:47 -0400
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 04:25 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 20:44 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 11:53 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 05:15 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 13:48 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 10:56 -0400
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 17:47 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 11:01 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-04 22:15 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 16:19 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 21:42 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 15:01 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 23:59 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 09:54 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 18:03 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 21:08 +0200
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 20:31 +0100
Re: >< swap operator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-05 15:59 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 21:18 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 03:51 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-06 12:19 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 19:49 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 12:25 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-07 14:19 +0100
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-07 06:56 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-07 16:30 +0100
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-09 13:17 +0200
C idioms (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 13:07 +0000
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-09 14:27 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-10 00:05 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-10 02:03 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-11 01:05 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 02:09 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 12:39 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-11 16:24 +0100
Re: C idioms scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 15:55 +0000
Re: C idioms Keith Thompson <kst-u@mib.org> - 2018-10-11 09:42 -0700
Re: C idioms Wouter Verhelst <w@uter.be> - 2018-10-11 19:23 +0200
Re: C idioms jameskuyper@alumni.caltech.edu - 2018-10-11 11:11 -0700
Re: C idioms Keith Thompson <kst-u@mib.org> - 2018-10-11 12:05 -0700
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 17:53 +0100
Re: C idioms Keith Thompson <kst-u@mib.org> - 2018-10-11 10:38 -0700
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-12 00:14 +0100
Re: C idioms Bart <bc@freeuk.com> - 2018-10-11 19:26 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 16:38 +0200
Re: C idioms (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 15:23 +0000
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 20:31 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-09 20:18 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 22:11 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-09 20:50 +0000
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-09 22:58 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-09 22:34 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 08:10 +0200
Re: C idioms (Was: >< swap operator) jameskuyper@alumni.caltech.edu - 2018-10-09 14:45 -0700
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 08:07 +0200
Hmmm... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 07:56 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-10 10:32 +0200
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) Ike Naar <ike@iceland.freeshell.org> - 2018-10-10 13:44 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:52 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) Wouter Verhelst <w@uter.be> - 2018-10-10 17:47 +0200
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-10 17:18 +0200
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 15:22 +0000
Re: Hmmm... (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-10 23:58 +0200
Re: Hmmm... Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-10 07:51 -0600
Re: Hmmm... gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:53 +0000
Re: Hmmm... David Brown <david.brown@hesbynett.no> - 2018-10-10 17:21 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 12:57 +0000
Re: C idioms (Was: >< swap operator) James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-10 12:29 -0400
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:07 +0200
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-09 14:50 -0700
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 08:13 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 12:56 +0000
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 15:55 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 15:17 +0100
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 14:49 +0000
Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:59 +0000
Re: Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) Bart <bc@freeuk.com> - 2018-10-10 16:09 +0100
Re: Fall-through in switch statements... (Was: C idioms (Was: >< swap operator)) nobody@example.org (Scott) - 2018-10-10 17:29 +0000
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 16:01 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 17:29 +0200
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-10 17:55 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 17:11 +0100
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-10 23:15 +0100
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:16 +0200
Re: C idioms (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-10 23:23 +0100
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-10 16:31 -0700
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-10 15:32 -0700
Re: C idioms (Was: >< swap operator) Keith Thompson <kst-u@mib.org> - 2018-10-10 16:24 -0700
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-11 10:52 +0200
Re: C idioms Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-10 09:59 -0600
Re: C idioms (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-10 17:26 +0200
Re: C idioms (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 14:48 +0000
Return values of fork() (Was: C idioms (Was: >< swap operator)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 14:51 +0000
Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 15:20 +0000
You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-10 15:28 +0000
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:23 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 13:22 +0000
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 15:58 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) scott@slp53.sl.home (Scott Lurndal) - 2018-10-11 14:17 +0000
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 16:42 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) Wouter Verhelst <w@uter.be> - 2018-10-11 16:53 +0200
Re: You know that and I know that, but ... (Was: Return values of fork() (Was: C idioms (Was: >< swap operator))) David Brown <david.brown@hesbynett.no> - 2018-10-11 20:11 +0200
Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) David Brown <david.brown@hesbynett.no> - 2018-10-11 00:20 +0200
Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) Keith Thompson <kst-u@mib.org> - 2018-10-10 16:15 -0700
Re: Return values of fork() Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-11 14:42 -0600
Re: C idioms Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-09 16:18 -0600
Re: C idioms gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 22:28 +0000
Re: C idioms scott@slp53.sl.home (Scott Lurndal) - 2018-10-10 12:58 +0000
Re: C idioms (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-09 07:48 -0700
Re: C idioms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 16:42 +0100
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-09 19:40 +0200
Re: C idioms (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-09 12:38 -0700
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-09 23:41 +0200
Re: C idioms (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-09 19:38 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 15:04 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-07 16:37 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 16:58 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-07 12:17 -0400
Grammar police! (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-07 20:37 +0000
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-07 09:31 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 18:09 +0100
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-07 14:05 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-07 22:35 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-08 02:56 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-08 10:48 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 12:09 +0100
Re: >< swap operator Ike Naar <ike@iceland.freeshell.org> - 2018-10-08 16:00 +0000
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 17:44 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 10:39 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 20:08 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 11:22 +0200
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-09 09:25 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 20:43 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-09 20:15 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 22:26 +0200
Re: >< swap operator Ike Naar <ike@iceland.freeshell.org> - 2018-10-08 21:09 +0000
Re: >< swap operator David Kleinecke <dkleinecke@gmail.com> - 2018-10-08 15:18 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 07:55 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-09 11:24 +0200
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-08 07:19 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 16:26 +0100
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-10 10:59 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 19:53 +0100
Re: >< swap operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-07 18:00 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-07 17:10 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 01:25 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-08 02:51 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 11:29 +0100
Re: >< swap operator mark.bluemel@gmail.com - 2018-10-08 04:41 -0700
Re: >< swap operator jameskuyper@alumni.caltech.edu - 2018-10-08 07:56 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 08:36 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 17:34 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-08 21:35 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 22:00 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 00:47 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-09 01:11 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-09 02:47 +0100
Re: >< swap operator mark.bluemel@gmail.com - 2018-10-09 00:49 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-09 11:28 +0100
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-09 13:00 +0000
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 10:28 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-08 10:49 -0700
Re: >< swap operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-07 20:00 -0600
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-06 13:07 -0700
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 23:35 +0000
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 03:49 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-06 16:18 +0200
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-06 14:48 +0000
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-06 12:53 -0700
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-07 16:38 +0000
Re: >< swap operator James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-07 15:56 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-07 16:53 -0700
Re: >< swap operator David Kleinecke <dkleinecke@gmail.com> - 2018-10-07 17:07 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-07 17:24 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-08 01:30 +0100
Re: >< swap operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2018-10-07 19:12 -0600
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 18:26 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-06 19:41 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-06 13:05 -0700
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-07 02:24 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-07 12:41 +0200
100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 00:22 +0000
Re: 100% of the user base... (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-06 01:55 +0100
Re: 100% of the user base... (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 03:58 -0700
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 11:51 +0000
Re: 100% of the user base... (Was: >< swap operator) Bart <bc@freeuk.com> - 2018-10-06 13:09 +0100
Re: 100% of the user base... (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-06 05:26 -0700
Re: 100% of the user base... (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 05:40 -0700
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 12:46 +0000
Re: 100% of the user base... (Was: >< swap operator) Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-06 12:46 +0000
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-06 12:49 +0000
Re: 100% of the user base... (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-06 06:27 -0700
Re: 100% of the user base... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-07 12:47 +0000
Re: 100% of the user base... (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-07 09:03 -0400
Re: 100% of the user base... (Was: >< swap operator) scott@slp53.sl.home (Scott Lurndal) - 2018-10-07 16:47 +0000
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 10:17 +0200
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 09:20 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 10:58 +0100
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 12:09 +0200
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 03:11 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 07:56 -0400
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 14:25 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 08:39 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 15:47 +0100
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 17:30 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 11:41 -0400
Re: >< swap operator Wouter Verhelst <w@uter.be> - 2018-10-05 17:56 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 12:00 -0400
Re: >< swap operator Richard Damon <Richard@Damon-Family.org> - 2018-10-05 12:34 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 12:48 -0400
Re: >< swap operator Richard Damon <Richard@Damon-Family.org> - 2018-10-05 13:55 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-05 11:20 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 14:45 -0400
Re: >< swap operator Richard Damon <Richard@Damon-Family.org> - 2018-10-05 21:39 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-07 08:51 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-11-25 14:18 -0800
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-05 15:46 +0300
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 06:05 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 06:16 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 15:09 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:18 -0400
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-05 17:32 +0300
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:34 -0400
Of course it is crazy! (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 15:17 +0000
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 18:30 +0000
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 14:48 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 15:06 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 13:55 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 06:14 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 16:18 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:21 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 17:27 +0200
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-05 15:26 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:28 -0400
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 14:46 +0000
When pigs fly... (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 16:10 +0000
Re: >< swap operator Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-05 17:35 +0300
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 10:46 -0400
Re: >< swap operator gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 15:15 +0000
6K years??? (Was: >< swap operator) gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-05 13:20 +0000
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 09:28 -0400
Re: 6K years??? (Was: >< swap operator) Wouter Verhelst <w@uter.be> - 2018-10-05 17:53 +0200
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 11:56 -0400
Re: 6K years??? (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-05 18:17 +0200
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 09:21 -0700
Re: 6K years??? (Was: >< swap operator) David Brown <david.brown@hesbynett.no> - 2018-10-05 18:50 +0200
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 12:52 -0400
Re: 6K years??? (Was: >< swap operator) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-05 13:05 -0400
Re: 6K years??? (Was: >< swap operator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 03:42 -0700
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-05 15:59 +0200
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 03:45 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-04 11:22 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 20:35 +0100
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-04 13:28 +0100
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 17:59 +0100
Re: >< swap operator John Bode <jfbode1029@gmail.com> - 2018-10-04 09:56 -0700
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 06:03 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-03 14:37 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 09:51 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 15:39 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 10:05 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 10:09 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 16:22 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 10:29 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 20:52 +0200
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 14:57 -0400
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 16:06 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-03 00:09 +0100
Re: >< swap operator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-02 19:21 -0400
Re: >< swap operator David Brown <david.brown@hesbynett.no> - 2018-10-03 11:21 +0200
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:43 -0700
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-02 21:01 +0000
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 14:29 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 22:37 +0100
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-03 05:07 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 21:01 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:06 -0400
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 21:45 +0100
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 17:09 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:11 -0400
Re: >< swap operator "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 16:22 -0400
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:17 -0700
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 13:24 -0700
Re: >< swap operator scott@slp53.sl.home (Scott Lurndal) - 2018-10-02 15:04 +0000
Re: >< swap operator Niles Rogoff <eternal-september@niles.xyz> - 2018-10-03 18:28 +0000
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-08-14 11:50 -0700
Re: >< swap operator Siri Cruise <chine.bleu@yahoo.com> - 2018-08-14 17:07 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 02:22 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 02:34 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 03:09 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 03:24 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 04:51 -0700
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 05:06 -0700
Re: >< swap operator Siri Cruise <chine.bleu@yahoo.com> - 2018-08-15 04:21 -0700
Re: >< swap operator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-08-15 14:43 +0100
Re: >< swap operator fir <profesor.fir@gmail.com> - 2018-08-15 07:08 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-08-15 16:52 +0100
Re: >< swap operator Ike Naar <ike@iceland.freeshell.org> - 2018-08-15 15:51 +0000
Re: >< swap operator John Bode <jfbode1029@gmail.com> - 2018-10-01 14:59 -0700
Re: >< swap operator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-02 03:06 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 11:43 +0100
Re: >< swap operator John Bode <jfbode1029@gmail.com> - 2018-10-02 07:27 -0700
Re: >< swap operator Bart <bc@freeuk.com> - 2018-10-02 15:43 +0100
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 11:01 -0700
Re: >< swap operator Keith Thompson <kst-u@mib.org> - 2018-10-02 10:54 -0700
Re: >< swap operator Thiago Adams <thiago.adams@gmail.com> - 2018-10-02 12:39 -0700
Re: >< swap operator skybuck2000@hotmail.com - 2018-10-10 18:10 -0700
Re: >< swap operator skybuck2000@hotmail.com - 2018-10-10 18:24 -0700
Page 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-05 18:03 +0100 |
| Message-ID | <CPMtD.50$vf.6@fx05.am4> |
| In reply to | #136244 |
On 05/10/2018 08:54, David Brown wrote:
> On 05/10/18 00:59, Bart wrote:
>> My language used ":=" for right-to-left assignment, so why not "=:" for
>> left-to-right?
> If I were making a new programming language, assignment would be a
> statement - not an expression. So that would mean "syntax error". (I
> know not everyone agrees with me on this point.)
I actually use two different kinds of assignment, one that is only for
statements, and doesn't return a value; and one used in expressions
which returns a value.
However, they both use the ":=", and the context tells you which is which:
a := b := c
The "b:=c" is an expression (yielding value of c); the "a:=..." is a
statement. In practise you don't need to worry which is which.
It's because there is a strict demarcation between statements, and
expressions (unlike in C where any statement is also an expression).
Because some parts of expressions are also useful as statements, they
are duplicate versions of each kind:
- assignments (as above)
- function calls
- increments
If I had to drop assignments inside expressions as you suggest, that
wouldn't be a big deal, and I would drop increment too. (Augmented
assignments are already dropped.) But function calls will always be needed.
> While it is more common to have "assign to the left", it is entirely
> possible to have "assign to the right" (I have seen that written with an
> arrow, "b -> a", rather than "b =: a" - read as "b goes to a"). But as
> you say, if the two styles are mixed it becomes extremely difficult to
> read the code.
The precedences also get harder to work out:
a + b -> c + d
Where would the brackets go to show how it is evaluated? ("=" in C has
right-to-left precedence.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-05 21:08 +0200 |
| Message-ID | <pp8cr8$jn$1@dont-email.me> |
| In reply to | #136295 |
On 05/10/18 19:03, Bart wrote:
> On 05/10/2018 08:54, David Brown wrote:
>
>> While it is more common to have "assign to the left", it is entirely
>> possible to have "assign to the right" (I have seen that written with an
>> arrow, "b -> a", rather than "b =: a" - read as "b goes to a"). But as
>> you say, if the two styles are mixed it becomes extremely difficult to
>> read the code.
>
> The precedences also get harder to work out:
>
> a + b -> c + d
>
> Where would the brackets go to show how it is evaluated? ("=" in C has
> right-to-left precedence.)
>
If you drop the "assignment is an expression" idea, then there is no
problem with precedences here.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-05 20:31 +0100 |
| Message-ID | <87va6gjile.fsf@bsb.me.uk> |
| In reply to | #136295 |
Bart <bc@freeuk.com> writes: > It's because there is a strict demarcation between statements, and > expressions (unlike in C where any statement is also an expression). I don't know what you intended to write there but what came out is wrong. Statements in C are not also expressions. In fact C also has a strict demarcation between statements and expressions. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2018-10-05 15:59 -0400 |
| Message-ID | <pp8fqk$kqm$1@dont-email.me> |
| In reply to | #136306 |
Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> It's because there is a strict demarcation between statements, and >> expressions (unlike in C where any statement is also an expression). > > I don't know what you intended to write there but what came out is > wrong. Statements in C are not also expressions. In fact C also has a > strict demarcation between statements and expressions. For example 3 + 2 is an expression, while 3 + 2 ; is a statement. ;-) -- Lew Pitcher "In Skills, We Trust"
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-05 21:18 +0100 |
| Message-ID | <UGPtD.329$p%6.29@fx26.am4> |
| In reply to | #136306 |
On 05/10/2018 20:31, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> It's because there is a strict demarcation between statements, and >> expressions (unlike in C where any statement is also an expression). > > I don't know what you intended to write there but what came out is > wrong. Statements in C are not also expressions. In fact C also has a > strict demarcation between statements and expressions. > It should have been the other way around. All expression can be a statement.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-06 03:51 +0100 |
| Message-ID | <87d0snkcs4.fsf@bsb.me.uk> |
| In reply to | #136313 |
Bart <bc@freeuk.com> writes: > On 05/10/2018 20:31, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> It's because there is a strict demarcation between statements, and >>> expressions (unlike in C where any statement is also an expression). >> >> I don't know what you intended to write there but what came out is >> wrong. Statements in C are not also expressions. In fact C also has a >> strict demarcation between statements and expressions. >> > It should have been the other way around. All expression can be a > statement. Ah, I see. That's also wrong, or at least misleading. There is a statement form that is an expression followed by a semi-colon. That's what makes the strict demarcation between statements and expressions that you claim C does not have. Expressions can not /be/ statements, but they can be trivially /made into/ statements. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-06 12:19 +0100 |
| Message-ID | <zT0uD.23929$1C7.14337@fx38.am4> |
| In reply to | #136321 |
On 06/10/2018 03:51, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 05/10/2018 20:31, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> It's because there is a strict demarcation between statements, and
>>>> expressions (unlike in C where any statement is also an expression).
>>>
>>> I don't know what you intended to write there but what came out is
>>> wrong. Statements in C are not also expressions. In fact C also has a
>>> strict demarcation between statements and expressions.
>>>
>> It should have been the other way around. All expression can be a
>> statement.
>
> Ah, I see. That's also wrong, or at least misleading. There is a
> statement form that is an expression followed by a semi-colon. That's
> what makes the strict demarcation between statements and expressions
> that you claim C does not have. Expressions can not /be/ statements,
> but they can be trivially /made into/ statements.
So ANY expression can be made into a statement. So any expression can BE
a statement, just by sticking a semicolon on the end.
Isn't a semicolon statement terminator? That sounds like, without a
semicolon, a statement (including an expression in the correct context)
is still a statement, just not terminated yet.
I think of stronger defining feature is an expression that occurs where
a statement is normally expected.
Anyway, the demarcation I make is much rigid than this and for the
simple reason that most expressions are meaningless as statements. A few
kinds of expression terms (assignment, function call and increment) are
useful enough to be duplicated as statements. In that form, they are
/not/ expressions.
(Having side-effects isn't useful enough to make an expression a statement:
f() + g();
This might have side-effects, but the result of the addition is
discarded, so this is probably a mistake. I require that to be written as:
eval f() + g()
C compilers will pick up such things as warnings; I have it as a feature
of the language.
However, it all also a damn nuisance when developing compilers as a lot
of the time, you will be writing lines like 'eval a[i]' when in C you
just write 'a[i]' when testing micro-features.)
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-06 19:49 +0100 |
| Message-ID | <87o9c6j4fl.fsf@bsb.me.uk> |
| In reply to | #136331 |
Bart <bc@freeuk.com> writes: > On 06/10/2018 03:51, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 05/10/2018 20:31, Ben Bacarisse wrote: >>>> Bart <bc@freeuk.com> writes: >>>> >>>>> It's because there is a strict demarcation between statements, and >>>>> expressions (unlike in C where any statement is also an expression). >>>> >>>> I don't know what you intended to write there but what came out is >>>> wrong. Statements in C are not also expressions. In fact C also has a >>>> strict demarcation between statements and expressions. >>>> >>> It should have been the other way around. All expression can be a >>> statement. >> >> Ah, I see. That's also wrong, or at least misleading. There is a >> statement form that is an expression followed by a semi-colon. That's >> what makes the strict demarcation between statements and expressions >> that you claim C does not have. Expressions can not /be/ statements, >> but they can be trivially /made into/ statements. > > So ANY expression can be made into a statement. So any expression can > BE a statement, just by sticking a semicolon on the end. Well, obviously I won't agree to your re-wording because it stresses exactly the part I was at pains to correct. But it's a tiny point, isn't it? You stress "BE just by" and I stress "be trivially MADE INTO". > Isn't a semicolon statement terminator? That sounds like, without a > semicolon, a statement (including an expression in the correct > context) is still a statement, just not terminated yet. You are welcome to call "x = 1" an unterminated statement but it's simpler to call it what it is (in C) -- we are talking about C, yes? > Anyway, the demarcation I make is much rigid than this In C? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-07 12:25 +0100 |
| Message-ID | <J2muD.2814$el1.2041@fx34.am4> |
| In reply to | #136355 |
On 06/10/2018 19:49, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> Isn't a semicolon statement terminator? That sounds like, without a
>> semicolon, a statement (including an expression in the correct
>> context) is still a statement, just not terminated yet.
>
> You are welcome to call "x = 1" an unterminated statement but it's
> simpler to call it what it is (in C) -- we are talking about C, yes?
>
>> Anyway, the demarcation I make is much [more] rigid than this
>
> In C?
Outside of C, I went from interchangeable statements and expressions
many years ago, to strictly segregated now. (If you see "++a" in both,
they are different internal constructs.)
In C, however much you can argue about exactly how you define a
statement, nothing really stops you from using expressions everywhere:
c?f():g();
if (p==NULL) puts("Memerror"), exit(1);
726.9,
"--------- divider line ---------",
123,456,789.0,
a+b+c,
a==b+c,
f()+g()+h();
Pretty much everything here, other than 'if (p=NULL)', can also be just
at home deep inside an expression.
A compiler may or may not say anything about this, but it is all
perfectly legal C.
In my language, none of this would be allowed, except the puts() and
exit() [or equivalent as 'exit' is a keyword], which would be classed as
procedure calls, not function calls (and they'd need to be separated by
semicolons).
So a stricter language helps you stop writing what could easily be
nonsense, rather than a language allowing any old rubbish and leaving it
to a compiler to pick up the pieces.
Which means /needing/ a more sophisticated compiler, and it still
probably won't pick up everything here; the first two lines will be let
through.
So, strict demarcation in C between statements and expressions? Not
really. C /needs/ expressions as statements to be able to do any work.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-07 14:19 +0100 |
| Message-ID | <87pnwlhp1q.fsf@bsb.me.uk> |
| In reply to | #136377 |
Bart <bc@freeuk.com> writes: > On 06/10/2018 19:49, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> Isn't a semicolon statement terminator? That sounds like, without a >>> semicolon, a statement (including an expression in the correct >>> context) is still a statement, just not terminated yet. >> >> You are welcome to call "x = 1" an unterminated statement but it's >> simpler to call it what it is (in C) -- we are talking about C, yes? >> >>> Anyway, the demarcation I make is much [more] rigid than this >> >> In C? > > Outside of C, I went from... Ah. I'm hope you won't think it rude, but I have no reason to be interested in what you did in your language. There are hundreds of programming languages, and many of them are well-documented, stable, and usable on my system. It would be much better, if you want to illustrate a point, to pick a publicly documented language to do it. > So, strict demarcation in C between statements and expressions? Not > really. Yes, really. > C /needs/ expressions as statements to be able to do any work. C needs expression statements -- statements formed from an expression and a semicolon -- to work. There is no reason to keep denying this distinction. If you dislike expression statements (and, off the top of my head, I can't think of anything about C that you don't dislike) your time would be better spent explaining why that is, rather than repeating statements that are just going to generate "yes it is", "no it isn't" exchanges. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-10-07 06:56 -0700 |
| Message-ID | <54e12132-07e7-432f-95e8-f292f5f5bdad@googlegroups.com> |
| In reply to | #136381 |
On Sunday, October 7, 2018 at 2:19:55 PM UTC+1, Ben Bacarisse wrote: > C needs expression statements -- statements formed from an expression > and a semicolon -- to work. There is no reason to keep denying this > distinction. > We could easily enough declare that an assignment doesn't yield a value. That would break some C code in a way that is difficult to simply fix, but arguably such code is badly written anyway and doesn't deserve to be supported. We could also declare that functions shall not return values. Only a minority of C functions are actually mathematical functions with any sort of convention behind them, and we could easily special case those by declaring them to be keywords. The result that you would have to pass a pointer to a function yielding a value. In some coding standards you do that anyway - the return value is reserved for error conditions. Then you don't need "expression statements".
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-07 16:30 +0100 |
| Message-ID | <87k1mthizq.fsf@bsb.me.uk> |
| In reply to | #136384 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Sunday, October 7, 2018 at 2:19:55 PM UTC+1, Ben Bacarisse wrote: > >> C needs expression statements -- statements formed from an expression >> and a semicolon -- to work. There is no reason to keep denying this >> distinction. >> > We could easily enough declare that an assignment doesn't yield a > value. Yes, you could. It would not be C, but you could. > That would break some C code in a way that is difficult to simply fix, > but arguably such code is badly written anyway and doesn't deserve to > be supported. Only in the sense that everything is arguable. There is no good argument for declaring that while ((c = fgetc(fp)) != EOF) nl += c == '\n'; does not deserve to be supported. I think if there were, you might have made it. > We could also declare that functions shall not return values. Only a > minority of C functions are actually mathematical functions with any > sort of convention behind them, and we could easily special case those > by declaring them to be keywords. The result that you would have to > pass a pointer to a function yielding a value. In some coding standards > you do that anyway - the return value is reserved for error > conditions. > > Then you don't need "expression statements". There are lots of ways to solve this non-problem. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-10-09 13:17 +0200 |
| Message-ID | <pbfu8f-mil.ln1@gangtai.home.grep.be> |
| In reply to | #136384 |
On 10/7/18 3:56 PM, Malcolm McLean wrote:
> On Sunday, October 7, 2018 at 2:19:55 PM UTC+1, Ben Bacarisse wrote:
>
>> C needs expression statements -- statements formed from an expression
>> and a semicolon -- to work. There is no reason to keep denying this
>> distinction.
>>
> We could easily enough declare that an assignment doesn't yield a value.
> That would break some C code in a way that is difficult to simply fix,
> but arguably such code is badly written anyway and doesn't deserve to
> be supported.
Whoa.
if((pid = fork()) < 0) {
// error handling
} else if(pid == 0) {
// child code
} else {
// parent code
}
I think that's not badly written at all, and uses the value of the
assignment expression.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-10-09 13:07 +0000 |
| Subject | C idioms (Was: >< swap operator) |
| Message-ID | <ppi95o$kfu$2@news.xmission.com> |
| In reply to | #136470 |
In article <pbfu8f-mil.ln1@gangtai.home.grep.be>,
Wouter Verhelst <w@uter.be> wrote:
>On 10/7/18 3:56 PM, Malcolm McLean wrote:
>> On Sunday, October 7, 2018 at 2:19:55 PM UTC+1, Ben Bacarisse wrote:
>>
>>> C needs expression statements -- statements formed from an expression
>>> and a semicolon -- to work. There is no reason to keep denying this
>>> distinction.
>>>
>> We could easily enough declare that an assignment doesn't yield a value.
>> That would break some C code in a way that is difficult to simply fix,
>> but arguably such code is badly written anyway and doesn't deserve to
>> be supported.
>
>Whoa.
>
>if((pid = fork()) < 0) {
> // error handling
>} else if(pid == 0) {
> // child code
>} else {
> // parent code
>}
>
>I think that's not badly written at all, and uses the value of the
>assignment expression.
That's a common idiom, but it is not really necessary. I'm sure many in
the "keep it clear - even to morons" crowd would argue that it should be
written:
pid = fork();
switch (pid) {
...
}
What's less clear is when you're doing a "while" loop. Then you want to be
able to do:
while ((c = getwhatver()) != EOF) {
...
}
Here it is less clear how to re-write this without using the embedded
assignment. In fact, I find the above idiom so central to the act of
reading a file, that, in languages (other than C) that don't support it
(like, I would imagine most of Bart's "languages") I've had to implement
this functionality myself.
Something like:
while (getwhatever(&c) != EOF) ...
--
To my knowledge, Jacob Navia is not a Christian.
- Rick C Hodgin -
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-09 14:27 +0100 |
| Subject | Re: C idioms (Was: >< swap operator) |
| Message-ID | <j12vD.4060$%T7.287@fx30.am4> |
| In reply to | #136477 |
On 09/10/2018 14:07, Kenny McCormack wrote:
> In article <pbfu8f-mil.ln1@gangtai.home.grep.be>,
> Wouter Verhelst <w@uter.be> wrote:
>> On 10/7/18 3:56 PM, Malcolm McLean wrote:
>>> On Sunday, October 7, 2018 at 2:19:55 PM UTC+1, Ben Bacarisse wrote:
>>>
>>>> C needs expression statements -- statements formed from an expression
>>>> and a semicolon -- to work. There is no reason to keep denying this
>>>> distinction.
>>>>
>>> We could easily enough declare that an assignment doesn't yield a value.
>>> That would break some C code in a way that is difficult to simply fix,
>>> but arguably such code is badly written anyway and doesn't deserve to
>>> be supported.
>>
>> Whoa.
>>
>> if((pid = fork()) < 0) {
>> // error handling
>> } else if(pid == 0) {
>> // child code
>> } else {
>> // parent code
>> }
>>
>> I think that's not badly written at all, and uses the value of the
>> assignment expression.
>
> That's a common idiom, but it is not really necessary. I'm sure many in
> the "keep it clear - even to morons" crowd would argue that it should be
> written:
>
> pid = fork();
> switch (pid) {
> ...
> }
>
> What's less clear is when you're doing a "while" loop. Then you want to be
> able to do:
>
> while ((c = getwhatver()) != EOF) {
> ...
> }
>
> Here it is less clear how to re-write this without using the embedded
> assignment. In fact, I find the above idiom so central to the act of
> reading a file, that, in languages (other than C) that don't support it
> (like, I would imagine most of Bart's "languages") I've had to implement
> this functionality myself.
>
> Something like:
>
> while (getwhatever(&c) != EOF) ...
>
They have assignment inside expressions, do the C idiom will work:
while (c:=nextchar(f))<>c_eof do..
except that I prefer doing it like this (in C syntax now):
while (1) {
c = nextchar(f();
if (c==EOF) break;
....
or using another method entirely (one of those that is heavily frowned
upon here):
while (!ateof(f)) {
c = nextchar(f);
......
Or:
while (!ateof(f)) {
n = readnextline(f,...);
......
Or:
while (!ateof*(f)) {
readnextrecord(f,...)
You get the picture; this idiom is far more general purpose.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-10 00:05 +0100 |
| Subject | Re: C idioms |
| Message-ID | <87y3b6u3ev.fsf@bsb.me.uk> |
| In reply to | #136480 |
Bart <bc@freeuk.com> writes:
<snip>
> or using another method entirely (one of those that is heavily frowned
> upon here):
>
> while (!ateof(f)) {
> c = nextchar(f);
> ......
It's frowned on here because, in C, that pattern requires ateof to read
the next character. You read the next character to test if you can read
the next character so that you can read the next character. Not nice.
ateof is not really testing for end-of-file but whether a character
could be read.
But there is a more general point. Input can often fail for many
reasons, so it is almost always better to test for success rather the
absence of one possible cause of failure. Most programs read more
complex data that can fail for all sorts of reasons. Since you will
need to write
if (got_next_payment_record(f, &rec)) ...
inside the loop, you might as well write
while (got_next_payment_record(f, &rec)) ...
anyway.
> Or:
>
> while (!ateof*(f)) {
> readnextrecord(f,...)
>
> You get the picture; this idiom is far more general purpose.
I think you posted a similar example the last time you tried to push
this bad way to do IO. If you don't test for errors, then I suppose
you might think this is a general-purpose pattern, but the proper way is
to write a function the tries to read a record and indicates success or
failure in the return value.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-10 02:03 +0100 |
| Subject | Re: C idioms |
| Message-ID | <fdcvD.26161$aw7.13806@fx04.am4> |
| In reply to | #136516 |
On 10/10/2018 00:05, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> <snip>
>> or using another method entirely (one of those that is heavily frowned
>> upon here):
>>
>> while (!ateof(f)) {
>> c = nextchar(f);
>> ......
>
> It's frowned on here because, in C, that pattern requires ateof to read
> the next character. You read the next character to test if you can read
> the next character so that you can read the next character. Not nice.
> ateof is not really testing for end-of-file but whether a character
> could be read.
>
> But there is a more general point. Input can often fail for many
> reasons, so it is almost always better to test for success rather the
> absence of one possible cause of failure. Most programs read more
> complex data that can fail for all sorts of reasons. Since you will
> need to write
>
> if (got_next_payment_record(f, &rec)) ...
>
> inside the loop, you might as well write
>
> while (got_next_payment_record(f, &rec)) ...
>
> anyway.
>
>> Or:
>>
>> while (!ateof*(f)) {
>> readnextrecord(f,...)
>>
>> You get the picture; this idiom is far more general purpose.
>
> I think you posted a similar example the last time you tried to push
> this bad way to do IO. If you don't test for errors, then I suppose
> you might think this is a general-purpose pattern, but the proper way is
> to write a function the tries to read a record and indicates success or
> failure in the return value.
You can take checking for errors too far.
I suppose if you had a program with malloc everywhere, you would put
error-checking code everywhere too?
Some errors are just unlikely - they are exceptions - and should be
treated differently.
I've had a point-of-sale application (scripted, not using C) running
daily for 23 years, based on my ideas for dealing with files either a
file-at-a-time, or a line-at-a-time via an eof-checking loop like my
examples.
If there were actual file errors (which I've never had reported), they
would show up because the lists of transactions don't match the paper
records.
Error-checking is high-level (mainly to detect operator mistakes) rather
than be concerned with low-level file operations, which would not that
useful for the operator to know.
Go and look at some Python code, which uses memory allocation and
deallocation on pretty much every line. But you will never see such
checks in the code. They are done behind the scenes.
You can put this stuff behind the scenes in C code too.
--
bart
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-11 01:05 +0100 |
| Subject | Re: C idioms |
| Message-ID | <877eiptkjj.fsf@bsb.me.uk> |
| In reply to | #136518 |
Bart <bc@freeuk.com> writes:
> On 10/10/2018 00:05, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> <snip>
>>> or using another method entirely (one of those that is heavily frowned
>>> upon here):
>>>
>>> while (!ateof(f)) {
>>> c = nextchar(f);
>>> ......
>>
>> It's frowned on here because, in C, that pattern requires ateof to read
>> the next character. You read the next character to test if you can read
>> the next character so that you can read the next character. Not nice.
>> ateof is not really testing for end-of-file but whether a character
>> could be read.
>>
>> But there is a more general point. Input can often fail for many
>> reasons, so it is almost always better to test for success rather the
>> absence of one possible cause of failure. Most programs read more
>> complex data that can fail for all sorts of reasons. Since you will
>> need to write
>>
>> if (got_next_payment_record(f, &rec)) ...
>>
>> inside the loop, you might as well write
>>
>> while (got_next_payment_record(f, &rec)) ...
>>
>> anyway.
>>
>>> Or:
>>>
>>> while (!ateof*(f)) {
>>> readnextrecord(f,...)
>>>
>>> You get the picture; this idiom is far more general purpose.
>>
>> I think you posted a similar example the last time you tried to push
>> this bad way to do IO. If you don't test for errors, then I suppose
>> you might think this is a general-purpose pattern, but the proper way is
>> to write a function the tries to read a record and indicates success or
>> failure in the return value.
>
> You can take checking for errors too far.
There are very few things that you can't take too far, so this is not a
very informative comment. Why, in the example you give here, would you
want to check only for end-of-file between records and nothing else?
Obviously you may need to plough on and process all the data, even in
the event of a bad record, but I would expect that to be written like
this in C:
do {
if (got_next_record(f, ...)) {
... // process it
}
} while (!feof(f) && !ferror(f));
and because this also naturally uses the "try and report" model of
input, the EOF test as the end if fine. There is no need for the
special ateof function.
The big picture (lest you worry we'll go down some narrow rabbit hole)
is that it is better to work with C's IO model. If you want to propose
another way to write input loops, you need to make a strong case for it
being better in general.
> I suppose if you had a program with malloc everywhere, you would put
> error-checking code everywhere too?
Hard to say, but it's not the same problem. Memory allocation failures
can very often be put into only one or two places.
> Some errors are just unlikely - they are exceptions - and should be
> treated differently.
Do you consider input errors to be unlikely and that they should be
treated differently? If so, how? Currently, you seem to be ignoring
them. I say "seem", because if treating input errors as exceptions
means you plan to raise an actual exception (in C, a signal), that would
not be visible in the code pattern you've given. Or maybe
readnextrecord detects errors internally and stops the program? Again,
you'd need to explain why you think that's a good pattern to advocate
for.
> I've had a point-of-sale application (scripted, not using C) running
> daily for 23 years, based on my ideas for dealing with files either a
> file-at-a-time, or a line-at-a-time via an eof-checking loop like my
> examples.
>
> If there were actual file errors (which I've never had reported), they
> would show up because the lists of transactions don't match the paper
> records.
If examining a paper record is the correct way to deal with input errors
(I'm not sure what you are including in "file errors") then you have an
exceptional application from which you can't draw many general
conclusions. In fact, the simple fact that no input errors have
occurred in 23 years makes this is an unusual application.
> Go and look at some Python code, which uses memory allocation and
> deallocation on pretty much every line. But you will never see such
> checks in the code. They are done behind the scenes.
I was talking about checking input.
> You can put this stuff behind the scenes in C code too.
How? This is a C group, so you would be adding real value if you showed
how to handle input errors "behind the scenes" in C.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-11 02:09 +0100 |
| Subject | Re: C idioms |
| Message-ID | <KpxvD.26024$eN2.24618@fx07.am4> |
| In reply to | #136601 |
On 11/10/2018 01:05, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> You can take checking for errors too far.
>
> There are very few things that you can't take too far, so this is not a
> very informative comment. Why, in the example you give here, would you
> want to check only for end-of-file between records and nothing else?
Because I'm reading records. If EOF occurs inside a record, then it'll
be an incomplete record. It's a different of error. Or you may assume
the record is OK, but it'll fail some validation check.
> Do you consider input errors to be unlikely and that they should be
> treated differently? If so, how? Currently, you seem to be ignoring
> them. I say "seem", because if treating input errors as exceptions
> means you plan to raise an actual exception (in C, a signal), that would
> not be visible in the code pattern you've given. Or maybe
> readnextrecord detects errors internally and stops the program? Again,
> you'd need to explain why you think that's a good pattern to advocate
> for.
It's just a more informal way of doing things. I don't think I'm going
to convince anyone here. But I've done things that way for ever. It
seems to work. And if it didn't work, I can't think of anything it could
usefully report.
>> If there were actual file errors (which I've never had reported), they
>> would show up because the lists of transactions don't match the paper
>> records.
>
> If examining a paper record is the correct way to deal with input errors
> (I'm not sure what you are including in "file errors") then you have an
> exceptional application from which you can't draw many general
> conclusions. In fact, the simple fact that no input errors have
> occurred in 23 years makes this is an unusual application.
These are mostly text files. I chose to read them a line at a line, but
I could equally have chosen to read them a file at a time, and have a
list of strings in memory.
Any possible 'file' errors in the input - incomplete lines, early EOF,
missing lines, the wrong data - would manifest themselves also in the
in-memory version of the file. But how would they be detected? Once in
memory, there are no file errors to contend with.
It would be data validation that is nothing to do with the types of i/o
errors you're concerned with.
And since these are machine-generated text files, it is just very
unlikely the contents will be wrong. If they are, that will usually
become obvious. (More likely errors are power failures, mitigated by the
use of USPs, but my program is designed to recover from those.)
If you will suggest that someone could have maliciously modified the
files, then that requires yet another approach to detect, and is anyway
outside the remit of low-level file processing.
>> Go and look at some Python code, which uses memory allocation and
>> deallocation on pretty much every line. But you will never see such
>> checks in the code. They are done behind the scenes.
>
> I was talking about checking input.
>
>> You can put this stuff behind the scenes in C code too.
>
> How? This is a C group, so you would be adding real value if you showed
> how to handle input errors "behind the scenes" in C.
I think my approach, which I use for user applications, will not be
popular here, where every single error possibility must be detected and
reported.
For example, here's an example of a very simple line-oriented text
format I use for C projects:
module hello.c
This version is just one line, but the format allows blank lines,
leading white space, other kinds of keywords other than 'module',
comments following the filename of the 'module' line. Unrecognised
keywords are ignored. Generally pretty sloppy, but that doesn't matter.
Suppose the task was to read such a file, look only at the lines using
'module' and report the name of the last such module specified in the
file. How would that look like in error-checking C code?
You can assume:
* No line is longer than some reasonable amount for a hand-written
project file, so say 1000 or 1024 characters.
* Keywords and file names are case insensitive (but you can change that)
* File names will not have embedded spaces or newlines, just consist of
printable characters (which include : \ and /). And all on one line.
A version using an eof loop in my script language is in the sig. I'll
see if I can put together an equally informal C version tomorrow.
Notice there is no error checking; the only check is that the file
exists (no shown).
--
bart
lastmodule := "(none)"
while not eof(f) do # f is an open file handle
readln @f, kwd:"n", name:"n" # 'n' reads a name or filename
if kwd = "module" then
lastmodule := name
fi
od
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-11 12:39 +0100 |
| Subject | Re: C idioms |
| Message-ID | <dEGvD.13159$vf.9799@fx05.am4> |
| In reply to | #136603 |
On 11/10/2018 02:09, Bart wrote:
> I think my approach, which I use for user applications, will not be
> popular here, where every single error possibility must be detected and
> reported.
>
> For example, here's an example of a very simple line-oriented text
> format I use for C projects:
>
> module hello.c
....
> A version using an eof loop in my script language is in the sig. I'll
> see if I can put together an equally informal C version tomorrow.
>
> Notice there is no error checking; the only check is that the file
> exists (no shown).
Here is the C code corresponding to that script (but this version is
case-sensitive). No error checking as promised, apart from checking the
file can be opened:
int main(void) {
FILE *f;
char *infile = "/mx/mm.pro";
enum {size = 1024};
char line[size];
char name[size];
char lastmodule[size];
char *ptr;
f = fopen(infile,"r");
if (f == NULL) {
printf("Can' open %s\n", infile);
exit(1);
}
strcpy(lastmodule, "(none)");
while (!ateof(f)) {
readnextline(f, line, size);
ptr = readname(line, name, size);
if (strcmp(name, "module") == 0) {
readname(ptr, lastmodule, size);
}
}
fclose(f);
printf("Last module was: %s\n",lastmodule);
}
(This scans a text file looking for the last line roughly matching:
[<white-space>] module <white-space> <filename> [<don't care>])
Is this really that objectionable? If a module name was expected, and it
displays "(none)", it means something went wrong. The probability that
an over-long line is split into two by fgets at just the write spot so that:
...........notmodule file.c
gives a spurious 'module file.c' input for the next line, is ignored.
The support headers and functions are here; C requires these occur
before the main() function:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int ateof(FILE *f) {
int c;
c = fgetc(f);
if (c == EOF) return 1;
ungetc(c,f);
return 0;
}
int readnextline(FILE *f, char *buffer, int size) {
*buffer = 0;
fgets(buffer, size, f);
}
char* readname(char *ptr, char *dest, int size) {
int length = 0;
*dest=0;
while (1) {
// can't use switch here as its 'break' clashes with 'while'
// stupid language ....
if (*ptr==' ' || *ptr=='\t') {
++ptr;
} else if (*ptr == 0) {
return ptr;
} else {
break;
}
}
*dest++ = *ptr++;
length = 1;
while (1) {
switch (*ptr) {
case ',': case '=': case ' ': case '\t':
*dest = 0;
return ptr+1;
case 0:
*dest = 0;
return ptr;
default:
if (++length < size) {
*dest++ = *ptr++;
} else {
++ptr;
}
}
}
return NULL;
}
--
bart
[toc] | [prev] | [next] | [standalone]
Page 4 of 18 — ← Prev page 1 2 3 [4] 5 6 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web