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 189 — 22 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-28 21:13 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-29 13:41 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-02 07:20 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-29 13:08 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 23:11 -0700
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 David Thompson <dave.thompson2@verizon.net> - 2015-09-20 18:35 -0400
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 15:04 -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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| 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]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-09-06 07:51 +0100 |
| Message-ID | <goRGx.403260$LU5.393469@fx12.am4> |
| In reply to | #69567 |
On 06/09/2015 03:59, Keith Thompson wrote: <snip> > Threading was added by C11, not C99. Picky picky picky. :-) -- 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-06 17:32 -0700 |
| Message-ID | <kfn8u8joyqt.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #69535 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> [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.
That's just what I'm looking for, your personal reactions.
> 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.
Excellent list, thank you for the info.
When you have time, here is a list of other significant features.
(I know it's long, but I'm not looking for a lengthy exposition;
just a few words on each would be great, or of course more if you
have more you want to say.)
va_copy macro
inline functions
compound literals
restricted pointers
empty macro arguments
flexible array members
designated initializers
reliable integer division
mixed declarations and code
more precise aliasing rules
__func__ predefined identifier
additional predefined macro names
increased minimum translation limits
remove implicit function declaration
macros with a variable number of arguments
trailing comma allowed in enum declaration
the vscanf family of functions in <stdio.h>
the snprintf family of functions in <stdio.h>
return without expression not permitted in function that
returns a value (and vice versa)
relaxed constraints on aggregate and union initialization
IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
> OVERALL: C99 significantly increased the size of the language,
Really, significantly? What besides VLA's and math stuff
(we can put _Complex in that category) changed the size
significantly? All the above seem like small changes to
me (support for IEEE floating point might be an exception
to that, but that is optional and almost all in an annex).
> and that in itself is, in my view, a backward step.
I can understand why you might have that reaction, but I'm still
curious about why you think C99 is significantly larger than C90.
Is it just VLA's and lots of math functionality? Or something
else?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-25 10:04 -0700 |
| Message-ID | <kfn1tfwgod1.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66040 |
Richard Heathfield <rjh@cpax.org.uk> writes: > [Tim, I warn you in advance that you will not like this answer.] That's because it was a non-answer answer. Any genuine answer to the actual question would have been fine.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-07-21 13:23 +0200 |
| Message-ID | <mola1d$f36$1@dont-email.me> |
| In reply to | #65710 |
On 16/07/15 18:48, Richard Heathfield wrote: > On 16/07/15 17:35, jacobnavia wrote: >> Le 15/07/2015 23:15, James Kuyper a écrit : >>> I know a fair amount of C++, more than >>> the average person on comp.lang.c - but I can't figure out what's >>> causing the parse error - so you need a better C++ expert than me. >> >> >> That is the reason I try to avoid C++ as faar as I can. >> >> C++ is unreadable, even for experts! > > Fortunately, I am not a C++ expert. I therefore have no problem reading > /my/ C++ programs, at least. Often I feel the same about C. It is quite possible to write incomprehensible code in any language - some people in this newsgroup seem to take pride in writing compilable line noise. C++ simply gives you more options for illegibility, and allows you to make your code incomprehensible through verbosity, while C obfuscation experts usually aim for compact source code. > > The problem seems to be that the language has so many features, all of > which seem enormously tempting. If you're not using a whole bunch of > classes (with multiple inheritance and polymorphism and all the rest of > it), you're not really writing in C++. If you're not using operator > overloading, you're not really writing in C++. If you're not writing > your own templates, you're not really writing in C++. If you're not... > how long do we have? And when you've finished, you have everything > shoehorned in there, but it's... eeeuuuuwwww. It is quite possible - and some would say this is a /good/ thing - to write C++ code using only the features that add benefit to the code. Unfortunately, there seem to be a good many bad C++ programmers around, who like to misuse features that they don't understand, or attempt to use the latest fashions, patterns or styles without purpose. I realise this is unjustified generalisation, but I feel that well-written C++ code is at least as clear as or clearer than well-written C code - while badly written C++ is worse than badly written C code. > > But by far the most frustrating thing I find about C++ is that nothing > ever seems to *do* anything. Everything seems to be about asking > something else to do the doing. When I finally get to one tiny part of > the doings, it's a couple of lines of code that give me no feel for > what's actually going on - the rest of it is /somewhere else/. I have seen code like that in C++. Everything seems to be a delegater or a factory function passing things around without doing anything useful. But I have also seen C code like that - and in general, when C code attempts to do something that the C++ language supports directly (like object oriented programming), the C code is far worse. > I get the > feeling that a very clever person with a deep understanding of the > language has worked very hard to stop me finding out how the program > actually works. Usually it's just a person who doesn't really understand the problem he is trying to solve, or the structure of the code he is trying to write. /Sometimes/ a bit of abstraction and delegation is a good thing, allowing parts of the code to be more independent - often it is making things so general that it is hard to get an overview of what is going on. > > So I decided not to even try to become an expert, and contented myself > instead with writing simple, readable C++ programs. > > <advocacy> > That's why I'd like C to stay simple; it's also why C99 was a big > mistake, and of course it's why C11 was an even bigger mistake. > </advocacy> > C99 has a number of useful features (for me), such as booleans, standardised fixed size integers, designated initialisers, inline functions, mixing declarations and code, one-line comments, and dropping monstrosities like implicit int. It is other features that are irrelevant to me, such as VLAs - but I see no harm in them. They cost nothing if they are not used, and they work in an obvious way when they /are/ used. C11 provides very little of use to me - _Static_assert is the only feature I have used (and pre-C11 I used an ugly macro to get the same effect). The multi-threading and atomic stuff is not a bad idea, but it is too little, too late, to be of much use. All in all, C11 seems more like a wasted opportunity to make real and useful improvements to the language, rather than being a "big mistake".
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-07-22 15:14 +0000 |
| Message-ID | <55afb30b.2254750@news.xs4all.nl> |
| In reply to | #66099 |
David Brown <david.brown@hesbynett.no> wrote: > On 16/07/15 18:48, Richard Heathfield wrote: > > On 16/07/15 17:35, jacobnavia wrote: > >> Le 15/07/2015 23:15, James Kuyper a écrit : > >>> I know a fair amount of C++, more than > >>> the average person on comp.lang.c - but I can't figure out what's > >>> causing the parse error - so you need a better C++ expert than me. > >> > >> > >> That is the reason I try to avoid C++ as faar as I can. > >> > >> C++ is unreadable, even for experts! > > > > Fortunately, I am not a C++ expert. I therefore have no problem reading > > /my/ C++ programs, at least. > > Often I feel the same about C. It is quite possible to write > incomprehensible code in any language - some people in this newsgroup > seem to take pride in writing compilable line noise. C++ simply gives > you more options for illegibility, and allows you to make your code > incomprehensible through verbosity, while C obfuscation experts usually > aim for compact source code. The advantage of the C way is that at least it will be _clear_ that it's obfuscated C code, while with illegible C++ you'll have to guess whether it's intentionally bad, unintentionally bad, or simply written in the 80% of the language you happen to be unfamiliar with. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-25 15:25 -0700 |
| Message-ID | <1ae592b8-18ee-4764-9d6d-b571e88d3ab3@googlegroups.com> |
| In reply to | #66099 |
On Tuesday, July 21, 2015 at 12:24:01 PM UTC+1, David Brown wrote: > > Unfortunately, there seem to be a good many bad C++ programmers around, > who like to misuse features that they don't understand, or attempt to > use the latest fashions, patterns or styles without purpose. I realise > this is unjustified generalisation, but I feel that well-written C++ > code is at least as clear as or clearer than well-written C code - while > badly written C++ is worse than badly written C code. > It's possible to do a good job with C++. However only a few programming problems really require that type of approach. Physical reality is not structured around objects which are derived types of each other, and whilst sometimes it makes sense to construct an artificial world with that metaphor, more often it doesn't. > > I have seen code like that in C++. Everything seems to be a delegater > or a factory function passing things around without doing anything useful. > > But I have also seen C code like that - and in general, when C code > attempts to do something that the C++ language supports directly (like > object oriented programming), the C code is far worse. > You can embed a few function pointers in C structures to allow for polymorphism. But once you go more than a short way down that route, the code becomes impossible to follow, and you're better off with C++. Essentially what C++ does is trivial re-presentation of data so you can manipulate it with the same code. (C does this, ptr++ will increment a pointer by one data element, be that a char or a 10K structure, but C++ makes it a principle). The snag is that the language isn't clever enough to do it all automatically, the user has to provide code. So essentially all that code is doing is packaging an reformatting. But that can't actually achieve any useful computation. > > Usually it's just a person who doesn't really understand the problem he > is trying to solve, or the structure of the code he is trying to write. > /Sometimes/ a bit of abstraction and delegation is a good thing, > allowing parts of the code to be more independent - often it is making > things so general that it is hard to get an overview of what is going on. > One layer of abstraction is extremely powerful. But two layers aren't twice as good. One raincoat will protect you from the rain, but putting on two raincoats will only help in a few unusual situations, but it will cost twice as more and be more than twice as awkward. > > C11 provides very little of use to me - _Static_assert is the only > feature I have used (and pre-C11 I used an ugly macro to get the same > effect). The multi-threading and atomic stuff is not a bad idea, but it > is too little, too late, to be of much use. All in all, C11 seems more > like a wasted opportunity to make real and useful improvements to the > language, rather than being a "big mistake". > C11 gradually moves C++ over to being less C with classes and more a language with dynamic typing and functional programming features like lambdas and closures.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-26 11:31 +1200 |
| Message-ID | <d1ikifFkmuhU1@mid.individual.net> |
| In reply to | #66364 |
Malcolm McLean wrote: > On Tuesday, July 21, 2015 at 12:24:01 PM UTC+1, David Brown wrote: >> >> Unfortunately, there seem to be a good many bad C++ programmers around, >> who like to misuse features that they don't understand, or attempt to >> use the latest fashions, patterns or styles without purpose. I realise >> this is unjustified generalisation, but I feel that well-written C++ >> code is at least as clear as or clearer than well-written C code - while >> badly written C++ is worse than badly written C code. >> > It's possible to do a good job with C++. However only a few programming > problems really require that type of approach. Physical reality > is not structured around objects which are derived types of each > other, and whilst sometimes it makes sense to construct an > artificial world with that metaphor, more often it doesn't. Yet again your are erroneously extrapolating from your own small niche. Most of the work in my niche (embedded, drivers and UNIX systems programming) is structured around objects, many of which are derived types of each other. I have also spent a number of years working with GUI code and XML DOM, both of which also fall into that category. My first experience with an OO design was an elegant C GUI toolkit. >> I have seen code like that in C++. Everything seems to be a delegater >> or a factory function passing things around without doing anything useful. >> >> But I have also seen C code like that - and in general, when C code >> attempts to do something that the C++ language supports directly (like >> object oriented programming), the C code is far worse. >> > You can embed a few function pointers in C structures to allow > for polymorphism. But once you go more than a short way down > that route, the code becomes impossible to follow, and you're > better off with C++. Essentially what C++ does is trivial > re-presentation of data so you can manipulate it with the same > code. Or not so trivial if you consider the alternative C code to achieve the same effect. > (C does this, ptr++ will increment a pointer by one > data element, be that a char or a 10K structure, but C++ makes > it a principle). The snag is that the language isn't clever > enough to do it all automatically, the user has to provide code. > So essentially all that code is doing is packaging an reformatting. > But that can't actually achieve any useful computation. In what sense? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-25 17:10 -0700 |
| Message-ID | <7d4eac26-36b2-4373-ae16-26a572975acf@googlegroups.com> |
| In reply to | #66375 |
On Sunday, July 26, 2015 at 12:31:37 AM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > > You can embed a few function pointers in C structures to allow > > for polymorphism. But once you go more than a short way down > > that route, the code becomes impossible to follow, and you're > > better off with C++. Essentially what C++ does is trivial > > re-presentation of data so you can manipulate it with the same > > code. > > Or not so trivial if you consider the alternative C code to achieve the > same effect. > The C code is often either a no-op or a void * plus a size parameter. For example C++ has a system of "copy constructors". You need to specify a copy constructor for each object you create. You also need a default constructor. An stl "vector" (wrapped array) then calls the default constructor to create empty objects, and the copy constructor to add them into the array. It's quite a bit of machinery. The C equivalent is memcpy(&array[i], &obj, sizeof(object)). You just don't have the move problem, because all the embedded objects in the structures must be represented by pointers. They get copied by bit pattern. The only situation it breaks down is where the structure has an embedded pointer to the structure itself. Then you have to be careful to store pointers to structures rather than the structures themselves. The real advantage of C++ is that object destruction is automatic. But on Linux, valgrind will catch memory leaks for you, so it's not usually an issue. If you can't valgrind code, then making sure everythign is cleaned up manually can be a problem. > > (C does this, ptr++ will increment a pointer by one > > data element, be that a char or a 10K structure, but C++ makes > > it a principle). The snag is that the language isn't clever > > enough to do it all automatically, the user has to provide code. > > So essentially all that code is doing is packaging an reformatting. > > But that can't actually achieve any useful computation. > > In what sense? > C++ templates, class inheritance, const correctness, lexical closures and other features are language-level operations. They don't calculate useful results, instead they give instructions to the compiler how to set up the environment so that a human programmer can specify such operations without accidentally writing over the wrong data, in the case of const, or to give him an interface, in the case of a base class that is designed to be overridden. But you often need quite a bit of code to do that. That's why you get the Russian doll program effect. A lot of the code the programmer writes doesn't do anything, it just tells the compiler that he agrees that an enum a can be inserted into a stream and if it is type text then it needs one conversion and if it is type binary it needs another, then if it's type text he sets up the template to bind to the string representation. But in C this just becomes fprintf(fp, "lettertype: %s", enum_a_ids[a]); You can of course just as easily type enum_b_ids[a] and you won't get a warning. But that's essentially what the code is achieving, it's not computing anything, it's setting up the system so that it's harder to write the wrong value to the file.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-26 13:29 +1200 |
| Message-ID | <d1irfmFkmuhU2@mid.individual.net> |
| In reply to | #66381 |
Malcolm McLean wrote: > On Sunday, July 26, 2015 at 12:31:37 AM UTC+1, Ian Collins wrote: >> Malcolm McLean wrote: >> >>> You can embed a few function pointers in C structures to allow >>> for polymorphism. But once you go more than a short way down >>> that route, the code becomes impossible to follow, and you're >>> better off with C++. Essentially what C++ does is trivial >>> re-presentation of data so you can manipulate it with the same >>> code. >> >> Or not so trivial if you consider the alternative C code to achieve the >> same effect. >> > The C code is often either a no-op or a void * plus a size > parameter. For example C++ has a system of "copy constructors". > You need to specify a copy constructor for each object you create. Nope. > You also need a default constructor. Nope. > An stl "vector" (wrapped array) then calls the default constructor > to create empty objects, and the copy constructor to add them > into the array. It's quite a bit of machinery. Which will be used if necessary (copying objects is non-trivial) , optimised away if not. Either way, the programmer doesn't have worry. This is especially important if a the object is modified and a copy is changed from trivial to non-trivial. > The C equivalent is memcpy(&array[i], &obj, sizeof(object)). And if copying obj is non-trivial? > You just don't have the move problem, because all the embedded > objects in the structures must be represented by pointers. They > get copied by bit pattern. The only situation it breaks down is > where the structure has an embedded pointer to the structure > itself. Then you have to be careful to store pointers to > structures rather than the structures themselves. So when you copy a structure with embedded pointers, who is responsible for freeing the memory they point to? > The real advantage of C++ is that object destruction is automatic. > But on Linux, valgrind will catch memory leaks for you, so it's > not usually an issue. If you can't valgrind code, then making sure > everythign is cleaned up manually can be a problem. Not forgetting memory isn't the only resource that has to be cleaned up. >>> (C does this, ptr++ will increment a pointer by one >>> data element, be that a char or a 10K structure, but C++ makes >>> it a principle). The snag is that the language isn't clever >>> enough to do it all automatically, the user has to provide code. >>> So essentially all that code is doing is packaging an reformatting. >>> But that can't actually achieve any useful computation. >> >> In what sense? >> > C++ templates, class inheritance, const correctness, lexical > closures and other features are language-level operations. They > don't calculate useful results, instead they give instructions > to the compiler how to set up the environment so that a human > programmer can specify such operations without accidentally writing > over the wrong data, in the case of const, or to give him an > interface, in the case of a base class that is designed to be > overridden. > But you often need quite a bit of code to do that. That's why you > get the Russian doll program effect. A lot of the code the programmer > writes doesn't do anything, it just tells the compiler that he > agrees that an enum a can be inserted into a stream and if it is > type text then it needs one conversion and if it is type binary > it needs another, then if it's type text he sets up the > template to bind to the string representation. > But in C this just becomes fprintf(fp, "lettertype: %s", enum_a_ids[a]); > You can of course just as easily type enum_b_ids[a] and you won't > get a warning. But that's essentially what the code is achieving, > it's not computing anything, it's setting up the system so that > it's harder to write the wrong value to the file. Which, I'm sure you will agree is a good thing. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-25 23:51 -0700 |
| Message-ID | <d67e5629-6f88-4eb3-aa63-2e289d358ed9@googlegroups.com> |
| In reply to | #66383 |
On Sunday, July 26, 2015 at 2:29:41 AM UTC+1, Ian Collins wrote:
> Malcolm McLean wrote:
>
> > The C equivalent is memcpy(&array[i], &obj, sizeof(object)).
>
> And if copying obj is non-trivial?
>
Consider this C/C++
C++;
class employee
{
wstring name;
currency salary;
id_type payrollid;
employee() :
name(L"Fred Placeholder"),
salary(0),
payrollid(NULL_PAYROLL_ID)
{
}
employee(const employee &tocopy) :
name(tocopy.name),
salary(tocopy.salary),
payrollid(tocopy.payroolid)
{
}
};
And this C
struct employee
{
char *name_utf8;
double salary;
PAYROLLID payroll_id;
};
The data is equivalent. But in C++ we're not sure what the members
are, so we can't do a bitwise copy. In C, it's impossible for that
problem to arise - assuming only that PAYROLLID is also a flat
structure. memcpy(&dest, &src, sizeof(strut employee)) must copy
an employee for us.
However in C, we have to be careful to specify whether we are copying
or cloning. memcpy() copies, which is fine for sorting or storing
employees in variable-length arrays. But not OK if we need two
Fred the Plumbers that live independently.
So the C++ is better in that it makes it harder for the programmer
to do the wrong thing, but it isn't more functional. And the C++
copy isn't entirely trivial. C++ now has what are called "move
semantics" to get round the efficiency problem in using the
above class in a sort, which adds a bit more complexity.
>
> So when you copy a structure with embedded pointers, who is responsible
> for freeing the memory they point to?
>
You are. Both source and copy are in the same scope, which is the
current tip of the execution branch. So at that point, the decision
has to be taken where the objects are to be freed, which copy is
the "master copy" and which is the temporary.
>
> Not forgetting memory isn't the only resource that has to be cleaned up.
>
I don't do much embedded programming (though I have done it
in the past). However my view is that using a C++ destructor
for anything other than memory clean-up is asking for trouble.
Of course port connections and so on need to be shut, but manually.
>
> > But in C this just becomes fprintf(fp, "lettertype: %s", enum_a_ids[a]);
> > You can of course just as easily type enum_b_ids[a] and you won't
> > get a warning. But that's essentially what the code is achieving,
> > it's not computing anything, it's setting up the system so that
> > it's harder to write the wrong value to the file.
>
> Which, I'm sure you will agree is a good thing.
>
As long as the programmer who is setting up the const correct
system is absolutely, 100% correct in his work, and doesn't
accidentally const qualify something that needs to be written.
And as long as he has 100% perfectly documented his work and
made the interfaces easy to understand, so the calling programmer
doesn't need to do exploratory programming.
But the whole premise of the system is that it is tolerant to
human error.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-26 20:24 +1200 |
| Message-ID | <d1jjq3F4cuvU1@mid.individual.net> |
| In reply to | #66397 |
Malcolm McLean wrote:
> On Sunday, July 26, 2015 at 2:29:41 AM UTC+1, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>>> The C equivalent is memcpy(&array[i], &obj, sizeof(object)).
>>
>> And if copying obj is non-trivial?
>>
> Consider this C/C++
>
> C++;
>
> class employee
> {
> wstring name;
> currency salary;
> id_type payrollid;
>
> employee() :
> name(L"Fred Placeholder"),
> salary(0),
> payrollid(NULL_PAYROLL_ID)
> {
> }
> employee(const employee &tocopy) :
> name(tocopy.name),
> salary(tocopy.salary),
> payrollid(tocopy.payroolid)
> {
> }
> };
>
> And this C
>
> struct employee
> {
> char *name_utf8;
> double salary;
> PAYROLLID payroll_id;
> };
>
> The data is equivalent.
No they aren't. A wstring is a much more complex object than a char*.
> But in C++ we're not sure what the members
> are, so we can't do a bitwise copy.
The compiler can (and will if the struct/class is a POD).
> In C, it's impossible for that
> problem to arise - assuming only that PAYROLLID is also a flat
> structure.
Which is a big assumption and restriction. If you apply the same
restriction to C++, you'll get the same result.
> memcpy(&dest, &src, sizeof(strut employee)) must copy
> an employee for us.
As would dest = src (in either language).
> However in C, we have to be careful to specify whether we are copying
> or cloning. memcpy() copies, which is fine for sorting or storing
> employees in variable-length arrays. But not OK if we need two
> Fred the Plumbers that live independently.
Quite.
> So the C++ is better in that it makes it harder for the programmer
> to do the wrong thing, but it isn't more functional.
In this case it is: wstring manages the lifetime of any dynamically
allocated memory.
> And the C++
> copy isn't entirely trivial.
It is if you enforce the same restrictions you have in C. Look at the
problem the other way round - say you do want the the two instances to
live independently.
> C++ now has what are called "move
> semantics" to get round the efficiency problem in using the
> above class in a sort, which adds a bit more complexity.
Move semantics are a solution to a different set of conditions.
>> So when you copy a structure with embedded pointers, who is responsible
>> for freeing the memory they point to?
>>
> You are. Both source and copy are in the same scope, which is the
> current tip of the execution branch.
Until they aren't....
> So at that point, the decision
> has to be taken where the objects are to be freed, which copy is
> the "master copy" and which is the temporary.
Until they live independently...
>> Not forgetting memory isn't the only resource that has to be cleaned up.
>>
> I don't do much embedded programming (though I have done it
> in the past). However my view is that using a C++ destructor
> for anything other than memory clean-up is asking for trouble.
Not all memory comes from the same allocator, especially in kernel space.
> Of course port connections and so on need to be shut, but manually.
Why manually? let the compiler take care of things people can forget.
One of the great advantages of automatic resource freeing is you don't
end up with those awful blocks of clean up code and the even more awful
gotos that often take you there!
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-26 03:02 -0700 |
| Message-ID | <bbf6c20a-5d64-4597-8a97-ead7bf7e55dc@googlegroups.com> |
| In reply to | #66399 |
On Sunday, July 26, 2015 at 9:24:57 AM UTC+1, Ian Collins wrote:
> Malcolm McLean wrote:
>
> >
> > The data is equivalent.
>
> No they aren't. A wstring is a much more complex object than a char*.
>
A utf8 char * will represent any sequence of characters in any human alphabet that
the Unicode people have considered worth supporting (so pretty much everything
except Voynichese). But the C++ wstring has more machinery and, in some
circumstances, can be more efficient.
> > But in C++ we're not sure what the members
> > are, so we can't do a bitwise copy.
>
> The compiler can (and will if the struct/class is a POD).
>
> > In C, it's impossible for that
> > problem to arise - assuming only that PAYROLLID is also a flat
> > structure.
>
> Which is a big assumption and restriction. If you apply the same
> restriction to C++, you'll get the same result.
>
You can write C++ which is effectively C. Which is real benefit of C++.
But a POD employee isn't idiomatic C++, most C++ era would frown.
>
> > memcpy(&dest, &src, sizeof(strut employee)) must copy
> > an employee for us.
>
> As would dest = src (in either language).
>
In C++ dest = src might make dest a copy of src or it might not - one can
presume a sane programmer who hasn't overloaded assignment to perform,
say, string concatenation. But he might well have got the copy semantics
wrong. I dislike structure assignment in C because it breaks that rule that
every C line must correspond to a trivial number of cycles. memcpy warns
you what you a re doing.
>
> > However in C, we have to be careful to specify whether we are copying
> > or cloning. memcpy() copies, which is fine for sorting or storing
> > employees in variable-length arrays. But not OK if we need two
> > Fred the Plumbers that live independently.
>
> Quite.
>
C++ has some genuine advantages.
>
> It is if you enforce the same restrictions you have in C. Look at the
> problem the other way round - say you do want the the two instances to
> live independently.
>
In C you need to be careful about the distinction between what is conventionally
call "copy" and what is conventionally called "clone". In C++ the problem
doesn't go away, but you can make it harder for the programmer to specify
the wrong operation. In this case, copying the employee's name is probably
not going to be performance constraint, and it's easiest just to say that all
copies are deep copies, or clones.
>
> > C++ now has what are called "move
> > semantics" to get round the efficiency problem in using the
> > above class in a sort, which adds a bit more complexity.
>
> Move semantics are a solution to a different set of conditions.
>
No, it for the same problem.
We're putting employees into a variable length array. Move sematics mean
that when we delete an employee form the middle of the array, for example,
we don't have to take a deep copy of the employees; name. We create a
null employee where the deleted employee was, then swap until he falls
off the end of the buffer.
>
> >> So when you copy a structure with embedded pointers, who is responsible
> >> for freeing the memory they point to?
> >>
> > You are. Both source and copy are in the same scope, which is the
> > current tip of the execution branch.
>
> Until they aren't....
>
C will allow you to create a mess if determined. So will C++, but it will be a
different type of mess.
>
> > So at that point, the decision
> > has to be taken where the objects are to be freed, which copy is
> > the "master copy" and which is the temporary.
>
> Until they live independently...
>
So they need to be cloned instead of copied.
>
> Why manually? let the compiler take care of things people can forget.
> One of the great advantages of automatic resource freeing is you don't
> end up with those awful blocks of clean up code and the even more awful
> gotos that often take you there!
>
Let's consider the following
class CplusplusFile
{
FILE *low_level_fp;
CplusPlusfile(wstring
~CplusplusFile()
{
fclose(low_level-fp);
}
}
Brilliant. Until someone points to that fclose can return an error. That means
you data wasn't flushed, the file is corrupt on disk.
Ok:
~CplusplusFile()
{
if(fclosef(low_level_fp) == EOF)
throw("File not closed correctly?");
}
However there's a snag here, throwing exception from destructors raises difficult
issues for stack unwinding.
it's a lot better to provide a close() member function. You can then assert fail in the
destructor if the file wasn't closed, which to be fair is a nice little error check.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-27 09:22 +1200 |
| Message-ID | <d1l1caF4cuvU2@mid.individual.net> |
| In reply to | #66400 |
Malcolm McLean wrote:
> On Sunday, July 26, 2015 at 9:24:57 AM UTC+1, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>>>
>>> The data is equivalent.
>>
>> No they aren't. A wstring is a much more complex object than a char*.
>>
> A utf8 char * will represent any sequence of characters in any human alphabet that
> the Unicode people have considered worth supporting (so pretty much everything
> except Voynichese). But the C++ wstring has more machinery and, in some
> circumstances, can be more efficient.
Quite, so you agree that they aren't equivalent.
>>> But in C++ we're not sure what the members
>>> are, so we can't do a bitwise copy.
>>
>> The compiler can (and will if the struct/class is a POD).
>>
>>> In C, it's impossible for that
>>> problem to arise - assuming only that PAYROLLID is also a flat
>>> structure.
>>
>> Which is a big assumption and restriction. If you apply the same
>> restriction to C++, you'll get the same result.
>>
> You can write C++ which is effectively C. Which is real benefit of C++.
> But a POD employee isn't idiomatic C++, most C++ era would frown.
POD types are more common in C++ than you realise.
>>> memcpy(&dest, &src, sizeof(strut employee)) must copy
>>> an employee for us.
>>
>> As would dest = src (in either language).
>>
> In C++ dest = src might make dest a copy of src or it might not - one can
> presume a sane programmer who hasn't overloaded assignment to perform,
> say, string concatenation. But he might well have got the copy semantics
> wrong. I dislike structure assignment in C because it breaks that rule that
> every C line must correspond to a trivial number of cycles. memcpy warns
> you what you a re doing.
Now where did that rule come from? Using memcpy to copy structs is
anything but idiomatic C. I'm sure the compiler can do a better job of
copying a struct than a call to memcpy would.
>>>> So when you copy a structure with embedded pointers, who is responsible
>>>> for freeing the memory they point to?
>>>>
>>> You are. Both source and copy are in the same scope, which is the
>>> current tip of the execution branch.
>>
>> Until they aren't....
>>
> C will allow you to create a mess if determined. So will C++, but it will be a
> different type of mess.
One that doesn't leak resources?
>>> So at that point, the decision
>>> has to be taken where the objects are to be freed, which copy is
>>> the "master copy" and which is the temporary.
>>
>> Until they live independently...
>>
> So they need to be cloned instead of copied.
>>
>> Why manually? let the compiler take care of things people can forget.
>> One of the great advantages of automatic resource freeing is you don't
>> end up with those awful blocks of clean up code and the even more awful
>> gotos that often take you there!
>>
> Let's consider the following
>
> class CplusplusFile
> {
> FILE *low_level_fp;
>
> CplusPlusfile(wstring
>
> ~CplusplusFile()
> {
> fclose(low_level-fp);
> }
> }
>
> Brilliant. Until someone points to that fclose can return an error. That means
> you data wasn't flushed, the file is corrupt on disk.
You (as the C++ standard library does) provide a close method. If the
result of fclose is important, call close(), if not let the destructor
take care of it. Most C code I've seen ignores the return from fclose....
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web