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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-29 18:32 -0700 |
| Message-ID | <lna8uemnuz.fsf@kst-u.example.com> |
| In reply to | #66541 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 29/07/15 23:50, Ben Bacarisse wrote:
[...]
>> not that all of the changes in C99 and C11 are inherently detrimental.
>
> I think they're detrimental only in the sense that they have split the
> language. Thought experiment: take any C99 or C11 feature, and imagine
> that C had it all along, right back to K&R C days. Would I think it was
> a bad feature? I doubt it very much. So it isn't the things that are
> changing, but the fact of the change, that is the problem (for me).
[...]
That's what I thought you meant, but I didn't find that to be 100%
clear until now.
A big factor is that C89/C90 was such a significant improvement over
pre-ANSI C (not least because the language was finally *standardized*),
and adoption by vendors was fairly quick. Prototypes in particular were
enough reason by themselves to switch over. I remember writing a
function call in pre-ANSI C with the wrong number of arguments, and the
compiler didn't complain about the error. I was horrified. (My
previous background was in Pascal, which is strict about such things.)
C99 and C11, on the other hand, have been more incremental changes, so
there's been less pressure on the vendors to implement them, making it
correspondingly harder for programmer who need to write portable code to
use the newer features.
Most of my own C programming has been in contexts where 100% portability
isn't necessary. Given that, I feel free to use C99-specific features
where they improve clarity (as I think you would do if C99 support were
as nearly universal as C90 support).
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-30 14:38 +1200 |
| Message-ID | <d1th0uF5hurU2@mid.individual.net> |
| In reply to | #66545 |
Keith Thompson wrote: > A big factor is that C89/C90 was such a significant improvement over > pre-ANSI C (not least because the language was finally *standardized*), > and adoption by vendors was fairly quick. Prototypes in particular were > enough reason by themselves to switch over. I remember writing a > function call in pre-ANSI C with the wrong number of arguments, and the > compiler didn't complain about the error. I was horrified. (My > previous background was in Pascal, which is strict about such things.) > > C99 and C11, on the other hand, have been more incremental changes, so > there's been less pressure on the vendors to implement them, making it > correspondingly harder for programmer who need to write portable code to > use the newer features. It has been interesting watching this discussion unroll. In the context of standards evolution, the portability and ubiquity of C can be its Achilles heal. Other languages often have a single implementation (Python and PHP spring to mind), so the argument that someone might be using an old interpreter isn't a good reason to stick with older versions of the language. C++ sits somewhere in between but has a greater momentum behind adoption of new standards. C++11 is close to fully supported by all major tool chains and they are all committed to C++14. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-30 10:56 +0100 |
| Message-ID | <87egjq3r4w.fsf@bsb.me.uk> |
| In reply to | #66548 |
Ian Collins <ian-news@hotmail.com> writes: <snip> > [...] Other languages often have a single > implementation (Python and PHP spring to mind), I know it's not really the point, but there's CPython and PyPy for Python, and PHP has Zend and HHVM and others. > so the argument that > someone might be using an old interpreter isn't a good reason to stick > with older versions of the language. I suspect that with the Python 3 re-write, them's fight'n words for some. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-30 22:28 +1200 |
| Message-ID | <d1uchkF5hurU3@mid.individual.net> |
| In reply to | #66553 |
Ben Bacarisse wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> so the argument that >> someone might be using an old interpreter isn't a good reason to stick >> with older versions of the language. > > I suspect that with the Python 3 re-write, them's fight'n words for > some. As a recent victim of said rewrite, I did hesitate a little when I wrote that :) While the Python changes did break plenty of code, it broke the code in a thoroughly portable and platform neutral way... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-30 10:57 +0100 |
| Message-ID | <mpcsbe$6oq$1@dont-email.me> |
| In reply to | #66548 |
On 30/07/2015 03:38, Ian Collins wrote: > Keith Thompson wrote: > >> A big factor is that C89/C90 was such a significant improvement over >> pre-ANSI C (not least because the language was finally *standardized*), >> and adoption by vendors was fairly quick. Prototypes in particular were >> enough reason by themselves to switch over. I remember writing a >> function call in pre-ANSI C with the wrong number of arguments, and the >> compiler didn't complain about the error. I was horrified. (My >> previous background was in Pascal, which is strict about such things.) >> >> C99 and C11, on the other hand, have been more incremental changes, so >> there's been less pressure on the vendors to implement them, making it >> correspondingly harder for programmer who need to write portable code to >> use the newer features. > > It has been interesting watching this discussion unroll. > > In the context of standards evolution, the portability and ubiquity of C > can be its Achilles heal. Other languages often have a single > implementation (Python and PHP spring to mind), so the argument that > someone might be using an old interpreter isn't a good reason to stick > with older versions of the language. Python isn't a good example of something having a single implementation. First, you have incompatible versions 2.x and 3.x. Then there are an assortment of versions of 3.0, 3.1, 3.11, ... 3.4, 3.5, ..... (And that's just CPython. Then there is Jython, IronPython, Brython RubyPython, Cython, Pyrex, RPython, Shed Skin, PyPy, etc with many incompatibilities.) Each new version also tends to be slower than the last, for a language not known for its speed in the first place. The choice isn't so simple. With C, the various new 'features' of the new standards just make it uglier IMO (uint_least32_t, _Bool, compound literals, designated initialisers, mixed up declarations and code...). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-03 08:02 -0700 |
| Message-ID | <kfny4hs8lf4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66460 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 25/07/15 18:02, Tim Rentsch wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> On 20/07/15 19:13, Tim Rentsch wrote:
>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
I would like to follow up and respond here, not to the particular
comments in the post being followed-up-to, but to the thread of
discussion as a whole.
I have been reading through the whole downstream discussion, and
trying to figure out what to say in response (or perhaps whether
I should say anything at all). What I think I would like to do
is not so much respond as play back your remarks, especially
those in the later stages, to see if I understand your point
of view (and especially your current understanding of it).
Your objection to C99 and following is that they have the effect
of diluting the standard. Just after C90 was standardized, and
basically for ten years thereafter, there was a single C
language, "one C to rule them all" one might say. And that was a
wonderful thing for C developers. Then in 1999, suddenly there
was a new C standard, different from C90, which changed a small
number of things and introduced a dozen or two new things (some
"big", some "small"), along with the declaration (ie, from ISO)
that this revised language is what constutes C.
An important consequence of C99, especially in light of what
compilers people were actually using, is that now "C" meant two
different things. Even worse, what C meant "officially" was
different from what C meant in practice, because C99 was not used
very much (for whatever set of reasons) for quite a few years
after it was introduced. No longer was it the case that there
was "one C to rule them all". This is horrible, especially if
one had endured the pre-standard era and then experienced the
joy after C was initially standardized (which description I
believe fits your own experience).
If we imagine a thought experiment, and one which is quite
impossible to actually perform, where what is now called C99
was the language initially standardized in 1989/90, and what
is now called C90 is the 1999 revision of that ("oops, we
put in features we shouldn't have"), based on your comments
I think you would have been just as adamant that the revision
(ie, what we now call C90) is a big mistake, and the original
language (what we now call C99) is much better. More adamant
in fact, since the (hypothetically) original language would
have been significantly reduced by the (again, hypothetical)
revision.
In characterizing the situation, you often use the word "simple",
but the simpleness is more about singleness of meaning than about
the language definition itself. Having to deal with a single C
language is simple; having to deal with multiple C languages is
not simple, even if (hypothetically) the simplicities of the
various C languages were all exactly the same. It is in this
sense that you say C99 was a big mistake (because it dilutes the
language) and C11 was a bigger mistake (because it dilutes the
language even more); the comment is not exactly about the
languages themselves as it is about the effect that having
multiple languages has on the development community.
All of the above is simply my attempt to play back what you have
said, in my own words of course, but trying to be faithful to
your intended meaning. Has my attempt done a good job of
hitting the mark? Or is there something I have misunderstood?
Proceeding on the (shaky) assumption that my rephrasing matches
what you were trying to say, there are two other comments I
would like to make.
The first is about portability, or more accurately about using
the term. In your remarks you often used the word portable or
one of its variants, but I think what you actually mean is
something slightly different, which is availability. Writing
code in C that is completely portable, even using just C90, is a
very difficult thing - limited range of ints, can't have big
objects, CHAR_BIT may be larger than 8, etc, I'm sure you know
the drill. The property you are looking for is that your
programs can be compiled widely, that is, availability of an
appropriate compiler for the language you are writing in, and not
a guarantee that the program will necessarily behave correctly on
all conforming implementations, even limited to just those
implementations that actually exist. (Of course, that is an
ideal that we would all like to achieve, but it isn't exactly
what you mean when you say C90 is portable -- right?)
The second is about how you answered. It is almost always true
that when I ask a question what I am looking for first is to
understand what the other person thinks. My problem with your
first answer is not that I disagreed with it, but that it didn't
do anything to help me understand your point of view. Not /why/
you think something, but /what/ it is you think in the first
place. To a first approximation I don't care if our opinions are
the same or different. But I do want to understand what your
opinion (or someone else's to whom I am asking a question) is.
Talking to me, it's better to simply state your views (assuming one
knows what they are in a state-able form, which isn't always the
case, but that's another matter) than to try to defend them.
(Unfortunately, how I come across to people when I ask questions
often seems to put them in a defensive posture, which I don't
understand very well but am trying to improve on. Anyway that's
my problem...) So for me in particular (and assuming it helps,
which may not be a good assumption), my suggestion is the short
advice "speak to convey, not to convice". If you convey your
point of view it may convince me; if you don't convey your point
of view it will never convince me. I don't claim this advice is
a good idea with all people, but generally I think it is a good
idea when you are (primarily) addressing a statement or question
that came from me.
I hope the above comments have helped further the discussion.
And now I await (with, I have to admit, a mixture of anticipation
and dread :) what comments you might make in response.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-03 08:33 -0700 |
| Message-ID | <aa15d6be-6700-4b3b-8a5d-c75534e408eb@googlegroups.com> |
| In reply to | #66784 |
On Monday, August 3, 2015 at 4:02:49 PM UTC+1, Tim Rentsch wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > > The first is about portability, or more accurately about using > the term. In your remarks you often used the word portable or > one of its variants, but I think what you actually mean is > something slightly different, which is availability. Writing > code in C that is completely portable, even using just C90, is a > very difficult thing - limited range of ints, can't have big > objects, CHAR_BIT may be larger than 8, etc, I'm sure you know > the drill. The property you are looking for is that your > programs can be compiled widely, that is, availability of an > appropriate compiler for the language you are writing in, and not > a guarantee that the program will necessarily behave correctly on > all conforming implementations, even limited to just those > implementations that actually exist. (Of course, that is an > ideal that we would all like to achieve, but it isn't exactly > what you mean when you say C90 is portable -- right?) > Code that compiles but doesn't execute correctly is a lot worse than code that won't compile. There are portability traps in C90. Basically the language trades micro efficiency for portablity. But there were a few simple things that could have been done. malloc() to take an in instead of a size_t. Arrays bigger than INT_MAX bytes to carry mandatory warnings. Now we've fixed things so you've got to work pretty hard to fix things so that int can't index any array. The problem with using integer types other than int is that you run into an N- squared compatibility problem. An int * won't match up with an sint32_t *, even if, as is likely, they're the same underlying types. The extra types do have legitimate uses where they are extremely handy, but those legitimate uses are few and far between. Once you make them available, you get programmers making everything a sint32_t thinking they're being more rigorous or more portable or whatever. The result is that interfacing code is full of casts and trivial reformatting functions, which mostly should be no-ops. 32 integer types or whatever it was at the last count is ridiculous, but that's what has happened.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-08-03 20:50 -0400 |
| Message-ID | <H%Tvx.70003$uE1.64906@fx01.iad> |
| In reply to | #66790 |
On 8/3/15 11:33 AM, Malcolm McLean wrote: > An int * won't match up with an sint32_t *, > even if, as is likely, they're the same underlying types. Actually, if int32_t is the same type as int (as in a typedef), then and int* and an int32_t* are the same type. The issue can be that if int and long are both 32 bit types, then this doesn't hold, as they are different fundamental types. You also have the issue that if you have int* and int32_t*, you can't normally assume they are the same, so you need to do something to fix things. (And casting is normally the wrong thing, as if, for example, and int was only 16 bits, accessing it through the int32_t accesses things outside the object).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-04 04:52 -0700 |
| Message-ID | <kfn4mkf8e3z.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66790 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, August 3, 2015 at 4:02:49 PM UTC+1, Tim Rentsch wrote: >> Richard Heathfield <rjh@cpax.org.uk> writes: >> >> The first is about portability, or more accurately about using >> the term. In your remarks you often used the word portable or >> one of its variants, but I think what you actually mean is >> something slightly different, which is availability. Writing >> code in C that is completely portable, even using just C90, is a >> very difficult thing - limited range of ints, can't have big >> objects, CHAR_BIT may be larger than 8, etc, I'm sure you know >> the drill. The property you are looking for is that your >> programs can be compiled widely, that is, availability of an >> appropriate compiler for the language you are writing in, and not >> a guarantee that the program will necessarily behave correctly on >> all conforming implementations, even limited to just those >> implementations that actually exist. (Of course, that is an >> ideal that we would all like to achieve, but it isn't exactly >> what you mean when you say C90 is portable -- right?) > > Code that compiles but doesn't execute correctly is a lot worse > than code that won't compile. I won't disagree but that is beside the point I was making, which is only about how the term was being used. > There are portability traps in C90. Basically the language > trades micro efficiency for portablity. But there were a few > simple things that could have been done. malloc() to take an > in instead of a size_t. Arrays bigger than INT_MAX bytes to > carry mandatory warnings. Now we've fixed things so you've got > to work pretty hard to fix things so that int can't index any > array. > > The problem with using integer types other than int is that you > run into an N- squared compatibility problem. An int * won't > match up with an sint32_t *, even if, as is likely, they're the > same underlying types. The extra types do have legitimate uses > where they are extremely handy, but those legitimate uses are > few and far between. Once you make them available, you get > programmers making everything a sint32_t thinking they're being > more rigorous or more portable or whatever. The result is that > interfacing code is full of casts and trivial reformatting > functions, which mostly should be no-ops. > > 32 integer types or whatever it was at the last count is > ridiculous, but that's what has happened. I don't agree with most of this editorial (and also it has some errors but that's another matter). If one is worried about the range of 'int' there is a simple way to avoid the problem, just use 'long' instead. The idea that the type of arguments to malloc() should be something other than size_t is silly. No doubt the somewhat large number of types and larger number of names for types that are some form of integer causes problems, but the notion that none of these should be used and everything written using just 'int' is hopelessly naive. I do think many people who use the types from <stdint.h> use them too much and in the wrong places, but completely abandoning the use of such types (or type names) goes too far in the other direction.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-04 06:08 -0700 |
| Message-ID | <a04612f6-c547-457e-ba4e-bd6775743e56@googlegroups.com> |
| In reply to | #66850 |
On Tuesday, August 4, 2015 at 12:52:57 PM UTC+1, Tim Rentsch wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > I don't agree with most of this editorial (and also it has some > errors but that's another matter). If one is worried about the > range of 'int' there is a simple way to avoid the problem, just > use 'long' instead. The idea that the type of arguments to > malloc() should be something other than size_t is silly. No > doubt the somewhat large number of types and larger number of > names for types that are some form of integer causes problems, > but the notion that none of these should be used and everything > written using just 'int' is hopelessly naive. I do think many > people who use the types from <stdint.h> use them too much and > in the wrong places, but completely abandoning the use of such > types (or type names) goes too far in the other direction. > In C as Denis Ritchie devised the language, there was implict int. Ritchie realised that everything should be an int, unless there was a clear reason otherwise. The syntax was wrong, however. It wasn't clear enough to a causal reader that foo() returned an integer. It had to be int foo(). But once implicit int went, so did the special status of int. There's now no standard for passing about integer types, there are 32 standards. Which means you need to have about 900 conversion functions that do nothing but convert buffers of integers to buffers of other integers, often with identical bit patterns.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-08-04 14:20 +0100 |
| Message-ID | <mpqe35$jse$1@dont-email.me> |
| In reply to | #66853 |
On 04/08/15 14:08, Malcolm McLean wrote: <snip> > There's now no standard for passing about integer types, there > are 32 standards. Which means you need to have about 900 conversion > functions that do nothing but convert buffers of integers to buffers > of other integers, often with identical bit patterns. Malcolm, you don't *have* to use the damn things! :-) -- 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-04 06:45 -0700 |
| Message-ID | <b1a253a0-7a20-499c-a62d-46b264c8b105@googlegroups.com> |
| In reply to | #66855 |
On Tuesday, August 4, 2015 at 2:20:19 PM UTC+1, Richard Heathfield wrote: > On 04/08/15 14:08, Malcolm McLean wrote: > > <snip> > > > There's now no standard for passing about integer types, there > > are 32 standards. Which means you need to have about 900 conversion > > functions that do nothing but convert buffers of integers to buffers > > of other integers, often with identical bit patterns. > > Malcolm, you don't *have* to use the damn things! :-) > That's true if you're just writing code for yourself. But once you've got to work with other people, you've got to agree on a format for communicating. Often that doesn't happen very well, often it can't, if you're using library A which uses size_t consistently for every count and index value, and library B which uses uint32_t for a size and int32_t for an index. The code is going to be littered with casts and ittle buffer-conversion routines.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 12:15 -0700 |
| Message-ID | <kfna8t0wucp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66853 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Tuesday, August 4, 2015 at 12:52:57 PM UTC+1, Tim Rentsch wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> I don't agree with most of this editorial (and also it has some >> errors but that's another matter). If one is worried about the >> range of 'int' there is a simple way to avoid the problem, just >> use 'long' instead. The idea that the type of arguments to >> malloc() should be something other than size_t is silly. No >> doubt the somewhat large number of types and larger number of >> names for types that are some form of integer causes problems, >> but the notion that none of these should be used and everything >> written using just 'int' is hopelessly naive. I do think many >> people who use the types from <stdint.h> use them too much and >> in the wrong places, but completely abandoning the use of such >> types (or type names) goes too far in the other direction. > > In C as Denis Ritchie devised the language, It's Dennis, not Denis. > there was implict int. > Ritchie realised that everything should be an int, unless there > was a clear reason otherwise. Forgive me if I disagree, but this statement is a crock. C was developed at at time when most machines, and especially machines that C was likely to run on, had only a single word size. Ritchie didn't "realize" anything about different sizes of integers, he simply made the obvious choice considering the types of machines available at the time. > The syntax was wrong, however. It wasn't clear enough to a causal > reader that foo() returned an integer. It had to be int foo(). > But once implicit int went, so did the special status of int. This is giberish. The "special status" of int disappeared long before implicit int did. C90 clearly shows this; it wasn't until C99 that implicit int went away. > There's now no standard for passing about integer types, there > are 32 standards. Which means you need to have about 900 conversion > functions that do nothing but convert buffers of integers to buffers > of other integers, often with identical bit patterns. This assumes that the occasion arises to convert between such array types, which IME it rarely - if ever - does.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-08-03 19:09 +0100 |
| Message-ID | <mpoalp$maf$1@dont-email.me> |
| In reply to | #66784 |
On 03/08/15 16:02, Tim Rentsch wrote:
<snip>
> Your objection to C99 and following is that they have the effect
> of diluting the standard. Just after C90 was standardized, and
> basically for ten years thereafter, there was a single C
> language, "one C to rule them all" one might say. And that was a
> wonderful thing for C developers. Then in 1999, suddenly there
> was a new C standard, different from C90, which changed a small
> number of things and introduced a dozen or two new things (some
> "big", some "small"), along with the declaration (ie, from ISO)
> that this revised language is what constutes C.
>
> An important consequence of C99, especially in light of what
> compilers people were actually using, is that now "C" meant two
> different things.
<snip>
That's a very good summary, yes.
>
> If we imagine a thought experiment, and one which is quite
> impossible to actually perform, where what is now called C99
> was the language initially standardized in 1989/90, and what
> is now called C90 is the 1999 revision of that ("oops, we
> put in features we shouldn't have"), based on your comments
> I think you would have been just as adamant that the revision
> (ie, what we now call C90) is a big mistake, and the original
> language (what we now call C99) is much better. More adamant
> in fact, since the (hypothetically) original language would
> have been significantly reduced by the (again, hypothetical)
> revision.
That's true. In fact, I conducted that thought experiment myself in a
recent reply (which I imagine is why you expressed it as you did,
above). It isn't the changes themselves, but the fact of the change.
> In characterizing the situation, you often use the word "simple",
> but the simpleness is more about singleness of meaning than about
> the language definition itself.
I think /sometimes/ it's about simplicity of language, though. Take, for
example, bool. Had this been in C90, I think it would have strengthened
the language. But wchar_t (which /was/ in C90) was a weakness. Frankly,
I think I would have preferred a C90 that did this:
byte - fundamental unit, exists only as unsigned type
char - guaranteed-at-least-32-bits character type, exists only as
unsigned type
to the mess we actually got. Unicode support would not then have
required any fundamental changes to the language.
> Having to deal with a single C
> language is simple; having to deal with multiple C languages is
> not simple, even if (hypothetically) the simplicities of the
> various C languages were all exactly the same. It is in this
> sense that you say C99 was a big mistake (because it dilutes the
> language) and C11 was a bigger mistake (because it dilutes the
> language even more); the comment is not exactly about the
> languages themselves as it is about the effect that having
> multiple languages has on the development community.
Yes, that's a reasonable summary.
>
> All of the above is simply my attempt to play back what you have
> said, in my own words of course, but trying to be faithful to
> your intended meaning. Has my attempt done a good job of
> hitting the mark? Or is there something I have misunderstood?
I think that's a job well jobbed.
>
> Proceeding on the (shaky) assumption that my rephrasing matches
> what you were trying to say, there are two other comments I
> would like to make.
>
> The first is about portability, or more accurately about using
> the term. In your remarks you often used the word portable or
> one of its variants, but I think what you actually mean is
> something slightly different, which is availability. Writing
> code in C that is completely portable, even using just C90, is a
> very difficult thing - limited range of ints, can't have big
> objects, CHAR_BIT may be larger than 8, etc, I'm sure you know
> the drill. The property you are looking for is that your
> programs can be compiled widely, that is, availability of an
> appropriate compiler for the language you are writing in, and not
> a guarantee that the program will necessarily behave correctly on
> all conforming implementations, even limited to just those
> implementations that actually exist.
It's both - in the sense that the program should actually do what is
required of it, regardless of the platform on which it is running.
> (Of course, that is an
> ideal that we would all like to achieve, but it isn't exactly
> what you mean when you say C90 is portable -- right?)
It's all about the program (if correctly written) doing the Right Thing
on all the platforms on which it runs. I think that /is/ an unattainable
ideal, yes - but at the very least we should be able to say:
#error Your platform is not supported because...
> The second is about how you answered. It is almost always true
> that when I ask a question what I am looking for first is to
> understand what the other person thinks. My problem with your
> first answer is not that I disagreed with it, but that it didn't
> do anything to help me understand your point of view. Not /why/
> you think something, but /what/ it is you think in the first
> place. To a first approximation I don't care if our opinions are
> the same or different. But I do want to understand what your
> opinion (or someone else's to whom I am asking a question) is.
> Talking to me, it's better to simply state your views (assuming one
> knows what they are in a state-able form, which isn't always the
> case, but that's another matter) than to try to defend them.
> (Unfortunately, how I come across to people when I ask questions
> often seems to put them in a defensive posture, which I don't
> understand very well but am trying to improve on.
You have an interesting writing style. I am, generally speaking, a
reasonably amicable person with quite a thick skin (specially developed
on, by, and for Usenet), so it isn't easy to offend me. In all honesty,
though, I do get the impression that you're trying hard. No doubt that
is a false impression, and it's just how it comes across to me, but it's
a hard impression to shake. I do my best to respond amicably, but
sometimes words fail me and I either don't reply at all or only offer a
very brief response. (Alas, it is also the case that I don't read every
article in comp.lang.c nowadays, so the absence of an answer does not
necessarily mean you've managed to get my goat again!) As I said, I'm
guessing that this outcome is not one that you intend, and so I try to
keep an open mind.
> Anyway that's
> my problem...) So for me in particular (and assuming it helps,
> which may not be a good assumption), my suggestion is the short
> advice "speak to convey, not to convice".
I'll see what I can do.
> If you convey your
> point of view it may convince me; if you don't convey your point
> of view it will never convince me. I don't claim this advice is
> a good idea with all people, but generally I think it is a good
> idea when you are (primarily) addressing a statement or question
> that came from me.
>
> I hope the above comments have helped further the discussion.
> And now I await (with, I have to admit, a mixture of anticipation
> and dread :) what comments you might make in response.
If you dread my response, you don't know me very well. It is true that
my sarcasm has been known to kill (at some distance, I might add), but I
don't crank it all the way up to 11 for just anyone, you know. :-)
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-04 06:09 -0700 |
| Message-ID | <kfnzj276vzc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66807 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 03/08/15 16:02, Tim Rentsch wrote: > > [I am snipping most of the stuff where there is just agreement] > >> In characterizing the situation, you often use the word "simple", >> but the simpleness is more about singleness of meaning than about >> the language definition itself. > > I think /sometimes/ it's about simplicity of language, though. > Take, for example, bool. Had this been in C90, I think it would > have strengthened the language. But wchar_t (which /was/ in C90) > was a weakness. Frankly, I think I would have preferred a C90 > that did this: > > byte - fundamental unit, exists only as unsigned type > char - guaranteed-at-least-32-bits character type, exists only as > unsigned type > > to the mess we actually got. Unicode support would not then have > required any fundamental changes to the language. But in spite of that you describe C90 as simple. This reinforces my view that, _when you made that particular statement_, "simple" is more about singleness of meaning than about how simple (or not) the language is. Please notice I said "more about", not "exclusively about". >> Proceeding on the (shaky) assumption that my rephrasing matches >> what you were trying to say, there are two other comments I >> would like to make. >> >> The first is about portability, or more accurately about using >> the term. In your remarks you often used the word portable or >> one of its variants, but I think what you actually mean is >> something slightly different, which is availability. Writing >> code in C that is completely portable, even using just C90, is a >> very difficult thing - limited range of ints, can't have big >> objects, CHAR_BIT may be larger than 8, etc, I'm sure you know >> the drill. The property you are looking for is that your >> programs can be compiled widely, that is, availability of an >> appropriate compiler for the language you are writing in, and not >> a guarantee that the program will necessarily behave correctly on >> all conforming implementations, even limited to just those >> implementations that actually exist. > > It's both - in the sense that the program should actually do what is > required of it, regardless of the platform on which it is running. I see that I wasn't specific enough in making my earlier statement. Let me try to correct that now. In comparing C90 and C99/C11, you describe C90 using the word portable (I don't remember if you say "more portable" but that isn't important). It is in this context that I made the above remarks. There is nothing about the language itself that makes C90 more portable than C99 - it isn't any harder to write a strictly conforming program in C99 than in C90 (and may in fact be very slightly easier, but in any case certainly is no harder). The difference you're talking about has not to do with how easy or hard it is to write programs that will execute identically, but how likely it is that someone will be able to compile a program in an unspecified environment. Limiting the context to _just that when you are comparing the languages_ (and not talking about programs), I think the portability adjective is not meant to be about properties of the languages themselves, but about the presence (or not) of implementations. In other words, availability. Do you agree? Or do you think it is easier to write strictly conforming code in C90 than it is in C99? I would be very surprised by the latter. >> (Of course, that is an >> ideal that we would all like to achieve, but it isn't exactly >> what you mean when you say C90 is portable -- right?) > > It's all about the program (if correctly written) doing the Right > Thing on all the platforms on which it runs. I think that /is/ an > unattainable ideal, yes - but at the very least we should be able > to say: > > #error Your platform is not supported because... I agree with your rule about detecting out-of-bounds circumstances, but again, when you say "C90 is portable" the statement is not about programs, and not about the language itself, but about the availability of implementions. Right? >> The second is about how you answered. It is almost always true >> that when I ask a question what I am looking for first is to >> understand what the other person thinks. My problem with your >> first answer is not that I disagreed with it, but that it didn't >> do anything to help me understand your point of view. Not /why/ >> you think something, but /what/ it is you think in the first >> place. To a first approximation I don't care if our opinions are >> the same or different. But I do want to understand what your >> opinion (or someone else's to whom I am asking a question) is. >> Talking to me, it's better to simply state your views (assuming one >> knows what they are in a state-able form, which isn't always the >> case, but that's another matter) than to try to defend them. >> (Unfortunately, how I come across to people when I ask questions >> often seems to put them in a defensive posture, which I don't >> understand very well but am trying to improve on. > > You have an interesting writing style. I am, generally speaking, > a reasonably amicable person with quite a thick skin (specially > developed on, by, and for Usenet), so it isn't easy to offend me. > In all honesty, though, I do get the impression that you're trying > hard. Really? You think my intention is to offend you? And not only that it is my intention to offend you but that I am making an effort to do so? I'm sorry to hear that; I don't know what to say except it isn't what I want to do and I will try to be aware in the future about what might be causing that. > No doubt that is a false impression, and it's just how it > comes across to me, but it's a hard impression to shake. I do my > best to respond amicably, but sometimes words fail me and I either > don't reply at all or only offer a very brief response. (Alas, it > is also the case that I don't read every article in comp.lang.c > nowadays, so the absence of an answer does not necessarily mean > you've managed to get my goat again!) As I said, I'm guessing > that this outcome is not one that you intend, and so I try to keep > an open mind. If or when it comes up again, please just ask me about it straight out. Hopefully it will be just a misunderstanding and one that can be cleared up easily. >> I hope the above comments have helped further the discussion. >> And now I await (with, I have to admit, a mixture of anticipation >> and dread :) what comments you might make in response. > > If you dread my response, you don't know me very well. > [snip elaboration] I won't try to explain further except to say my response to your writing style is similar to your response to my writing style. (Not identical, just similar.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-08-04 14:40 +0100 |
| Message-ID | <mpqf9e$ocm$1@dont-email.me> |
| In reply to | #66854 |
On 04/08/15 14:09, Tim Rentsch wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> On 03/08/15 16:02, Tim Rentsch wrote: >> >> [I am snipping most of the stuff where there is just agreement] >> >>> In characterizing the situation, you often use the word "simple", >>> but the simpleness is more about singleness of meaning than about >>> the language definition itself. >> >> I think /sometimes/ it's about simplicity of language, though. >> Take, for example, bool. Had this been in C90, I think it would >> have strengthened the language. But wchar_t (which /was/ in C90) >> was a weakness. Frankly, I think I would have preferred a C90 >> that did this: >> >> byte - fundamental unit, exists only as unsigned type >> char - guaranteed-at-least-32-bits character type, exists only as >> unsigned type >> >> to the mess we actually got. Unicode support would not then have >> required any fundamental changes to the language. > > But in spite of that you describe C90 as simple. Well, it's simpler than C99 or C11, yes. > This > reinforces my view that, _when you made that particular > statement_, "simple" is more about singleness of meaning > than about how simple (or not) the language is. Please > notice I said "more about", not "exclusively about". Alas, "simplicity" is heterological. It is extraordinarily difficult to pin down what we mean by "simplicity". Nevertheless, it is often possible to recognise it when we see it. I would regard the fact that (say) the plethora of integer types has made C more complicated as self-evident, but would you? I don't know. <snip> >>> The property you are looking for is that your >>> programs can be compiled widely, that is, availability of an >>> appropriate compiler for the language you are writing in, and not >>> a guarantee that the program will necessarily behave correctly on >>> all conforming implementations, even limited to just those >>> implementations that actually exist. >> >> It's both - in the sense that the program should actually do what is >> required of it, regardless of the platform on which it is running. > > I see that I wasn't specific enough in making my earlier statement. > Let me try to correct that now. > > In comparing C90 and C99/C11, you describe C90 using the word > portable (I don't remember if you say "more portable" but that > isn't important). It is in this context that I made the above > remarks. There is nothing about the language itself that makes C90 > more portable than C99 - it isn't any harder to write a strictly > conforming program in C99 than in C90 (and may in fact be very > slightly easier, but in any case certainly is no harder). The > difference you're talking about has not to do with how easy or hard > it is to write programs that will execute identically, but how > likely it is that someone will be able to compile a program in an > unspecified environment. Yes. C90 is available on pretty much any platform, even those that the mainstream has passed by. So those out in the eddies, so to speak, can still compile C90 programs, but they may not be able to compile C99 programs. (I accept that the number of people in this category is almost certainly diminishing, but I know that it's more than 0.) > Limiting the context to _just that when you are comparing the > languages_ (and not talking about programs), I think the > portability adjective is not meant to be about properties of the > languages themselves, but about the presence (or not) of > implementations. In other words, availability. Do you agree? Yes. > Or do you think it is easier to write strictly conforming > code in C90 than it is in C99? I would be very surprised by > the latter. I think it's (realistically speaking) almost impossible to write a /useful/ strictly conforming program in either dialect. Anyway, I can only speak from my own experience but I find it easier both to read C90 and to write C90 than to read or write C99 programs (if you discount those C99 programs that are also C90 programs). That's a general observation - to back it up would take more time than I care to invest. >>> (Of course, that is an >>> ideal that we would all like to achieve, but it isn't exactly >>> what you mean when you say C90 is portable -- right?) >> >> It's all about the program (if correctly written) doing the Right >> Thing on all the platforms on which it runs. I think that /is/ an >> unattainable ideal, yes - but at the very least we should be able >> to say: >> >> #error Your platform is not supported because... > > I agree with your rule about detecting out-of-bounds circumstances, > but again, when you say "C90 is portable" the statement is not > about programs, and not about the language itself, but about the > availability of implementions. Right? Yes. Let's do some indirection. Let p = &C89. ANSI standardised *p, and ISO adopted *p in 1990, and *p became widely portable. If p had originally been &C99, then we'd have a widely portable C99 language, and my beef with C99 (or at least *that* beef) would be non-existent. <snip> >>> (Unfortunately, how I come across to people when I ask questions >>> often seems to put them in a defensive posture, which I don't >>> understand very well but am trying to improve on. >> >> You have an interesting writing style. I am, generally speaking, >> a reasonably amicable person with quite a thick skin (specially >> developed on, by, and for Usenet), so it isn't easy to offend me. >> In all honesty, though, I do get the impression that you're trying >> hard. > > Really? You think my intention is to offend you? Actually, no. That is the *impression* I get. I don't think the impression accurately reflects your intent. Nevertheless, it is the impression I get. I therefore have to consciously reject that impression when replying to you, knowing that of course you're not trying to offend me, but I may not always be successful in doing this. <snip> >>> I hope the above comments have helped further the discussion. >>> And now I await (with, I have to admit, a mixture of anticipation >>> and dread :) what comments you might make in response. >> >> If you dread my response, you don't know me very well. >> [snip elaboration] > > I won't try to explain further except to say my response to > your writing style is similar to your response to my writing > style. (Not identical, just similar.) In elder days, Usenauts would write in an elaborately polite (and self-consciously anachronous) style, precisely because they knew this problem existed and wished to find a way to sidestep it. I am given to understand that it worked quite well. Nevertheless, it appears to have fallen by the wayside. That might be a shame. -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-05 13:24 -0700 |
| Message-ID | <kfnoahgvclx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66856 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 04/08/15 14:09, Tim Rentsch wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> On 03/08/15 16:02, Tim Rentsch wrote:
>>>
> [lots of technical stuff]
I read through what you wrote several times, but I still don't
know the answer to my most basic question. I think it is fair to
say (ie, we would both agree to the proposition) that you think
C90 is "better" than C99 (and later, but considering just C99 for
the moment). Assuming that is right (and of course please tell me
if it isn't!), then exactly one of the following statements must
hold:
A. You think C90 is better because and only because it was
standardized first; or
B. You think C90 is better because, whatever "betterness"
may have obtained from being standardized first, there
are also other factors that make it better.
Can you tell me which of A or B is the case?
If A is the case, I'm confused by some of what you said in
your last posting (ie, the snipped part).
If B is the case, I want to ask my question again: which
additions or changes in C99 constitute improvements, and which
fall into the "worserness" category? Please note that I mean
this question to be completely independent of any consideration
about which was standardized first.
> [various personal reactions]
Thank you for the comments. I read through these but don't want
to dilute the technical discussion just now. May have more to
say later. In any case I appreciate the responses.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-05 21:51 +0100 |
| Message-ID | <gBIGx.430438$bt.352405@fx32.am4> |
| In reply to | #69532 |
[I thought this thread was long dead!] On 05/09/2015 21:24, Tim Rentsch wrote: > Richard Heathfield<rjh@cpax.org.uk> writes: > >> On 04/08/15 14:09, Tim Rentsch wrote: >>> Richard Heathfield<rjh@cpax.org.uk> writes: >>> >>>> On 03/08/15 16:02, Tim Rentsch wrote: >>>> >> [lots of technical stuff] > > I read through what you wrote several times, but I still don't > know the answer to my most basic question. I think it is fair to > say (ie, we would both agree to the proposition) that you think > C90 is "better" than C99 (and later, but considering just C99 for > the moment). Assuming that is right (and of course please tell me > if it isn't!), then exactly one of the following statements must > hold: > > A. You think C90 is better because and only because it was > standardized first; or > > B. You think C90 is better because, whatever "betterness" > may have obtained from being standardized first, there > are also other factors that make it better. > > Can you tell me which of A or B is the case? It's B. <snip> > If B is the case, I want to ask my question again: which > additions or changes in C99 constitute improvements, and which > fall into the "worserness" category? Please note that I mean > this question to be completely independent of any consideration > about which was standardized first. I don't have a list of all the changes to hand, and I don't plan to look for one. So the following list is from memory, and I don't plan to spend very long on it, so it will be quite limited in scope. The observations are, of course, personal, and I recognise that one programmer's nightmare is another programmer's essential feature. deprecation of gets() and implicit int: good, and I presume you agree; burgeoning integer types: bad - they make the code harder to read; VLAs: bad - programs can already fail without the programmer being able to tell that there's a problem, for example, through over-use of recursion, so I'm not saying that VLAs introduced this difficulty, but they can only help to make the problem worse; all the extra maths stuff: bad because they massively increase the size of the Standard without a commensurate gain in utility; bool: good - I use it a lot in C++, but not of course in C; //: mixed - I don't use them myself because of portability constraints (I use them freely in C++), but if used exclusively they make "commenting out" of code much harder, which is a good thing, as comments should comment. But line-splicing can introduce a hard-to-find bug for those who don't use syntax colouring! for(int i: bad - the scoping of i becomes less clear; threading: mixed - I can see why they did it, but I predict that it will cause many problems for many of those who use it (writing threaded code properly is much harder than it looks); implied 0 return from main: bad - it is unnecessary (it takes about half a second to type return 0;) and makes no sense at all to me; ... that's all I have time for. OVERALL: C99 significantly increased the size of the language, and that in itself is, in my view, a backward step. Sorry, got other things to do now. <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-09-05 17:16 -0400 |
| Message-ID | <55EB5BB6.2090200@verizon.net> |
| In reply to | #69535 |
On 09/05/2015 04:51 PM, Richard Heathfield wrote: ... > for(int i: bad - the scoping of i becomes less clear; I don't see why. I can understand people not knowing what the scope is, but it's not a difficult scope to understand. The scope starts at the end of the declarator, and continues over the entire for-statement. It's also, in many cases, precisely the smallest scope that the variable needs to have (the variable can and should be declared somewhere else if that's not the case).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-05 19:59 -0700 |
| Message-ID | <lnlhckuubr.fsf@kst-u.example.com> |
| In reply to | #69535 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> all the extra maths stuff: bad because they massively increase the size
> of the Standard without a commensurate gain in utility;
Does this refer to the math functions for float and long double?
For example, C90 only has
double sqrt(double);
C99 added
float sqrtf(float);
long double sqrtl(long double);
and likewise for the other math functions.
That does increase the size of the standard, but since it's a uniform
change across the math functions, I wouldn't say it increases
the *conceptual* size by much. And I'd say it makes long double
substantially more useful.
[...]
> //: mixed - I don't use them myself because of portability constraints
> (I use them freely in C++), but if used exclusively they make
> "commenting out" of code much harder, which is a good thing, as comments
> should comment. But line-splicing can introduce a hard-to-find bug for
> those who don't use syntax colouring!
(If I were designing a language from scratch, it would *only* have
end-of-line comments.)
Line-splicing is a good point. For example, this:
#include <stdio.h>
int main(void) {
// This is a comment \
printf("foo");
puts("bar");
}
*should* print "foobar", because there's a space after the backslash,
and only a backslash *immediately* followed by a newline causes a line
splice. But both gcc and clang print "bar", which IMHO is incorrect;
clang at least warns about the space and the multi-line // comment.
> for(int i: bad - the scoping of i becomes less clear;
I disagree; the scope of i is perfectly clear.
> threading: mixed - I can see why they did it, but I predict that it will
> cause many problems for many of those who use it (writing threaded code
> properly is much harder than it looks);
Threading was added by C11, not C99.
[...]
--
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]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web