Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #97546 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2016-11-26 12:49 -0800 |
| Last post | 2016-12-01 12:33 +0800 |
| Articles | 20 on this page of 567 — 30 participants |
Back to article view | Back to comp.lang.c
absence of max fir <profesor.fir@gmail.com> - 2016-11-26 12:49 -0800
absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-26 15:34 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 00:21 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-27 04:25 -0800
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-11-27 13:54 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 13:54 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 07:33 -0800
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-11-27 14:06 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:47 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 15:35 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:48 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:53 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:14 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:36 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:03 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:23 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 21:05 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 16:53 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 08:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:37 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:26 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:42 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:16 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 09:31 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 10:38 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 10:59 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 12:09 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 13:05 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:50 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:52 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 05:44 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 15:12 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 06:54 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:37 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 03:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 13:28 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 05:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 18:57 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 11:33 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 20:09 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:55 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:06 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:18 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:28 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 10:49 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 11:40 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 12:17 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 15:18 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-29 18:30 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 18:49 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 14:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 10:56 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 11:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 20:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 20:31 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:45 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 12:54 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 16:21 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:47 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:30 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 14:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 22:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 22:33 +0000
Re: absence of max jameskuyper@verizon.net - 2016-11-29 14:52 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 15:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 23:51 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 02:08 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 18:10 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 21:30 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:47 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 14:59 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 15:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:12 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 01:11 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 18:01 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:19 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-29 13:26 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 17:09 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:01 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:29 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:02 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 01:21 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:53 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:11 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:12 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 11:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 09:46 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 17:04 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 07:21 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:50 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 00:19 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:43 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 01:51 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 22:26 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:25 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 09:07 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 14:22 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-30 09:03 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:38 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 15:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 00:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 17:22 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 01:40 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 18:03 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 17:25 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:29 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:55 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:05 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:20 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:41 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 13:48 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:23 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 09:39 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:35 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 14:51 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 15:05 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 20:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 16:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 01:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:57 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:38 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 13:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 00:06 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 20:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 02:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 21:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 01:56 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:25 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:33 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 15:20 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:40 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-02 21:57 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:46 -0500
Re: absence of max asetofsymbols@gmail.com - 2016-11-30 06:36 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 16:41 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-11-30 20:50 +1300
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:11 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 12:00 +0000
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 11:32 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 19:25 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 20:45 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-30 14:17 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:14 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 07:37 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 17:05 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 10:06 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-12-01 13:53 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-01 12:22 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:02 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 10:05 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 11:01 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 17:28 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:13 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 11:51 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 14:28 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 15:00 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:28 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 10:30 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:50 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 09:39 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 10:17 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-02 11:46 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 15:02 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 11:58 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 13:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 15:31 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 13:34 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 19:32 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 01:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 20:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:50 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 22:45 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 11:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 13:46 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:29 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 18:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:59 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:51 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 22:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:19 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-04 01:28 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-04 14:34 +1300
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 00:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 10:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 08:38 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 15:52 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:03 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 19:19 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 11:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 11:33 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-04 00:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:23 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 10:32 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 17:15 +0100
Re: absence of max jameskuyper@verizon.net - 2016-12-03 08:33 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-03 11:08 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 21:31 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-04 08:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 19:39 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 07:15 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 13:38 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-05 14:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:21 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:05 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 09:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 13:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:33 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 15:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 20:48 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 14:43 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:26 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 11:32 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:56 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 20:28 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:10 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:01 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 20:00 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:51 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:44 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 22:49 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-05 15:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:24 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:47 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:51 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:30 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 01:44 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:54 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:05 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 11:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:16 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:45 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:07 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:58 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 17:49 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:46 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:04 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 08:45 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:54 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:02 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:38 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:43 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:00 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 09:58 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:48 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-18 16:51 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:54 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-19 21:24 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:38 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 15:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 19:12 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 17:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 21:41 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-17 09:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:49 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-18 08:26 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-19 19:19 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:40 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 18:03 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:44 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:19 -0600
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:12 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:44 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 06:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:58 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:21 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:34 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 06:58 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 15:15 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 12:30 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 16:25 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 13:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 13:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:03 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:50 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:44 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:00 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:28 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:29 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 16:24 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 17:04 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:29 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:37 -0800
Re: absence of max me <crisdunbar@gmail.com> - 2016-12-07 14:25 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:19 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:36 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-08 16:22 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 10:52 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 08:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:08 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:50 -0800
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:14 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:17 +0100
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:21 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:24 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:06 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:15 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:05 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:22 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 15:12 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:57 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-12 00:13 -0600
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:48 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:11 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:48 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:39 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:01 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-17 11:27 -0800
People who confuse and jumble up the difference between past, present, and future (Was: absence of max) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-17 20:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:15 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:40 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:19 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 12:29 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 14:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:24 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:58 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:09 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-11 20:56 +1300
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:35 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 13:42 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:54 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:54 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:14 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-11 18:11 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:18 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 15:55 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:11 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:21 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:48 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:02 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:39 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:37 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 00:13 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 22:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:19 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 19:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:38 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 07:52 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 19:37 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-08 14:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-08 15:46 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-13 13:04 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-13 13:38 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 14:07 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 22:51 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-14 08:17 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-14 11:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-14 16:53 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 05:14 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 15:02 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-15 08:54 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 19:55 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 13:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-15 14:20 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 15:32 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 23:44 +0100
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 07:00 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 08:21 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 21:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-16 13:24 -0800
Re: absence of max "D. Aaron Sawyer" <aaron@110.net> - 2016-12-16 18:51 -0400
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-20 09:03 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:21 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-14 19:05 +0100
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-08 15:58 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 00:18 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-09 07:25 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 11:29 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 09:07 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 14:20 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:31 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:15 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 22:11 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 15:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:21 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:19 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:31 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:14 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:05 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:58 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:20 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:29 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:53 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:58 +0000
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-12 19:11 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-13 10:31 +0100
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 15:38 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 12:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:06 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:44 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:23 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:23 -0800
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-08 20:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:32 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:42 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:40 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:33 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 15:02 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 13:01 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:11 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 18:59 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 20:56 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:04 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-11 16:18 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 19:38 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:35 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:22 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-12 17:35 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:54 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:17 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 13:01 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 13:16 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:05 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:21 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:09 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-12 13:12 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:01 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:03 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 12:58 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:11 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:53 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:46 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:07 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:53 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:11 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:32 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 13:26 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 19:39 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-12 11:31 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 19:01 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:06 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:19 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:13 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-12 15:38 +0000
Re: absence of max jameskuyper@verizon.net - 2016-12-02 08:54 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 17:20 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:35 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 09:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-02 10:44 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 16:52 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:15 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:49 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:35 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-27 09:39 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:35 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:10 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 22:07 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:55 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:46 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 13:16 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 14:52 +0100
Re: absence of max jadill33@gmail.com - 2016-11-28 09:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:04 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 18:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:52 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:31 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:09 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 14:14 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:02 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:26 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:43 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:46 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:56 +0100
Re: absence of max jameskuyper@verizon.net - 2016-11-27 16:21 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 10:10 -0800
Re: absence of max Tim Prince <tprince@computer.org> - 2016-11-27 07:40 -0500
absence of max asetofsymbols@gmail.com - 2016-11-27 08:46 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:18 -0800
Re: absence of max asetofsymbols@gmail.com - 2016-11-27 09:22 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:27 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 17:33 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-27 17:51 +0000
Re: absence of max Ken Brody <kenbrody@spamcop.net> - 2016-11-30 13:15 -0500
Re: absence of max "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-01 12:33 +0800
Page 28 of 29 — ← Prev page 1 … 26 27 [28] 29 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-27 22:55 +0000 |
| Message-ID | <o1fo60$u4t$1@dont-email.me> |
| In reply to | #97606 |
On 27/11/2016 21:07, David Brown wrote:
> On 27/11/16 21:10, BartC wrote:
>> I don't have many open-source projects lying around on my machine, but I
>> do happen to have CPython and SQLite. And by coincidence, they both
>> define MIN and MAX macros!
>>
>> SQLITE:
>> /*
>> ** Macros to compute minimum and maximum of two numbers.
>> */
>> #define MIN(A,B) ((A)<(B)?(A):(B))
>> #define MAX(A,B) ((A)>(B)?(A):(B))
>>
>> CPython:
>> #undef MAX
>> #undef MIN
>> #define MAX(x, y) ((x) < (y) ? (y) : (x))
>> #define MIN(x, y) ((x) < (y) ? (x) : (y))
>>
>> The purpose of having such functions built-in is precisely to avoid each
>> application defining it's own inferior versions.
>>
>
> These definitions are clear, simple, and written in about 14 seconds.
Wasn't one of your points there such a feature would rarely be used? Yet
the the first two applications I look at both rely on them.
(And looking further, with GMP there is:
#define __GMP_MAX(h,i) ((h) > (i) ? (h) : (i))
although strangely no __GMP_MIN. And in NCURSES:
#ifndef max
# define max(a,b) (((a) > (b)) ? (a) : (b))
#endif
#ifndef min
# define min(a,b) (((a) < (b)) ? (a) : (b))
#endif
)
Anyway these are all inferior because MAX(a[++i],b[++j]) might not do
what you'd expect; they are not a general solution.
> Until C11 generics came along, they could not be improved upon within
> the C language - there would need to be changes to the language that
> were far bigger than just a "min" or "max" standard library function in
> order to implement them.
You're looking at language-building features as a solution. I don't
agree. At the minute we are expected to use macros so that we end up
with thousands of variations of half-assed macros, all with slightly
different names, to do stuff like:
FOR(i, a, b) {...}
REPEAT(N) {...}
ARRAY_LEN(a)
MAX(a,b)
CLAMP(x,y,z)
BINARY(101101)
DECIMAL_WITH_COMMAS(1,048,576)
Etc.
I think the C11 changes will have the same problems as macros. And
presumably, the generic features end up generating standard C code which
is compiled as normal? That's not much different to my wrapping a thick
syntax layer around the whole language! (Which is then processed with a
tool resulting in standard C to compile.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-28 12:46 +0100 |
| Message-ID | <o1h5d0$nls$1@dont-email.me> |
| In reply to | #97609 |
On 27/11/16 23:55, BartC wrote:
> On 27/11/2016 21:07, David Brown wrote:
>> On 27/11/16 21:10, BartC wrote:
>
>>> I don't have many open-source projects lying around on my machine, but I
>>> do happen to have CPython and SQLite. And by coincidence, they both
>>> define MIN and MAX macros!
>>>
>>> SQLITE:
>>> /*
>>> ** Macros to compute minimum and maximum of two numbers.
>>> */
>>> #define MIN(A,B) ((A)<(B)?(A):(B))
>>> #define MAX(A,B) ((A)>(B)?(A):(B))
>>>
>>> CPython:
>>> #undef MAX
>>> #undef MIN
>>> #define MAX(x, y) ((x) < (y) ? (y) : (x))
>>> #define MIN(x, y) ((x) < (y) ? (x) : (y))
>>>
>>> The purpose of having such functions built-in is precisely to avoid each
>>> application defining it's own inferior versions.
>>>
>>
>> These definitions are clear, simple, and written in about 14 seconds.
>
> Wasn't one of your points there such a feature would rarely be used? Yet
> the the first two applications I look at both rely on them.
All you have shown is that two rather large code bases both define MAX
and MIN macros. That is still perfectly consistent with being rarely
used. Now, if you count the number of /uses/ of these macros and show
it to be a reasonable fraction of the number of lines of code in the
source, then you can say it is commonly used in at least these two code
bases.
(I have no proof for saying that max/min are rarely used - it is merely
an opinion. I also haven't given any kind of indication about what I
meant by "rarely", such as comparisons to the usefulness of other
features. So don't get hung up about that point - my only concrete
justification is that cpu instruction sets usually do not have any
integer min/max instruction. Floating point is always more complicated,
and cannot be easily generated from a few individual instructions
because of NaNs and other nonsense - thus an fmin or fmax instruction
/is/ worth the effort.)
>
> (And looking further, with GMP there is:
>
> #define __GMP_MAX(h,i) ((h) > (i) ? (h) : (i))
>
> although strangely no __GMP_MIN. And in NCURSES:
>
> #ifndef max
> # define max(a,b) (((a) > (b)) ? (a) : (b))
> #endif
> #ifndef min
> # define min(a,b) (((a) < (b)) ? (a) : (b))
> #endif
> )
>
> Anyway these are all inferior because MAX(a[++i],b[++j]) might not do
> what you'd expect; they are not a general solution.
They are what you get in C, so they are what people use. And they are
simple and easy to make.
The question is, would a "safer" built-in version be worth the effort?
it would not more more efficient, and it would not safe noticeably on
developer effort (since the macro here is so easy to write). It would
not help for anything that can use gcc (or clang) extensions, as "safe"
macros can be written or copied directly from the gcc manual.
So the only problem with today's "max" solutions is when you call them
with arguments that have side-effects. Frankly, I am always sceptical
to any function call whose arguments have side effects - in most cases,
I think the code is less clear and potentially more fragile (there is no
defined order for these side effects). There can be particular cases
where it makes sense, but I would usually reject max(a[++i], b[++j]) as
smart-ass code that tries to do too much in one line.
>
>> Until C11 generics came along, they could not be improved upon within
>> the C language - there would need to be changes to the language that
>> were far bigger than just a "min" or "max" standard library function in
>> order to implement them.
>
> You're looking at language-building features as a solution. I don't
> agree. At the minute we are expected to use macros so that we end up
> with thousands of variations of half-assed macros, all with slightly
> different names, to do stuff like:
>
> FOR(i, a, b) {...}
> REPEAT(N) {...}
> ARRAY_LEN(a)
> MAX(a,b)
> CLAMP(x,y,z)
> BINARY(101101)
> DECIMAL_WITH_COMMAS(1,048,576)
>
And how is this in any way different from any other programming
language? No language is "complete" with standard library functions
covering /everything/. C happens to have a relatively small standard
library - but that is by design, not by accident. It means that the
language is good for small and efficient programs with little overhead.
It is also fine when combined with other libraries - libraries don't
need to be part of the C standard to be useful. It also means that it
is often not a great choice for big projects, because you do need to
invent so much yourself.
> Etc.
>
> I think the C11 changes will have the same problems as macros. And
> presumably, the generic features end up generating standard C code which
> is compiled as normal? That's not much different to my wrapping a thick
> syntax layer around the whole language! (Which is then processed with a
> tool resulting in standard C to compile.)
>
Have you actually /looked/ at _Generic, or are you just guessing? Here
is a generic "max" macro. It is ugly and verbose, especially compared
to something like C++ templates, but it does the job. It gets the types
right, while avoiding double evaluation of side effects.
Should it be added to the C standard library? I don't really see why
not, now that _Generic is there. But the functions could not be called
"max" and "min" without clashing too much with existing code - they
would have to be something like _Max and _Min (with a <stdmaxmin.h> to
define "max" and "min" names). Would they be used enough to make it
worth the effort? Probably not.
static inline int _maxi(int const x, int const y) {
return y > x ? y : x;
}
static inline unsigned _maxui(unsigned const x, unsigned const y) {
return y > x ? y : x;
}
static inline long _maxl(long const x, long const y) {
return y > x ? y : x;
}
static inline unsigned long _maxul(unsigned long const x, unsigned long
const y) {
return y > x ? y : x;
}
static inline long long _maxll(long long const x, long long const y) {
return y > x ? y : x;
}
static inline unsigned long long _maxull(unsigned long long const x,
unsigned long long const y) {
return y > x ? y : x;
}
static inline float _maxf(float const x, float const y) {
return y > x ? y : x;
}
static inline double _maxd(double const x, double const y) {
return y > x ? y : x;
}
static inline long double _maxld(long double const x, long double const y) {
return y > x ? y : x;
}
#define max(x, y) (_Generic((x) + (y), \
int: _maxi, \
unsigned: _maxu, \
long: _maxl, \
unsigned long: _maxul, \
long long: _maxll, \
unsigned long long: _maxull, \
float: _maxf, \
double: _maxd, \
long double: _maxld)((x), (y)))
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-28 13:16 +0000 |
| Message-ID | <o1hall$9nm$1@dont-email.me> |
| In reply to | #97629 |
On 28/11/2016 11:46, David Brown wrote:
> On 27/11/16 23:55, BartC wrote:
>> Wasn't one of your points there such a feature would rarely be used? Yet
>> the the first two applications I look at both rely on them.
>
> All you have shown is that two rather large code bases both define MAX
> and MIN macros. That is still perfectly consistent with being rarely
> used. Now, if you count the number of /uses/ of these macros and show
> it to be a reasonable fraction of the number of lines of code in the
> source, then you can say it is commonly used in at least these two code
> bases.
It shows people often have to end up inventing these macros. And the
fact that they are pretty much the same macros suggests it is quite a
common need.
The use of generics to do that doesn't really change things, as the
definitions for min/max still have to be added, and that is now a lot
more complicated (and makes the code, for now, less portable). Although
the resulting implementations will be better.
(Note the lccwin compiler appears to include min/max macros as standard,
but because it is just one compiler makes it less useful. Also dangerous
as, as the names are lower case, people might think they are functions.)
>> Anyway these are all inferior because MAX(a[++i],b[++j]) might not do
>> what you'd expect; they are not a general solution.
>
> They are what you get in C, so they are what people use. And they are
> simple and easy to make.
>
> The question is, would a "safer" built-in version be worth the effort?
> it would not more more efficient, and it would not safe noticeably on
> developer effort (since the macro here is so easy to write). It would
> not help for anything that can use gcc (or clang) extensions, as "safe"
> macros can be written or copied directly from the gcc manual.
>
> So the only problem with today's "max" solutions is when you call them
> with arguments that have side-effects.
So you say sloppy coding is good? Great, that means a lot less work for
my own code generation efforts! The question of side effects comes up,
apart from min/max, in the implementation of constructs like these, when
x and y are arbitrary expressions:
x += y;
x==y==z; # [not C] when interpreted as (x==y) && (y==z)
swap(x,y); # [not C]
and such, where the simplest implementation involves re-evaluating one
or more operands. (Some code-generation techniques will take care of
such issues; but the one I use doesn't!)
>> You're looking at language-building features as a solution. I don't
>> agree. At the minute we are expected to use macros so that we end up
>> with thousands of variations of half-assed macros, all with slightly
>> different names, to do stuff like:
>>
>> FOR(i, a, b) {...}
>> REPEAT(N) {...}
>> ARRAY_LEN(a)
>> MAX(a,b)
>> CLAMP(x,y,z)
>> BINARY(101101)
>> DECIMAL_WITH_COMMAS(1,048,576)
>>
>
> And how is this in any way different from any other programming
> language? No language is "complete" with standard library functions
> covering /everything/.
Many of those are fundamental (well not clamp and probably not min/max).
That is, simple iterative loops, repeating a block N times, getting the
number of elements in an array, writing binary literals or literals with
separators, and so on.
You don't want everyone either reinventing the same workaround with
macros, or not doing so and writing things out in full, or writing
binary as hex, or long numbers without separators.
> C happens to have a relatively small standard
> library
It's not a library thing. If the language has to, it can implement some
of these with macros (as it does many things), then it's only an extra
few lines in one of the standard headers. But they will then be standard
at least.
>> I think the C11 changes will have the same problems as macros.
> Have you actually /looked/ at _Generic, or are you just guessing? Here
> is a generic "max" macro. It is ugly and verbose, especially compared
> to something like C++ templates, but it does the job. It gets the types
> right, while avoiding double evaluation of side effects.
> static inline int _maxi(int const x, int const y) {
> return y > x ? y : x;
> }
.......
> #define max(x, y) (_Generic((x) + (y), \
(I was thinking (x)>(y) would be better here, as that is used within the
functions. And it would work for pointers too. But then, that will
always return type int ...)
> int: _maxi, \
> unsigned: _maxu, \
> long: _maxl, \
> unsigned long: _maxul, \
> long long: _maxll, \
> unsigned long long: _maxull, \
> float: _maxf, \
> double: _maxd, \
> long double: _maxld)((x), (y)))
That's quite neat. (I may borrow this feature actually...)
But it's also pretty much what I do in my code-generation: a family of
min/max function variations, but the selection is done within the
translator (unless the expression can be handled in-line).
With these C versions, the onus is on the programmer to write all this,
and provide it with the distribution of the source code. And if code is
subsequently shared, then A's implementation of min/max may end up
clashing with B'S similar implementation.
However I can't, at the minute, post a code snippet using min/max and
expect anyone else to be able to compile it.
Otherwise it seems a fine feature to use for building a library.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-28 14:52 +0100 |
| Message-ID | <o1hco2$gju$1@dont-email.me> |
| In reply to | #97633 |
On 28/11/16 14:16, BartC wrote:
> On 28/11/2016 11:46, David Brown wrote:
>> On 27/11/16 23:55, BartC wrote:
>
>>> Wasn't one of your points there such a feature would rarely be used? Yet
>>> the the first two applications I look at both rely on them.
>>
>> All you have shown is that two rather large code bases both define MAX
>> and MIN macros. That is still perfectly consistent with being rarely
>> used. Now, if you count the number of /uses/ of these macros and show
>> it to be a reasonable fraction of the number of lines of code in the
>> source, then you can say it is commonly used in at least these two code
>> bases.
>
> It shows people often have to end up inventing these macros. And the
> fact that they are pretty much the same macros suggests it is quite a
> common need.
>
> The use of generics to do that doesn't really change things, as the
> definitions for min/max still have to be added, and that is now a lot
> more complicated (and makes the code, for now, less portable). Although
> the resulting implementations will be better.
>
> (Note the lccwin compiler appears to include min/max macros as standard,
> but because it is just one compiler makes it less useful. Also dangerous
> as, as the names are lower case, people might think they are functions.)
>
>>> Anyway these are all inferior because MAX(a[++i],b[++j]) might not do
>>> what you'd expect; they are not a general solution.
>>
>> They are what you get in C, so they are what people use. And they are
>> simple and easy to make.
>>
>> The question is, would a "safer" built-in version be worth the effort?
>> it would not more more efficient, and it would not safe noticeably on
>> developer effort (since the macro here is so easy to write). It would
>> not help for anything that can use gcc (or clang) extensions, as "safe"
>> macros can be written or copied directly from the gcc manual.
>>
>> So the only problem with today's "max" solutions is when you call them
>> with arguments that have side-effects.
>
> So you say sloppy coding is good? Great, that means a lot less work for
> my own code generation efforts! The question of side effects comes up,
> apart from min/max, in the implementation of constructs like these, when
> x and y are arbitrary expressions:
>
> x += y;
> x==y==z; # [not C] when interpreted as (x==y) && (y==z)
> swap(x,y); # [not C]
>
> and such, where the simplest implementation involves re-evaluating one
> or more operands. (Some code-generation techniques will take care of
> such issues; but the one I use doesn't!)
It is quite simple. Don't call macros with arguments with side-effects.
If you want to say that this is bad, and that it is poor language
design, then I agree. It /is/ bad. There are better alternatives. C
supports three ways to improve on macros with this sort of problem. One
is "static inline" functions - but then you have lost type generics.
Another is "_Generic" - but then you need C11, and it is ugly and
verbose. A third is gcc extensions - but then you need gcc (or a
compatible compiler). And of course, other languages do a better job -
C++ has templates, but then you are no longer working in C.
If you want to /complain/ about C, then you are on your own - C is what
it is, despite what we might wish.
>
>>> You're looking at language-building features as a solution. I don't
>>> agree. At the minute we are expected to use macros so that we end up
>>> with thousands of variations of half-assed macros, all with slightly
>>> different names, to do stuff like:
>>>
>>> FOR(i, a, b) {...}
>>> REPEAT(N) {...}
>>> ARRAY_LEN(a)
>>> MAX(a,b)
>>> CLAMP(x,y,z)
>>> BINARY(101101)
>>> DECIMAL_WITH_COMMAS(1,048,576)
>>>
>>
>> And how is this in any way different from any other programming
>> language? No language is "complete" with standard library functions
>> covering /everything/.
>
> Many of those are fundamental (well not clamp and probably not min/max).
> That is, simple iterative loops, repeating a block N times, getting the
> number of elements in an array, writing binary literals or literals with
> separators, and so on.
The loops and iteration macros here are not remotely "fundamental". I
have never felt the need for them, and I write plenty of loops in C.
I'll warrant that the same applies to most C programmers.
Binary literals are a rather specialised thing - few people need to
write them apart from embedded developers, and embedded compilers
usually support 0b0101 syntax. (This is something I really think should
be included in the C standards - I cannot comprehend why it is missing
from C11, as it is supported by many compilers and is standardised in
C++11.)
Digit separators would be nice, but they are not "fundamental" - C
programmers have managed without them for a good many years. C++ added
them with ' as the separator, which was not the nicest of choices (but
alternatives such as , and _ had too many other problems).
>
> You don't want everyone either reinventing the same workaround with
> macros, or not doing so and writing things out in full, or writing
> binary as hex, or long numbers without separators.
People who write C /do/ reinvent the same wheels, again and again. I
have often said that most people who program in C, and most programs
written in C, would be better using higher level languages. But I don't
think the problem is with the C language - the problem is that people
choose C when other languages would let them write better code, or be
more productive in writing their code.
>
>> C happens to have a relatively small standard
>> library
>
> It's not a library thing. If the language has to, it can implement some
> of these with macros (as it does many things), then it's only an extra
> few lines in one of the standard headers. But they will then be standard
> at least.
>
>>> I think the C11 changes will have the same problems as macros.
>
>> Have you actually /looked/ at _Generic, or are you just guessing? Here
>> is a generic "max" macro. It is ugly and verbose, especially compared
>> to something like C++ templates, but it does the job. It gets the types
>> right, while avoiding double evaluation of side effects.
>
>> static inline int _maxi(int const x, int const y) {
>> return y > x ? y : x;
>> }
> .......
>
>> #define max(x, y) (_Generic((x) + (y), \
>
> (I was thinking (x)>(y) would be better here, as that is used within the
> functions. And it would work for pointers too. But then, that will
> always return type int ...)
Exactly. Using "+" gets the promotions and conversions right.
>
>> int: _maxi, \
>> unsigned: _maxu, \
>> long: _maxl, \
>> unsigned long: _maxul, \
>> long long: _maxll, \
>> unsigned long long: _maxull, \
>> float: _maxf, \
>> double: _maxd, \
>> long double: _maxld)((x), (y)))
>
> That's quite neat. (I may borrow this feature actually...)
Feel free. I "borrowed" it from the internet somewhere :-)
>
> But it's also pretty much what I do in my code-generation: a family of
> min/max function variations, but the selection is done within the
> translator (unless the expression can be handled in-line).
You are writing a code generator - it makes sense to do this sort of
thing during code generation.
>
> With these C versions, the onus is on the programmer to write all this,
> and provide it with the distribution of the source code. And if code is
> subsequently shared, then A's implementation of min/max may end up
> clashing with B'S similar implementation.
>
> However I can't, at the minute, post a code snippet using min/max and
> expect anyone else to be able to compile it.
>
> Otherwise it seems a fine feature to use for building a library.
>
[toc] | [prev] | [next] | [standalone]
| From | jadill33@gmail.com |
|---|---|
| Date | 2016-11-28 09:41 -0800 |
| Message-ID | <f6236522-4e33-496b-a115-6514579240e1@googlegroups.com> |
| In reply to | #97629 |
On Monday, November 28, 2016 at 6:47:01 AM UTC-5, David Brown wrote:
<snip>
> Should it be added to the C standard library? I don't really see why
> not, now that _Generic is there. But the functions could not be called
> "max" and "min" without clashing too much with existing code - they
> would have to be something like _Max and _Min (with a <stdmaxmin.h> to
> define "max" and "min" names). Would they be used enough to make it
> worth the effort? Probably not.
>
>
>
> static inline int _maxi(int const x, int const y) {
> return y > x ? y : x;
> }
>
> static inline unsigned _maxui(unsigned const x, unsigned const y) {
> return y > x ? y : x;
> }
>
> static inline long _maxl(long const x, long const y) {
> return y > x ? y : x;
> }
>
> static inline unsigned long _maxul(unsigned long const x, unsigned long
> const y) {
> return y > x ? y : x;
> }
>
> static inline long long _maxll(long long const x, long long const y) {
> return y > x ? y : x;
> }
>
> static inline unsigned long long _maxull(unsigned long long const x,
> unsigned long long const y) {
> return y > x ? y : x;
> }
>
> static inline float _maxf(float const x, float const y) {
> return y > x ? y : x;
> }
>
> static inline double _maxd(double const x, double const y) {
> return y > x ? y : x;
> }
>
> static inline long double _maxld(long double const x, long double const y) {
> return y > x ? y : x;
> }
>
> #define max(x, y) (_Generic((x) + (y), \
> int: _maxi, \
> unsigned: _maxu, \
> long: _maxl, \
> unsigned long: _maxul, \
> long long: _maxll, \
> unsigned long long: _maxull, \
> float: _maxf, \
> double: _maxd, \
> long double: _maxld)((x), (y)))
You might consider using a macro for your function definitions.
#define MAX_FN_IMPL( NAME, TYPE ) \
static inline TYPE _max##NAME(TYPE const x, TYPE const y) { \
return y > x ? y : x; \
}
I actually use this style on occasion to define type specific functions
as needed.
Best regards,
John D.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-29 11:04 +0100 |
| Message-ID | <o1jjp0$hlr$1@dont-email.me> |
| In reply to | #97656 |
On 28/11/16 18:41, jadill33@gmail.com wrote:
>
> You might consider using a macro for your function definitions.
>
> #define MAX_FN_IMPL( NAME, TYPE ) \
> static inline TYPE _max##NAME(TYPE const x, TYPE const y) { \
> return y > x ? y : x; \
> }
>
Yes, I considered writing it this way - but I thought it better to avoid
the extra layers of macros for this example.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-27 18:02 +0000 |
| Message-ID | <o1f71j$q1e$1@dont-email.me> |
| In reply to | #97578 |
On 27/11/2016 16:35, David Brown wrote:
> On 27/11/16 01:21, BartC wrote:
>> So 14 functions so far, and you haven't yet looked at in-place versions.
>
> And that is why there is no "max" standard function in C.
Huh? That is the very reason why it ought to be built-in and benefiting
from overloading.
>> If you try and do it with macros, then you have to think about problems
>> like MAX(a[++i],b). Plus all the usual issues you get when you leave
>> things like this to the creativity of millions of individual programmers.
>>
>> There are benefits to having even apparently trivial features like this
>> supported by the language.
>
> In C, this would have to be implemented as an operator, not a function,
> in order to work on a range of types.
Yes, but it can be a operator with function-like syntax. I can write in
my language any of:
a:=max(b,c)
a:=b max c
a max:=b
which translates to this C:
a = (b>c?b:c);
a = (b>c?b:c);
a = (a>b?a:b);
(When a,b,c are simple; more complex terms generate more fiddly code
than may call built-in functions. The important thing however is that
that isn't a concern of the guy writing the above code using 'max'. The
best implementation is left to the language.)
> gcc used to have an extension "a <? b" and "a >? b" as the minimum and
> maximum operators - precisely because making an operator was the only
> way to achieve the effect for different types while being safe from the
> "evaluate twice" problem. But these operators have long since been
> removed from gcc, for a variety of reasons:
>
> 1. They were rarely used. It makes little sense to maintain such an
> extension unless people actually find it useful.
>
> 2. It was non-portable. If you are happy with gcc extensions, then
> there are perfectly good ways to achieve the effect using other gcc
> extensions that /are/ useful in a number of contexts:
>
> #define max(a,b) \
> ({ typeof (a) _a = (a); \
> typeof (b) _b = (b); \
> _a > _b ? _a : _b; })
>
> 3. It is not needed in C++, which has templates (and therefore very
> simple std::max and std::min functions). So it is only relevant for C,
> not C++.
>
> 4. It takes only 14 seconds to write your own custom function or inline
> code when you need a "max". That is less time than it takes to look up
> the gcc manual to learn about the extra operator.
>
> So in the end, there is not much need of a "max" in the language.
It also takes less than 14 seconds, or not much more, to:
* Write a=a+1 instead of ++a
* Write a+=1 instead of ++a
* Write !(a==b) instead of a!=b
* Write b<a instead of a>b
* Write (*P).m instead of P->m
* Write a strlen() or strcpy() function
* Write an abs() function
etc.
But these features presumably exist for a reason.
Your reasons are just the usual excuses that try and justify why some
obvious feature isn't in C. Of course if it /was/ in, then it would be
indispensable!
And FWIW I use min and max a lot. (There is also 'clamp', a related
feature, although that is used less often: y = clamp(x,lower,upper).)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-27 20:52 +0100 |
| Message-ID | <o1fdfu$lvs$1@dont-email.me> |
| In reply to | #97598 |
On 27/11/16 19:02, BartC wrote:
> On 27/11/2016 16:35, David Brown wrote:
>> On 27/11/16 01:21, BartC wrote:
>
>>> So 14 functions so far, and you haven't yet looked at in-place versions.
>>
>> And that is why there is no "max" standard function in C.
>
> Huh? That is the very reason why it ought to be built-in and benefiting
> from overloading.
Standard C library functions don't support overloading. Only operators
support overloading. (And with C11 generics, you can make a kind of
overloading via macros.)
>
>>> If you try and do it with macros, then you have to think about problems
>>> like MAX(a[++i],b). Plus all the usual issues you get when you leave
>>> things like this to the creativity of millions of individual
>>> programmers.
>>>
>>> There are benefits to having even apparently trivial features like this
>>> supported by the language.
>>
>> In C, this would have to be implemented as an operator, not a function,
>> in order to work on a range of types.
>
> Yes, but it can be a operator with function-like syntax. I can write in
> my language any of:
>
> a:=max(b,c)
> a:=b max c
> a max:=b
>
> which translates to this C:
>
> a = (b>c?b:c);
> a = (b>c?b:c);
> a = (a>b?a:b);
That's fine - in /your/ language. There are many languages where
operators and functions are basically the same thing, just with a bit of
syntactic sugar. C is not one of those languages. And we were
discussing C, were we not?
>
> (When a,b,c are simple; more complex terms generate more fiddly code
> than may call built-in functions. The important thing however is that
> that isn't a concern of the guy writing the above code using 'max'. The
> best implementation is left to the language.)
>
>> gcc used to have an extension "a <? b" and "a >? b" as the minimum and
>> maximum operators - precisely because making an operator was the only
>> way to achieve the effect for different types while being safe from the
>> "evaluate twice" problem. But these operators have long since been
>> removed from gcc, for a variety of reasons:
>>
>> 1. They were rarely used. It makes little sense to maintain such an
>> extension unless people actually find it useful.
>>
>> 2. It was non-portable. If you are happy with gcc extensions, then
>> there are perfectly good ways to achieve the effect using other gcc
>> extensions that /are/ useful in a number of contexts:
>>
>> #define max(a,b) \
>> ({ typeof (a) _a = (a); \
>> typeof (b) _b = (b); \
>> _a > _b ? _a : _b; })
>>
>> 3. It is not needed in C++, which has templates (and therefore very
>> simple std::max and std::min functions). So it is only relevant for C,
>> not C++.
>>
>> 4. It takes only 14 seconds to write your own custom function or inline
>> code when you need a "max". That is less time than it takes to look up
>> the gcc manual to learn about the extra operator.
>>
>> So in the end, there is not much need of a "max" in the language.
>
> It also takes less than 14 seconds, or not much more, to:
>
> * Write a=a+1 instead of ++a
> * Write a+=1 instead of ++a
> * Write !(a==b) instead of a!=b
> * Write b<a instead of a>b
> * Write (*P).m instead of P->m
> * Write a strlen() or strcpy() function
> * Write an abs() function
>
> etc.
>
> But these features presumably exist for a reason.
Yes, there are two key reasons. One is that it makes compilers simpler
(which was very relevant in the past), allowing compilers to translate
"a = a + b" into "add a, b" and "a++" into "inc a". The other is that
these sorts of features are used a great deal, so it is very convenient
to have them on hand. This is much less the case for "max" and "min",
which rarely have direct assembly implementations, and which are not
used nearly as often in user code. (The fact that they rarely exist as
assembly instructions is a good indication of this.)
>
> Your reasons are just the usual excuses that try and justify why some
> obvious feature isn't in C. Of course if it /was/ in, then it would be
> indispensable!
/I/ did not specify the C language, write the standards, or implement
compilers. I am not justifying anything here - I have no need to do so.
The question was asked why there is no "max" or "min" function in the
C standard library, so I have given some explanations for why they are
not there. It would not bother me if they /were/ there, and I might
have occasional use for them in my code if they were standardised. But
I don't feel bothered by their lack. Some people, of course, /would/
object to them being added - either because they don't want the language
to grow, or because they don't want conflicts with their own use of
those identifiers (it is /really/ hard to add new features to C without
annoying someone!). Oh, and there are lots of features of C that I
could happily live without, and lots more that I would change if I
could. But in most cases I can understand why the feature exists, even
if I don't personally want it.
>
> And FWIW I use min and max a lot. (There is also 'clamp', a related
> feature, although that is used less often: y = clamp(x,lower,upper).)
>
And in C++, where it is much easier to add new features to the standard
library than C, "clamp" has been added to C++17 to join "min" and "max".
But then, C++ has templates making the implementation trivial and thus
giving a different balance of pros and cons.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-27 20:31 +0000 |
| Message-ID | <o1ffp3$uuv$1@dont-email.me> |
| In reply to | #97602 |
On 27/11/2016 19:52, David Brown wrote:
> On 27/11/16 19:02, BartC wrote:
>> Yes, but it can be a operator with function-like syntax. I can write in
>> my language any of:
>>
>> a:=max(b,c)
>> a:=b max c
>> a max:=b
>>
>> which translates to this C:
>>
>> a = (b>c?b:c);
>> a = (b>c?b:c);
>> a = (a>b?a:b);
>
> That's fine - in /your/ language. There are many languages where
> operators and functions are basically the same thing, just with a bit of
> syntactic sugar. C is not one of those languages. And we were
> discussing C, were we not?
We're discussing having min and max built-in. The standard ways of
adding this stuff via user-code is with functions and with macros, both
of which have their own problems.
Why /couldn't/ there be an operator that uses function-like syntax? (As
happens with 'syntax(x)'. But it be operator-like syntax as I've shown
as well.
My example shows that it is doable, it's readable, and can map easily to
existing C features.
>> And FWIW I use min and max a lot. (There is also 'clamp', a related
>> feature, although that is used less often: y = clamp(x,lower,upper).)
>>
>
> And in C++, where it is much easier to add new features to the standard
> library than C, "clamp" has been added to C++17 to join "min" and "max".
> But then, C++ has templates making the implementation trivial and
How trivial was it to implement templates!
>> But these features presumably exist for a reason.
> This is much less the case for "max" and "min",
> which rarely have direct assembly implementations, and which are not
> used nearly as often in user code. (The fact that they rarely exist as
> assembly instructions is a good indication of this.)
My own implementation of min/max is not very demanding, certainly
nowhere on the scale of C++ templates.
It was made easier more recently with special x86 assembly instructions,
namely:
cmov for integers
minss, maxss etc for floating point
Yes, the instruction set for floating point includes dedicated min and
max instructions! Extraordinary given that such operations are
apparently so rare.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-27 22:09 +0000 |
| Message-ID | <o1flfv$ju0$1@dont-email.me> |
| In reply to | #97605 |
On 27/11/2016 20:31, BartC wrote: > Why /couldn't/ there be an operator that uses function-like syntax? (As > happens with 'syntax(x)'. Oops: I mean 'sizeof(x)'.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-27 14:14 -0800 |
| Message-ID | <02e59a7a-61a9-4b89-891b-1370d6e65346@googlegroups.com> |
| In reply to | #97607 |
On Sunday, November 27, 2016 at 4:09:29 PM UTC-6, Bart wrote: > On 27/11/2016 20:31, BartC wrote: > > > Why /couldn't/ there be an operator that uses function-like syntax? (As > > happens with 'syntax(x)'. > > Oops: I mean 'sizeof(x)'. The sizeof operator is often written as though it takes function-like syntax, but it actually has two syntactic forms: it can be applied to a value, in which case parentheses are not required, or to a type, in which case they are required. It's interesting that a lot of code writes "sizeof(variable)" or "sizeof (int)" rather than "sizeof variable" or "sizeof (int)", which probably contributes to the confusion.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-27 23:02 +0000 |
| Message-ID | <o1foje$3oa$1@dont-email.me> |
| In reply to | #97608 |
On 27/11/2016 22:14, supercat@casperkitty.com wrote: > On Sunday, November 27, 2016 at 4:09:29 PM UTC-6, Bart wrote: >> On 27/11/2016 20:31, BartC wrote: >> >>> Why /couldn't/ there be an operator that uses function-like syntax? (As >>> happens with 'syntax(x)'. >> >> Oops: I mean 'sizeof(x)'. > > The sizeof operator is often written as though it takes function-like syntax, > but it actually has two syntactic forms: it can be applied to a value, in > which case parentheses are not required, or to a type, in which case they > are required. It's interesting that a lot of code writes "sizeof(variable)" > or "sizeof (int)" rather than "sizeof variable" or "sizeof (int)", which > probably contributes to the confusion. Yeah ... because a lot of people can't remember when it requires parentheses and when it doesn't! My proposed max() would always require parentheses. (That's for C; as I use it now, it can also be written in infix form, but that would be a bit much for C. Infix doesn't really suit it min or max, but it makes it possible to do 'a max= b' like other infix operators.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-27 23:26 +0000 |
| Message-ID | <o1fq00$842$1@dont-email.me> |
| In reply to | #97610 |
On 27/11/16 23:02, BartC wrote: > On 27/11/2016 22:14, supercat@casperkitty.com wrote: >> On Sunday, November 27, 2016 at 4:09:29 PM UTC-6, Bart wrote: >>> On 27/11/2016 20:31, BartC wrote: >>> >>>> Why /couldn't/ there be an operator that uses function-like syntax? (As >>>> happens with 'syntax(x)'. >>> >>> Oops: I mean 'sizeof(x)'. >> >> The sizeof operator is often written as though it takes function-like >> syntax, >> but it actually has two syntactic forms: it can be applied to a value, in >> which case parentheses are not required, or to a type, in which case they >> are required. It's interesting that a lot of code writes >> "sizeof(variable)" >> or "sizeof (int)" rather than "sizeof variable" or "sizeof (int)", which >> probably contributes to the confusion. > > Yeah ... because a lot of people can't remember when it requires > parentheses and when it doesn't! It never, *ever* requires parentheses except on the vanishingly few occasions when you need to specify a type rather than an expression. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-27 23:43 +0000 |
| Message-ID | <o1fr0h$b1a$1@dont-email.me> |
| In reply to | #97611 |
On 27/11/2016 23:26, Richard Heathfield wrote:
> On 27/11/16 23:02, BartC wrote:
>> On 27/11/2016 22:14, supercat@casperkitty.com wrote:
>>> It's interesting that a lot of code writes
>>> "sizeof(variable)"
>>> or "sizeof (int)" rather than "sizeof variable" or "sizeof (int)", which
>>> probably contributes to the confusion.
>>
>> Yeah ... because a lot of people can't remember when it requires
>> parentheses and when it doesn't!
>
> It never, *ever* requires parentheses except on the vanishingly few
> occasions when you need to specify a type rather than an expression.
In my code, that can happen a lot. (See below, although here I used it
so much that I wrapped it in a macro.)
-------------------------------------------------------
#include <stdio.h>
#include <windows.h>
#define SHOWSIZE(T) fprintf(f,#T " %d\n",sizeof(T))
int main(void) {
FILE* f;
if (sizeof(void*)==8) {
f=fopen("sizes64","wb");
fprintf(f,"-- 64 BITS\n");
}
else {
f=fopen("sizes32","wb");
fprintf(f,"-- 32 BITS\n");
}
SHOWSIZE(BOOL);
SHOWSIZE(WORD);
SHOWSIZE(INT);
SHOWSIZE(INPUT_RECORD);
SHOWSIZE(WCHAR);
SHOWSIZE(DWORD);
SHOWSIZE(HWND);
SHOWSIZE(UINT);
SHOWSIZE(CHAR);
SHOWSIZE(KEY_EVENT_RECORD);
SHOWSIZE(WPARAM);
SHOWSIZE(LPARAM);
SHOWSIZE(SCROLLINFO);
SHOWSIZE(SCROLLBARINFO);
SHOWSIZE(COLORREF);
SHOWSIZE(LOGPALETTE);
SHOWSIZE(PALETTEENTRY);
SHOWSIZE(PALETTEENTRY);
SHOWSIZE(BITMAP);
SHOWSIZE(BITMAPCOREHEADER);
SHOWSIZE(BITMAPCOREINFO);
SHOWSIZE(BITMAPFILEHEADER);
SHOWSIZE(BITMAPINFO);
SHOWSIZE(BITMAPINFOHEADER);
SHOWSIZE(BITMAPV4HEADER);
SHOWSIZE(BITMAPV5HEADER);
SHOWSIZE(BLENDFUNCTION);
SHOWSIZE(DIBSECTION);
SHOWSIZE(RGBQUAD);
SHOWSIZE(RGBTRIPLE);
SHOWSIZE(SIZE);
SHOWSIZE(LPSIZE);
SHOWSIZE(TRIVERTEX);
SHOWSIZE(RGNDATA);
SHOWSIZE(RGNDATAHEADER);
SHOWSIZE(PAINTSTRUCT);
SHOWSIZE(LOGBRUSH);
//SHOWSIZE(LOGBRUSH32);
SHOWSIZE(ABC);
SHOWSIZE(ABCFLOAT);
SHOWSIZE(ENUMLOGFONT);
SHOWSIZE(TEXTMETRIC);
SHOWSIZE(NEWTEXTMETRIC);
SHOWSIZE(LOGFONT);
SHOWSIZE(EXTLOGFONT);
SHOWSIZE(EXTLOGPEN);
SHOWSIZE(LOGPEN);
SHOWSIZE(MSG);
SHOWSIZE(CHAR_INFO);
SHOWSIZE(CONSOLE_CURSOR_INFO);
SHOWSIZE(CONSOLE_FONT_INFO);
SHOWSIZE(CONSOLE_SCREEN_BUFFER_INFO);
//SHOWSIZE(CONSOLE_SCREEN_BUFFER_INFOEX);
SHOWSIZE(INPUT_RECORD);
SHOWSIZE(KEY_EVENT_RECORD);
SHOWSIZE(FOCUS_EVENT_RECORD);
SHOWSIZE(MENU_EVENT_RECORD);
SHOWSIZE(MOUSE_EVENT_RECORD);
SHOWSIZE(SMALL_RECT);
SHOWSIZE(WINDOW_BUFFER_SIZE_RECORD);
SHOWSIZE(COORD);
SHOWSIZE(POINT);
SHOWSIZE(POINTS);
SHOWSIZE(RECT);
SHOWSIZE(DISPLAY_DEVICE);
//SHOWSIZE(VIDEOPARAMETERS);
SHOWSIZE(STARTUPINFO);
SHOWSIZE(PROCESS_INFORMATION);
SHOWSIZE(WNDCLASSEX);
SHOWSIZE(LRESULT);
SHOWSIZE(OPENFILENAME);
fclose(f);
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-27 23:46 +0000 |
| Message-ID | <o1fr6l$b89$1@dont-email.me> |
| In reply to | #97612 |
On 27/11/16 23:43, BartC wrote: > On 27/11/2016 23:26, Richard Heathfield wrote: >> On 27/11/16 23:02, BartC wrote: >>> On 27/11/2016 22:14, supercat@casperkitty.com wrote: > >>>> It's interesting that a lot of code writes >>>> "sizeof(variable)" >>>> or "sizeof (int)" rather than "sizeof variable" or "sizeof (int)", >>>> which >>>> probably contributes to the confusion. >>> >>> Yeah ... because a lot of people can't remember when it requires >>> parentheses and when it doesn't! >> >> It never, *ever* requires parentheses except on the vanishingly few >> occasions when you need to specify a type rather than an expression. > > In my code, that can happen a lot. I have only found one instance in my own code. The sizeof(type) construct is often used unwisely (which is not to say that there are not legitimate reasons to use it). -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-28 12:56 +0100 |
| Message-ID | <o1h5u6$pbi$1@dont-email.me> |
| In reply to | #97613 |
On 28/11/16 00:46, Richard Heathfield wrote: > On 27/11/16 23:43, BartC wrote: >> On 27/11/2016 23:26, Richard Heathfield wrote: >>> On 27/11/16 23:02, BartC wrote: >>>> On 27/11/2016 22:14, supercat@casperkitty.com wrote: >> >>>>> It's interesting that a lot of code writes >>>>> "sizeof(variable)" >>>>> or "sizeof (int)" rather than "sizeof variable" or "sizeof (int)", >>>>> which >>>>> probably contributes to the confusion. >>>> >>>> Yeah ... because a lot of people can't remember when it requires >>>> parentheses and when it doesn't! >>> >>> It never, *ever* requires parentheses except on the vanishingly few >>> occasions when you need to specify a type rather than an expression. >> >> In my code, that can happen a lot. > > I have only found one instance in my own code. The sizeof(type) > construct is often used unwisely (which is not to say that there are not > legitimate reasons to use it). > I find I use sizeof on types quite a lot, but in many of these cases it is as a static_assert to confirm the size of a struct before it is used, and therefore before there are any objects of that type in the code. But the need to make structs that match exactly to existing formats is probably more common in my type of programming than many other types of code. I also like to use parentheses when using sizeof on objects. I fully agree with you that it is not necessary - but I think it looks clearer. That is purely a personal choice, of course, and not required by the language.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-27 16:21 -0800 |
| Message-ID | <7adf8931-38bc-4d98-b61c-ca953a7bde04@googlegroups.com> |
| In reply to | #97612 |
On Sunday, November 27, 2016 at 6:43:32 PM UTC-5, Bart wrote:
> On 27/11/2016 23:26, Richard Heathfield wrote:
> > On 27/11/16 23:02, BartC wrote:
> >> On 27/11/2016 22:14, supercat@casperkitty.com wrote:
>
> >>> It's interesting that a lot of code writes
> >>> "sizeof(variable)"
> >>> or "sizeof (int)" rather than "sizeof variable" or "sizeof (int)", which
> >>> probably contributes to the confusion.
> >>
> >> Yeah ... because a lot of people can't remember when it requires
> >> parentheses and when it doesn't!
> >
> > It never, *ever* requires parentheses except on the vanishingly few
> > occasions when you need to specify a type rather than an expression.
>
> In my code, that can happen a lot. (See below, although here I used it
> so much that I wrapped it in a macro.)
>
>
> -------------------------------------------------------
>
> #include <stdio.h>
> #include <windows.h>
>
> #define SHOWSIZE(T) fprintf(f,#T " %d\n",sizeof(T))
>
> int main(void) {
> FILE* f;
>
> if (sizeof(void*)==8) {
> f=fopen("sizes64","wb");
> fprintf(f,"-- 64 BITS\n");
> }
> else {
> f=fopen("sizes32","wb");
> fprintf(f,"-- 32 BITS\n");
> }
>
> SHOWSIZE(BOOL);
> SHOWSIZE(WORD);
> SHOWSIZE(INT);
> SHOWSIZE(INPUT_RECORD);
> SHOWSIZE(WCHAR);
> SHOWSIZE(DWORD);
> SHOWSIZE(HWND);
> SHOWSIZE(UINT);
> SHOWSIZE(CHAR);
> SHOWSIZE(KEY_EVENT_RECORD);
> SHOWSIZE(WPARAM);
> SHOWSIZE(LPARAM);
> SHOWSIZE(SCROLLINFO);
> SHOWSIZE(SCROLLBARINFO);
> SHOWSIZE(COLORREF);
> SHOWSIZE(LOGPALETTE);
> SHOWSIZE(PALETTEENTRY);
> SHOWSIZE(PALETTEENTRY);
>
> SHOWSIZE(BITMAP);
> SHOWSIZE(BITMAPCOREHEADER);
> SHOWSIZE(BITMAPCOREINFO);
> SHOWSIZE(BITMAPFILEHEADER);
> SHOWSIZE(BITMAPINFO);
> SHOWSIZE(BITMAPINFOHEADER);
> SHOWSIZE(BITMAPV4HEADER);
> SHOWSIZE(BITMAPV5HEADER);
> SHOWSIZE(BLENDFUNCTION);
> SHOWSIZE(DIBSECTION);
> SHOWSIZE(RGBQUAD);
> SHOWSIZE(RGBTRIPLE);
> SHOWSIZE(SIZE);
> SHOWSIZE(LPSIZE);
> SHOWSIZE(TRIVERTEX);
> SHOWSIZE(RGNDATA);
> SHOWSIZE(RGNDATAHEADER);
> SHOWSIZE(PAINTSTRUCT);
> SHOWSIZE(LOGBRUSH);
> //SHOWSIZE(LOGBRUSH32);
> SHOWSIZE(ABC);
> SHOWSIZE(ABCFLOAT);
> SHOWSIZE(ENUMLOGFONT);
> SHOWSIZE(TEXTMETRIC);
> SHOWSIZE(NEWTEXTMETRIC);
> SHOWSIZE(LOGFONT);
> SHOWSIZE(EXTLOGFONT);
> SHOWSIZE(EXTLOGPEN);
> SHOWSIZE(LOGPEN);
> SHOWSIZE(MSG);
> SHOWSIZE(CHAR_INFO);
> SHOWSIZE(CONSOLE_CURSOR_INFO);
> SHOWSIZE(CONSOLE_FONT_INFO);
> SHOWSIZE(CONSOLE_SCREEN_BUFFER_INFO);
> //SHOWSIZE(CONSOLE_SCREEN_BUFFER_INFOEX);
> SHOWSIZE(INPUT_RECORD);
> SHOWSIZE(KEY_EVENT_RECORD);
> SHOWSIZE(FOCUS_EVENT_RECORD);
> SHOWSIZE(MENU_EVENT_RECORD);
> SHOWSIZE(MOUSE_EVENT_RECORD);
> SHOWSIZE(SMALL_RECT);
> SHOWSIZE(WINDOW_BUFFER_SIZE_RECORD);
> SHOWSIZE(COORD);
> SHOWSIZE(POINT);
> SHOWSIZE(POINTS);
> SHOWSIZE(RECT);
> SHOWSIZE(DISPLAY_DEVICE);
> //SHOWSIZE(VIDEOPARAMETERS);
> SHOWSIZE(STARTUPINFO);
> SHOWSIZE(PROCESS_INFORMATION);
> SHOWSIZE(WNDCLASSEX);
> SHOWSIZE(LRESULT);
> SHOWSIZE(OPENFILENAME);
>
> fclose(f);
>
> }
This is an atypical use of sizeof: you're just collecting information about the
characteristics of a particular implementation.
More typical uses are when you need the size of an object in order to do
something size-dependent to that object, such as malloc(), memcpy(), or
fwrite(). It's always possible to use sizeof(Type) in those cases, but it's
generally more appropriate (and less error prone) to write "sizeof expression",
where expression is an lvalue referring to the object whose size you need.
Of course, your refusal to correctly understand the distinctions between
pointers and arrays in C means that you would probably often fail to choose an
appropriate lvalue expression - sizeof is one of the key cases where your
carefully cultivated confusion about such matters is most likely to cause
problems.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-28 10:10 -0800 |
| Message-ID | <lntwara317.fsf@kst-u.example.com> |
| In reply to | #97598 |
BartC <bc@freeuk.com> writes:
> On 27/11/2016 16:35, David Brown wrote:
>> On 27/11/16 01:21, BartC wrote:
>
>>> So 14 functions so far, and you haven't yet looked at in-place versions.
>>
>> And that is why there is no "max" standard function in C.
>
> Huh? That is the very reason why it ought to be built-in and benefiting
> from overloading.
[...]
> Your reasons are just the usual excuses that try and justify why some
> obvious feature isn't in C. Of course if it /was/ in, then it would be
> indispensable!
Ultimately, the set of features that are built into C is pretty
much arbitrary. Built-in min and max operators might have been nice
to have, but they just don't happen to have been in the original
language -- and the functionality can always be implemented in code,
though a bit less conveniently than using a built-in operator.
If Ritchie had decided to implement min and max operators, I don't
believe I'd be saying that they're indepensible. I'd probably
say that they can be useful, but they're never strictly necessary,
and the language could have gotten along without them.
[...]
--
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 | Tim Prince <tprince@computer.org> |
|---|---|
| Date | 2016-11-27 07:40 -0500 |
| Message-ID | <ea02okFjr71U1@mid.individual.net> |
| In reply to | #97546 |
On 11/26/2016 3:49 PM, fir wrote: > classical question > > maybe someone know that (i realized it clearly quite recently) that there is no max (nor min) anywhere in c standard library (afaik there are fmax fmin for floats in math.h ) > > this is weird, maybe max from ibrary would be slow (though compilers have intrisinc for that so it could be made fast) and maybe this is a reason but absence of min max got weirld result that it must be defined in each project (no big worry as it is one line but still weird) > gcc -ffast-math optimizes fmax et al. by discarding the special requirements about non-finite operands. Recent releases of icc optimize the usual macros (with the usual caveats). There isn't adequate overlap even between icc and gcc on expressing this efficiently (nor between icpc, which optimizes std::max, and g++ nor msvc++). So I have macros which translate according to the compiler in use.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-11-27 08:46 -0800 |
| Message-ID | <fd651da7-b718-4ca6-8bdf-3454180c99cc@googlegroups.com> |
| In reply to | #97546 |
x>y?x:y
[toc] | [prev] | [next] | [standalone]
Page 28 of 29 — ← Prev page 1 … 26 27 [28] 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web