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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| 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]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-26 15:04 -0700 |
| Message-ID | <061d8f22-2213-411b-8295-f9cc434ae75b@googlegroups.com> |
| In reply to | #66417 |
On Sunday, July 26, 2015 at 10:22:27 PM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > But the C++ wstring has more machinery and, in some > > circumstances, can be more efficient. > > Quite, so you agree that they aren't equivalent. > They're equivalent in the sense that char *name_uft8; and wstring name; have the same functionality, and you can replace one by the other in any real program. They're not identical, in that you can do so without any other changes. One's C, ones C++, although you can provide an object-style wstring in very contrived C code, and you can use the utf8 char* in C++. > > > 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. > C++ can mean many things. Sometimes you have to lay out bits in memory. But if you need a POD employee then your're admitting that the OO machinery has failed. > > 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. > But a human programmer can eliminate the call altogether, which is much harder for a compiler to do. And if a = b isn't equivalent to memcpy(&a, &b, sizeof(a)) then the optimiser isn't much shakes, so better give the human the easiest environment you can. > > > 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? > It's a fair point that destructors are one trick that C++ has which you can't easily imitate in C. But we can see a C++ mess in embryo below. fclose() can fail. Most programmers don't realise this, and in many environments, it doesn't matter. If it turns out to matter then, in C, it's usually a trivial modification - the fclose comes after a series of fwrites that are checked, and you simple test the return and execute the same error code. If you've wrapped up fclose in a destructor, it's much more challenging. > > 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.... > So you can either call close, or let the destructor handle it. So the interface is starting to get hard to read. If we're C programmers and comp.lang.c regulars, and we know that fclose can return an error condition that is often ignored, it makes some sort of sense, although you wonder why the interface designer is bending over backwards to accommodate what is all said and done a bug. But if you're coming to the C++ File object cold, that's weird and quirky. Object serialization is one of those fundamentals that really should be built into a programming language. When C was being designed, this wasn't realised, and it was not. The consequence is that streams are something that do benefit from object-orientation, even in code which is largely procedural. It's not impossible to design a good C++ stream class. But the C++ standard library didn't do a good job. We're currently using boost serialization. But that's not an unproblematic answer either - one first pass porting our code base to a new compiler, the compiler announced it was parsing 1,400 nested headers, which is deeply worrying.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-27 10:32 +1200 |
| Message-ID | <d1l5gpF4cuvU3@mid.individual.net> |
| In reply to | #66421 |
Malcolm McLean wrote: > On Sunday, July 26, 2015 at 10:22:27 PM UTC+1, Ian Collins wrote: >> Malcolm McLean wrote: >>> But the C++ wstring has more machinery and, in some >>> circumstances, can be more efficient. >> >> Quite, so you agree that they aren't equivalent. >> > They're equivalent in the sense that > > char *name_uft8; > and > wstring name; > > have the same functionality, and you can replace one by the other > in any real program. They're not identical, in that you can do > so without any other changes. If that were true, C++ wouldn't have a (w)string class. Even a simple operation such as fred.name = L"Fred Bloggs"; has an entirely different effect. (Hint: what type is L"Fred Bloggs"?) > One's C, ones C++, although you can provide an object-style > wstring in very contrived C code, and you can use the utf8 char* > in C++. Not for wide string names... >>> 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. >> > C++ can mean many things. Sometimes you have to lay out bits in > memory. But if you need a POD employee then your're admitting that > the OO machinery has failed. Why? >> 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. >> > But a human programmer can eliminate the call altogether, which > is much harder for a compiler to do. And if a = b isn't equivalent > to memcpy(&a, &b, sizeof(a)) then the optimiser isn't much shakes, > so better give the human the easiest environment you can. In C at least, it always will be equivalent. The best way to give the human the easiest environment you can is to write clear, idiomatic code. >>> 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? >> > It's a fair point that destructors are one trick that C++ has which > you can't easily imitate in C. But we can see a C++ mess in embryo > below. fclose() can fail. Most programmers don't realise this, and > in many environments, it doesn't matter. If it turns out to matter > then, in C, it's usually a trivial modification - the fclose comes > after a series of fwrites that are checked, and you simple test > the return and execute the same error code. If you've wrapped up > fclose in a destructor, it's much more challenging. >> >> 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.... >> > So you can either call close, or let the destructor handle it. So > the interface is starting to get hard to read. Well I'm sorry if you can't manage to read the interface. C++ programmers have managed since the last century! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-26 16:49 -0700 |
| Message-ID | <4d845399-c74d-4467-911c-495f0802e7d5@googlegroups.com> |
| In reply to | #66423 |
On Sunday, July 26, 2015 at 11:33:08 PM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > If that were true, C++ wouldn't have a (w)string class. Even a simple > operation such as > > fred.name = L"Fred Bloggs"; > > has an entirely different effect. (Hint: what type is L"Fred Bloggs"?) > In C it's a clear error to assign an L-qualified string literal to a char * that is documented as holding UTF-8. In C++ it's impossible to know what the effect of the code will be without digging into the internals of the class that defines fred.name. In particular, we don't know whether we're taking a local copy of the string, a pointer to the literal embedded somewhere in memory, or a hybrid system that will use the embedded memory until the data is modified, at which pint it will swap in a local copy. The documentation will tell us, but we've got to read through the entire class very carefully to be sure we're doing what we intend. > > > One's C, ones C++, although you can provide an object-style > > wstring in very contrived C code, and you can use the utf8 char* > > in C++. > > Not for wide string names... > UTF-8 will encode virtually any character. Of course you have to convert your data to utf-8 if it's coming in in a different format. > > > C++ can mean many things. Sometimes you have to lay out bits in > > memory. But if you need a POD employee then your're admitting that > > the OO machinery has failed. > > Why? > There are two situations where you have idiomatic OO C++. The first is where an employee is an "object" with methods such as "pay_salary". The second is where employees aren't hard-coded into the system, and instead you have some sort of scheme whereby a field of string type called "name" and of numerical type called "salary" is attached to a "database entity". The first is seen in toy programs where "employee" really means "a data item", the second is more likely in a real payroll program. But laying out a struct employee isn't idiomatic C++. It's normal data. It's not a special item that needs a determined memory footprint. If you do that, you're abandoning OO. > > > So you can either call close, or let the destructor handle it. So > > the interface is starting to get hard to read. > > Well I'm sorry if you can't manage to read the interface. C++ > programmers have managed since the last century! > A perennial problem with C++ programmers is arrogance. They set up a system which is too complex, then blame other people for their inability to work through the mess that they have created. If you've got a close method, and the destructor also calls close, then the calling programmer has to work out when he needs to call close manually and when he can rely on the destructor to do it, and that's too complicated. Not in the sense that the averagely intelligent person will be completely defeated, but in the sense that we're adding cumulative layers of difficulty, until eventually the system will break down and the program will fail.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-27 21:46 +1200 |
| Message-ID | <d1mcvsFohsbU1@mid.individual.net> |
| In reply to | #66431 |
Malcolm McLean wrote: >> > A perennial problem with C++ programmers is arrogance. They set up > a system which is too complex, then blame other people for their > inability to work through the mess that they have created. So you now accuse the C++ language committee of arrogance? They specify the standard library, not us mere programmers. > If you've got a close method, and the destructor also calls close, > then the calling programmer has to work out when he needs to call close > manually and when he can rely on the destructor to do it, and that's > too complicated. Not in the sense that the averagely intelligent > person will be completely defeated, but in the sense that we're adding > cumulative layers of difficulty, until eventually the system will break > down and the program will fail. I don't see any difference between this and deciding whether or not to check the return of fclose. I guess you just find even slightly abstract functionality (such as struct assignment) hard to grasp. Either that, or you have a condescending attitude towards other programmers. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-27 04:53 -0700 |
| Message-ID | <dbfb03b1-fb6b-40a5-9e14-bbacfda4857b@googlegroups.com> |
| In reply to | #66439 |
On Monday, July 27, 2015 at 10:46:49 AM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > >> > > A perennial problem with C++ programmers is arrogance. They set up > > a system which is too complex, then blame other people for their > > inability to work through the mess that they have created. > > So you now accuse the C++ language committee of arrogance? They specify > the standard library, not us mere programmers. > The language specification is too complex, and pretty much everyone agrees that that is the case. But that's not necessarily due to the arrogance of the standards committee. It has the unfortunate effect of making it easy to write unreadable, unmaintainable C++ code, and for the C++ programmer who creates such a mess then to blame the maintainers for lack of proficiency in the language. > > I don't see any difference between this and deciding whether or not to > check the return of fclose. I guess you just find even slightly > abstract functionality (such as struct assignment) hard to grasp. > Either that, or you have a condescending attitude towards other > programmers. > I don;t have a condescending attitude to other programmers. I endeavour to make code as simple as possible for them to follow. The algorithms I develop are typically complicated enough, without the person trying to use my stuff having to cope with a complicated programming interface. Destructors that do anything other than free memory are one small example of a complicated and difficult to use interface. As are hidden expensive operations. The difficulty is cumulative, a few small points of awkwardness or counter-intuitive behaviours don't have much effect, but two such problems are more than twice as as time consuming as one.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-26 14:58 -0700 |
| Message-ID | <lnbneyy41b.fsf@kst-u.example.com> |
| In reply to | #66400 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> I dislike structure assignment in C because it breaks that rule that
> every C line must correspond to a trivial number of cycles.
[...]
Fortunately, there is no such rule. On some systems, floating-point
operations translate to function calls. Would you rather write the
calls yourself?
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-26 15:15 -0700 |
| Message-ID | <ae557066-5dae-4156-98ed-06840e9d4165@googlegroups.com> |
| In reply to | #66420 |
On Sunday, July 26, 2015 at 10:58:50 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > Fortunately, there is no such rule. On some systems, floating-point > operations translate to function calls. Would you rather write the > calls yourself? > In some ways yes. In the olden days you could have serious performance issues due to floating point, and it would have been better to have a warning. But basic arithmetical operations are an exception in many ways. For example, operator overloading is mainly a nuisance feature that makes code hard to read, hides bugs, and encourages undesirable idioms such as the use of + for string concatenation or / for matrix inversion. But it really comes into its own for huge integers and other user-defined basic numbers. You've got to balance the fact that you're not warned that you are calling potentially slow and buggy code against the readability of expressions. With assignment, it's less of a problem, because usually a structure assignment will be a single line, a = b; You're not losing as much readability by making the call explicit.
[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