Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91437 > unrolled thread
| Started by | luser droog <luser.droog@gmail.com> |
|---|---|
| First post | 2016-07-31 15:31 -0700 |
| Last post | 2016-08-08 22:12 -0700 |
| Articles | 20 on this page of 144 — 28 participants |
Back to article view | Back to comp.lang.c
Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-07-31 15:31 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-07-31 15:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:21 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 20:34 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 12:14 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 12:46 -0700
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 15:56 -0400
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 14:28 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 23:37 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 15:03 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-02 00:11 +0200
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 18:19 -0400
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-02 12:46 -0500
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-03 15:26 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 15:49 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:07 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 19:26 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:55 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-03 20:38 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 05:10 -0700
Re: Extending C with GC? Siri Cruise <chine.bleu@yahoo.com> - 2016-08-04 05:57 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 06:13 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 07:24 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 12:47 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:32 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 10:09 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 20:32 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-05 06:14 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:14 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-06 13:23 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:38 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 04:34 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 05:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:05 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:12 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:02 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 06:11 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:50 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 07:57 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 17:02 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:20 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 14:27 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:45 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 09:59 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 19:38 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 17:03 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 09:54 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-07 21:53 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 11:34 +0100
Re: Extending C with GC? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-07 12:06 +0000
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-07 14:10 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 15:38 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:32 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 23:44 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 16:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 01:42 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:56 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:20 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-08 09:39 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 02:30 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:15 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 01:24 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 02:08 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:49 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 03:28 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 12:14 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 07:37 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:56 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 08:11 +1200
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-07 22:19 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:23 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 14:29 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:36 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 15:04 -0700
Re: Extending C with GC? jameskuyper@verizon.net - 2016-08-07 15:19 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 00:04 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 16:20 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:21 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:35 +0100
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:13 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 11:53 -0700
Re: Extending C with GC? raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:58 +0000
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-10 07:05 -0700
Re: Extending C with GC? Ken Brody <kenbrody@spamcop.net> - 2016-08-10 12:29 -0400
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 21:15 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 08:57 -0700
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-07 15:37 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:58 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:26 +1200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 10:26 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:13 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:41 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 12:00 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 22:07 +1200
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-08 12:57 +0200
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:12 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:25 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 02:57 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 13:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 05:42 -0700
Re: Extending C with GC? Florian Weimer <fw@deneb.enyo.de> - 2016-08-07 11:49 +0200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:18 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:27 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 10:55 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:31 -0700
Re: Extending C with GC? James Kuyper <jameskuyper@verizon.net> - 2016-08-03 22:36 -0400
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 10:57 +0200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 04:09 -0700
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 14:01 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 07:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 08:57 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 09:19 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 12:30 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 15:21 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 16:50 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-05 07:31 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 16:01 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-04 21:00 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-04 20:26 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 10:37 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:52 +0100
Re: Extending C with GC? antispam@math.uni.wroc.pl - 2016-08-21 00:09 +0000
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-21 08:58 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-21 10:48 +0200
Re: Extending C with GC? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-08-21 19:58 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-22 08:46 -0700
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-26 02:24 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-26 13:37 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-27 00:41 +0200
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-28 06:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-05 10:06 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:26 +0100
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:11 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 17:43 +0200
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:28 -0700
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-04 17:11 -0500
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-01 07:45 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 08:49 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 09:06 -0700
Re: Extending C with GC? Aleksandar Kuktin <akuktin@gmail.com> - 2016-08-05 18:11 +0000
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-05 11:24 -0700
Re: Extending C with GC? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-08 22:12 -0700
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2016-08-04 05:57 -0700 |
| Message-ID | <chine.bleu-E0389F.05570104082016@news.eternal-september.org> |
| In reply to | #91642 |
In article <6c8ded05-9ca9-4bae-a603-00b526ac0a77@googlegroups.com>, "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > Protocol: > > Use of new structure > Strict adherence to calling constructor() to create something. > Strict adherence to calling destructor() to destroy something. A program that uses a dynamic graph of objects no longer has a simple way to know when a node object is no longer in use. Three ways of dealing with this is copy an object so each node has only incoming edge and released when the node on the other end of the edge is released; count the number of incoming edges and release on no more edges, but this fails if the graph is cyclic; or keep a list of all nodes and periodically trace all acyclic paths through the graph, then release any node not reached. -- :-<> 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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-04 06:13 -0700 |
| Message-ID | <579bfcdd-daed-4835-94a5-7eaf02085596@googlegroups.com> |
| In reply to | #91644 |
On Thursday, August 4, 2016 at 8:57:33 AM UTC-4, Siri Cruise wrote: > In article <6c8ded05-9ca9-4bae-a603-00b526ac0a77@googlegroups.com>, > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > > > Protocol: > > > > Use of new structure > > Strict adherence to calling constructor() to create something. > > Strict adherence to calling destructor() to destroy something. > > A program that uses a dynamic graph of objects no longer has a simple way to > know when a node object is no longer in use. Three ways of dealing with this is > copy an object so each node has only incoming edge and released when the node on > the other end of the edge is released; count the number of incoming edges and > release on no more edges, but this fails if the graph is cyclic; or keep a list > of all nodes and periodically trace all acyclic paths through the graph, then > release any node not reached. With language support, it can be known in all cases which do not involve some kind of underhanded dealings, such as using facilities outside of the application to free or duplicate something. I have given this much thought for CAlive. I have concluded that a model using a managed pointer is required, one that includes each reference made to it, that are created and destroyed as they go in and out of scope. I have also considered something larger which encapsulates the allocated blocks for a thing, like a task, which will then allow those which are still hanging in memory, orphan pointers that are no longer known anywhere, but persist, to be freed when the task itself is GC'd. I plan to introduce these concepts in CAlive, but it's a low priority item for me, and one I can add later. It may not make it into version 1.0. We'll see though. If I get enough help, it could be in there. So far it's just me. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-05 07:24 +1200 |
| Message-ID | <e0hj4hF7bmqU1@mid.individual.net> |
| In reply to | #91642 |
On 08/ 5/16 12:10 AM, Rick C. Hodgin wrote: > > The only way GC could be introduced in C directly, is to change the > fundamental nature of how it creates, uses, and releases memory, and > that would be a hobbling of C's direct-access model. Garbage collection is already used with C today. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-04 12:47 -0700 |
| Message-ID | <39d45c61-964f-46e8-8f62-ee9611ee0d6d@googlegroups.com> |
| In reply to | #91667 |
On Thursday, August 4, 2016 at 3:25:16 PM UTC-4, Ian Collins wrote: > On 08/ 5/16 12:10 AM, Rick C. Hodgin wrote: > > The only way GC could be introduced in C directly, is to change the > > fundamental nature of how it creates, uses, and releases memory, and > > that would be a hobbling of C's direct-access model. > > Garbage collection is already used with C today. I'm sure it is, but only as Malcolm indicated (API + protocol). It is not part of the C language natively, and could only be added through those add-on-top libraries. To make it native would require modifying the C compiler to inject support for GC throughout, which would hobble C's existing model, and its efficiency. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-04 23:32 -0700 |
| Message-ID | <1d9bb5b0-42eb-4810-968f-bdd42cd1c360@googlegroups.com> |
| In reply to | #91673 |
On Thursday, August 4, 2016 at 8:47:29 PM UTC+1, Rick C. Hodgin wrote: > On Thursday, August 4, 2016 at 3:25:16 PM UTC-4, Ian Collins wrote: > > On 08/ 5/16 12:10 AM, Rick C. Hodgin wrote: > > > The only way GC could be introduced in C directly, is to change the > > > fundamental nature of how it creates, uses, and releases memory, and > > > that would be a hobbling of C's direct-access model. > > > > Garbage collection is already used with C today. > > I'm sure it is, but only as Malcolm indicated (API + protocol). > > It is not part of the C language natively, and could only be added through > those add-on-top libraries. To make it native would require modifying the > C compiler to inject support for GC throughout, which would hobble C's > existing model, and its efficiency. > Actually it doesn't. Jacob's compiler has GC, but if the garbage collector is not used, there's essentially no impact on runtime performance.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-05 10:09 +0100 |
| Message-ID | <87shujr38r.fsf@bsb.me.uk> |
| In reply to | #91703 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snip> > Jacob's compiler has GC, but if the garbage collector is not used, > there's essentially no impact on runtime performance. I though lcc-win32 did GC by using the Boehm library (but it's been a while since that was discussed here). Since in other threads Jacob is talking about language changes to support GC, the otherwise rather fussy distinction between the compiler and the whole implementation is rather more important here. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-05 20:32 +1200 |
| Message-ID | <e0j19dFkucbU1@mid.individual.net> |
| In reply to | #91673 |
On 08/ 5/16 07:47 AM, Rick C. Hodgin wrote: > On Thursday, August 4, 2016 at 3:25:16 PM UTC-4, Ian Collins wrote: >> On 08/ 5/16 12:10 AM, Rick C. Hodgin wrote: >>> The only way GC could be introduced in C directly, is to change the >>> fundamental nature of how it creates, uses, and releases memory, and >>> that would be a hobbling of C's direct-access model. >> >> Garbage collection is already used with C today. > > I'm sure it is, but only as Malcolm indicated (API + protocol). > > It is not part of the C language natively, and could only be added through > those add-on-top libraries. To make it native would require modifying the > C compiler to inject support for GC throughout, which would hobble C's > existing model, and its efficiency. Nope, on many platforms there are several different allocator libraries. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-05 06:14 -0700 |
| Message-ID | <0fe11c04-9255-475b-a3b3-797d3119ec26@googlegroups.com> |
| In reply to | #91707 |
On Friday, August 5, 2016 at 4:32:55 AM UTC-4, Ian Collins wrote: > On 08/ 5/16 07:47 AM, Rick C. Hodgin wrote: > > On Thursday, August 4, 2016 at 3:25:16 PM UTC-4, Ian Collins wrote: > >> On 08/ 5/16 12:10 AM, Rick C. Hodgin wrote: > >>> The only way GC could be introduced in C directly, is to change the > >>> fundamental nature of how it creates, uses, and releases memory, and > >>> that would be a hobbling of C's direct-access model. > >> > >> Garbage collection is already used with C today. > > > > I'm sure it is, but only as Malcolm indicated (API + protocol). > > > > It is not part of the C language natively, and could only be added through > > those add-on-top libraries. To make it native would require modifying the > > C compiler to inject support for GC throughout, which would hobble C's > > existing model, and its efficiency. > > Nope, on many platforms there are several different allocator libraries. Are they libraries you can use if you include and link to them? Does the C compiler provide any native facilities to track pointer usage for GC automatically? Or is it all done through protocol adherence? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-06 04:14 -0700 |
| Message-ID | <c0cb52d1-bb07-4aab-90c5-a9e892f6640c@googlegroups.com> |
| In reply to | #91723 |
On Friday, August 5, 2016 at 9:14:38 AM UTC-4, Rick C. Hodgin wrote: > On Friday, August 5, 2016 at 4:32:55 AM UTC-4, Ian Collins wrote: > > On 08/ 5/16 07:47 AM, Rick C. Hodgin wrote: > > > On Thursday, August 4, 2016 at 3:25:16 PM UTC-4, Ian Collins wrote: > > >> On 08/ 5/16 12:10 AM, Rick C. Hodgin wrote: > > >>> The only way GC could be introduced in C directly, is to change the > > >>> fundamental nature of how it creates, uses, and releases memory, and > > >>> that would be a hobbling of C's direct-access model. > > >> > > >> Garbage collection is already used with C today. > > > > > > I'm sure it is, but only as Malcolm indicated (API + protocol). > > > > > > It is not part of the C language natively, and could only be added through > > > those add-on-top libraries. To make it native would require modifying the > > > C compiler to inject support for GC throughout, which would hobble C's > > > existing model, and its efficiency. > > > > Nope, on many platforms there are several different allocator libraries. > > Are they libraries you can use if you include and link to them? Does the > C compiler provide any native facilities to track pointer usage for GC > automatically? Or is it all done through protocol adherence? Ian Collins, do you have an answer? If there is a C compiler with integrated GC, I'd like to have a look at its design. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-08-06 13:23 +0200 |
| Message-ID | <20160806132359.295e8d7e@maxa-pc> |
| In reply to | #91802 |
On Sat, 6 Aug 2016 04:14:14 -0700 (PDT) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > On Friday, August 5, 2016 at 9:14:38 AM UTC-4, Rick C. Hodgin wrote: > > On Friday, August 5, 2016 at 4:32:55 AM UTC-4, Ian Collins wrote: > > > On 08/ 5/16 07:47 AM, Rick C. Hodgin wrote: > > > > On Thursday, August 4, 2016 at 3:25:16 PM UTC-4, Ian Collins > > > > wrote: > > > >> On 08/ 5/16 12:10 AM, Rick C. Hodgin wrote: > > > >>> The only way GC could be introduced in C directly, is to > > > >>> change the fundamental nature of how it creates, uses, and > > > >>> releases memory, and that would be a hobbling of C's > > > >>> direct-access model. > > > >> > > > >> Garbage collection is already used with C today. > > > > > > > > I'm sure it is, but only as Malcolm indicated (API + protocol). > > > > > > > > It is not part of the C language natively, and could only be > > > > added through those add-on-top libraries. To make it native > > > > would require modifying the C compiler to inject support for GC > > > > throughout, which would hobble C's existing model, and its > > > > efficiency. > > > > > > Nope, on many platforms there are several different allocator > > > libraries. > > > > Are they libraries you can use if you include and link to them? > > Does the C compiler provide any native facilities to track pointer > > usage for GC automatically? Or is it all done through protocol > > adherence? > > Ian Collins, do you have an answer? If there is a C compiler with > integrated GC, I'd like to have a look at its design. Take a look at D compilers ldc(clang based) and gdc(gcc based)... Experience with GC in D can be very helpful...
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-06 04:38 -0700 |
| Message-ID | <caf6e6bd-cd02-48e0-a5c3-74e42eb8bdd2@googlegroups.com> |
| In reply to | #91803 |
On Saturday, August 6, 2016 at 7:24:10 AM UTC-4, Melzzzzz wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > > Ian Collins, do you have an answer? If there is a C compiler with > > integrated GC, I'd like to have a look at its design. > > Take a look at D compilers ldc(clang based) and gdc(gcc based)... > Experience with GC in D can be very helpful... Will do. Thanks, Melzzzzz. I've been a fan of Walter Bright's work for many years. I've watched several videos where he explains details of his thinking in the reasoning behind design aspects of the D programming language. He was one of the inspirations I had (by example) in moving forward with creating my own compiler. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-06 04:34 -0700 |
| Message-ID | <4c5800c3-b867-4daf-acb3-1c3e0fd6d789@googlegroups.com> |
| In reply to | #91802 |
On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: > > Ian Collins, do you have an answer? If there is a C compiler with > integrated GC, I'd like to have a look at its design. > Jacob's lcc-win. However it's closed source. The GC is one of the major competitive advantages, and you can't reasonably expect Jacob to give away his business's assets to satisfy your curiosity. You might be able to arrange some sort of deal whereby he licences the technology to you, however. I can't negotiate arrangements on Jacob's behalf, of course.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-06 05:28 -0700 |
| Message-ID | <cfc008e8-adc9-4013-9bb4-199898bc64f1@googlegroups.com> |
| In reply to | #91804 |
On Saturday, August 6, 2016 at 7:34:46 AM UTC-4, Malcolm McLean wrote:
> On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote:
> >
> > Ian Collins, do you have an answer? If there is a C compiler with
> > integrated GC, I'd like to have a look at its design.
> >
> Jacob's lcc-win.
> However it's closed source. The GC is one of the major competitive
> advantages, and you can't reasonably expect Jacob to give away his
> business's assets to satisfy your curiosity.
> You might be able to arrange some sort of deal whereby he licences
> the technology to you, however. I can't negotiate arrangements on
> Jacob's behalf, of course.
I have not investigated the matter, but as Ben indicated, and as I have
gathered from the other GC thread spawned from this one (entitled, "A
GC proposal"):
https://groups.google.com/forum/#!topic/comp.lang.c/F4YcgyYGmsg
That GC is not native in lcc-win, but uses the add-on library:
https://en.wikipedia.org/wiki/Boehm_garbage_collector
This means lcc does not support GCC natively, but only through add-on
libraries and adherence to the protocol.
Ben made the comment recently about a "fussy distinction" in that regard,
and I could not determine if he was being humorous, or serious, but I do
not view it as a fussy distinction, but as a real aspect of design.
-----
To incorporate the facilities to allow GC means a C compiler would
have to be significantly altered to inject the additional function
calls whenever pointers are passed around, as well as something like
setting a pointer to NULL to free it, rather than actually freeing
it as by a function call.
I have given this area of research a great deal of thought in preparation
for inclusion in my CAlive language. I am convinced that GC has utility,
but that it requires a managed pointer in order to be used (one that is
managed by the compiler through each use, and one that is subsequently
rather expensive compared to native raw pointer performance).
I envision a structure which has logically negative offsets relate to its
data pointer, which reach into the managed portions (assuming a 32-bit
implementation):
// A 2-way link list for handling references in/out
struct SGCLL
{
SLL link_list; // 2-way link list
void** ptr; // Pointer to the reference pointer
SGC* gc_block; // Pointer to the source item
};
// GC structure
struct SGC
{
// Offsets logical from actual data:
/* -28 */ SLL link_list; // 2-way, to related others
/* -24 */ u32 uid; // Unique ID
/* -20 */ u32 semaphore; // OS gated access
/* -16 */ bool (*onNull)(SGC* sgc); // Handler for NULL use
/* -12 */ SGCLL* references_out; // List of references out
/* -8 */ SGCLL* references_in; // List of references in
/* -4 */ int size; // Allocated block size
/* 0 */ void* data; // Pointer to managed data
};
// Note that other members also exist, but aren't shown here
Normal and fast C processing would obtain a pointer to data for C-like speed
(without then going through consistent indirection on use):
SGC* gcptr = malloc(16); // It's SGC*, so the GC-aware compiler auto-
// directs malloc() into gc_malloc()
void* data = dataof gcptr; // Grab the gcptr->data member by protocol
When passing the pointer around within the system, it would pass gcptr, which
would spawn references out each time. As the passed references go out of
scope, those references out are deleted.
Scoping for gcptr and references to gcptr would be used to determine when
data is in or out of scope. As long as at least one reference out exists
for gcptr, its data member would be valid. Once all references out to gcptr
are gone, data is no longer valid even though it may not be GC'd for some
time.
The references_in member exists because in a multi-threading environment,
a gcptr could be explicitly force-deleted, causing all system-wide references
to the block to no longer be valid as of that instant, and the link list of
references goes out to each reference so they can be set as well.
In cases of direct use of gcptr rather than data, a test would be performed on
each use to validate whether or not the pointer is still valid. As such, no
gcptr, once allocated, would ever be deleted, though prior use gcptr values
could be reused, which is why the uid member exists, so it can be tested to
see if it's still in scope, with the expected block.
I also would like to be able to simply use:
gcptr = NULL;
to release something. I don't think it should have to call a function as
by the developer typing source code to do so, but I think the compiler
should inject those required aspects automatically.
-----
In short, it requires full management. And I believe this has tremendous
utility for passing messages around the system, but very little utility for
use in a normal system. C's standard memory management is far better as it
allocates and deallocates on use, and checks itself for NULL, etc.
I also plan on providing a feature in my operating system which, through
LiveCode facilities, guarantees that memory will be allocated by the time
an instruction which references a memory block are reached. If it could
not have been allocated, the program would've suspended to the debugger,
or gone through a handler which rewinds things back to some prior point in
the program:
https://github.com/RickCHodgin/libsf/tree/master/exodus/LibSF_ES2
"Jul.14.2016 -- ES/2 will guarantee memory allocation. If it fails,
the task will be suspended where it is until resources can be freed.
Legacy support will also be given for memory allocation which can
fail, and will need to have NULL pointer tests performed."
I have many plans, many goals, and I am proceeding in developing them. I
would like to have others come on board and help me with development. I
believe as I get further along, some will do so.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-06 06:05 -0700 |
| Message-ID | <d3c7e428-151c-46e2-8093-e01883b8b378@googlegroups.com> |
| In reply to | #91806 |
On Saturday, August 6, 2016 at 8:29:08 AM UTC-4, Rick C. Hodgin wrote:
> In short, it requires full management. And I believe this has tremendous
> utility for passing messages around the system, but very little utility for
> use in a normal SYSTEM. C's standard memory management is far better as it
> allocates and deallocates on use, and checks itself for NULL, etc.
This should read:
In short, it requires full management. And I believe this has
tremendous utility for passing messages around the system, but very
little utility for use in a normal APPLICATION. C's standard memory
management is far better as it allocates and deallocates on use, and
checks itself for NULL, etc.
My thinking is that using this kind of GC'd memory would be an ideal method
for global memory allocations into a shared memory block system-wide. But
for use within a single system, it is unnecessary and counter-productive.
As such, both models should exist as native first-class citizens in a future
C compiler.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-06 06:12 -0700 |
| Message-ID | <153f07cc-b708-48ab-9816-187fa95bf5a0@googlegroups.com> |
| In reply to | #91808 |
On Saturday, August 6, 2016 at 9:05:57 AM UTC-4, Rick C. Hodgin wrote:
> My thinking is that using this kind of GC'd memory would be an ideal method
> for global memory allocations into a shared memory block system-wide. But
> for use within a single system, it is unnecessary and counter-productive.
And this should read:
My thinking is that using this kind of GC'd memory would be an ideal
method for global memory allocations into a shared memory block system-
wide. But for use within a single APPLICATION, it is unnecessary and
counter-productive.
-----
And now I'll sing a little song to solidify my apparent mental "theme of
the day":
Oh my brain! Oh my brain!
Oh my brain, I wonder of thee.
Oh my brain! Oh my brain!
I wonder sometimes just how you think.
:-)
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-06 14:02 +0100 |
| Message-ID | <87k2funj8k.fsf@bsb.me.uk> |
| In reply to | #91804 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: >> >> Ian Collins, do you have an answer? If there is a C compiler with >> integrated GC, I'd like to have a look at its design. >> > Jacob's lcc-win. > However it's closed source. The GC is one of the major competitive > advantages, and you can't reasonably expect Jacob to give away his > business's assets to satisfy your curiosity. Are you sure? To quote from an admittedly rather old copy of the lcc-win's manual: "Lcc-win comes with an automatic memory manager (also called garbage collector in the literature) written by Hans Boehm." Now it's quite possible a lot of work was needed to make the GC library work with lcc-win, so maybe there is a significant business assets here, but Rick could surely get 99% of the design just be reading the GC sources. Even in lcc-win now has its own closed source GC library, Rick would surely learn more from reading the papers and source code of a comparatively portable library. > You might be able to arrange some sort of deal whereby he licences > the technology to you, however. I can't negotiate arrangements on > Jacob's behalf, of course. ... or visit http://www.hboehm.info/gc/ and follow the links. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-06 06:11 -0700 |
| Message-ID | <3b4ff9ca-55ca-44e4-bc9f-e6a91b03f516@googlegroups.com> |
| In reply to | #91807 |
On Saturday, August 6, 2016 at 2:02:32 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: > >> > >> Ian Collins, do you have an answer? If there is a C compiler with > >> integrated GC, I'd like to have a look at its design. > >> > > Jacob's lcc-win. > > However it's closed source. The GC is one of the major competitive > > advantages, and you can't reasonably expect Jacob to give away his > > business's assets to satisfy your curiosity. > > Are you sure? To quote from an admittedly rather old copy of the > lcc-win's manual: > No I'm not. I've no connection with Jacob Navia other than that we both contribute to comp.lang.c. But my understanding is that lcc-win comes with a garbage collector which can be disabled, in which case the compiler is a standard C compiler with essentially no GC overhead, or used, in which case Jacob takes advantage of the fact that he controls both the compiler and the garbage collector to use some sort of pointer tagging system that enables GC to work more efficiently than with a compiler independent system. I don't know however. I haven't examined the source.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-06 14:50 +0100 |
| Message-ID | <878twanh0t.fsf@bsb.me.uk> |
| In reply to | #91809 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 6, 2016 at 2:02:32 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: >> >> >> >> Ian Collins, do you have an answer? If there is a C compiler with >> >> integrated GC, I'd like to have a look at its design. >> >> >> > Jacob's lcc-win. >> > However it's closed source. The GC is one of the major competitive >> > advantages, and you can't reasonably expect Jacob to give away his >> > business's assets to satisfy your curiosity. >> >> Are you sure? To quote from an admittedly rather old copy of the >> lcc-win's manual: >> > No I'm not. > I've no connection with Jacob Navia other than that we both contribute > to comp.lang.c. > But my understanding is that lcc-win comes with a garbage collector > which can be disabled, in which case the compiler is a standard > C compiler with essentially no GC overhead, or used, in which case > Jacob takes advantage of the fact that he controls both the compiler > and the garbage collector to use some sort of pointer tagging system > that enables GC to work more efficiently than with a compiler > independent system. Where does this understanding come from? > I don't know however. Curious that you would chose to comment then. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-06 07:57 -0700 |
| Message-ID | <8926988e-ed9c-44af-8f9b-1da152a5ab24@googlegroups.com> |
| In reply to | #91813 |
On Saturday, August 6, 2016 at 2:50:17 PM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Saturday, August 6, 2016 at 2:02:32 PM UTC+1, Ben Bacarisse wrote: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> > >> > On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: > >> >> > >> >> Ian Collins, do you have an answer? If there is a C compiler with > >> >> integrated GC, I'd like to have a look at its design. > >> >> > >> > Jacob's lcc-win. > >> > However it's closed source. The GC is one of the major competitive > >> > advantages, and you can't reasonably expect Jacob to give away his > >> > business's assets to satisfy your curiosity. > >> > >> Are you sure? To quote from an admittedly rather old copy of the > >> lcc-win's manual: > >> > > No I'm not. > > I've no connection with Jacob Navia other than that we both contribute > > to comp.lang.c. > > But my understanding is that lcc-win comes with a garbage collector > > which can be disabled, in which case the compiler is a standard > > C compiler with essentially no GC overhead, or used, in which case > > Jacob takes advantage of the fact that he controls both the compiler > > and the garbage collector to use some sort of pointer tagging system > > that enables GC to work more efficiently than with a compiler > > independent system. > > Where does this understanding come from? > > > I don't know however. > > Curious that you would chose to comment then. > That's what Jacob has said. But if you are disputing it, it's best to let him speak for himself, it's entirely possible I have misunderstood or remembered incorrectly.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-06 17:02 +0100 |
| Message-ID | <87wpjtnavt.fsf@bsb.me.uk> |
| In reply to | #91814 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 6, 2016 at 2:50:17 PM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> > On Saturday, August 6, 2016 at 2:02:32 PM UTC+1, Ben Bacarisse wrote: >> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> >> >> > On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: >> >> >> >> >> >> Ian Collins, do you have an answer? If there is a C compiler with >> >> >> integrated GC, I'd like to have a look at its design. >> >> >> >> >> > Jacob's lcc-win. >> >> > However it's closed source. The GC is one of the major competitive >> >> > advantages, and you can't reasonably expect Jacob to give away his >> >> > business's assets to satisfy your curiosity. >> >> >> >> Are you sure? To quote from an admittedly rather old copy of the >> >> lcc-win's manual: >> >> >> > No I'm not. >> > I've no connection with Jacob Navia other than that we both contribute >> > to comp.lang.c. >> > But my understanding is that lcc-win comes with a garbage collector >> > which can be disabled, in which case the compiler is a standard >> > C compiler with essentially no GC overhead, or used, in which case >> > Jacob takes advantage of the fact that he controls both the compiler >> > and the garbage collector to use some sort of pointer tagging system >> > that enables GC to work more efficiently than with a compiler >> > independent system. >> >> Where does this understanding come from? >> >> > I don't know however. >> >> Curious that you would chose to comment then. >> > That's what Jacob has said. Privately? I've read no posts that could lead you think what you wrote, but (sorry to ask) you could always cite a post or two so I can read what you are referring to. By the way, if you are referring to the recent threads about GC, he is sketching an incomplete (and, in my opinion, unworkable) plan for compiler-assisted GC. > But if you are disputing it, it's best to let him speak for himself, > it's entirely possible I have misunderstood or remembered incorrectly. I'm disputing what *you* said. I am happy that I know what he said, though I am willing to be shown I'm wrong. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web