Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #90419 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-07-15 23:36 +0200 |
| Last post | 2016-08-02 13:20 -0700 |
| Articles | 20 on this page of 164 — 22 participants |
Back to article view | Back to comp.lang.c
High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-15 23:36 +0200
Re: High level C supercat@casperkitty.com - 2016-07-15 15:17 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:09 +0200
Re: High level C supercat@casperkitty.com - 2016-07-17 20:02 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-15 15:17 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-07-31 23:55 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-15 23:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:13 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 02:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 11:07 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:29 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:40 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 11:57 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 11:30 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 03:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:53 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 07:49 -0700
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-16 17:08 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-16 09:09 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 16:26 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 18:05 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 20:15 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 23:44 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:39 +0000
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-23 22:58 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-27 14:52 +0000
Re: High level C Richard Heathfield <rjh@cpax.org.uk> - 2016-07-27 16:29 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:38 +0000
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 14:17 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 13:46 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 12:05 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 11:03 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-17 03:39 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 18:20 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 14:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 23:13 +0530
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 20:14 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-17 20:14 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-17 20:45 +0100
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-07-17 21:00 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 09:48 +0530
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 00:55 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:25 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 11:40 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-18 05:05 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:59 +0530
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 22:50 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-18 19:07 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-19 11:53 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 11:15 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 14:00 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:01 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 15:26 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 15:57 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 17:13 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 18:14 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:20 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 19:46 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:44 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-20 10:59 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-20 03:07 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 01:44 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-21 18:58 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 17:20 +0100
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-21 20:52 +0100
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:14 +0100
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-21 13:23 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-21 21:50 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-22 12:52 +0200
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-22 04:03 -0700
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:56 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:09 +0100
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-22 23:49 +0530
Re: High level C BartC <bc@freeuk.com> - 2016-07-22 20:37 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 19:16 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:17 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-19 21:07 +0200
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-20 02:36 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 07:27 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-19 16:27 +0100
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-19 08:43 -0700
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-19 19:14 +0100
Re: High level C Jean-Marc Bourguet <jm@bourguet.org> - 2016-07-18 10:08 +0200
Re: High level C Udyant Wig <udyant.wig@gmail.com> - 2016-07-18 23:04 +0530
Re: High level C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-07-16 10:18 +0100
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-23 19:26 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-25 09:21 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-25 10:19 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-28 10:31 -0700
Re: High level C luser droog <luser.droog@gmail.com> - 2016-07-28 21:13 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 09:05 -0700
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-07-29 09:30 -0700
Re: High level C supercat@casperkitty.com - 2016-07-29 10:08 -0700
Re: High level C Ike Naar <ike@iceland.freeshell.org> - 2016-07-29 17:57 +0000
Re: High level C supercat@casperkitty.com - 2016-07-29 11:50 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 07:16 -0700
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-07-31 14:34 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 14:55 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 03:10 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 07:40 -0700
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-01 19:43 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 10:21 -0500
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-03 13:14 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:40 -0700
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-05 09:28 -0700
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-05 09:55 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:51 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:43 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:43 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:52 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:42 +0000
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-11 12:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-07-31 16:42 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 12:59 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-07-31 17:12 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:12 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 00:54 -0500
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-01 08:08 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-01 12:58 -0500
Re: High level C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-01 12:25 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:44 -0700
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 11:56 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 19:29 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-03 13:45 -0400
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 13:23 -0500
Re: High level C BartC <bc@freeuk.com> - 2016-08-03 19:27 +0100
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 21:04 +0200
Re: High level C Gareth Owen <gwowen@gmail.com> - 2016-08-03 20:08 +0100
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:09 -0500
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 16:06 -0500
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-03 23:36 +0200
Re: High level C Les Cargill <lcargill99@comcast.com> - 2016-08-03 19:44 -0500
Re: High level C supercat@casperkitty.com - 2016-08-03 15:03 -0700
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 19:17 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 05:48 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 08:24 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 18:30 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 10:34 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-05 20:50 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:39 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 00:50 +0200
Re: High level C Keith Thompson <kst-u@mib.org> - 2016-08-05 17:08 -0700
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 02:23 +0200
Re: High level C raltbos@xs4all.nl (Richard Bos) - 2016-08-06 10:03 +0000
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 12:13 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:10 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:40 +0200
Re: High level C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-06 11:56 -0400
Re: High level C Melzzzzz <mel@zzzzz.com> - 2016-08-06 17:51 +0200
Re: High level C supercat@casperkitty.com - 2016-08-08 09:12 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-31 22:07 +0200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 15:05 -0700
Re: High level C Ian Collins <ian-news@hotmail.com> - 2016-08-03 11:22 +1200
Re: High level C Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-03 08:50 -0700
Re: High level C BartC <bc@freeuk.com> - 2016-07-16 01:12 +0100
Re: High level C Jerry Stuckle <jstucklex@attglobal.net> - 2016-07-15 20:16 -0400
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 09:17 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 08:20 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-16 17:24 +0200
Re: High level C Siri Cruise <chine.bleu@yahoo.com> - 2016-07-16 09:24 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:15 -0700
Re: High level C carlglassberg@gmail.com - 2016-07-17 14:22 -0700
Re: High level C jacobnavia <jacob@jacob.remcomp.fr> - 2016-07-17 23:58 +0200
Re: High level C fir <profesor.fir@gmail.com> - 2016-08-02 13:20 -0700
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-06 00:50 +0200 |
| Message-ID | <20160806005008.3218a22e@maxa-pc> |
| In reply to | #91783 |
On Fri, 05 Aug 2016 15:39:29 -0700 Tim Rentsch <txr@alumni.caltech.edu> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > > On Thu, 04 Aug 2016 19:17:42 -0700 > > Tim Rentsch <txr@alumni.caltech.edu> wrote: > > > >> Something I wanted to mention but didn't work its way into the > >> flow is how to deal with resources (eg, open files). Any > >> resource that is needed normally will be given its own object. > >> When a resource object is allocation, normally it will register > >> a "finalization hook", a function that is called just before > >> the object is about to be reclaimed. I think most collectors > >> these days provide a way to associate finalization hooks with > >> allocated objects, for exactly this purpose. > > > > Wrong. Finalizers are useless for resource management as > > conservative GC is non deterministic. Finalizers are only good for > > debugging purposes... > > That is a gross overstatement. That overstatement is not mine. I heard it lot of times... And obviously there are ways to > mitigate the problem, especially in the context of program > exit cleanup. In any case my commentary was meant as a broad > brush outline about using GC generally, not specifically about > conservative collectors. Even in that domain, how useful > something is depends on what alternatives are available. I > daresay a system based on a conservative collector would exhibit > better memory use behavior than some browsers I run, which rely > on manual memory management rather than GC or something similar. Not a chance. GC makes lot of problems on it's own... problems start to rise when memory usage goes beyond trivial...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-05 17:08 -0700 |
| Message-ID | <lnk2fuyd0k.fsf@kst-u.example.com> |
| In reply to | #91785 |
Melzzzzz <mel@zzzzz.com> writes:
> On Fri, 05 Aug 2016 15:39:29 -0700
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Melzzzzz <mel@zzzzz.com> writes:
[...]
>> > Wrong. Finalizers are useless for resource management as
>> > conservative GC is non deterministic. Finalizers are only good for
>> > debugging purposes...
>>
>> That is a gross overstatement.
>
> That overstatement is not mine. I heard it lot of times...
[...]
It's a statement you made without attribution or qualification.
--
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 | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-06 02:23 +0200 |
| Message-ID | <20160806022332.39b341ad@maxa-pc> |
| In reply to | #91791 |
On Fri, 05 Aug 2016 17:08:59 -0700 Keith Thompson <kst-u@mib.org> wrote: > Melzzzzz <mel@zzzzz.com> writes: > > On Fri, 05 Aug 2016 15:39:29 -0700 > > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> Melzzzzz <mel@zzzzz.com> writes: > [...] > >> > Wrong. Finalizers are useless for resource management as > >> > conservative GC is non deterministic. Finalizers are only good > >> > for debugging purposes... > >> > >> That is a gross overstatement. > > > > That overstatement is not mine. I heard it lot of times... > [...] > > It's a statement you made without attribution or qualification. > I think it's well known fact. I believe it's all over the internet... eg " This dual interface leads to another inevitable borrowing from C# (ultimately, a Java feature): finalizers. A finalizer is a block of code that is executed when the GC reclaims the storage of an object allocated by gcnew. In the early 1990s, finalizers were considered the Java equivalent of destructors but programmers soon realized that they weren’t. Determinacy is the main difference between the two. A C++ destructor always executes at a predictable time -- when calling delete, when an automatic object goes out of scope etc. By contrast, a finalizer is executed at an unpredictable time after the object has become unreferenced. This could take seconds -- or weeks. When the GC is suspended or completely disabled, finalizers don’t run. This erratic behavior makes finalizers nearly useless. The easiest way to see it is by comparing a corpus of C++ code with a Java/C# corpus of the same size. The C++ destructor count compared to the number of finalizers is revealing. A ratio is about 1 finalizer for every 100 destructors shouldn’t come as a surprise. " https://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=274
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-08-06 10:03 +0000 |
| Message-ID | <57a5b566.2418828@news.xs4all.nl> |
| In reply to | #91793 |
Melzzzzz <mel@zzzzz.com> wrote: > Keith Thompson <kst-u@mib.org> wrote: > > Melzzzzz <mel@zzzzz.com> writes: > > > On Fri, 05 Aug 2016 15:39:29 -0700 > > > Tim Rentsch <txr@alumni.caltech.edu> wrote: =20 > > >> That is a gross overstatement. =20 > > > > > > That overstatement is not mine. I heard it lot of times... =20 > > It's a statement you made without attribution or qualification. > > I think it's well known fact. I believe it's all over the internet... Many well-known facts are all over the internet, such as the fact that Hillary Clinton is a mass murderer or the fact that Donald Trump is a child rapist. The defensibility of internet "facts" is generally dubious, in both those cases as well as yours; never rely on "it's all over the internet" as evidence for the truth or untruth of anything. Richard
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-06 12:13 +0200 |
| Message-ID | <20160806121335.5a4cefe7@maxa-pc> |
| In reply to | #91797 |
On Sat, 06 Aug 2016 10:03:41 GMT raltbos@xs4all.nl (Richard Bos) wrote: > Melzzzzz <mel@zzzzz.com> wrote: > > > Keith Thompson <kst-u@mib.org> wrote: > > > Melzzzzz <mel@zzzzz.com> writes: > > > > On Fri, 05 Aug 2016 15:39:29 -0700 > > > > Tim Rentsch <txr@alumni.caltech.edu> wrote: =20 > > > > >> That is a gross overstatement. =20 > > > > > > > > That overstatement is not mine. I heard it lot of times... =20 > > > > It's a statement you made without attribution or qualification. > > > > I think it's well known fact. I believe it's all over the > > internet... > > Many well-known facts are all over the internet, such as the fact that > Hillary Clinton is a mass murderer or the fact that Donald Trump is a > child rapist. The defensibility of internet "facts" is generally > dubious, in both those cases as well as yours; never rely on "it's all > over the internet" as evidence for the truth or untruth of anything. > > Richard Moving goalposts noted...
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-06 11:10 -0400 |
| Message-ID | <cbdd2b78-6f91-5bbb-e8ac-72dd37bb745d@verizon.net> |
| In reply to | #91799 |
On 08/06/2016 06:13 AM, Melzzzzz wrote: > On Sat, 06 Aug 2016 10:03:41 GMT > raltbos@xs4all.nl (Richard Bos) wrote: > >> Melzzzzz <mel@zzzzz.com> wrote: ... >>> I think it's well known fact. I believe it's all over the >>> internet... >> >> Many well-known facts are all over the internet, such as the fact that >> Hillary Clinton is a mass murderer or the fact that Donald Trump is a >> child rapist. The defensibility of internet "facts" is generally >> dubious, in both those cases as well as yours; never rely on "it's all >> over the internet" as evidence for the truth or untruth of anything. >> >> Richard > > Moving goalposts noted... They didn't move - "it's all over the internet" has never been a compelling argument. It's predecessor, "everyone says", was never particularly compelling, either.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-06 17:40 +0200 |
| Message-ID | <20160806174012.6345a8d8@maxa-pc> |
| In reply to | #91815 |
On Sat, 6 Aug 2016 11:10:14 -0400 "James R. Kuyper" <jameskuyper@verizon.net> wrote: > On 08/06/2016 06:13 AM, Melzzzzz wrote: > > On Sat, 06 Aug 2016 10:03:41 GMT > > raltbos@xs4all.nl (Richard Bos) wrote: > > > >> Melzzzzz <mel@zzzzz.com> wrote: > ... > >>> I think it's well known fact. I believe it's all over the > >>> internet... > >> > >> Many well-known facts are all over the internet, such as the fact > >> that Hillary Clinton is a mass murderer or the fact that Donald > >> Trump is a child rapist. The defensibility of internet "facts" is > >> generally dubious, in both those cases as well as yours; never > >> rely on "it's all over the internet" as evidence for the truth or > >> untruth of anything. > >> > >> Richard > > > > Moving goalposts noted... > > They didn't move - "it's all over the internet" has never been a > compelling argument. It's predecessor, "everyone says", was never > particularly compelling, either. So you think finalizers are useful for resource management?
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-06 11:56 -0400 |
| Message-ID | <44d76a08-d74e-757e-cf3a-7b6132fd3c6c@verizon.net> |
| In reply to | #91817 |
On 08/06/2016 11:40 AM, Melzzzzz wrote: > On Sat, 6 Aug 2016 11:10:14 -0400 > "James R. Kuyper" <jameskuyper@verizon.net> wrote: > >> On 08/06/2016 06:13 AM, Melzzzzz wrote: >>> On Sat, 06 Aug 2016 10:03:41 GMT >>> raltbos@xs4all.nl (Richard Bos) wrote: >>> >>>> Melzzzzz <mel@zzzzz.com> wrote: >> ... >>>>> I think it's well known fact. I believe it's all over the >>>>> internet... >>>> >>>> Many well-known facts are all over the internet, such as the fact >>>> that Hillary Clinton is a mass murderer or the fact that Donald >>>> Trump is a child rapist. The defensibility of internet "facts" is >>>> generally dubious, in both those cases as well as yours; never >>>> rely on "it's all over the internet" as evidence for the truth or >>>> untruth of anything. >>>> >>>> Richard >>> >>> Moving goalposts noted... >> >> They didn't move - "it's all over the internet" has never been a >> compelling argument. It's predecessor, "everyone says", was never >> particularly compelling, either. > > So you think finalizers are useful for resource management? I've commented only on the issue I feel competent to address - namely, the persuasiveness (or lack thereof) of "it's all over the internet" as a supporting argument. I've not used GC or finalizers. I am familiar with the use of C++ ctors and dtors for resource management, and I've seen many cases where dtors did nothing more urgent than releasing memory that was no longer needed. In particular, closing a file that was opened read-only involves nothing more urgent that the release of the memory used to manage that file. If it's not a serious problem for you that a GC might fail to release memory, then I don't see why it would be any more of a problem if it fails to execute a finalizer that was equivalent to such a dtor. Therefore, Keith's argument seems plausible to me - but I can't claim any personal experience that's directly relevant.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-06 17:51 +0200 |
| Message-ID | <20160806175133.66835500@maxa-pc> |
| In reply to | #91815 |
On Sat, 6 Aug 2016 11:10:14 -0400
"James R. Kuyper" <jameskuyper@verizon.net> wrote:
> On 08/06/2016 06:13 AM, Melzzzzz wrote:
> > On Sat, 06 Aug 2016 10:03:41 GMT
> > raltbos@xs4all.nl (Richard Bos) wrote:
> >
> >> Melzzzzz <mel@zzzzz.com> wrote:
> ...
> >>> I think it's well known fact. I believe it's all over the
> >>> internet...
> >>
> >> Many well-known facts are all over the internet, such as the fact
> >> that Hillary Clinton is a mass murderer or the fact that Donald
> >> Trump is a child rapist. The defensibility of internet "facts" is
> >> generally dubious, in both those cases as well as yours; never
> >> rely on "it's all over the internet" as evidence for the truth or
> >> untruth of anything.
> >>
> >> Richard
> >
> > Moving goalposts noted...
>
> They didn't move - "it's all over the internet" has never been a
> compelling argument. It's predecessor, "everyone says", was never
> particularly compelling, either.
The trouble with class destructors
Despite having a GC, resource management in D is one of the most difficult point of the language.
In particular, class destructors in D enjoy a variety of limitations you should be aware of.
1. Don't expect class destructors to be called at all by the GC
The garbage collector is not guaranteed to run the destructors for all unreferenced objects.
2. Don't expect class destructors to be called timely and by the right thread
Class destructors might be called when a collect is performed which can be later than you wished and by any thread the GC is currently running on.
3. Don't expect members to be valid in a class destructor
The order in which the garbage collector calls destructors for unreferenced objects is not specified. Don't use members in class destructors if you expect to be called by the GC.
4. Don't allocate within a destructor called by the GC
Using GC allocation is forbidden within a class destructor.
Conclusion
All this is in sharp contrast with the deterministic way C++ deals with destructors. However, all these constraints go away if destructors are called manually using:
std.typecons.scoped (documentation here)
std.typecons.Unique (documentation here)
calling destroy on an object manually
using delete or scope class (deprecated)
TL;DR There is not much that can safely be done in a class destructor
if called by the GC. A solution to this problem is GC-proof resource
classes.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-08 09:12 -0700 |
| Message-ID | <3fb40b0a-9dbe-4a4a-867f-1cf7bb9a4b15@googlegroups.com> |
| In reply to | #91785 |
On Friday, August 5, 2016 at 5:50:16 PM UTC-5, Melzzzzz wrote: > Not a chance. GC makes lot of problems on it's own... problems start to > rise when memory usage goes beyond trivial... Microcomputer BASIC interpreters of the 1970s and 1980s were extremely RAM- limited, but many interpreters including those by Microsoft used garbage- collection to reduce RAM overhead to a minimum. On a typical Microsoft BASIC interpreter (e.g. for an Apple II+ or Commodore PET/VIC-20/C64, among others), an array of 100 strings which holds 50 string literals defined in code and 25 different strings totaling 500 bytes will require, if I recall 9 bytes for the array descriptor (not quite positive about this) 300 bytes to hold the length of each item and a pointer to it 500 bytes to hold the contents of any strings which are not literals The literals will be sitting in memory as part of the BASIC program and will not need to be duplicated elsewhere. Efficiency could have been improved perhaps if the storage format for the program were to replace quote + string + quote [which requires string-length+2 characters] with literal-marker + length + string [the closing quote would be generated when the program is listed], but it's hard to imagine shaving more than 50 bytes or so from the total storage requirements.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-31 22:07 +0200 |
| Message-ID | <nnllpt$dnq$1@dont-email.me> |
| In reply to | #91391 |
Le 31/07/2016 à 16:42, Melzzzzz a écrit : > Care to show links? http://lambda-the-ultimate.org/node/2552 Garbage collection yields numerous software engineering benefits, but its quantitative impact on performance remains elusive. One can measure the cost of conservative garbage collection relative to explicit memory management in C/C++ programs by linking in an appropriate collector. This kind of direct comparison is not possible for languages designed for garbage collection (e.g., Java), because programs in these languages naturally do not contain calls to free. Thus, the actual gap between the time and space performance of explicit memory management and precise, copying garbage collection remains unknown. We take the first steps towards quantifying the performance of precise garbage collection versus explicit memory management. We present a novel experimental methodology that lets us treat unaltered Java programs as if they used explicit memory management. Our system generates exact object reachability information by processing heap traces with the Merlin algorithm [34, 35]. It then re-executes the program, invoking free on objects just before they become unreachable. Since this point is the latest that a programmer could explicitly free objects, our approach conservatively approximates explicit memory management. By executing inside an architecturally-detailed simulator, this "oracular" memory manager eliminates the effects of trace processing while measuring the costs of calling malloc and free. We compare explicit memory management to both copying and non-copying garbage collectors across a range of benchmarks, and include real (non-simulated) runs that validate our results. These results quantify the time-space tradeoff of garbage collection: with five times as much memory, an Appel-style generational garbage collector with a non-copying mature space matches the performance of explicit memory management. With only three times as much memory, it runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%. When physical memory is scarce, paging causes garbage collection to run an order of magnitude slower than explicit memory management.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-07-31 15:05 -0700 |
| Message-ID | <kfn1t29mpja.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91424 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 31/07/2016 <<E0>> 16:42, Melzzzzz a ecrit : >> Care to show links? > > http://lambda-the-ultimate.org/node/2552 > > Garbage collection yields numerous software engineering > benefits, but its quantitative impact on performance remains > elusive. [...] Nice information. Thank you for posting it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-03 11:22 +1200 |
| Message-ID | <e0coacFmnvgU1@mid.individual.net> |
| In reply to | #91389 |
On 08/ 1/16 02:16 AM, Tim Rentsch wrote: > > The problems of getting automatic storage reclamation (aka > garbage collection) into C are more cultural than technical. > Obviously the C community as a whole would not accept it as > a required feature of the language. However, it might be > palatable as an optional feature, especially if the option > were user-selectable and the default value if no choice > is made were NO. Garbage collection doesn't even need to be an optional language feature. It can be used in library form with standard C. I haven't used the "GC style" of programming in C, but I have used a GC library as a memory leak detection tool. > There is a common belief in some circles that GC incurs a > substantial performance penalty relative to manual coding of > free(), etc. Experience with actual systems does not bear this > out. Indeed, the experience in some large code bases has been > that switching to GC actually improves performance. I agree > getting C developers to embrace GC is a hard sell, but I think > that is based largely on misconception rather than on a real > understanding of the issues. In the business application space (especially where multiple threads are allocating and freeing memory) I can see that there would be gain in consolidating memory frees. > Don't get me wrong, there are consequences for adopting a > GC-based model for memory allocation. Certainly there are > contexts (writing OS kernels being an obvious one) where using GC > is rightly viewed with great skepticism. But I think most C > programs would benefit from switching to a GC-based model. The > reason is a gain in developer productivity: studies that have > been done show a productivity improvement in the range of 60 to > 100 percent. That is, writing code where there is no need for > manual deallocation produces somewhere between 1.6 times and 2 > times as many lines of code per day. That is a huge win. I can believe those numbers, not having to worry about manual deallocation in C++ is certainly a productivity and code quality win. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-03 08:50 -0700 |
| Message-ID | <kfnziotj1gq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #91587 |
Ian Collins <ian-news@hotmail.com> writes: > On 08/ 1/16 02:16 AM, Tim Rentsch wrote: > >> The problems of getting automatic storage reclamation (aka >> garbage collection) into C are more cultural than technical. >> Obviously the C community as a whole would not accept it as >> a required feature of the language. However, it might be >> palatable as an optional feature, especially if the option >> were user-selectable and the default value if no choice >> is made were NO. > > Garbage collection doesn't even need to be an optional language > feature. It can be used in library form with standard C. I haven't > used the "GC style" of programming in C, but I have used a GC library > as a memory leak detection tool. An important reason for having GC be a user-selectable option is to provide a compile-time warning to protect against inadvertent use. For example, there might be two kinds of closures, one kind that is allowed to escape its enclosing activation record, and another kind that is not. It would be nice to say to the compiler "don't let this code use the first kind, but give me an error instead". This case is one where I think it is important to require the (optional) enforcement be included in the compiler, and not just checked by an independent tool.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-07-16 01:12 +0100 |
| Message-ID | <nmbu57$rf4$1@dont-email.me> |
| In reply to | #90419 |
On 15/07/2016 22:36, jacobnavia wrote:
> Well, the library is splitted into several dozens files. I decided to
> write a C program then, that would take all the files and produce a
> single file containing all others.
>
>
> That gives:
> 166 int main(void)
> 167 {
> 168 int res;
> 169 List *fileList = iList.Create(sizeof(SourceFile));
> 170 GlobalIncludes = iDictionary.Create(sizeof(void *),500);
> 171
> 172 res = BuildFileList(fileList);
> 173 if (res) return res;
> 174 res = ProcessFiles(fileList);
> 175 if (res) return res;
> 176 res = Output(fileList);
> 177 return res;
> 178 }
>
> I build a list of files, then process them and output the result.
> Nothing earth shattering here. But it was nice to be able to express it
> like that.
It sounds like you're taking any list of C sources that form a project,
and processing them by simply putting all the includes (either one of
each #include, or actually inserting the contents of the include file)
at the top.
But would that work for any project?
I'd imagine there would be dependencies where the order of the includes
is important. (Or maybe you build a dependency tree where includes can
be sorted, but it is also possible that header files, with guards,
include each other.)
Another problem, if you then simply concatenate the contents of the rest
of each source into the single source file, is that local variables,
typedefs, structs, enums, defines and functions of a module, can clash
with identically name entities in another.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-07-15 20:16 -0400 |
| Message-ID | <nmbuc2$rl7$1@jstuckle.eternal-september.org> |
| In reply to | #90424 |
On 7/15/2016 8:12 PM, BartC wrote:
> On 15/07/2016 22:36, jacobnavia wrote:
>
>> Well, the library is splitted into several dozens files. I decided to
>> write a C program then, that would take all the files and produce a
>> single file containing all others.
>>
>>
>> That gives:
>> 166 int main(void)
>> 167 {
>> 168 int res;
>> 169 List *fileList = iList.Create(sizeof(SourceFile));
>> 170 GlobalIncludes = iDictionary.Create(sizeof(void *),500);
>> 171
>> 172 res = BuildFileList(fileList);
>> 173 if (res) return res;
>> 174 res = ProcessFiles(fileList);
>> 175 if (res) return res;
>> 176 res = Output(fileList);
>> 177 return res;
>> 178 }
>>
>> I build a list of files, then process them and output the result.
>> Nothing earth shattering here. But it was nice to be able to express it
>> like that.
>
>
> It sounds like you're taking any list of C sources that form a project,
> and processing them by simply putting all the includes (either one of
> each #include, or actually inserting the contents of the include file)
> at the top.
>
> But would that work for any project?
>
> I'd imagine there would be dependencies where the order of the includes
> is important. (Or maybe you build a dependency tree where includes can
> be sorted, but it is also possible that header files, with guards,
> include each other.)
>
The only reason there would be a dependency is if one header depended on
the contents of another header - in which case the depending header
should include the dependent header.
> Another problem, if you then simply concatenate the contents of the rest
> of each source into the single source file, is that local variables,
> typedefs, structs, enums, defines and functions of a module, can clash
> with identically name entities in another.
>
I wouldn't concatenate the contents of one source file into another.
There are good reasons for having the file separate.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-16 09:17 +0200 |
| Message-ID | <nmcn1e$kmt$1@dont-email.me> |
| In reply to | #90424 |
Le 16/07/2016 à 02:12, BartC a écrit :
> On 15/07/2016 22:36, jacobnavia wrote:
>
>> Well, the library is splitted into several dozens files. I decided to
>> write a C program then, that would take all the files and produce a
>> single file containing all others.
>>
>>
>> That gives:
>> 166 int main(void)
>> 167 {
>> 168 int res;
>> 169 List *fileList = iList.Create(sizeof(SourceFile));
>> 170 GlobalIncludes = iDictionary.Create(sizeof(void *),500);
>> 171
>> 172 res = BuildFileList(fileList);
>> 173 if (res) return res;
>> 174 res = ProcessFiles(fileList);
>> 175 if (res) return res;
>> 176 res = Output(fileList);
>> 177 return res;
>> 178 }
>>
>> I build a list of files, then process them and output the result.
>> Nothing earth shattering here. But it was nice to be able to express it
>> like that.
>
>
> It sounds like you're taking any list of C sources that form a project,
> and processing them by simply putting all the includes (either one of
> each #include, or actually inserting the contents of the include file)
> at the top.
>
Yes. That's exactly what I do.
> But would that work for any project?
>
Probably not. What happens if some file does
#define FOO 759654
You have to add
#undef FOO
to erase all those defines after including the body of the file.
Happily, Tom StDenis has written a very clean library, and that just
doesn't happen. How nice!
> I'd imagine there would be dependencies where the order of the includes
> is important. (Or maybe you build a dependency tree where includes can
> be sorted, but it is also possible that header files, with guards,
> include each other.)
>
Yes.
> Another problem, if you then simply concatenate the contents of the rest
> of each source into the single source file, is that local variables,
> typedefs, structs, enums, defines and functions of a module, can clash
> with identically name entities in another.
>
There are no global variables in the library in the sense you are using
them here. They make the library not reentrant.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2016-07-16 08:20 -0700 |
| Message-ID | <chine.bleu-4657CA.08201316072016@news.eternal-september.org> |
| In reply to | #90419 |
In article <nmbl0s$t8n$1@dont-email.me>, jacobnavia <jacob@jacob.remcomp.fr> wrote: > Don't like mine? Is High Level C C programs written on an airplane flight or C programs used on the space station? -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. 'I desire mercy, not sacrifice.' If you assume the final scene is a dying delusion as Tom Cruise drowns below the Louvre, then Edge of Tomorrow has a happy ending. Kill Tom repeat..
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-07-16 17:24 +0200 |
| Message-ID | <nmdjjb$bid$1@dont-email.me> |
| In reply to | #90446 |
Le 16/07/2016 à 17:20, Siri Cruise a écrit : > In article <nmbl0s$t8n$1@dont-email.me>, jacobnavia <jacob@jacob.remcomp.fr> > wrote: > >> Don't like mine? > > Is High Level C C programs written on an airplane flight or C programs used on > the space station? > NICE! All you manage to say is a meaningless sentence... It is impossible to discuss C here. See this thread and the deluge of posts about lisp. You are just another wanna be trying to write a cute sentence without achieving your goal. Maybe: ARE High level C programs ...
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2016-07-16 09:24 -0700 |
| Message-ID | <chine.bleu-39D2C8.09244816072016@news.eternal-september.org> |
| In reply to | #90447 |
In article <nmdjjb$bid$1@dont-email.me>, jacobnavia <jacob@jacob.remcomp.fr> wrote: > Le 16/07/2016 à 17:20, Siri Cruise a écrit : > > In article <nmbl0s$t8n$1@dont-email.me>, jacobnavia > > <jacob@jacob.remcomp.fr> > > wrote: > > > >> Don't like mine? > > > > Is High Level C C programs written on an airplane flight or C programs used > > on > > the space station? > > > > NICE! > > All you manage to say is a meaningless sentence... > > It is impossible to discuss C here. See this thread and the deluge of > posts about lisp. > > You are just another wanna be trying to write a cute sentence without > achieving your goal. > > Maybe: > > ARE High level C programs ... Uh, no. 'High level C' is a singular noun and takes a singular verb. The predicate nominative 'C programs...or C programs...' are plural, but do not control verb inflexion. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. 'I desire mercy, not sacrifice.' If you assume the final scene is a dying delusion as Tom Cruise drowns below the Louvre, then Edge of Tomorrow has a happy ending. Kill Tom repeat..
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web