Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #94192 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2016-09-28 09:35 -0700 |
| Last post | 2016-09-28 20:20 +0100 |
| Articles | 20 on this page of 135 — 24 participants |
Back to article view | Back to comp.lang.c
Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 09:35 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 09:39 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 09:46 -0700
Re: Is there any place to talk about language features? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-28 17:53 +0100
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-09-28 21:21 +0200
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-28 20:36 +0100
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 13:55 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:02 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-09-29 10:03 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:13 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-09-29 10:22 +1300
Re: Is there any place to talk about language features? Robert Latest <boblatest@yahoo.com> - 2016-10-03 08:47 +0000
Re: Is there any place to talk about language features? James Kuyper <jameskuyper@verizon.net> - 2016-10-03 07:44 -0400
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 04:56 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 13:18 +0100
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-10-03 12:43 -0500
Re: Is there any place to talk about language features? Ike Naar <ike@iceland.freeshell.org> - 2016-10-03 21:43 +0000
Re: Is there any place to talk about language features? John Gordon <gordon@panix.com> - 2016-10-03 22:28 +0000
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-03 04:51 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 13:10 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 05:48 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-03 14:03 +0100
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-03 14:24 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 07:07 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-03 19:16 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 07:16 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 07:45 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 07:57 -0700
Re: Is there any place to talk about language features? James Kuyper <jameskuyper@verizon.net> - 2016-10-03 08:21 -0400
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-03 05:31 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 06:43 -0700
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-03 15:08 +0200
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:22 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 15:16 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 16:08 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 16:57 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 14:19 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 14:50 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 17:03 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-29 01:08 +0100
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-28 17:33 -0700
Re: Is there any place to talk about language features? Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-29 01:02 +0000
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-09-29 01:39 -0500
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-29 00:48 -0700
Re: Is there any place to talk about language features? BGB <cr88192@hotmail.com> - 2016-09-29 11:59 -0500
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 08:09 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 12:14 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 09:07 +1300
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-30 13:53 -0700
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-09-30 22:13 +0100
Re: Is there any place to talk about language features? raltbos@xs4all.nl (Richard Bos) - 2016-10-01 09:36 +0000
Re: Is there any place to talk about language features? Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-01 13:04 -0400
Re: Is there any place to talk about language features? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-30 14:20 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-09-30 22:30 +0100
Re: Is there any place to talk about language features? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-10-02 07:30 +0000
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 01:51 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 10:31 +0100
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-01 23:22 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 06:15 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 15:28 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-01 10:07 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-01 19:52 +0100
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-02 20:38 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-02 03:37 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-03 08:35 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-02 15:17 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-03 18:29 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 01:09 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-04 08:21 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-03 13:12 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-03 14:34 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 00:47 -0700
Re: Is there any place to talk about language features? Ike Naar <ike@iceland.freeshell.org> - 2016-10-04 07:49 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-04 07:50 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-04 08:57 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-04 10:42 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 15:47 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-04 20:58 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 18:14 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 02:15 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-05 22:44 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 03:12 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:38 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:50 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 16:25 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 21:19 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 18:11 +1300
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-10-06 06:38 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-06 00:36 -0700
Re: Is there any place to talk about language features? gwowen <gwowen@gmail.com> - 2016-10-06 07:33 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-06 09:00 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 00:32 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 05:05 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-07 08:13 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 00:20 -0700
Re: Is there any place to talk about language features? Gareth Owen <gwowen@gmail.com> - 2016-10-07 17:01 +0100
Re: Is there any place to talk about language features? Les Cargill <lcargill99@comcast.com> - 2016-10-05 12:45 -0500
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 11:12 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 03:15 -0700
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 14:41 +0100
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 08:01 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 08:41 -0700
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 10:29 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 12:29 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 11:08 +0100
Re: Is there any place to talk about language features? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-05 14:35 +0100
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 18:15 +0100
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 10:38 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-05 19:14 +0100
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 11:56 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 11:57 -0700
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-05 12:18 -0700
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-05 21:49 +0200
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-10-05 13:07 -0700
Re: Is there any place to talk about language features? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-10-05 16:23 -0400
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-06 14:26 +0200
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-05 13:56 -0700
Re: Is there any place to talk about language features? BartC <bc@freeuk.com> - 2016-10-06 14:17 +0100
Re: Is there any place to talk about language features? David Brown <david.brown@hesbynett.no> - 2016-10-06 15:53 +0200
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-10-06 09:12 -0700
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-06 11:28 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:31 +1300
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 15:32 +1300
Re: Is there any place to talk about language features? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-05 19:43 -0700
Re: Is there any place to talk about language features? Ian Collins <ian-news@hotmail.com> - 2016-10-06 16:05 +1300
Re: Is there any place to talk about language features? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2016-10-02 07:24 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-09-30 16:17 -0700
Re: Is there any place to talk about language features? raltbos@xs4all.nl (Richard Bos) - 2016-10-01 09:39 +0000
Re: Is there any place to talk about language features? supercat@casperkitty.com - 2016-10-01 14:11 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-29 07:47 -0700
Re: Is there any place to talk about language features? Thiago Adams <thiago.adams@gmail.com> - 2016-09-29 10:25 -0700
Re: Is there any place to talk about language features? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-28 12:59 -0400
Re: Is there any place to talk about language features? Richard Heathfield <rjh@cpax.org.uk> - 2016-09-28 18:30 +0100
Re: Is there any place to talk about language features? Keith Thompson <kst-u@mib.org> - 2016-09-28 12:10 -0700
Re: Is there any place to talk about language features? James Harris <james.harris.1@gmail.com> - 2016-09-28 20:20 +0100
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-01 10:07 -0700 |
| Message-ID | <25ce313b-434c-4289-8c3d-51e15f1e40af@googlegroups.com> |
| In reply to | #94367 |
On Saturday, October 1, 2016 at 3:28:17 PM UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Saturday, October 1, 2016 at 11:22:42 AM UTC+1, Ian Collins wrote:
> <snip>
> >> You overlook the fact that many if not most resource allocation and
> >> release happens in different parts of a programme.
> >>
> > There's also the structure pattern. A graph is created, then nodes and
> > edges are added and deleted as the algorithm does its stuff. So
> > obviously memory has to be allocated at the point a node is created
> > and released at the point it is destroyed. But everything should
> > be accessible from the root, and at every time it ought to be
> > possible to destroy the entire structure by calling the destructor
> > on the root.
> >
> > The trick is to use structured programming. Each "block" (which is
> > similar to but not identical to a C curly braces block") has one
> > point of entry and one point of exit. So creation and destruction
> > are matched. A block either destroys all the resources it holds
> > on exit, or passes them up to caller. If it passes them up to caller,
> > it must be matched by a "destructor" function, which caller must
> > call on his own exit (or pass them up to super-caller, and provide
> > a destructor of his own, which then calls the destructor).
>
> This pattern does not always work. You can't always have nested
> creation and deletion like this. A Lisp implementation comes to mind as
> an example. (Actually it may be possible to enforce this at the expense
> of a great deal of copying but I'm not sure even that is possible.)
>
Firstly toplevel will be
int lisp(void)
{
LISPENGINE *lisp = 0;
int err = 0;
lisp = creatlispengine("myprogam.((())))");
if(!lisp)
goto error_exit;
do
{
halted = lisp_runastep(lisp, &err);
if(err)
goto error_exit;
} while(!halted);
killlispeengine(lisp);
return 0;
error_exit:
killlispengine(lisp);
return -1;
}
So that's not problematic, the only difficulty is that lisp_runastep()
does not return anything except a halt flag in normal execution,
but may run out of memory or experience IO failure internally, in
which case it needs to pass the error up to abort.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-01 19:52 +0100 |
| Message-ID | <878tu76gwq.fsf@bsb.me.uk> |
| In reply to | #94375 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, October 1, 2016 at 3:28:17 PM UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > On Saturday, October 1, 2016 at 11:22:42 AM UTC+1, Ian Collins wrote:
>> <snip>
>> >> You overlook the fact that many if not most resource allocation and
>> >> release happens in different parts of a programme.
>> >>
>> > There's also the structure pattern. A graph is created, then nodes and
>> > edges are added and deleted as the algorithm does its stuff. So
>> > obviously memory has to be allocated at the point a node is created
>> > and released at the point it is destroyed. But everything should
>> > be accessible from the root, and at every time it ought to be
>> > possible to destroy the entire structure by calling the destructor
>> > on the root.
>> >
>> > The trick is to use structured programming. Each "block" (which is
>> > similar to but not identical to a C curly braces block") has one
>> > point of entry and one point of exit. So creation and destruction
>> > are matched. A block either destroys all the resources it holds
>> > on exit, or passes them up to caller. If it passes them up to caller,
>> > it must be matched by a "destructor" function, which caller must
>> > call on his own exit (or pass them up to super-caller, and provide
>> > a destructor of his own, which then calls the destructor).
>>
>> This pattern does not always work. You can't always have nested
>> creation and deletion like this. A Lisp implementation comes to mind as
>> an example. (Actually it may be possible to enforce this at the expense
>> of a great deal of copying but I'm not sure even that is possible.)
>>
> Firstly toplevel will be
>
> int lisp(void)
> {
> LISPENGINE *lisp = 0;
> int err = 0;
>
> lisp = creatlispengine("myprogam.((())))");
> if(!lisp)
> goto error_exit;
>
> do
> {
> halted = lisp_runastep(lisp, &err);
> if(err)
> goto error_exit;
> } while(!halted);
>
> killlispeengine(lisp);
> return 0;
>
> error_exit:
> killlispengine(lisp);
> return -1;
> }
>
>
> So that's not problematic,
What's not problematic? The code above is fine (except for a
disagreement about style) but that's because it doesn't illustrate the
problem.
The problem is not wasting space by deleting objects at the end of their
lifetime but whose lifetime does not correspond to the (dynamic) nesting
of function calls in the C program.
> the only difficulty is that lisp_runastep()
> does not return anything except a halt flag in normal execution,
> but may run out of memory or experience IO failure internally, in
> which case it needs to pass the error up to abort.
I don't see why that's a difficulty at all (though I'd probably put the
error state into the lisp engine object).
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-02 20:38 +1300 |
| Message-ID | <e5brqtF4ag4U1@mid.individual.net> |
| In reply to | #94366 |
On 10/ 2/16 02:15 AM, Malcolm McLean wrote: > On Saturday, October 1, 2016 at 11:22:42 AM UTC+1, Ian Collins wrote: >> On 10/ 1/16 09:51 PM, Malcolm McLean wrote: >>> On Friday, September 30, 2016 at 8:10:05 PM UTC+1, Ian Collins wrote: >>>> >>>> It all comes down to where the complexity required to manage a task >>>> lies: in user code in C or in the language in C++. >>>> >>> In C we can use this pattern. >>> >>> a) Variables may not be declared in block scope, only function scope. >>> (only really matters for pointer and handles, but make it all). >>> b) Every pointer or handle is initialised to null. >>> c) There is a label called "out_of_memory" (for a "Malcolm function, >>> which can only fail on out of memory conditions and for no other >>> reason) or "error_exit" (for a "Malcolm procedure" which does IO >>> and can experience IO failure). >>> d) out_of_memory or error_exit is jumped to on memory allocation >>> or IO failure. >>> e) code the error label destroys all resources, which will be null >>> if not intialised. >>> f) In the usual situation of an failure also meaning a failure in >>> caller, an error return must be passed up. So normally if the function >>> return a pointer it returns null, otherwise it returns -1 for >>> out-of memory, or a lower negative for IO errors. >>> >>> >>> Simple rules, not very complex or hard to follow. >> >> Simple but fallible rules for simple use cases of simple resources. >> Life gets way more interesting when those simple things become a little >> more complicated. >> >>> The only real point of difficulty is that when allocating a structure >>> which itself contains pointers to be allocated, those pointers must >>> immediately be set to null so the destructor logic doesn't free >>> wild pointers. >> >> You overlook the fact that many if not most resource allocation and >> release happens in different parts of a programme. >> > There's also the structure pattern. A graph is created, then nodes and > edges are added and deleted as the algorithm does its stuff. So > obviously memory has to be allocated at the point a node is created > and released at the point it is destroyed. But everything should > be accessible from the root, and at every time it ought to be > possible to destroy the entire structure by calling the destructor > on the root. A good example of where this gets a little more complicated is where there are multiple references to a node or nodes. XML DOM manipulation is one such case. Then you need reference counting (or possibly GC) which is something else that has to be manually maintained (in C, not C++!). > The trick is to use structured programming. Each "block" (which is > similar to but not identical to a C curly braces block") has one > point of entry and one point of exit. So creation and destruction > are matched. A block either destroys all the resources it holds > on exit, or passes them up to caller. If it passes them up to caller, > it must be matched by a "destructor" function, which caller must > call on his own exit (or pass them up to super-caller, and provide > a destructor of his own, which then calls the destructor). > > Where it does get more difficult is where you have threads. You don't even need threads: just storing stored items for later consumption breaks your simple use case. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-02 03:37 -0700 |
| Message-ID | <72aa4608-96be-4c09-bb2a-cf5bd0da6efa@googlegroups.com> |
| In reply to | #94395 |
On Sunday, October 2, 2016 at 8:38:15 AM UTC+1, Ian Collins wrote: > On 10/ 2/16 02:15 AM, Malcolm McLean wrote: > > > The trick is to use structured programming. Each "block" (which is > > similar to but not identical to a C curly braces block") has one > > point of entry and one point of exit. So creation and destruction > > are matched. A block either destroys all the resources it holds > > on exit, or passes them up to caller. If it passes them up to caller, > > it must be matched by a "destructor" function, which caller must > > call on his own exit (or pass them up to super-caller, and provide > > a destructor of his own, which then calls the destructor). > > You don't even need threads: just storing stored items for later > consumption breaks your simple use case. > That's another pattern. The scaleable resource. In the simplest case, we have an array where we do no have a tight bound on maximum size on function entry, so we need to expand with realloc. Also, the expansion has to be done in a subroutine. But it's the same essential idea. Top level calls malloc() to create the array with the initial entries, often zero ora single seed . It then attaches it to a structure which it passes down to the subroutines, which call realloc() if they need to add new entries. Then top level destroys the array or passes it back to to its own caller. The only difference is that you need to allow any subroutine that makes a call to realloc() to return an error value of out of memory. Then the call chain all jumps to it out_of_memory label, and the error is passed back up until a very high level function, usually, decides what to do. Baby X makes extensive use of the dynamic graph paradigm, so to simplify and avoid having to pass an error condition up to every function, which caller isn't going to be able to handle sensibly anyway, Baby X functions call bbx_malloc(), which is guaranteed to never return null. (It asks the user to shut down other applications if memory allocation fails, or gives him an option to abort).
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-03 08:35 +1300 |
| Message-ID | <e5d5rnFf4dbU1@mid.individual.net> |
| In reply to | #94396 |
On 10/ 2/16 11:37 PM, Malcolm McLean wrote: > On Sunday, October 2, 2016 at 8:38:15 AM UTC+1, Ian Collins wrote: >> On 10/ 2/16 02:15 AM, Malcolm McLean wrote: >> >>> The trick is to use structured programming. Each "block" (which is >>> similar to but not identical to a C curly braces block") has one >>> point of entry and one point of exit. So creation and destruction >>> are matched. A block either destroys all the resources it holds >>> on exit, or passes them up to caller. If it passes them up to caller, >>> it must be matched by a "destructor" function, which caller must >>> call on his own exit (or pass them up to super-caller, and provide >>> a destructor of his own, which then calls the destructor). >> >> You don't even need threads: just storing stored items for later >> consumption breaks your simple use case. >> > That's another pattern. > > The scaleable resource. In the simplest case, we have an array where we > do no have a tight bound on maximum size on function entry, so we need > to expand with realloc. Also, the expansion has to be done in a subroutine. So you see the pattern of more and more complexity creeping into the application code? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-02 15:17 -0700 |
| Message-ID | <5def853b-2418-4f89-a7ad-3ea77b66b654@googlegroups.com> |
| In reply to | #94403 |
On Sunday, October 2, 2016 at 8:35:27 PM UTC+1, Ian Collins wrote: > > So you see the pattern of more and more complexity creeping into the > application code? > Not really. A complex parser is always a bit of a special case. With the Lisp interpreter, we need to write a structured program to emulate and run an unstructured program (in the sense of being written using a different paradigm, not unstructured in the sense of being "bad"). So of course you have to have the non-structure somewhere, and that is in the pattern of Lisp node linking by which each child is allowed several parents, and even circular structures. We have to have that mess of a graph somewhere and in some form. So we put it in its own private Lisp hell. All the nodes, for efficiency, will be allocated from an unbounded but expected to be small list of large pools, over which we run a block allocator. So we destroy the lot easily and ,assuming the block allocator is stable and debugged, we can't have any memory leaks. The Lispy chaos can't get out into our nice structured imperative C program. Internally we'll need a reference count or a garbage collection pass to allow Lisp to do its stuff. But if we get it wrong, all that means is that Lisp eventually runs out of memory. And we can trivially give it a memory budget. The system is robust.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-03 18:29 +1300 |
| Message-ID | <e5e8kuFq0riU1@mid.individual.net> |
| In reply to | #94404 |
On 10/ 3/16 11:17 AM, Malcolm McLean wrote: > On Sunday, October 2, 2016 at 8:35:27 PM UTC+1, Ian Collins wrote: >> >> So you see the pattern of more and more complexity creeping into the >> application code? >> > Not really. So you don't see each of your solutions becoming steadily more complex? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-03 01:09 -0700 |
| Message-ID | <47b562a1-78e4-4c20-86e5-e980954ab436@googlegroups.com> |
| In reply to | #94408 |
On Monday, October 3, 2016 at 6:29:10 AM UTC+1, Ian Collins wrote: > On 10/ 3/16 11:17 AM, Malcolm McLean wrote: > > On Sunday, October 2, 2016 at 8:35:27 PM UTC+1, Ian Collins wrote: > >> > >> So you see the pattern of more and more complexity creeping into the > >> application code? > >> > > Not really. > > So you don't see each of your solutions becoming steadily more complex? > Not really. Graphs always were a special case, in a sense. The data is still "passed up", but the process is not as trivial as returning a pointer or filling a double pointer. Instead the new item is inserted into the structure that is passed down from caller, and it's not always a totally simple matter to keep the structure coherent. Structured programs like trees, and most graphs are trees, or at least primarily trees with maybe a few secondary links. So they can be destroyed easily. Where the graph isn't a tree, and doesn't have a regular structure, then the question becomes how to ensure you can destroy it. Often the answer is that you need to maintain a list of nodes somewhere. If you use a block allocator, that comes for free, and also the block allocations will be more efficient than calls to malloc(), at least in most malloc() implementations. So that usually makes sense. So the problems aren't real. But obviously if we demand that a structured program shall emulate an arbitrary unstructured program, then the unstructured program must be represented somewhere and somehow.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-04 08:21 +1300 |
| Message-ID | <e5fpdnF716rU1@mid.individual.net> |
| In reply to | #94409 |
On 10/ 3/16 09:09 PM, Malcolm McLean wrote: > On Monday, October 3, 2016 at 6:29:10 AM UTC+1, Ian Collins wrote: >> On 10/ 3/16 11:17 AM, Malcolm McLean wrote: >>> On Sunday, October 2, 2016 at 8:35:27 PM UTC+1, Ian Collins wrote: >>>> >>>> So you see the pattern of more and more complexity creeping into the >>>> application code? >>>> >>> Not really. >> >> So you don't see each of your solutions becoming steadily more complex? >> > Not really. Are you serious? You started out with a set of simplistic rules for a trivial use case that broke down as soon as they encountered a more realistic problem. You have then added yet more special case solutions. Do you not see how much easier such code is to write with automated resource management? RAII allows the programmer (and the reader) to focus on the higher level aspects of a solution without having to worry about the trivia associated with resource management. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-03 13:12 -0700 |
| Message-ID | <6f007f5a-7bc1-48d8-aa2b-549fa09e583c@googlegroups.com> |
| In reply to | #94429 |
On Monday, October 3, 2016 at 8:21:39 PM UTC+1, Ian Collins wrote: > On 10/ 3/16 09:09 PM, Malcolm McLean wrote: > > Do you not see how much easier such code is to write with automated > resource management? RAII allows the programmer (and the reader) to > focus on the higher level aspects of a solution without having to worry > about the trivia associated with resource management. > RAII is exactly the same as the system proposed by me, with the exception that code is executed without an explicit trace in the source. It also creates difficulties if we wish to call constructor a if a flag is set, constructor b if it is clear, but otherwise execute the same code. It's just a less clear way of achieving the same thing. The special cases aren't really special cases. The creator of a resource either destroys it or passes it up. If all he does is create an intialise the resource, the natural way to pass back up is by returning a pointer. But if we pass a double pointer which he then fills, we are not changing anything significant. So what if he returns two resources? Pass two double pointers, again not a big change. Or pass a structure pointer with two fields to fill in. Again not a big change. However if we then generalise the structure pointer to "any graph", there is admittedly a bit of a change. the graph must be kept coherent. So if it is a linked list, the new node must not orphan any following nodes. If you further insist that the graph shall not have a root and may have any topology, it starts getting difficult. But that's a fairly rare requirement, and you can still satisfy with only a bit of difficulty, by maintaining a list of nodes somewhere. So we don't need any complex language features. All we need is the two simple rules, either match constructor and destructor, or pass up and allow caller to call the destructor, and of course each block has one point of entry and two points of exit, the normal exit and the error exit.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-03 14:34 -0700 |
| Message-ID | <14aa2ff2-32cd-4261-bba7-102426072c67@googlegroups.com> |
| In reply to | #94430 |
On Monday, October 3, 2016 at 3:12:12 PM UTC-5, Malcolm McLean wrote:
> The special cases aren't really special cases. The creator of a
> resource either destroys it or passes it up. If all he does is
> create an intialise the resource, the natural way to pass back up
> is by returning a pointer. But if we pass a double pointer which
> he then fills, we are not changing anything significant.
Unfortunately, there is no type in Standard C that can serve as a "pointer
to a pointer to a structure of arbitrary type". In the days prior to
aggressive type-based aliasing, many implementations would allow a void**
to be used--with suitable typecasts--for such a purpose, but Standard C
does not provide any reasonable equivalent. While a pattern like:
myResource *rsrc;
actionIndirectlyCreatingResource(&rsrc, procToCreateResource);
is better than
myResource *rsrc;
rsrc = actionIndirectlyCreatingResource(procToCreateResource);
at handling situations where the function might fail after the resource is
created (if the action that creates the resource populates the pointer when
the resource reaches a state requiring cleanup, outer code will be able to
tell which things need cleanup even if an intermediate-level function fails).
Unfortunately, while the latter pattern works just fine even if the action
creating the resource doesn't know what type it is (the outer function can
simply return a void*) the former pattern would require either that the
client code use type void* to hold pointers to objects whose type the client
code knows, or that the client code create a temporary void*, copy its pointer
to that, pass the address of the temporary, and then copy the void* back to
its real pointer (which would cause the resource to be lost if something
fails and causes a longjmp() after the resource has been created).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-04 00:47 -0700 |
| Message-ID | <7a677866-03e9-4303-aadc-56c34cbebe9f@googlegroups.com> |
| In reply to | #94431 |
On Monday, October 3, 2016 at 10:35:33 PM UTC+1, supe...@casperkitty.com wrote: > On Monday, October 3, 2016 at 3:12:12 PM UTC-5, Malcolm McLean wrote: > > The special cases aren't really special cases. The creator of a > > resource either destroys it or passes it up. If all he does is > > create an intialise the resource, the natural way to pass back up > > is by returning a pointer. But if we pass a double pointer which > > he then fills, we are not changing anything significant. > > Unfortunately, there is no type in Standard C that can serve as a "pointer > to a pointer to a structure of arbitrary type". In the days prior to > aggressive type-based aliasing, many implementations would allow a void** > to be used--with suitable typecasts--for such a purpose, but Standard C > does not provide any reasonable equivalent. While a pattern like: > > myResource *rsrc; > actionIndirectlyCreatingResource(&rsrc, procToCreateResource); > > is better than > > myResource *rsrc; > rsrc = actionIndirectlyCreatingResource(procToCreateResource); > > at handling situations where the function might fail after the resource > is created (if the action that creates the resource populates the > pointer when the resource reaches a state requiring cleanup, outer > code will be able to tell which things need cleanup even if an > intermediate-level function fails). > Unfortunately, while the latter pattern works just fine even if the > action creating the resource doesn't know what type it is (the outer > function can simply return a void*) the former pattern would require > either that the client code use type void* to hold pointers to > objects whose type the client code knows, or that the client code > create a temporary void*, copy its pointer to that, pass the address > of the temporary, and then copy the void* back to its real pointer > (which would cause the resource to be lost if something > fails and causes a longjmp() after the resource has been created). > Function pointers, or to be more accurate, dynamic binding destroys the structure of structured programs and makes life a lot more difficult. We can have a void **, but it always must point to a void, so no-one can use it unless he knows how to match with the original type. And as you say, if something fails, that has to be the out_of_memory handler as well as the regular code.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-10-04 07:49 +0000 |
| Message-ID | <slrn3vfsnv6no3.9nk.ike@iceland.freeshell.org> |
| In reply to | #94431 |
On 2016-10-03, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> Unfortunately, there is no type in Standard C that can serve as a "pointer
> to a pointer to a structure of arbitrary type".
How about void* ?
/* <code> */
#include <assert.h>
struct S0 {double d;};
struct S1 {double d;};
int main(void)
{
struct S0 {double d;} s0, *ps0 = &s0, **pps0 = &ps0;
struct S1 {double d;} s1, *ps1 = &s1, **pps1 = &ps1;
void *v = pps0; /* v serves as pointer to pointer to struct S0 */
struct S0 **cpps0 = v;
assert(cpps0 == pps0);
v = pps1; /* v serves as pointer to pointer to struct S1 */
struct S1 **cpps1 = v;
assert(cpps1 == pps1);
return 0;
}
/* </code> */
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-04 07:50 -0700 |
| Message-ID | <60102d22-def5-4211-8e24-40f928edd318@googlegroups.com> |
| In reply to | #94438 |
On Tuesday, October 4, 2016 at 2:49:36 AM UTC-5, Ike Naar wrote: > On 2016-10-03, supercat wrote: > > Unfortunately, there is no type in Standard C that can serve as a "pointer > > to a pointer to a structure of arbitrary type". > > How about void* ? That is a possible kludge, which I mentioned, but that requires that the pointer type be cast or coerced to the type of the target object everywhere it's used, and throws any concept of useful type safety out the window. If a memory management library needs to work with a pointer in type-agnostic fashion but everything else that uses the pointer will use it as a struct S1*, it would make a lot more sense to allow the owners of a pointer to hold it as a struct S1* but let the memory-management library manipulate it with a pointer-to-pointer-to-arbitrary-structure-type. Such an ability was widely supported prior to C89, and there should have been no difficulty defining a syntax to explicitly support it, but unfortunately those who recognized the need for such ability expected compilers to support the existing pattern, so no new syntax was necessary, while those who didn't recognize the need for such ability weren't interested in a syntax for it either, so the net effect is that an ability which made the C language useful prior to C89 got silently yanked from the language with no decent replacement.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-04 08:57 -0700 |
| Message-ID | <lnd1jgqf7w.fsf@kst-u.example.com> |
| In reply to | #94444 |
supercat@casperkitty.com writes:
> On Tuesday, October 4, 2016 at 2:49:36 AM UTC-5, Ike Naar wrote:
>> On 2016-10-03, supercat wrote:
>> > Unfortunately, there is no type in Standard C that can serve as a
>> > "pointer to a pointer to a structure of arbitrary type".
>>
>> How about void* ?
>
> That is a possible kludge, which I mentioned, but that requires that
> the pointer type be cast or coerced to the type of the target object
> everywhere it's used, and throws any concept of useful type safety out
> the window.
[snip]
>
> Such an ability was widely supported prior to C89, and there should
> have been no difficulty defining a syntax to explicitly support it,
> but unfortunately those who recognized the need for such ability
> expected compilers to support the existing pattern, so no new syntax
> was necessary, while those who didn't recognize the need for such
> ability weren't interested in a syntax for it either, so the net
> effect is that an ability which made the C language useful prior to
> C89 got silently yanked from the language with no decent replacement.
So pre-ANSI C supported a "pointer to a pointer to a structure of
arbitrary type" *in a type-safe manner*?
C has void* as a generic pointer type. In pre-ANSI C, char* could be
used similarly (though I don't know what explicit guarantees were
offered). I'm not sure what you think has been lost.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-04 10:42 -0700 |
| Message-ID | <97635416-afbc-49d8-8296-2a8e77aea7f7@googlegroups.com> |
| In reply to | #94445 |
On Tuesday, October 4, 2016 at 10:57:45 AM UTC-5, Keith Thompson wrote: > supercat writes: > So pre-ANSI C supported a "pointer to a pointer to a structure of > arbitrary type" *in a type-safe manner*? It allowed a pointer that was type-safe *with regard to code that cared about its type*, to be manipulated, in reliable but non-type-safe fashion, by code that was agnostic to its type. If 95+% of the code that uses a pointer uses it as a "struct S*", and the only code that doesn't merely wants to use it as a "pointer to some kind of object", I would think it should make more sense to have the declared type of the pointer be a "struct S*" than "void*", and use typecasts in the <5% of code that uses it as a "pointer to some kind of object", than to make the type of the pointer be "void*" and require typecasts throughout the 95%+ of the code where it is used as a "pointer to struct S". It may not be possible to have the code be 100% typesafe everywhere, but having 95+% of the code be typesafe would seem better than having only a tiny fraction of it be typesafe. All a compiler would have to do to make such a pattern work is refrain from caching pointers to structures across code which casts such pointers to void** and might then dereference them. Restricting optimizations in those places will allow programmers to use more specific pointer types elsewhere in code, which will in turn allow compilers more optimization opportunities throughout the remainder of the code than they would have if programmers used void* everywhere. > C has void* as a generic pointer type. In pre-ANSI C, char* could be > used similarly (though I don't know what explicit guarantees were > offered). I'm not sure what you think has been lost. What has been lost is the ability of code to manipulate pointers stored in memory in type-agnostic fashion. One of the reasons "qsort" is slower than C++ sort routines is that even if given something nice like an array of pointers, it can't just load and store pointers to swap them but must instead use the equivalent of memcpy. A routine that was specialized for "sequentially-stored collection of pointer to something" could be made much faster, and one for pointers to structures with some known fields containing the sort key, but which could have other information beyond, could be faster yet, but that would require that the collection of pointers be stored as type void* or as a pointer to the header type, rather than as a collection of pointers to the actual data type.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-05 15:47 +1300 |
| Message-ID | <e5j7trF14chU1@mid.individual.net> |
| In reply to | #94430 |
On 10/ 4/16 09:12 AM, Malcolm McLean wrote: > On Monday, October 3, 2016 at 8:21:39 PM UTC+1, Ian Collins wrote: >> On 10/ 3/16 09:09 PM, Malcolm McLean wrote: >> >> Do you not see how much easier such code is to write with automated >> resource management? RAII allows the programmer (and the reader) to >> focus on the higher level aspects of a solution without having to worry >> about the trivia associated with resource management. >> > RAII is exactly the same as the system proposed by me, with the > exception that code is executed without an explicit trace in the > source. No it isn't. RAII exploits automatic creation and destruction of objects used to manage resources. See https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization > The special cases aren't really special cases. The creator of a > resource either destroys it or passes it up. Passes up to whom? What if the resource goes into a pool with multiple consumers? What if some of the consumers persist references to the resource? What if... Even in the simple case, the lifetime management is manual and therefore prone to error. To mitigate the risk, clean release of the resource will have to be tested everywhere it may be released, yet another burden on the developer. > So we don't need any complex language features. No, but to make our code safe and simple we need a simple one: automatic objects destruction. > All we need is > the two simple rules, either match constructor and destructor, > or pass up and allow caller to call the destructor, and of course > each block has one point of entry and two points of exit, the > normal exit and the error exit. Rules fall apart as soon as they hit the real world... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-04 20:58 -0700 |
| Message-ID | <d5c247b4-0744-4c77-a03d-9ee3e8e7708c@googlegroups.com> |
| In reply to | #94465 |
On Wednesday, October 5, 2016 at 3:47:32 AM UTC+1, Ian Collins wrote:
> On 10/ 4/16 09:12 AM, Malcolm McLean wrote:
> > On Monday, October 3, 2016 at 8:21:39 PM UTC+1, Ian Collins wrote:
> >> On 10/ 3/16 09:09 PM, Malcolm McLean wrote:
> >>
> >> Do you not see how much easier such code is to write with automated
> >> resource management? RAII allows the programmer (and the reader) to
> >> focus on the higher level aspects of a solution without having to worry
> >> about the trivia associated with resource management.
> >>
> > RAII is exactly the same as the system proposed by me, with the
> > exception that code is executed without an explicit trace in the
> > source.
>
> No it isn't. RAII exploits automatic creation and destruction of
> objects used to manage resources. See
>
> https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
>
C++ makes null objects problematic, and declaring an object and
creating it are the same thing, because of the constructor syntax.
It also hides the fact that a destructor is called, and instead
of jumping to an out_of_memory label, it has machinery for exceptions.
C doesn't have a problem with null pointers, at cost of not being
able to toggle between stack and heap as easily as C++, and you
have to implement exception handling yourself. However you know it
is an exception because the pattern implements it as a goto within
a structured program.
>
> > The special cases aren't really special cases. The creator of a
> > resource either destroys it or passes it up.
>
> Passes up to whom? What if the resource goes into a pool with multiple
> consumers? What if some of the consumers persist references to the
> resource? What if...
>
Caller. A structured program is a tree, and there is only one chain
back to the root (main) from any current position. If a consumer
"persists a reference to a resource" we have created a graph, which
should be held by the level which destroys it. Consumers can't
persist, they must return to caller, so if they create a link between
something they create and an object passed them by caller, there
are only two options, either the consumer destroys the object
(and so the link disappears), or the consumer returns the object to
caller, in which case caller now holds two objects linked to each
other, in other words, he holds a graph.
Graphs have to be kept coherent. But whilst that is linked to
memory management, its a broader problem. You can almost say that
coherent graphs and bug-free programs are one and the same thing.
>
> Even in the simple case, the lifetime management is manual and therefore
> prone to error. To mitigate the risk, clean release of the resource
> will have to be tested everywhere it may be released, yet another burden
> on the developer.
>
You can have errors, of course. However automatic systems create
less tractable errors. There was an interesting talk on C++ by
Herb Sutter (I think) which described how what looks like a solid
reference in C++ can in fact be deleted. I forget the details, it
was subtle and unexpected, and something to do with exceptions I
beleive. Automatic systems work well until they fail, then they are
harder to fix than simpler systems.
Valgrind will pick up if memory is not freed.
>
> > So we don't need any complex language features.
>
> No, but to make our code safe and simple we need a simple one: automatic
> objects destruction.
>
It can be a trap.
Consider this
template<T> struct node
{
std::unique_ptr<node> child;
std::unique_ptr<node> next;
T Data;
}
See the danger here? Can you spot it? Hint, we've got a relatively
shallow hierarchy with only a few levels, and lots of nodes.
>
> > All we need is
> > the two simple rules, either match constructor and destructor,
> > or pass up and allow caller to call the destructor, and of course
> > each block has one point of entry and two points of exit, the
> > normal exit and the error exit.
>
> Rules fall apart as soon as they hit the real world...
>
This system doesn't. It works.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-05 18:14 +1300 |
| Message-ID | <e5jgh2F38jcU1@mid.individual.net> |
| In reply to | #94467 |
On 10/ 5/16 04:58 PM, Malcolm McLean wrote:
> On Wednesday, October 5, 2016 at 3:47:32 AM UTC+1, Ian Collins wrote:
>> On 10/ 4/16 09:12 AM, Malcolm McLean wrote:
>>> On Monday, October 3, 2016 at 8:21:39 PM UTC+1, Ian Collins wrote:
>>>> On 10/ 3/16 09:09 PM, Malcolm McLean wrote:
>>>>
>>>> Do you not see how much easier such code is to write with automated
>>>> resource management? RAII allows the programmer (and the reader) to
>>>> focus on the higher level aspects of a solution without having to worry
>>>> about the trivia associated with resource management.
>>>>
>>> RAII is exactly the same as the system proposed by me, with the
>>> exception that code is executed without an explicit trace in the
>>> source.
>>
>> No it isn't. RAII exploits automatic creation and destruction of
>> objects used to manage resources. See
>>
>> https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
>>
> C++ makes null objects problematic, and declaring an object and
> creating it are the same thing, because of the constructor syntax.
Neither of which have ever case me any problems. If a default or null
state for an object makes sense, use a default constructor. If it
doesn't make sense, delete the default constructor. Either way, you
know the object is in a valid state.
> It also hides the fact that a destructor is called, and instead
> of jumping to an out_of_memory label, it has machinery for exceptions.
Which is a big bonus: no more goto!
> C doesn't have a problem with null pointers, at cost of not being
> able to toggle between stack and heap as easily as C++, and you
> have to implement exception handling yourself. However you know it
> is an exception because the pattern implements it as a goto within
> a structured program.
If I could parse that, I'd reply... Exception handling without stack
unwinding is a disaster that has already happened, which is why no
workable scheme for C has ever taken off.
>>> The special cases aren't really special cases. The creator of a
>>> resource either destroys it or passes it up.
>>
>> Passes up to whom? What if the resource goes into a pool with multiple
>> consumers? What if some of the consumers persist references to the
>> resource? What if...
>>
> Caller. A structured program is a tree, and there is only one chain
> back to the root (main) from any current position. If a consumer
> "persists a reference to a resource" we have created a graph, which
> should be held by the level which destroys it. Consumers can't
> persist, they must return to caller, so if they create a link between
> something they create and an object passed them by caller, there
> are only two options, either the consumer destroys the object
> (and so the link disappears), or the consumer returns the object to
> caller, in which case caller now holds two objects linked to each
> other, in other words, he holds a graph.
So how would you describe the situation where objects are placed on a
queue and processed by other threads?
> Graphs have to be kept coherent. But whilst that is linked to
> memory management, its a broader problem. You can almost say that
> coherent graphs and bug-free programs are one and the same thing.
Memory isn't the only resource!
>> Even in the simple case, the lifetime management is manual and therefore
>> prone to error. To mitigate the risk, clean release of the resource
>> will have to be tested everywhere it may be released, yet another burden
>> on the developer.
>>
> You can have errors, of course. However automatic systems create
> less tractable errors.
But you only have to test them once and any error only has to be fixed
once, not everywhere the code is used.
> Valgrind will pick up if memory is not freed.
Memory isn't the only resource!
>>> So we don't need any complex language features.
>>
>> No, but to make our code safe and simple we need a simple one: automatic
>> objects destruction.
>>
> It can be a trap.
> Consider this
>
> template<T> struct node
> {
> std::unique_ptr<node> child;
> std::unique_ptr<node> next;
> T Data;
> }
>
> See the danger here? Can you spot it? Hint, we've got a relatively
> shallow hierarchy with only a few levels, and lots of nodes.
You wouldn't use std::unique_ptr in a case such as this.
>>> All we need is
>>> the two simple rules, either match constructor and destructor,
>>> or pass up and allow caller to call the destructor, and of course
>>> each block has one point of entry and two points of exit, the
>>> normal exit and the error exit.
>>
>> Rules fall apart as soon as they hit the real world...
>>
> This system doesn't. It works.
Until you forget to free something.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-05 02:15 -0700 |
| Message-ID | <d7dd228d-0643-491b-b235-77b73efc671b@googlegroups.com> |
| In reply to | #94468 |
On Wednesday, October 5, 2016 at 6:14:21 AM UTC+1, Ian Collins wrote:
> On 10/ 5/16 04:58 PM, Malcolm McLean wrote:
> > On Wednesday, October 5, 2016 at 3:47:32 AM UTC+1, Ian Collins wrote:
>
> > C++ makes null objects problematic, and declaring an object and
> > creating it are the same thing, because of the constructor syntax.
>
> Neither of which have ever case me any problems. If a default or null
> state for an object makes sense, use a default constructor. If it
> doesn't make sense, delete the default constructor. Either way, you
> know the object is in a valid state.
>
> > It also hides the fact that a destructor is called, and instead
> > of jumping to an out_of_memory label, it has machinery for exceptions.
>
> Which is a big bonus: no more goto!
>
You've hidden the goto. How do you think a C++ to C compiler implements
throw?
>
> > C doesn't have a problem with null pointers, at cost of not being
> > able to toggle between stack and heap as easily as C++, and you
> > have to implement exception handling yourself. However you know it
> > is an exception because the pattern implements it as a goto within
> > a structured program.
>
> If I could parse that, I'd reply... Exception handling without stack
> unwinding is a disaster that has already happened, which is why no
> workable scheme for C has ever taken off.
>
This is a scheme which does that. It relies on the fact that every object
in scope is either destructible or null, and it places the burden on the
programmer to ensure that. But that's where it belongs.
>
> So how would you describe the situation where objects are placed on a
> queue and processed by other threads?
>
The queue is a graph which is owned by the supervisor or main thread,
and everyone keeps it coherent. Which in practice probably means we have
to to have tight restrictions on the data the queue might hold. Making
sure the objects within the queue are destructible is part of that.
>
> > Graphs have to be kept coherent. But whilst that is linked to
> > memory management, its a broader problem. You can almost say that
> > coherent graphs and bug-free programs are one and the same thing.
>
> Memory isn't the only resource!
>
For a so-called "Malcolm function", memory is the only resource. Part of good
design involves separating the Malcolm-functions from the Malcolm-procedures.
Malcolm functions only shuffle about bits within the computer's memory,
they may not operate on IO devices or other hardware like thread control
instructions.
But memory isn't really special in this sense. Malcolm-procedures may hold
open files or other resources which are not memory.
>
> > You can have errors, of course. However automatic systems create
> > less tractable errors.
>
> But you only have to test them once and any error only has to be fixed
> once, not everywhere the code is used.
>
A function in a structured program has no dynamic binding. It takes a pattern
of bits, and returns another pattern of bits, or it is part of a constructor /
destructor pair. As long as it works on one platform and passes valgrind, and
it has been tested on enough inputs to cover all execution paths (that can be
difficult of course), then it should work anywhere.
>
> > It can be a trap.
> > Consider this
> >
> > template<T> struct node
> > {
> > std::unique_ptr<node> child;
> > std::unique_ptr<node> next;
> > T Data;
> > }
> >
> > See the danger here? Can you spot it? Hint, we've got a relatively
> > shallow hierarchy with only a few levels, and lots of nodes.
>
> You wouldn't use std::unique_ptr in a case such as this.
>
So we've sensibly rejected the automatic RAII approach.
>
> > This system doesn't. It works.
>
> Until you forget to free something.
>
You can have a bug. I'm not claiming that this is a magic bullet that eliminates
all bugs. But if you follow the pattern consistently, you have no variables other
than at function scope, and you've got what is probably a simple list of
destructor calls in the out_of_memory label. So it's relatively easy to see if
a destructor call has been missed.
Secondly, keeping graphs coherent is an important part of making programs
correct. The nice thing about manual destructors is that they usually pick
up quite quickly when a graph is not coherent. If a tree contains a cycle or
a shared branch, and that is not allowed, the manual destructor will likely
fail and alert the problem early, automatic methods have no way of knowing
whether such structures are permitted or not. If a branch is accidentally
orphaned, garbage collection will often destroy it, a manual destructor must
fail valgrind. It's a system or early detection of bugs.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web