Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #65653 > unrolled thread
| Started by | doctor@doctor.nl2k.ab.ca (The Doctor) |
|---|---|
| First post | 2015-07-15 20:40 +0000 |
| Last post | 2015-07-16 09:55 +1200 |
| Articles | 20 on this page of 182 — 21 participants |
Back to article view | Back to comp.lang.c
SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-15 20:40 +0000
Re: SQL filesortcc question Paavo Helde <myfirstname@osa.pri.ee> - 2015-07-15 16:08 -0500
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-15 17:15 -0400
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-15 23:22 +0000
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 18:35 +0200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 17:48 +0100
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 19:38 +0200
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:48 +0000
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 22:17 +0200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-16 21:44 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:51 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-17 09:05 +1200
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:52 +0000
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-17 11:36 -0400
Re: SQL filesortcc question The Doctor <doctor@doctor.nl2k.ab.ca> - 2015-07-17 22:22 +0000
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-17 18:44 -0400
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-18 11:13 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 22:06 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:52 +0000
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:24 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-17 00:26 +0000
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:50 +0000
Re: SQL filesortcc question John Bode <jfbode1029@gmail.com> - 2015-07-31 13:39 -0700
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:48 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-17 09:07 +1200
Re: SQL filesortcc question Philip Lantz <prl@canterey.us> - 2015-07-16 16:05 -0700
Re: SQL filesortcc question David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:28 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 11:13 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-20 19:27 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-21 08:46 +1200
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-22 15:12 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:55 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:01 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:51 +1200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 10:02 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-27 23:35 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 14:16 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 04:49 +0100
Re: SQL filesortcc question Martin Shobe <martin.shobe@yahoo.com> - 2015-07-27 23:25 -0500
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-28 09:32 +0000
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-28 10:22 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-27 22:33 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 04:57 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 16:38 +1200
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-28 00:51 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 07:06 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 20:32 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 10:02 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 22:08 +1200
Re: SQL filesortcc question David Kleinecke <dkleinecke@gmail.com> - 2015-07-28 18:17 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 12:14 -0400
Re: SQL filesortcc question Martin Shobe <martin.shobe@yahoo.com> - 2015-07-29 11:27 -0500
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 13:01 -0400
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-29 17:33 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-29 21:07 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 16:33 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-29 22:12 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-29 23:50 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 00:13 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 01:49 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 02:07 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 03:04 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 08:25 +0100
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-30 09:15 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 17:17 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 17:00 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 17:12 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-30 15:12 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 23:13 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-31 10:29 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-31 08:10 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 11:12 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-31 22:56 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 18:34 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-01 13:55 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 07:13 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-01 15:36 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 09:19 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-01 18:16 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 15:30 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-02 09:00 -0400
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-02 09:19 -0400
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:23 +0000
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 06:35 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 19:11 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 10:28 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 09:04 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 00:19 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 13:55 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 07:03 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 16:53 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 09:19 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 21:20 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 14:07 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 12:24 +0200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 13:49 +0100
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 15:41 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 07:24 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-07 17:04 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 06:48 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 08:00 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 08:52 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:56 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-04 23:45 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-05 08:45 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:00 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-01 13:17 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-01 16:11 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 14:00 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 10:40 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:20 -0700
Re: SQL filesortcc question Rosario19 <Ros@invalid.invalid> - 2015-08-22 08:24 +0200
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-22 19:26 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 05:39 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 13:51 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 10:38 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:14 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 01:15 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:24 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 02:32 +0200
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 12:57 +1200
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-01 22:23 -0700
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:21 -0500
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 19:21 +0200
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:05 -0500
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:24 -0500
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 23:56 -0700
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:25 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 14:19 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-29 19:53 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-29 23:45 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 04:22 -0700
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 13:13 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 13:27 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 13:57 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 14:11 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 14:39 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 15:05 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 14:03 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-30 11:22 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-29 18:32 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 14:38 +1200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 10:56 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 22:28 +1200
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 10:57 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 08:02 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 08:33 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-03 20:50 -0400
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 04:52 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:08 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:20 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:45 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:15 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-03 19:09 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 06:09 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:40 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 13:24 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-09-05 21:51 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-09-05 17:16 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-09-05 19:59 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-09-06 07:51 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 17:32 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 10:04 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-07-21 13:23 +0200
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-22 15:14 +0000
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:25 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:31 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 17:10 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 13:29 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 23:51 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 20:24 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 03:02 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 09:22 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 15:04 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 10:32 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 16:49 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 21:46 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-27 04:53 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-26 14:58 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 15:15 -0700
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:47 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:55 +1200
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-30 02:07 +0100 |
| Message-ID | <mpbt8v$j9e$1@dont-email.me> |
| In reply to | #66543 |
On 30/07/15 01:49, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 29/07/15 23:50, Ben Bacarisse wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: >>> >>>> On 29/07/15 17:14, James Kuyper wrote: >>> <snip> >>>>> That strikes me as so implausible that I must favor a different >>>>> explanation: you're simply prejudiced against making any changes to C >>>>> whatsoever. And that must indeed be a prejudice, not a reasoned >>>>> judgment, because the idea that C as originally standardized was so >>>>> perfect that it could not be improved upon is just plain ridiculous. >>>> >>>> I would argue that it is a reasoned judgement *even though* C90 isn't >>>> perfect. C90 /must/ remain, for the *practical* reason that it works >>>> everywhere. For me, the ability to write /*this*/ like //this >>>> isn't sufficient compensation for one of my users no longer being able >>>> to compile my code. >>> >>> But your ability to write //this rather than /*this*/ >>> does not prevent a single user from compiling your code. >> >> Because it's you saying it, I'm trying hard to see some sense in what >> you say, but I'm afraid I'm failing. Okay, let's try this: it's >> certainly true that the ability itself doesn't prevent a user from >> compiling my code *provided that* I do not avail myself of that >> ability - and indeed that's the route I take. But somehow I don't >> think that's what you mean. > > No, that's exactly what I mean. You are railing against changes that > you do not need to avail yourself of. Yes. > I have no complaint about your > rational choice to use the smallest practical subset of C that suits > your needs, but what is your argument against the growth of C in ways > that are not incompatible with that? This molehill is well on its way to becoming a Munro, isn't it? C90 has three massive advantages in its favour: 1) it's really, really fast; 2) it's really, really portable; 3) it's really, really simple. C99 and C11 are both less portable and less simple than C90 (although I wouldn't want to rank them against each other, since I understand that some C11 features are C99 features made optional, which would actually increase portability relative to C99 for those not using those features). It is my contention that the extra features of C99 and C11 do not compensate for the loss of portability and simplicity that is entailed in adding new features to /any/ language. As I have said elsethread, if on some occasions I don't need the portability of C90 (and yes, this does happen), why on earth would I use C99 or C11 when I can use C++? I see nothing in either C99 or C11 that attracts me. If I want to write, say, a GUI program, there is a certain satisfaction to be gained from writing it in C but if I'm even slightly in a hurry to get something up and running I head straight for C++ like a half-starved bear heads for a picnic basket. Now, it may well be that you see plenty in C99 or C11 that attracts you to them rather than to C++, and that's fine... for you. But, as the man said, include me out. <snip> -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-30 03:04 +0100 |
| Message-ID | <87k2ti4cza.fsf@bsb.me.uk> |
| In reply to | #66544 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 30/07/15 01:49, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 29/07/15 23:50, Ben Bacarisse wrote:
>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>>>
>>>>> On 29/07/15 17:14, James Kuyper wrote:
>>>> <snip>
>>>>>> That strikes me as so implausible that I must favor a different
>>>>>> explanation: you're simply prejudiced against making any changes to C
>>>>>> whatsoever. And that must indeed be a prejudice, not a reasoned
>>>>>> judgment, because the idea that C as originally standardized was so
>>>>>> perfect that it could not be improved upon is just plain ridiculous.
>>>>>
>>>>> I would argue that it is a reasoned judgement *even though* C90 isn't
>>>>> perfect. C90 /must/ remain, for the *practical* reason that it works
>>>>> everywhere. For me, the ability to write /*this*/ like //this
>>>>> isn't sufficient compensation for one of my users no longer being able
>>>>> to compile my code.
>>>>
>>>> But your ability to write //this rather than /*this*/
>>>> does not prevent a single user from compiling your code.
>>>
>>> Because it's you saying it, I'm trying hard to see some sense in what
>>> you say, but I'm afraid I'm failing. Okay, let's try this: it's
>>> certainly true that the ability itself doesn't prevent a user from
>>> compiling my code *provided that* I do not avail myself of that
>>> ability - and indeed that's the route I take. But somehow I don't
>>> think that's what you mean.
>>
>> No, that's exactly what I mean. You are railing against changes that
>> you do not need to avail yourself of.
>
> Yes.
>
>> I have no complaint about your
>> rational choice to use the smallest practical subset of C that suits
>> your needs, but what is your argument against the growth of C in ways
>> that are not incompatible with that?
>
> This molehill is well on its way to becoming a Munro, isn't it?
What do you mean by this? I don't know what it is the molehill, what is
the Munro, and who is making the one from the other. Do you mean that
your main contention ("I'm against making changes to C") is trivial? Do
mean that I'm making too much of it by asking you to explain your
reasoning for that position?
> C90 has three massive advantages in its favour:
>
> 1) it's really, really fast;
> 2) it's really, really portable;
> 3) it's really, really simple.
>
> C99 and C11 are both less portable and less simple than C90 (although
> I wouldn't want to rank them against each other, since I understand
> that some C11 features are C99 features made optional, which would
> actually increase portability relative to C99 for those not using
> those features).
>
> It is my contention that the extra features of C99 and C11 do not
> compensate for the loss of portability and simplicity that is entailed
> in adding new features to /any/ language.
So the problems are all for other people -- they might have to learn a
more complex language (because there might be no one around to tell them
to just learn C90) and they might loose portability, again because of
bad advice?
When you wrote "For me, the ability to write /*this*/ like //this isn't
sufficient compensation for one of my users no longer being able to
compile my code" were you just being rhetorical? Did you mean to say
that whilst *you* know how to get your code to compile everywhere, other
people might be seduced into using less universally supported features?
If so, I don't want to argue that point -- you may be right about it --
it was what you seemed to be saying about the effect of the language
changes on *your* code and *your* aim of portability that I had a
problem with.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-30 08:25 +0100 |
| Message-ID | <mpcjdu$840$1@dont-email.me> |
| In reply to | #66546 |
On 30/07/15 03:04, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
<snip>
>>
>> This molehill is well on its way to becoming a Munro, isn't it?
>
> What do you mean by this? I don't know what it is the molehill, what is
> the Munro, and who is making the one from the other.
The molehill is the tiny, tiny point at issue - which is that I don't
like the changes being made to C. It's something I care quite strongly
about but it's a tiny point nevertheless, because ISO don't give a damn
what I think and they're not going to rewind the whole C world on my
say-so. We, comp.lang.c, have turned this tiny tiny molehill of a
discussion into a mountain - and probably it's me who should carry most
of the blame because I was never very good at spotting the right point
at which to agree to differ and move on (although I do try).
> Do you mean that
> your main contention ("I'm against making changes to C") is trivial?
To everyone but me, yes, of course it's trivial. Like *everything* we
discuss here. But I just get the feeling that, for some reason, this
particular discussion seems to be beginning to raise tempers, and I
don't think that's a good thing among friends.
> Do
> mean that I'm making too much of it by asking you to explain your
> reasoning for that position?
No, I certainly don't mean that. I think that we as a group are making
too much of it, and that's probably my fault.
>> C90 has three massive advantages in its favour:
>>
>> 1) it's really, really fast;
>> 2) it's really, really portable;
>> 3) it's really, really simple.
>>
>> C99 and C11 are both less portable and less simple than C90 (although
>> I wouldn't want to rank them against each other, since I understand
>> that some C11 features are C99 features made optional, which would
>> actually increase portability relative to C99 for those not using
>> those features).
>>
>> It is my contention that the extra features of C99 and C11 do not
>> compensate for the loss of portability and simplicity that is entailed
>> in adding new features to /any/ language.
>
> So the problems are all for other people -- they might have to learn a
> more complex language (because there might be no one around to tell them
> to just learn C90) and they might loose portability, again because of
> bad advice?
I don't suppose other people even consider it to be a problem.
> When you wrote "For me, the ability to write /*this*/ like //this isn't
> sufficient compensation for one of my users no longer being able to
> compile my code" were you just being rhetorical? Did you mean to say
> that whilst *you* know how to get your code to compile everywhere, other
> people might be seduced into using less universally supported features?
I think that happened a long time ago, didn't it?
> If so, I don't want to argue that point -- you may be right about it --
> it was what you seemed to be saying about the effect of the language
> changes on *your* code and *your* aim of portability that I had a
> problem with.
I think the real danger is that, if C90 is left far enough behind,
people will stop producing C90 compilers for new machines as and when
they come along, and then we'll /all/ have a problem with portability.
But don't mind me.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-30 09:15 -0700 |
| Message-ID | <ln1tfpmxkr.fsf@kst-u.example.com> |
| In reply to | #66552 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 30/07/15 03:04, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
>>> This molehill is well on its way to becoming a Munro, isn't it?
>>
>> What do you mean by this? I don't know what it is the molehill, what is
>> the Munro, and who is making the one from the other.
>
> The molehill is the tiny, tiny point at issue - which is that I don't
> like the changes being made to C.
[snip]
I'm familiar with the idea of "making a mountain out of a molehill", but
I've never heard Munro used in that context. I see that a "Munro" is
defined as a mountain in Scotland with a height over 3000 feet (not one
specific mountain, it's a generic term); I had never heard that term
before.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-30 17:17 +0100 |
| Message-ID | <mpdiki$qgu$1@dont-email.me> |
| In reply to | #66568 |
On 30/07/15 17:15, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> On 30/07/15 03:04, Ben Bacarisse wrote: >>> Richard Heathfield <rjh@cpax.org.uk> writes: > [...] >>>> This molehill is well on its way to becoming a Munro, isn't it? >>> >>> What do you mean by this? I don't know what it is the molehill, what is >>> the Munro, and who is making the one from the other. >> >> The molehill is the tiny, tiny point at issue - which is that I don't >> like the changes being made to C. > [snip] > > I'm familiar with the idea of "making a mountain out of a molehill", but > I've never heard Munro used in that context. Nor had I. I think I can claim precedence. > I see that a "Munro" is > defined as a mountain in Scotland with a height over 3000 feet (not one > specific mountain, it's a generic term); I had never heard that term > before. There are plenty of other hitherto unfamiliar mountain categories to get to grips with, including "Marilyn" - a prominence (i.e. a height above a contour line that contains no higher peaks) of at least 492 feet, and yes, bless them, they called it a "Marilyn" to contrast with "Munro" (even though she didn't spell it like that). See also "Hewitt", "Nuttall", "Wainwright", "Donald", and "Corbett". (Non-exhaustive list!) -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-30 17:00 +0100 |
| Message-ID | <878u9x4oud.fsf@bsb.me.uk> |
| In reply to | #66552 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 30/07/15 03:04, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
> <snip>
>>>
>>> This molehill is well on its way to becoming a Munro, isn't it?
>>
>> What do you mean by this? I don't know what it is the molehill, what is
>> the Munro, and who is making the one from the other.
>
> The molehill is the tiny, tiny point at issue - which is that I don't
> like the changes being made to C.
That's not the point I took issue with. I know your views on the changes
made to C and I have no desire to discuss them.
I joined in only because of your apparent claim that the changes to C
affect the portability of your code -- they don't (except for a couple
of cases you've discounted and a couple more that you've not cited as
being a problematic).
You supported your position ("I'm against making changes to C") with the
requirement that no user should be unable to compile your code, but
you've not said how any of the changes you dislike might prevent that.
If your objections are, in fact, unrelated to the portability of your
own code, then I misunderstood, but it seemed clear at the time that
that was not what you were saying.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-30 17:12 +0100 |
| Message-ID | <mpdiab$p91$1@dont-email.me> |
| In reply to | #66569 |
On 30/07/15 17:00, Ben Bacarisse wrote: <snip> > I joined in only because of your apparent claim that the changes to C > affect the portability of your code -- they don't (except for a couple > of cases you've discounted and a couple more that you've not cited as > being a problematic). Actually, the more I think about this (and the more you berate me for not having thought about it enough!), the less concerned I am about it, so long as the changes do not remove important C90 features. Personally, I'd be happy to lose continue, goto, setjmp, longjmp, all the wide char stuff, and a whole bunch else besides, but I think other people might not be too pleased to see those things disappear. But if, for example, C2X decided to deprecate strcpy, and C2Y then removed it, yes, that would be a problem for me. <snip> -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-30 15:12 -0400 |
| Message-ID | <mpdss9$6jd$1@dont-email.me> |
| In reply to | #66570 |
On 07/30/2015 12:12 PM, Richard Heathfield wrote: > On 30/07/15 17:00, Ben Bacarisse wrote: > > <snip> > >> I joined in only because of your apparent claim that the changes to C >> affect the portability of your code -- they don't (except for a couple >> of cases you've discounted and a couple more that you've not cited as >> being a problematic). > > Actually, the more I think about this (and the more you berate me for > not having thought about it enough!), the less concerned I am about it, > so long as the changes do not remove important C90 features. Precisely - it's only changes to or removal of C90 features that you are actually using (unlike gets() and implicit int) that would have any impact on the portability of your code. Unless, of course, you use one of the new keywords as a user-defined identifier - but there's not many of those, and as of C2011 they've started more consistently using names that are reserved to the implementation. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-30 23:13 -0700 |
| Message-ID | <23e151d6-343b-41ea-a9e7-5fcd3c286c9d@googlegroups.com> |
| In reply to | #66575 |
On Thursday, July 30, 2015 at 8:12:52 PM UTC+1, James Kuyper wrote:
>
> Precisely - it's only changes to or removal of C90 features that you are
> actually using (unlike gets() and implicit int) that would have any
> impact on the portability of your code. Unless, of course, you use one
> of the new keywords as a user-defined identifier - but there's not many
> of those, and as of C2011 they've started more consistently using names
> that are reserved to the implementation.
>
That's not really true.
Consider this.
int powell_minimise( double (*fptr)(double *x, void *context), double *xmax, double *xmin, int N, void *context, double **ret, int *Nret)
/*
find the minima of fptr.
fptr - function to minimise
xmax, xmin - vectors for maximum and minimum limits on x
N - number of elements.
context - context pointer passed back to fptr
ret - return for minima found (malloced)
Nret - number of minima found.
Returns: -1 on error (usually function not well behaved enough),
0 on success.
*/
That's the sort of standard C code that could have been written years ago.
A modern compiler will whinge about N and Nret not being size_t's,
Also if you try to pass constants to xmin and xmax.
But C++ will have far more serious problems. If the C++ programmer
wants his context to be a class and the function to be a class
member, as is reasonable, the parameters are in the wrong order.
And worse still, it violates const correctness. Context is likely
to be a constant, because it only makes sense to find the minima
of a stable, deterministic function. But if the C++ programmer uses
const, the interface becomes thoroughly const poisoned.
We can make trivial modifications to this function to address these
problems. Then of course you break any existing code that calls it,
and you've got to use ugly pre-processor magic to define way the
consts and size_ts for the legacy compilers.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-31 10:29 +0100 |
| Message-ID | <87d1z8bror.fsf@bsb.me.uk> |
| In reply to | #66597 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, July 30, 2015 at 8:12:52 PM UTC+1, James Kuyper wrote: >> >> Precisely - it's only changes to or removal of C90 features that you are >> actually using (unlike gets() and implicit int) that would have any >> impact on the portability of your code. Unless, of course, you use one >> of the new keywords as a user-defined identifier - but there's not many >> of those, and as of C2011 they've started more consistently using names >> that are reserved to the implementation. >> > That's not really true. > Consider this. > > int powell_minimise( double (*fptr)(double *x, void *context), double *xmax, double *xmin, int N, void *context, double **ret, int *Nret) > > /* > find the minima of fptr. > fptr - function to minimise > xmax, xmin - vectors for maximum and minimum limits on x > N - number of elements. > context - context pointer passed back to fptr > ret - return for minima found (malloced) > Nret - number of minima found. > Returns: -1 on error (usually function not well behaved enough), > 0 on success. > */ > That's the sort of standard C code that could have been written years ago. > > A modern compiler will whinge about N and Nret not being size_t's, Why? (Maybe I don't have any modern compilers here, but those that I do have are silent on this matter.) > Also if you try to pass constants to xmin and xmax. You mean, I think, that you'll be warned if you pass pointer *to* const qualified objects, but why would you not want to be warned about that? It's helpful to be told that the interface is badly specified, isn't it? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-31 08:10 -0400 |
| Message-ID | <mpfog8$6c2$1@dont-email.me> |
| In reply to | #66601 |
On 07/31/2015 05:29 AM, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Thursday, July 30, 2015 at 8:12:52 PM UTC+1, James Kuyper wrote: >>> >>> Precisely - it's only changes to or removal of C90 features that you are >>> actually using (unlike gets() and implicit int) that would have any >>> impact on the portability of your code. Unless, of course, you use one >>> of the new keywords as a user-defined identifier - but there's not many >>> of those, and as of C2011 they've started more consistently using names >>> that are reserved to the implementation. >>> >> That's not really true. >> Consider this. >> >> int powell_minimise( double (*fptr)(double *x, void *context), double *xmax, double *xmin, int N, void *context, double **ret, int *Nret) >> >> /* >> find the minima of fptr. >> fptr - function to minimise >> xmax, xmin - vectors for maximum and minimum limits on x >> N - number of elements. >> context - context pointer passed back to fptr >> ret - return for minima found (malloced) >> Nret - number of minima found. >> Returns: -1 on error (usually function not well behaved enough), >> 0 on success. >> */ >> That's the sort of standard C code that could have been written years ago. >> >> A modern compiler will whinge about N and Nret not being size_t's, > > Why? (Maybe I don't have any modern compilers here, but those that I do > have are silent on this matter.) And what does that have to do with the differences between C90 and C2011, the subject of that paragraph? C90 and C2011 provide exactly the same amount of justification for issuing such a warning - which is to say, none whatsoever. >> Also if you try to pass constants to xmin and xmax. > > You mean, I think, that you'll be warned if you pass pointer *to* const > qualified objects, but why would you not want to be warned about that? > It's helpful to be told that the interface is badly specified, isn't it? Yes - and the features of C that enable such useful warnings was already present in C90. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-31 11:12 -0700 |
| Message-ID | <41d84730-d85b-46e6-bf9f-5ee81d019b83@googlegroups.com> |
| In reply to | #66601 |
On Friday, July 31, 2015 at 10:30:18 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Thursday, July 30, 2015 at 8:12:52 PM UTC+1, James Kuyper wrote: > >> > >> Precisely - it's only changes to or removal of C90 features that you are > >> actually using (unlike gets() and implicit int) that would have any > >> impact on the portability of your code. Unless, of course, you use one > >> of the new keywords as a user-defined identifier - but there's not many > >> of those, and as of C2011 they've started more consistently using names > >> that are reserved to the implementation. > >> > > That's not really true. > > Consider this. > > > > int powell_minimise( double (*fptr)(double *x, void *context), double *xmax, double *xmin, int N, void *context, double **ret, int *Nret) > > > > /* > > find the minima of fptr. > > fptr - function to minimise > > xmax, xmin - vectors for maximum and minimum limits on x > > N - number of elements. > > context - context pointer passed back to fptr > > ret - return for minima found (malloced) > > Nret - number of minima found. > > Returns: -1 on error (usually function not well behaved enough), > > 0 on success. > > */ > > That's the sort of standard C code that could have been written years ago. > > > > A modern compiler will whinge about N and Nret not being size_t's, > > Why? (Maybe I don't have any modern compilers here, but those that I do > have are silent on this matter.) > > > Also if you try to pass constants to xmin and xmax. > > You mean, I think, that you'll be warned if you pass pointer *to* const > qualified objects, but why would you not want to be warned about that? > It's helpful to be told that the interface is badly specified, isn't it? > The interface isn't badly specified. It's none of the minimiser's business what caller does with his context pointer. Whilst typically it will be some parameters for the function which are read-only for the duration of the call, if it puts up pretty graphics on screen to give a visual feedback of progress, that's acceptable.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-31 22:56 +0100 |
| Message-ID | <87wpxg9eka.fsf@bsb.me.uk> |
| In reply to | #66611 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, July 31, 2015 at 10:30:18 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > On Thursday, July 30, 2015 at 8:12:52 PM UTC+1, James Kuyper wrote: >> >> >> >> Precisely - it's only changes to or removal of C90 features that you are >> >> actually using (unlike gets() and implicit int) that would have any >> >> impact on the portability of your code. Unless, of course, you use one >> >> of the new keywords as a user-defined identifier - but there's not many >> >> of those, and as of C2011 they've started more consistently using names >> >> that are reserved to the implementation. >> >> >> > That's not really true. >> > Consider this. >> > >> > int powell_minimise( double (*fptr)(double *x, void *context), double *xmax, double *xmin, int N, void *context, double **ret, int *Nret) >> > >> > /* >> > find the minima of fptr. >> > fptr - function to minimise >> > xmax, xmin - vectors for maximum and minimum limits on x >> > N - number of elements. >> > context - context pointer passed back to fptr >> > ret - return for minima found (malloced) >> > Nret - number of minima found. >> > Returns: -1 on error (usually function not well behaved enough), >> > 0 on success. >> > */ >> > That's the sort of standard C code that could have been written years ago. >> > >> > A modern compiler will whinge about N and Nret not being size_t's, >> >> Why? (Maybe I don't have any modern compilers here, but those that I do >> have are silent on this matter.) >> >> > Also if you try to pass constants to xmin and xmax. >> >> You mean, I think, that you'll be warned if you pass pointer *to* const >> qualified objects, but why would you not want to be warned about that? >> It's helpful to be told that the interface is badly specified, isn't it? >> > The interface isn't badly specified. Yes, it is. It fails to convey some key information and you then specifically, and incorrectly, blame C for this fault in the interface. > It's none of the minimiser's > business what caller does with his context pointer. You: "Also if you try to pass constants to xmin and xmax". The context pointer is not at issue. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-31 18:34 -0700 |
| Message-ID | <55c991ac-01b7-4f79-bf36-9064e179e401@googlegroups.com> |
| In reply to | #66622 |
On Friday, July 31, 2015 at 10:56:39 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > It's none of the minimiser's > > business what caller does with his context pointer. > > You: "Also if you try to pass constants to xmin and xmax". The context > pointer is not at issue. > That particular "weakness" is a fair enough point. The function can't alter min and max. If the callback fiddles with them, the system is likely to fail quite badly. If we const qualify everything, then that can't happen (const isn't entirely useless, there are some bugs it will catch). But you need to have a certain degree of insight into how a minimiser works to call one successfully anyway, and in reality it's going to fail because caller tries to pass it a function which has minima but which is too difficult for it, not because there's an internal bug that over-writes xmin/xmax (possible but not the type of bug that's very likely to get to a late stage), or because caller thinks he can fiddle with those values in the callback. const qualifying the min/max would give him an extra degree of warning, but wouldn't actually prevent that, since min / max are not const in the scope of the caller. A better argument is that xmin /xmax are confusing, because they could be used to return limits on the minima, rather than to pass in limits on the search space. But the confusion only arises because some programmers like to be "const correct", that is, everything which happens to be an input takes const. So that's another way in which the introduction of a new keyword has an impact on those who would prefer to ignore it. My own view is that the visual clutter of const over-rides the input / output documentation benefits, though that's obviously a subjective claim .
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-01 13:55 +0100 |
| Message-ID | <878u9v9nhy.fsf@bsb.me.uk> |
| In reply to | #66630 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, July 31, 2015 at 10:56:39 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > It's none of the minimiser's >> > business what caller does with his context pointer. >> >> You: "Also if you try to pass constants to xmin and xmax". The context >> pointer is not at issue. >> > That particular "weakness" is a fair enough point. Right. So, just to be clear, you have now withdrawn both of the points you raised. When James said: || Precisely - it's only changes to or removal of C90 features that you are || actually using (unlike gets() and implicit int) that would have any || impact on the portability of your code. Unless, of course, you use one || of the new keywords as a user-defined identifier - but there's not many || of those, and as of C2011 they've started more consistently using names || that are reserved to the implementation. and you replied: | That's not really true. | Consider this. you now agree that neither of your points were valid? (I assume your not answering my question about the first point was because you agree it was wrong.) Do you, in fact, now agree with James? I know you have other concerns, but the discussion would be more cordial and collegiate if you would say when you end up agreeing with a position that you originally appear to disagree with. Maybe you still don't agree with the remark, but then you need to say what's wrong with it citing evidence that does not collapse as soon as it is examined. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-01 07:13 -0700 |
| Message-ID | <16a336f5-97c4-4846-b4e9-99083820e2d2@googlegroups.com> |
| In reply to | #66633 |
On Saturday, August 1, 2015 at 1:55:53 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > > That particular "weakness" is a fair enough point. > > Right. So, just to be clear, you have now withdrawn both of the points > you raised. When James said: > No, because it's a fair enough principle that input-only parameters should be marked "const". There are also reasons for not so doing, such as to maintain compatibility with pre-const compilers, to reduce visual clutter, and because const tends to lead to lead to programming errors which are hard to correct, when something is const-qualified accidentally. There's also the point that C const doesn't do what it says on the tin. The question is whether the legitimate position that const should be ignored is undermined by the existence of the const extension to the language. The answer is yes. If you dislike const, for whatever reason, it's not a valid counter-argument that "it's there for people who find it useful, it doesn't have to affect you". However the question of whether const was a good or bad addition to the language is a separate one. Of course there's a perfectly good case to be made that it was a good idea, unless we take the position that the committee is utterly stupid, there must be at least one argument you can advance that stands up to more than a few minutes' scrutiny.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-08-01 15:36 +0100 |
| Message-ID | <8738039itr.fsf@bsb.me.uk> |
| In reply to | #66635 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 1, 2015 at 1:55:53 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > That particular "weakness" is a fair enough point. >> >> Right. So, just to be clear, you have now withdrawn both of the points >> you raised. When James said: >> > No, because it's a fair enough principle that input-only parameters > should be marked "const". There are also reasons for not so doing, > such as to maintain compatibility with pre-const compilers, to > reduce visual clutter, and because const tends to lead to lead > to programming errors which are hard to correct, when something is > const-qualified accidentally. None of that has anything to do with what James (and I) said, and I see you've cut the remark in question again from the quotes. This suggests you don't really want to address it (probably because you now agree with it). The remark was about post C90 changes that would affect the portability of C90 code, to which you said "That's not really true" and preceded to give an example that showed nothing at all about post C90 changes. I won't re-instate the quote again -- the one you say is not not really true -- because you'll probably just cut it again and talk about why you don't like const. If you still think James's remark is not really true (essentially a summary of what had been said earlier), put the quote back yourself and have another go at giving evidence to support that position. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-01 09:19 -0700 |
| Message-ID | <7bf88bc6-6144-4601-b539-b34f994bd8c5@googlegroups.com> |
| In reply to | #66636 |
On Saturday, August 1, 2015 at 3:36:45 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Saturday, August 1, 2015 at 1:55:53 PM UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> > >> > That particular "weakness" is a fair enough point. > >> > >> Right. So, just to be clear, you have now withdrawn both of the points > >> you raised. When James said: > >> > > No, because it's a fair enough principle that input-only parameters > > should be marked "const". There are also reasons for not so doing, > > such as to maintain compatibility with pre-const compilers, to > > reduce visual clutter, and because const tends to lead to lead > > to programming errors which are hard to correct, when something is > > const-qualified accidentally. > > None of that has anything to do with what James (and I) said, and I see > you've cut the remark in question again from the quotes. This suggests > you don't really want to address it (probably because you now agree with > it). > > The remark was about post C90 changes that would affect the portability > of C90 code, to which you said "That's not really true" and preceded to > give an example that showed nothing at all about post C90 changes. > > I won't re-instate the quote again -- the one you say is not not really > true -- because you'll probably just cut it again and talk about why you > don't like const. If you still think James's remark is not really true > (essentially a summary of what had been said earlier), put the quote > back yourself and have another go at giving evidence to support that > position. > James: Precisely - it's only changes to or removal of C90 features that you are actually using (unlike gets() and implicit int) that would have any impact on the portability of your code. Unless, of course, you use one of the new keywords as a user-defined identifier - but there's not many of those, and as of C2011 they've started more consistently using names that are reserved to the implementation. So I've shown that's not generally the case, if we replace C90 by "any C standard". I don't think James was talking specifically about C90, he was making a more general point about the evolution of languages. At first sight it seems obvious that he's right - if a new feature is a superset of the old language and you don't use it, it shouldn't affect you. But a closer analysis shows that he's wrong here (whilst still making an intelligent and well-mannered contribution tot eh discussion).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-08-01 18:16 -0400 |
| Message-ID | <55BD4528.7050505@verizon.net> |
| In reply to | #66636 |
On Saturday, August 1, 2015 at 12:21:04 PM UTC-4, Malcolm McLean wrote: > James: > Precisely - it's only changes to or removal of C90 features that you are > actually using (unlike gets() and implicit int) that would have any > impact on the portability of your code. Unless, of course, you use one > of the new keywords as a user-defined identifier - but there's not many > of those, and as of C2011 they've started more consistently using names > that are reserved to the implementation. > > So I've shown that's not generally the case, if we replace C90 by "any C standard". > I don't think James was talking specifically about C90, he was making a > more general point about the evolution of languages. At first sight it seems > obvious that he's right - if a new feature is a superset of the old language > and you don't use it, it shouldn't affect you. But a closer analysis shows > that he's wrong here (whilst still making an intelligent and well-mannered > contribution tot eh discussion). I apologize for taking so long to respond - I normally only see your messages when someone else responds to them, and no one else has seen fit to respond to that one. I happened to notice it only because I was using Google Groups to conduct a search that happened to match this thread. Because I've instructed Thunderbird to delete any of your messages as soon as they arrive, and that deletion is irreversible, I can't even respond to them directly, I can only attach my responses to the right thread in approximately the right location by responding to someone else's message. Sorry for any confusion caused by that misplacement. This whole exchange has demonstrated to me the wisdom of having set up my message filters that way - as usual, I've found discussion with you rather frustrating. You're right about the fact that I was making a general point. It is just as true of "K&R C" as it is about "C90". Therefore, if the introduction of 'const' with the first version of the C standard had been a good counter-example, you would have been justified in objecting to the general rule I was invoking - though you could have made your point a lot clearer by explicitly saying that that was the point you were making. The wording you actually used left us with the impression that you were objecting to that particular application of the rule, rather than the rule itself. However, your argument is not a counter-example. I would assume that your K&R C code did not use 'const' as an identifier in a way that conflicted with it's C90 status as a keyword (one of the exceptions I explicitly acknowledged). If so, then the only way you could have ran into problems due to the fact that C90 added 'const' is if those problems were the result of 'const' being added in appropriate locations to the declarations of identifiers that are not in your code - either standard headers or third-party library headers. Such changes are examples of "changes to ... [K&R C] features that you are actually using". As such, the problems you ran into are correctly covered by the statement I made, with "C90" replaced by "K&R C".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-01 15:30 -0700 |
| Message-ID | <eb28bc83-e2b7-4070-9ea8-ff526fc494f3@googlegroups.com> |
| In reply to | #66657 |
On Saturday, August 1, 2015 at 11:16:24 PM UTC+1, James Kuyper wrote: > > I would assume that your K&R C code did not use 'const' as an identifier > in a way that conflicted with it's C90 status as a keyword (one of the > exceptions I explicitly acknowledged). If so, then the only way you > could have ran into problems due to the fact that C90 added 'const' is > if those problems were the result of 'const' being added in appropriate > locations to the declarations of identifiers that are not in your code - > either standard headers or third-party library headers. Such changes are > examples of "changes to ... [K&R C] features that you are actually > using". As such, the problems you ran into are correctly covered by the > statement I made, with "C90" replaced by "K&R C". > No, you've failed to understand. if I provide subroutines that are not "const correct" then callers who attempt to impose const correctness face problems. So the existence of const has implications. If we all agree that const is deprecated, then of course we can write const-free code and everything will work. But you can't expect such an agreement when providing code for use by people whose identity may be unknown. Whilst const is an obvious example, it's not the only one. If caller is used to a stream of arbitrary bytes being a uint8_t *, he's not going to be happy casting to an unsigned char, even though it's almost certainly a no-op (his code will break on non CHAR_BIT 8 machines, code that ses unsigned char probably won't). Even if you think you're retaining backwards compatibility, you're often not really, the legacy code might still compile, but it becomes less usable.
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web