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 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-02 09:43 -0400 |
| Message-ID | <povsmj$606$1@dont-email.me> |
| In reply to | #135996 |
On 10/2/2018 9:35 AM, David Brown wrote:
> On 02/10/18 15:16, Rick C. Hodgin wrote:
>
>> The syntax "a, b, c" already has meaning in CAlive, as it allows
>> multiple return values. For your version to work, it would need
>> to be encoded in CAlive as "a, b, c = (10, 20, 30);"
>>
>> int a, b, c;
>>
>> a, b, c = some_function(5);
>>
>> // The function definition in CAlive
>> function some_function
>> | params int i
>> | returns int r1, r2, r3
>> {
>> r1 = i + 5;
>> r2 = i + 4;
>> r3 = i + 3;
>> }
>>
>> By assigning the values to the return variables, rather
>> than issuing a simple "return x;" the ability to have
>> multiple return values becomes obvious.
>>
>> Mechanically they are stored as pointers to those variables
>> and are handled that way. It would be the same as if you
>> wrote this in C:
>>
>> void some_function(int i, int *r1, int *r2, int *r3)
>> {
>> *r1 = i + 5;
>> *r2 = i + 4;
>> *r3 = i + 3;
>> }
>>
>> int a, b, c;
>>
>> some_function(5, &a, &b, &c);
>
> It would probably be more efficient to consider the function as
> returning a struct of three int's, rather than passing three
> pointers-to-int. Struct returns that are too big to fit in a register
> are typically implemented by passing a pointer to the struct - but now
> you are passing a single pointer, not three.
Yep. This is the design I added to my Arxoda CPU with the
addition of new base-pointer registers (lower-left):
http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/arxoda/core/wex_register_mapping.png
wspp stands for "Stack Pointer Parameters," and wbpp stands
for "Base Pointer Parameters." It is that very way of hav-
ing large numbers of input or return values prepared at com-
pile time, and then passed in that way.
It's also more efficient, depending on how often r1, r2, and
r3 are used, to store them to temporary variables, and then
do an atexit() algorithm which assigns them to their pointer
values one time.
But, those are all mechanics ... and who cares? :-)
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-02 10:51 -0700 |
| Message-ID | <ln1s988cfk.fsf@kst-u.example.com> |
| In reply to | #135993 |
Bart <bc@freeuk.com> writes:
[...]
> (If you are using C syntax, then C's comma operator will screw this up:
>
> a, b, c = 10, 20, 30;
>
> is legal C, but has the effect of assigning 10 to c, and leaving a and b
> unchanged. (This is somewhat surprising, I expected 30 to be assigned to
> C.))
It's not surprising if you remember that the comma operator has
lower precedence than the assignment operator.
You can *very loosely* think of the comma operator as similar to
the semicolon, but separating expressions rather than statements.
(No need to enumerate the ways in which they differ.) (The idea
that an assignment is an expression may seem odd to some.)
Of course you can use parentheses:
c = (10, 20, 30);
which is useful if the operands are expressions with side effects.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-02 09:08 -0400 |
| Message-ID | <povql8$oqj$1@dont-email.me> |
| In reply to | #135992 |
On 10/2/2018 8:58 AM, Bart wrote:
> On 02/10/2018 13:20, Rick C. Hodgin wrote:
>> On Monday, October 1, 2018 at 10:46:57 AM UTC-4, skybu...@hotmail.com wrote:
>>> On Tuesday, August 14, 2018 at 4:50:55 PM UTC+2, bart...@gmail.com wrote:
>>>> How about just swap(x,y) then you don't need to explain what >< means.
>>>
>>> I have seen "swap" functions that would surprise you, they do something
>>> different than you thought. Therefore it's still required to examine the
>>> "swap" function.
>>>
>>> With A> going to B and <B going to A, I think it's much more clear what is
>>> going to happen :)
>>>
>>> Plus it's the shortest notation so far ;)
>>
>> I agree. I think "a >< b" is a great construction. I would
>> suggest that that operator should exist, along with "><=" so
>> that it works stand alone:
>>
>> int a = 5, b = 3;
>>
>> printf("a=%d, b=%d\n", a, b);
>>
>> a ><= b;
>
> I think a><b is terrible. (And a><=b worse. Not least because I've no idea
> what the difference is between ><= and ><. If a+b can be written stand-alone,
> why can't a><b?)
"a + b" can be written stand-alone, but it has no effect unless
it's in some other context;
int a = 5, b = 3;
a + b;
a >< b;
What does "a + b;" do? Nothing. It would compute operations:
01: load a
02: load b
03: add
04: discard the result
The "a >< b;" swap operator does have meaning in that context:
01: load a
02: store t
03: load b
04: store b to a
05: store t to b
But, it's confusing in source code. That's why I say ><= should
exist. At least that way the eye will see it's an assignment.
> One reason it's terrible is that it's just some random, made-up symbol with
> no long history of use (unlike "+" for example).
There was a time when + didn't exist. I've seen ancient math
and they don't use a + sign. They use something else, often
simply being positional with no symbol.
All things have an inception date. Using * for a pointer didn't
always exist. It had an inception date. >< does too. And so
does ><=.
> And also, swap, IME, is quite an uncommon operation so doesn't need such a
> compact and mysterious representation, and is never needed in an expression
> so it doesn't need a result type.
Even if >< and ><= exist, there's nothing to prevent you using
swap:
#define swap(a,b) a >< b
Now you can have your swap() and eat it too. :-)
> (At one time I used ":=:" for swap, in a language where ":=" was assignment
> so that ":=:" suggested a two-way assignment. But eventually I dropped that
> and just used the much easier to type, and far more obvious:
:=: is a good syntax too. I like it as well.
My thinking on >< is it kind of goes along with the spaceship
operator. It's an extension that has a purpose.
> swap(a,b)
>
> What actually is the problem with just using this?)
Unless you defined swap() to be swap(int& a, int& b), it would
not work. It would make more sense in C's context to be:
swap(&a, &b);
Using "a >< b;" or "a ><= b;" is much cleaner in my opinion.
>> printf("a=%d, b=%d\n", a, b);
>>
>> The >< operator can still be used in-flight, in the middle of other
>> expressions, switching them there in place, which may yield the re-
>> sult of some intermediate able to be switched with the indicated
>> value.
>
> /Which/ intermediate value? Any return value must be an obvious one, but
> there is no obvious result type from swap().
I mean when it's used in an expression like this:
int new_value = 0;
// Only test if there are two valid samples in a row
if (new_value >< get_sample())
// Code here
> The only one I can think is for swap(a,b) to simply return the multiple value
> (b,a), but such values are difficult to work with and require further
> language features.
I think it should return the right-hand value. "a >< b" would
return the b value.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-02 15:26 +0100 |
| Message-ID | <EeLsD.532215$%L2.146241@fx15.am4> |
| In reply to | #135994 |
On 02/10/2018 14:08, Rick C. Hodgin wrote:
> On 10/2/2018 8:58 AM, Bart wrote:
>> I think a><b is terrible. (And a><=b worse. Not least because I've no
>> idea what the difference is between ><= and ><. If a+b can be written
>> stand-alone, why can't a><b?)
>
> "a + b" can be written stand-alone, but it has no effect unless
> it's in some other context;
Perhaps that was a bad example. "a=b" is better, as that has the same
syntax inside an expression and outside it. Or a+=b.
Although technically, it's impossible to be outside an expression, if
this is anywhere C-like.
Because in C, an expression can be a statement. So if a><b is legal in
an expression, then so is this:
a><b;
> There was a time when + didn't exist. I've seen ancient math
> and they don't use a + sign. They use something else, often
> simply being positional with no symbol.
>
> All things have an inception date. Using * for a pointer didn't
> always exist.
* was an invention of C, but it occurs EVERYWHERE in the language. So it
deserves a compact representation. Anyone using C needs to know about
it, and that knowledge is constantly reinforced by seeing it all the time.
Swap is only used infrequently, and it doesn't need some meaningless
symbol to be created for it.
> #define swap(a,b) a >< b
>
> Now you can have your swap() and eat it too. :-)
This is what I don't understand. You seem to think it's great that you
can make a><b work like swap(a,b). So why not just used swap(a,b); why
the preoccupation with cryptic symbols?
(And using #define is unsatisfactory for the same reasons such
'solutions' in C always are. Now you have drag a little library of such
#defines along with any code that uses swap. Everybody else will be
using SWAP or Swap for such a define. Or they will already have a 'swap'
macro that does something entirely different.)
>> (At one time I used ":=:" for swap, in a language where ":=" was
>> assignment so that ":=:" suggested a two-way assignment. But
>> eventually I dropped that and just used the much easier to type, and
>> far more obvious:
>
> :=: is a good syntax too. I like it as well.
You're welcome to it. I found it a pain to type, because it's shift,
un-shift, shift.
> My thinking on >< is it kind of goes along with the spaceship
> operator. It's an extension that has a purpose.
No, that was to do with compare, which doesn't modify its operands. It
is unrelated.
(On that note, I use <> for not-equals, which is similar to the <=>
spaceship operator. But <> was used in existing languages for not-equals.)
>
>> swap(a,b)
>>
>> What actually is the problem with just using this?)
>
> Unless you defined swap() to be swap(int& a, int& b), it would
> not work.
I don't understand. This is a new feature, that /you/ implement, you
make it work as you like. It's not a function, but syntax that looks
like a function call.
And anyway, swap(int&,int&) [what language is that?], is not a swap
operator, as it would only swap ints.
Besides, it /does/ work [not C]:
int a:=100, b:=99999
println a,b
swap(a,b)
println a,b
Output:
100 99999
99999 100
> It would make more sense in C's context to be:
>
> swap(&a, &b);
I thought that (int&,int&) defined reference parameters so that you
didn't need & here?
Whatever, the question is why are you so worried about implementation
details for swap(a,b), but not a><b? It's not as though using the latter
syntax instead of the former gives you some magical free pass so that it
just works without having to think about how.
>
> Using "a >< b;" or "a ><= b;" is much cleaner in my opinion.
I would guess that would be a minority option. Ask 100 programmers of
any language what they think "a><b" means. Then ask them what they think
"swap(a,b)" means. Which one do you think they will get right more?
> I mean when it's used in an expression like this:
>
> int new_value = 0;
>
> // Only test if there are two valid samples in a row
> if (new_value >< get_sample())
I have no idea what this is supposed to mean.
I thought that >< swapped the values of its operands in-place, so how
does that work with a function-call?
Perhaps you have another kind of operator in mind, but you'd have to
spell out, using conventional operators that everyone will know, how
this code fragment works.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-02 10:52 -0400 |
| Message-ID | <pp00nk$195$1@dont-email.me> |
| In reply to | #136000 |
On 10/2/2018 10:26 AM, Bart wrote:
> On 02/10/2018 14:08, Rick C. Hodgin wrote:
>> #define swap(a,b) a >< b
>> Now you can have your swap() and eat it too. :-)
>
> This is what I don't understand. You seem to think it's great that you can
> make a><b work like swap(a,b). So why not just used swap(a,b); why the
> preoccupation with cryptic symbols?
Are these non-cryptic?
b = *c;
c = &a;
Things are only cryptic until they're not. I'll be honest,
when I first saw the spaceship operator, I immediately
thought back to what Vader's ship looked like:
https://www.starwars.com/databank/darth-vader-s-tie-fighter
I'm surprised someone hasn't called that operator the "vader."
> (And using #define is unsatisfactory for the same reasons such 'solutions' in
> C always are. Now you have drag a little library of such #defines along with
> any code that uses swap. Everybody else will be using SWAP or Swap for such a
> define. Or they will already have a 'swap' macro that does something entirely
> different.)
>
>>> (At one time I used ":=:" for swap, in a language where ":=" was
>>> assignment so that ":=:" suggested a two-way assignment. But eventually I
>>> dropped that and just used the much easier to type, and far more obvious:
>>
>> :=: is a good syntax too. I like it as well.
>
> You're welcome to it. I found it a pain to type, because it's shift,
> un-shift, shift.
It's like step, bump, step, bump bump (at 1:02):
https://www.youtube.com/watch?v=D6VQDNIZH7U&t=1m2s
Only different. And I can't advocate everything on that
video, just the step bump, step bump bump part. Funny. :-)
>> My thinking on >< is it kind of goes along with the spaceship
>> operator. It's an extension that has a purpose.
>
> No, that was to do with compare, which doesn't modify its operands. It is
> unrelated.
Okay, what if we used <=> for the vader1 operator (spaceship),
and >=< for for the vader2 operator (swap). Nothing confusing
about that.
> (On that note, I use <> for not-equals, which is similar to the <=> spaceship
> operator. But <> was used in existing languages for not-equals.)
I used to use <> for not-equal, and then I discovered !=. In
XBASE languages you can also use # for not-equal. It's sup-
posed to be like an equal with a line through it.
>>> swap(a,b)
>>>
>>> What actually is the problem with just using this?)
>>
>> Unless you defined swap() to be swap(int& a, int& b), it would
>> not work.
>
> I don't understand. This is a new feature, that /you/ implement, you make it
> work as you like. It's not a function, but syntax that looks like a function
> call.
I think that part's confusing. It would be like "they're all
functions everywhere ... except swap, which is different." No
confusion there I'm sure. :-)
> And anyway, swap(int&,int&) [what language is that?], is not a swap operator,
> as it would only swap ints.
I was using it as an example.
> Besides, it /does/ work [not C]:
>
> int a:=100, b:=99999
>
> println a,b
> swap(a,b)
> println a,b
>
> Output:
>
> 100 99999
> 99999 100
>
>
>> It would make more sense in C's context to be:
>>
>> swap(&a, &b);
>
> I thought that (int&,int&) defined reference parameters so that you didn't
> need & here?
Yes. But this is one of my arguments against allowing a
user to pass in a and b to something like swap here, which
would have int& for the parameters, because on the call
there is no indication they could be updated in that way.
I think they should be passed in using:
swap(@a, @b);
In that way it indicates they are potentially updated.
> Whatever, the question is why are you so worried about implementation details
> for swap(a,b), but not a><b? It's not as though using the latter syntax
> instead of the former gives you some magical free pass so that it just works
> without having to think about how.
By introducing >< you gain the ability to use swap(a,b).
By introducing swap(a,b) you're stuck with it, and do
not have the >< ability.
I see one solution as addressing your wants, and other
people's wants who don't want to use swap(). And another
solution addressing those who don't mind using swap()
only.
>> Using "a >< b;" or "a ><= b;" is much cleaner in my opinion.
>
> I would guess that would be a minority option. Ask 100 programmers of any
> language what they think "a><b" means. Then ask them what they think
> "swap(a,b)" means. Which one do you think they will get right more?
That's true of most things in C. You ask most people
what many things in C mean and they'll tell you straight
up. "Nothing confusing here. Move along. Move along."
>> I mean when it's used in an expression like this:
>>
>> int new_value = 0;
>>
>> // Only test if there are two valid samples in a row
>> if (new_value >< get_sample())
>
> I have no idea what this is supposed to mean.
It would be like this:
old_new_value = new_value;
t = get_sample();
swap(t, new_value);
if (old_new_value)
> I thought that >< swapped the values of its operands in-place, so how does
> that work with a function-call?
The function call returns a value. That value is in-flight
at that usage, allowing the value being returned to be swapped
with the prior value, which then assigns the new sample value
to new_value, and uses the old new_value to do the test.
> Perhaps you have another kind of operator in mind, but you'd have to spell
> out, using conventional operators that everyone will know, how this code
> fragment works.
I have lots of ideas. My brain is constantly in motion,
and not just when I'm walking. :-) Sometimes I can't shut
the darned thing off.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-02 17:57 +0100 |
| Message-ID | <YrNsD.264$BM.147@fx09.am4> |
| In reply to | #136005 |
On 02/10/2018 15:52, Rick C. Hodgin wrote:
> On 10/2/2018 10:26 AM, Bart wrote:
> I think that part's confusing. It would be like "they're all
> functions everywhere ... except swap, which is different." No
> confusion there I'm sure. :-)
How about this in C:
f(a,b) // this doesn't modify a and b
g(a,b) // this modifies a and b
h(a,b) // h is a pointer to function, unlike f and g
i(a,b) // a and b are arrays
j(a,b) // a and b are pointers
Two kinds of function, two kinds of argument, two kinds of behaviour,
for the same x(y,z) function syntax. Or this:
k(a,b)
where k is a macro, so /anything/ is possible. And what exactly does f()
do anyway? You'd have to look at the docs. The docs for:
swap(a,b)
will say that a and b are modified.
> there is no indication they could be updated in that way.
But that is OK when using ><?
In my language, 'swap' can be used as though it was an operator, or a
function:
a swap b
swap(a, b)
It's just syntax.
> I think they should be passed in using:
>
> swap(@a, @b);
> In that way it indicates they are potentially updated.
Only when using an operator like 'swap' isn't enough of a clue. And if
it isn't, then using @a and @b won't be enough: how exactly will they be
updated?
>> Whatever, the question is why are you so worried about implementation
>> details for swap(a,b), but not a><b? It's not as though using the
>> latter syntax instead of the former gives you some magical free pass
>> so that it just works without having to think about how.
>
> By introducing >< you gain the ability to use swap(a,b).
> By introducing swap(a,b) you're stuck with it, and do
> not have the >< ability.
By having the most sensible choice in the first place, there will be
less need to redefine built-in features.
Suppose (1) there was a way to define new infix operator symbols and to
attach those to an existing operation; (2) there was a swap operator
used as 'swap(a,b)'.
Then, how many would feel the need to create an operator version of
swap? How many would choose to use "><"?
(Didn't this come up in another thread where you were similarly
advocating using weird symbols for min and max, instead of just using
min and max?
That I can't remember what those symbols says enough about it I think.
For min and max at least, nothing has to be updated.)
>>> if (new_value >< get_sample())
>>
>> I have no idea what this is supposed to mean.
>
> It would be like this:
>
> old_new_value = new_value;
> t = get_sample();
> swap(t, new_value);
> if (old_new_value)
Since t is not used anywhere else, this is equivalent to:
old_new_value = new_value;
new_value = get_sample();
if (old_new_value)
So nothing to do with swap. What it does is another feature that has
been discussed here in the past, some way to update a variable, but
return its prior value.
Trying to associate swap() with that is a big mistake I think.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-02 13:27 -0400 |
| Message-ID | <pp09qj$vma$1@dont-email.me> |
| In reply to | #136008 |
On 10/2/2018 12:57 PM, Bart wrote: > On 02/10/2018 15:52, Rick C. Hodgin wrote: >> On 10/2/2018 10:26 AM, Bart wrote: > >> I think that part's confusing. It would be like "they're all >> functions everywhere ... except swap, which is different." No >> confusion there I'm sure. :-) > > How about this in C: > > f(a,b) // this doesn't modify a and b > g(a,b) // this modifies a and b > h(a,b) // h is a pointer to function, unlike f and g > i(a,b) // a and b are arrays > j(a,b) // a and b are pointers I agree completely. I think function pointers should also be referenced using @h() so it indicates clearly what it is. I might even desire the syntax *h() to indicate you're calling the thing pointed to by h. > Two kinds of function, two kinds of argument, two kinds of behaviour, for the > same x(y,z) function syntax. Or this: > > k(a,b) > > where k is a macro, so /anything/ is possible. And what exactly does f() do > anyway? You'd have to look at the docs. The docs for: > > swap(a,b) > > will say that a and b are modified. > > >> there is no indication they could be updated in that way. > > But that is OK when using ><? > > In my language, 'swap' can be used as though it was an operator, or a function: > > a swap b > swap(a, b) > > It's just syntax. #define swap >< You have your success then. >> I think they should be passed in using: >> >> swap(@a, @b); > >> In that way it indicates they are potentially updated. > > Only when using an operator like 'swap' isn't enough of a clue. And if it > isn't, then using @a and @b won't be enough: how exactly will they be updated? No. Who's to say it's not S-WAP, indicating a secure access prototol of some kind? That's one of the easiest ways to obfuscate code is to call functions by some other name. You can't go by that. >>> Whatever, the question is why are you so worried about implementation >>> details for swap(a,b), but not a><b? It's not as though using the latter >>> syntax instead of the former gives you some magical free pass so that it >>> just works without having to think about how. >> >> By introducing >< you gain the ability to use swap(a,b). >> By introducing swap(a,b) you're stuck with it, and do >> not have the >< ability. > > By having the most sensible choice in the first place, there will be less > need to redefine built-in features. > > Suppose (1) there was a way to define new infix operator symbols and to > attach those to an existing operation; (2) there was a swap operator used as > 'swap(a,b)'. > > Then, how many would feel the need to create an operator version of swap? How > many would choose to use "><"? > > (Didn't this come up in another thread where you were similarly advocating > using weird symbols for min and max, instead of just using min and max? > > That I can't remember what those symbols says enough about it I think. For > min and max at least, nothing has to be updated.) > >>>> if (new_value >< get_sample()) >>> >>> I have no idea what this is supposed to mean. >> >> It would be like this: >> >> old_new_value = new_value; >> t = get_sample(); >> swap(t, new_value); >> if (old_new_value) > > Since t is not used anywhere else, this is equivalent to: > > old_new_value = new_value; > new_value = get_sample(); > if (old_new_value) > > So nothing to do with swap. What it does is another feature that has been > discussed here in the past, some way to update a variable, but return its > prior value. > > Trying to associate swap() with that is a big mistake I think. It exists that way, Bart. That is its operation. I don't think we'll agree on this, so I'll agree to disagree. I think >< is nice. I think we need ><= as well. I may add them to CAlive. We'll see. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-02 11:52 -0700 |
| Message-ID | <d6896a2a-e07c-4465-8e90-fd50ddb3fd9f@googlegroups.com> |
| In reply to | #136011 |
On Tuesday, October 2, 2018 at 1:27:55 PM UTC-4, Rick C. Hodgin wrote: > I don't think we'll agree on this, so I'll agree to disagree. > I think >< is nice. I think we need ><= as well. I may add > them to CAlive. We'll see. Bart, I will add this general comment: I like operators. I like their utility, I like the fact that they're fundamental to the language, and I like that with #define references you can create a word to represent them and use that word in your code. I believe operators should have a place. All they need is a special encoding, and then you can #define any wrapper around them you want. I do not believe in adding special cases (like swap(a,b)) to be a built-in compiler feature that behaves differently than other functions. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-02 20:48 +0100 |
| Message-ID | <3YPsD.393167$tw.210351@fx11.am4> |
| In reply to | #136016 |
On 02/10/2018 19:52, Rick C. Hodgin wrote: > On Tuesday, October 2, 2018 at 1:27:55 PM UTC-4, Rick C. Hodgin wrote: >> I don't think we'll agree on this, so I'll agree to disagree. >> I think >< is nice. I think we need ><= as well. I may add >> them to CAlive. We'll see. > > Bart, I will add this general comment: I like operators. I > like their utility, I like the fact that they're fundamental > to the language, and I like that with #define references you > can create a word to represent them and use that word in your > code. > > I believe operators should have a place. All they need is a > special encoding, and then you can #define any wrapper around > them you want. Slight problem: there is a limit to how many different operators you can practically create out of combining any of < = > + - ! ~ * / & % | ? : ^. A three character sequence will give 3000 combinations, but how many would anyone remember beyond a dozen new ones? Named operators on the other hand can easily contain 4, 5, 6 or more characters with little trouble, and they can be chosen to spell out some meaningful function, or serve as an aide-memoire more effectively than !*@&. There is no real limit to how many could be created. (My languages use identifiers for many operators; see a selection below. I'd be really interested in what symbol you would choose for the 'in' operator (a in b returns true when a occurs in b; the details depend on the types). There is also the composite operator 'not in'. BTW if you like operator-rich languages, have a look at K, a version of APL but using ASCII. Very powerful language, but even a one-line program is unreadable.) > I do not believe in adding special cases (like swap(a,b)) to > be a built-in compiler feature that behaves differently than > other functions. What not? You take arguments a and b, apply swap to them, and something happens. Just the same as applying any function. ------------------------------------------------------ and infix or iand ior ixor in rem min infix or function-style syntax max swap clamp concat append not prefix inot abs sqrt Written as 'sqrt a' sqr sin ... len Written as 'a.len' lwb upb minvalue maxvalue bytes bitwidth isint ... -- bart
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-02 15:56 -0400 |
| Message-ID | <pp0ihj$r43$1@dont-email.me> |
| In reply to | #136019 |
On 10/2/2018 3:48 PM, Bart wrote: > On 02/10/2018 19:52, Rick C. Hodgin wrote: >> On Tuesday, October 2, 2018 at 1:27:55 PM UTC-4, Rick C. Hodgin wrote: >>> I don't think we'll agree on this, so I'll agree to disagree. >>> I think >< is nice. I think we need ><= as well. I may add >>> them to CAlive. We'll see. >> >> Bart, I will add this general comment: I like operators. I >> like their utility, I like the fact that they're fundamental >> to the language, and I like that with #define references you >> can create a word to represent them and use that word in your >> code. >> >> I believe operators should have a place. All they need is a >> special encoding, and then you can #define any wrapper around >> them you want. > > Slight problem: there is a limit to how many different operators you can > practically create out of combining any of < = > + - ! ~ * / & % | ? : ^. You can introduce @ and # in use. CAlive makes use of @ and # in new ways. > A three character sequence will give 3000 combinations, but how many would > anyone remember beyond a dozen new ones? LOL! I actually laughed out loud on that part. :-) That's not the issue. There are only so many operators that are needed. We have code today that does what they do, and a few new ones can be added like the spaceship operator, and like swap. They're basic operations that make sense. How many more do we need? > Named operators on the other hand can easily contain 4, 5, 6 or more > characters with little trouble, and they can be chosen to spell out some > meaningful function, or serve as an aide-memoire more effectively than !*@&. > There is no real limit to how many could be created. I would say two characters plus an optional equal sign. I also would have no problem defining a new character to represent an operator, and make it a single character / keystroke on a special programmer keyboard. > (My languages use identifiers for many operators; see a selection below. > > I'd be really interested in what symbol you would choose for the 'in' > operator (a in b returns true when a occurs in b; the details depend on the > types). There is also the composite operator 'not in'. I have function for those. I use in(needle, haystack1, hay2, ... hayN); I also have occurs(needle, haystack); which searches the string haystack for the string needle, and returns how many times it occurs. Those are ideal for functions. > BTW if you like operator-rich languages, have a look at K, a version of APL > but using ASCII. Very powerful language, but even a one-line program is > unreadable.) If it's unreadable ... it's not for me, but I'll look at it out of curiosity. Did you ever have a chance to look at Julia? >> I do not believe in adding special cases (like swap(a,b)) to >> be a built-in compiler feature that behaves differently than >> other functions. > > What not? You take arguments a and b, apply swap to them, and something > happens. Just the same as applying any function. > > ------------------------------------------------------ > > and infix > or > iand > ior > ixor > in > rem > > min infix or function-style syntax > max > swap > clamp > concat > append > > > not prefix > inot > abs > > sqrt Written as 'sqrt a' > sqr > sin > ... > > len Written as 'a.len' > lwb > upb > minvalue > maxvalue > bytes > bitwidth > > isint > ... I'd have to see them in use. RDC does allow for a target to reference the things to the right or left of it, and if you place the right priority on things, any of those could be added as an operator and use the left and right relative objs for input. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-10-02 13:05 -0700 |
| Message-ID | <54f174c8-9184-437a-9457-df9be71daf53@googlegroups.com> |
| In reply to | #136019 |
On Tuesday, October 2, 2018 at 4:48:25 PM UTC-3, Bart wrote: > On 02/10/2018 19:52, Rick C. Hodgin wrote: > > On Tuesday, October 2, 2018 at 1:27:55 PM UTC-4, Rick C. Hodgin wrote: > >> I don't think we'll agree on this, so I'll agree to disagree. > >> I think >< is nice. I think we need ><= as well. I may add > >> them to CAlive. We'll see. > > > > Bart, I will add this general comment: I like operators. I > > like their utility, I like the fact that they're fundamental > > to the language, and I like that with #define references you > > can create a word to represent them and use that word in your > > code. > > > > I believe operators should have a place. All they need is a > > special encoding, and then you can #define any wrapper around > > them you want. > > Slight problem: there is a limit to how many different operators you can > practically create out of combining any of < = > + - ! ~ * / & % | ? : ^. > > A three character sequence will give 3000 combinations, but how many > would anyone remember beyond a dozen new ones? > > Named operators on the other hand can easily contain 4, 5, 6 or more > characters with little trouble, and they can be chosen to spell out some > meaningful function, or serve as an aide-memoire more effectively than > !*@&. There is no real limit to how many could be created. > > (My languages use identifiers for many operators; see a selection below. > > I'd be really interested in what symbol you would choose for the 'in' > operator (a in b returns true when a occurs in b; the details depend on > the types). There is also the composite operator 'not in'. > > BTW if you like operator-rich languages, have a look at K, a version of > APL but using ASCII. Very powerful language, but even a one-line program > is unreadable.) > > > > I do not believe in adding special cases (like swap(a,b)) to > > be a built-in compiler feature that behaves differently than > > other functions. > > What not? You take arguments a and b, apply swap to them, and something > happens. Just the same as applying any function. The importance of operators in C, is that they are built-in polymorphic operations. People that want swap operator (I had suggested this also some time ago) is because having this operator we don't need to implement it for all types. The min a max function doesn't have this problem because they can be implemented with simple macros. We can find other operations that have the same characteristic. I find symbols hard to remember compared with names. We have in math the symbol for set union, set intersection etc and it is hard to remember. These operations also would be very useful in computing.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-02 13:26 -0700 |
| Message-ID | <lnlg7g6qo4.fsf@kst-u.example.com> |
| In reply to | #136023 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Tuesday, October 2, 2018 at 4:48:25 PM UTC-3, Bart wrote:
>> On 02/10/2018 19:52, Rick C. Hodgin wrote:
[...]
>> > I do not believe in adding special cases (like swap(a,b)) to
>> > be a built-in compiler feature that behaves differently than
>> > other functions.
>>
>> What not? You take arguments a and b, apply swap to them, and something
>> happens. Just the same as applying any function.
>
> The importance of operators in C, is that
> they are built-in polymorphic operations.
> People that want swap operator (I had suggested this also
> some time ago) is because having this operator we
> don't need to implement it for all types.
> The min a max function doesn't have this problem because
> they can be implemented with simple macros.
> We can find other operations that have the same characteristic.
>
> I find symbols hard to remember compared with names.
> We have in math the symbol for set union, set intersection etc
> and it is hard to remember. These operations also would be very
> useful in computing.
There's no reason the name of an operator has to be made up of
punctuation characters. Most of them are, but `sizeof` and `_Alignof`
are both operators, and their names are keywords.
*If* we wanted to add a swap operator to C, it could easily be defined
as an operator with two operands:
a swap b
with whatever semantics seem appropriate. (Of course "swap" is
already used as an identifier in existing code. We could have a
_Swap keyword and a new header defining "swap" as a macro.)
I would opppose making "swap" a new built-in operation whose syntax
makes it look like a function call:
swap(a, b)
(There's also std::swap in C++, which depends on features that C doesn't
have.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-02 21:36 +0100 |
| Message-ID | <1FQsD.356348$4w.83290@fx44.am4> |
| In reply to | #136029 |
On 02/10/2018 21:26, Keith Thompson wrote:
> I would opppose making "swap" a new built-in operation whose syntax
> makes it look like a function call:
> swap(a, b)
But sizeof(a) is OK?
And as is any function-like macro invocation?
And as are many variable declarations when someone decides to add
parentheses? Example:
typedef int f;
f(a);
Anyway, 'sizeof' is a reserved word in C with its own rules, and so
would 'swap' be.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-02 13:47 -0700 |
| Message-ID | <lnh8i46ppz.fsf@kst-u.example.com> |
| In reply to | #136030 |
Bart <bc@freeuk.com> writes:
> On 02/10/2018 21:26, Keith Thompson wrote:
>> I would opppose making "swap" a new built-in operation whose syntax
>> makes it look like a function call:
>> swap(a, b)
>
> But sizeof(a) is OK?
>
> And as is any function-like macro invocation?
>
> And as are many variable declarations when someone decides to add
> parentheses? Example:
>
> typedef int f;
>
> f(a);
>
> Anyway, 'sizeof' is a reserved word in C with its own rules, and so
> would 'swap' be.
A valid point.
Note that `sizeof(a)` where a is a type name is a special case syntax
(I wouldn't have called sizeof an "operator" in that case, but I
accept that the language calls it one). If a is an expression,
then the parentheses aren't part of the syntax of the operator,
it's just the operator applied to a parenthesized expression.
I write `sizeof a` rather than `sizeof(a)` for the same reason I
write `-1` rather than `-(1)`.
And if `swap` is an operator keyword, why not follow existing
convention and infix syntax for an operator that takes two operands?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-03 11:14 +0200 |
| Message-ID | <pp219a$32p$1@dont-email.me> |
| In reply to | #136030 |
On 02/10/18 22:36, Bart wrote:
> On 02/10/2018 21:26, Keith Thompson wrote:
>
>> I would opppose making "swap" a new built-in operation whose syntax
>> makes it look like a function call:
>> swap(a, b)
>
> But sizeof(a) is OK?
The thing I would question about "swap(a, b)" in C is that it /changes/
"a" and "b". "sizeof" and "_Alignof" are operators with names rather
than symbols, but they don't change anything - they are only for inspection.
When you see "f(a, b)" in C, you expect "a" and "b" to be unchanged
afterwards. You can, of course, write a macro that breaks this rule -
but there is a solid tradition that it be written in all-caps, like
"SWAP(a, b)" to indicate there is something odd going on.
In C++, reference parameters mean it is fine to write functions that do
change things - so for C++ programmers, there would not be a problem.
(And they already have "std::swap(a, b)" that does the job.)
("sizeof" is also different in that you can write "sizeof a", which is
what many people prefer. Personally, I tend to use more parenthesis
than necessary and write "sizeof(a)", but that's just my habits. I
don't think "swap a, b;" would be a popular alternative.)
>
> And as is any function-like macro invocation?
>
> And as are many variable declarations when someone decides to add
> parentheses? Example:
>
> typedef int f;
>
> f(a);
>
> Anyway, 'sizeof' is a reserved word in C with its own rules, and so
> would 'swap' be.
>
If there were a point in having a "swap" operator as fundamental in C,
then I would like a syntax such as "_Swap(a, b)". "swap" is too common
a word to be made a keyword at this stage in the language.
However, I can't see the slightest benefit in having it in the language.
Swapping things is not a hugely common operation - it doesn't need an
operator or keyword of its own. And if you are writing code that does a
lot of swapping, you are likely to write a macro to do the job, or use
functions with pointers (letting the compiler optimise the code).
If you want to add something to the language to improve this, I would
much rather see the gcc "typeof" extension standardised so that you can
write:
#define swap(a, b) \
do { typeof(a) _a = a; \
a = b; \
b = _a; \
} while (0)
"typeof" is a vastly more useful and flexible extension, and will let
you write a "perfect" swap macro.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-02 16:37 -0400 |
| Message-ID | <pp0ktp$b0a$1@dont-email.me> |
| In reply to | #136029 |
On 10/2/2018 4:26 PM, Keith Thompson wrote:
> There's no reason the name of an operator has to be made up of
> punctuation characters. Most of them are, but `sizeof` and `_Alignof`
> are both operators, and their names are keywords.
Many of them should be replaced with something to convey their
meaning in something other than in words. Not everybody speaks
English. Symbols are good for certain things. They only have
to be learned once, and then used. The same can be said of the
English words, but why limit people to a specific language more
than need be?
sizeof(x) --> ?#(x) // # = number of characters
_Alignof(x) --> ?&&(x) // && = address of the address of x
And a lengthof(x), which is like sizeof(x) yet without the
trailing \0 being counted on strings:
lengthof(x) --> ?!(x) // ! = without \0 if char [], same
// as sizeof(x) otherwise
I also think when you use something built-in like that, it
shouldn't be using (), but rather []. It should be:
sizeof[x]
_Alignof[x]
lengthof[x]
And why introduce "_Alignof(x)" after sizeof(x) had already
been established? Why not alignof(x)?
It's like what posix did. "So many functions, do I prefix
this one with an underscore in this compiler? Is the posix
version supported? I don't know, let's try it and see if it
generates an error. Ope. An error. Try this alternate way
of spelling it. Another error. Let me try a third. Ah!
Got it."
I do not understand why those legacy things remain.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-02 22:02 +0100 |
| Message-ID | <52RsD.545684$ju.259221@fx18.am4> |
| In reply to | #136031 |
On 02/10/2018 21:37, Rick C. Hodgin wrote:
> On 10/2/2018 4:26 PM, Keith Thompson wrote:
>> There's no reason the name of an operator has to be made up of
>> punctuation characters. Most of them are, but `sizeof` and `_Alignof`
>> are both operators, and their names are keywords.
>
>
> Many of them should be replaced with something to convey their
> meaning in something other than in words. Not everybody speaks
> English. Symbols are good for certain things. They only have
> to be learned once, and then used. The same can be said of the
> English words, but why limit people to a specific language more
> than need be?
>
> sizeof(x) --> ?#(x) // # = number of characters
> _Alignof(x) --> ?&&(x) // && = address of the address of x
You really think that would be a benefit to anybody?
If so I won't bother arguing further.
> And a lengthof(x),
Ah, you've sensibly created a version that tells you the number of
elements in an array, so or I thought at first.
which is like sizeof(x) yet without the
> trailing \0 being counted on strings:
>
> lengthof(x) --> ?!(x) // ! = without \0 if char [], same
> // as sizeof(x) otherwise
But apparently this promising-sounding new feature just does this:
sizeof(x)-1
Although even that is badly defined; what would it give here:
char x[11] = "bart";
sizeof(x) gives 11; sizeof(x)-1 gives 10, but it sounds like lengthof(x)
gives 10 too, which are all wrong of you want the length of the
contained string (4) rather than the size of the array (11).
For the length of a string, use strlen. For the length of a string
constant, use:
strlen("bart")-1;
> I also think when you use something built-in like that, it
> shouldn't be using (), but rather []. It should be:
>
> sizeof[x]
> _Alignof[x]
> lengthof[x]
>
> And why introduce "_Alignof(x)" after sizeof(x) had already
> been established? Why not alignof(x)?
>
> It's like what posix did. "So many functions, do I prefix
> this one with an underscore in this compiler? Is the posix
> version supported? I don't know, let's try it and see if it
> generates an error. Ope. An error. Try this alternate way
> of spelling it. Another error. Let me try a third. Ah!
> Got it."
You missed out the ones starting with two underscores. Or ending with
them. Or both. C is really paranoid about encroaching on the namespaces
of programs written decades before.
I'm sure there are ways to deal with that without inconveniencing future
programmers for eternity.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2018-10-02 17:16 -0400 |
| Message-ID | <pp0n82$pqp$1@dont-email.me> |
| In reply to | #136044 |
On 10/2/2018 5:02 PM, Bart wrote:
> On 02/10/2018 21:37, Rick C. Hodgin wrote:
>> sizeof(x) --> ?#(x) // # = number of characters
>> _Alignof(x) --> ?&&(x) // && = address of the address of x
>
> You really think that would be a benefit to anybody?
> If so I won't bother arguing further.
#define sizeof ?#
#define _Alignof ?&&
Now everybody's happy. See how it works?
>> And a lengthof(x),
>
> Ah, you've sensibly created a version that tells you the number of elements
> in an array, so or I thought at first.
For that I have countof(x);
> which is like sizeof(x) yet without the
>> trailing \0 being counted on strings:
>>
>> lengthof(x) --> ?!(x) // ! = without \0 if char [], same
>> // as sizeof(x) otherwise
>
> But apparently this promising-sounding new feature just does this:
> sizeof(x)-1
>
> Although even that is badly defined; what would it give here:
> char x[11] = "bart";
4 of course. :-) But, that is baked in at compile-time. If
you later populate x with something else, you couldn't use
lengthof(x), but would need strlen(x).
> sizeof(x) gives 11; sizeof(x)-1 gives 10, but it sounds like lengthof(x)
> gives 10 too, which are all wrong of you want the length of the contained
> string (4) rather than the size of the array (11).
>
> For the length of a string, use strlen. For the length of a string constant,
> use:
> strlen("bart")-1;
Only if it's dynamic. I use lengthof(x) in my code as a
compile-time construct. It doesn't work well with C/C++
because it doesn't accommodate your char x[11] = "bart";
example, but I don't usually do that, and where I do I
manually add the special case code.
>> I also think when you use something built-in like that, it
>> shouldn't be using (), but rather []. It should be:
>>
>> sizeof[x]
>> _Alignof[x]
>> lengthof[x]
>>
>> And why introduce "_Alignof(x)" after sizeof(x) had already
>> been established? Why not alignof(x)?
>>
>> It's like what posix did. "So many functions, do I prefix
>> this one with an underscore in this compiler? Is the posix
>> version supported? I don't know, let's try it and see if it
>> generates an error. Ope. An error. Try this alternate way
>> of spelling it. Another error. Let me try a third. Ah!
>> Got it."
>
> You missed out the ones starting with two underscores. Or ending with them.
> Or both. C is really paranoid about encroaching on the namespaces of programs
> written decades before.
Each time I see them I literally shake my head, or at least
let out an exhale as I regather my concentration.
> I'm sure there are ways to deal with that without inconveniencing future
> programmers for eternity.
:-) I'd be keen to hear them, my friend.
Part of my goal with RDC is to allow add-ins that are dropped-
in at runtime, meaning the RDC CAlive database comes from the
factory as it does, allowing the parsing of files as is pre-
defined, but then a user can go into the editor and add-on
things they'd like to see in the language.
These add-ons are not trivial, but once they're developed, the
can be shared and passed around.
My goal is to change the way C/C++ developers write code, with
the great hope better compiler and debugger authors than myself
will come on board and make RDC and CAlive soar.
--
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-03 11:25 +0200 |
| Message-ID | <pp21uh$74d$1@dont-email.me> |
| In reply to | #136048 |
On 02/10/18 23:16, Rick C. Hodgin wrote: > On 10/2/2018 5:02 PM, Bart wrote: >> On 02/10/2018 21:37, Rick C. Hodgin wrote: >>> sizeof(x) --> ?#(x) // # = number of characters >>> _Alignof(x) --> ?&&(x) // && = address of the address of x >> >> You really think that would be a benefit to anybody? >> If so I won't bother arguing further. > > #define sizeof ?# > #define _Alignof ?&& > > Now everybody's happy. See how it works? No, /not/ everyone is happy. You always forget that people have to /read/ code as well as write it. Most people will write "sizeof" as before. And then you come across code that uses "?#" no one (except you) has the slightest clue what it might mean. It might be uglier to write "_Alignof" than "alignof", and some will write one version and other write the other version - but no one will have trouble understanding what is written.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-03 10:52 +0100 |
| Message-ID | <Pj0tD.708297$iK2.144389@fx08.am4> |
| In reply to | #136080 |
On 03/10/2018 10:25, David Brown wrote:
> On 02/10/18 23:16, Rick C. Hodgin wrote:
>> On 10/2/2018 5:02 PM, Bart wrote:
>>> On 02/10/2018 21:37, Rick C. Hodgin wrote:
>>>> sizeof(x) --> ?#(x) // # = number of characters
>>>> _Alignof(x) --> ?&&(x) // && = address of the address of x
>>>
>>> You really think that would be a benefit to anybody?
>>> If so I won't bother arguing further.
>>
>> #define sizeof ?#
>> #define _Alignof ?&&
>>
>> Now everybody's happy. See how it works?
>
> No, /not/ everyone is happy. You always forget that people have to
> /read/ code as well as write it.
>
> Most people will write "sizeof" as before. And then you come across
> code that uses "?#" no one (except you) has the slightest clue what it
> might mean.
Not even Rick will know when he comes across:
a><f()??#(b):b>:c
Using normal identifiers, that would be:
swap(a,f())?sizeof(b):min(b,c) // or it might be max
This is not that meaningful as it applies swap() in a weird manner that
only makes sense to Rick, but at least you can now see what operations
are being used.
--
bart
[toc] | [prev] | [next] | [standalone]
Page 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web