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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-05 22:44 +1300 |
| Message-ID | <e5k0cgF6qd1U1@mid.individual.net> |
| In reply to | #94469 |
On 10/ 5/16 10:15 PM, Malcolm McLean wrote: > 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? That is irrelevant. It is not how a native C++ 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. That is the point on which we disagree. Let the language take care of the trivia and leave the programmer to deal with the higher level problems. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-05 03:12 -0700 |
| Message-ID | <c0e0063a-f799-405d-8d5b-3022342d6f8c@googlegroups.com> |
| In reply to | #94471 |
On Wednesday, October 5, 2016 at 10:44:57 AM UTC+1, Ian Collins wrote: > On 10/ 5/16 10:15 PM, Malcolm McLean wrote: > > > You've hidden the goto. How do you think a C++ to C compiler implements > > throw? > > That is irrelevant. It is not how a native C++ implements throw. > "throw" is essentially C++'s way of implementing a chain of out_of_memory handlers. It hides it from the user, that's all. And to be fair, it means that as long as destructors are set up correctly, you don't have to ensure that they are called. But it's not doing anything different. And a C++ to C compiler will generate code along the lines of. In my system, "catch" is, "if out of memory, don't jump to your own out_of_memory handler, instead do something different. > > > 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. > > That is the point on which we disagree. Let the language take care of > the trivia and leave the programmer to deal with the higher level problems. > Yes, this is something on which there isn't ever a right answer. If you do everything manually programming becomes too tedious. But what many people don't recognise is that automatic systems lack flexibility, and can go wrong in subtle ways that cause serious bugs, which are difficult to find because there's no single line of code which is "the bug", and often programmers don't understand how the automatic system is implemented so they lose the skills to track down the errors. But if you set up a graph with lots of links, you should keep that under control. You should know where the links are, and which are primary "owning" links and which are secondary (or if in fact we can't have a concept of "owning" links because the graph is too dynamic). Relying on garbage collection or RAII with destructors to do the job for you is a trap.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-06 15:38 +1300 |
| Message-ID | <e5lrp7Fki0fU3@mid.individual.net> |
| In reply to | #94474 |
On 10/ 5/16 11:12 PM, Malcolm McLean wrote: > On Wednesday, October 5, 2016 at 10:44:57 AM UTC+1, Ian Collins wrote: >> On 10/ 5/16 10:15 PM, Malcolm McLean wrote: >> >>> You've hidden the goto. How do you think a C++ to C compiler implements >>> throw? >> >> That is irrelevant. It is not how a native C++ implements throw. >> > "throw" is essentially C++'s way of implementing a chain of out_of_memory > handlers. No, it isn't. It is a much more generic method for handling error conditions. > It hides it from the user, that's all. And to be fair, it means that as > long as destructors are set up correctly, you don't have to ensure that they are > called. But it's not doing anything different. You alluded to the most significant difference - the compiler does the donkey work for you and unlike us, compilers don't forget and don't get bored with tedium. > And a C++ to C compiler will generate > code along the lines of. ? > In my system, "catch" is, "if out of memory, don't jump to your own out_of_memory > handler, instead do something different. Er, no.. >>> 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. >> >> That is the point on which we disagree. Let the language take care of >> the trivia and leave the programmer to deal with the higher level problems. >> > Yes, this is something on which there isn't ever a right answer. If you do everything > manually programming becomes too tedious. But what many people don't recognise > is that automatic systems lack flexibility, and can go wrong in subtle ways that > cause serious bugs, which are difficult to find because there's no single line of > code which is "the bug", and often programmers don't understand how the automatic > system is implemented so they lose the skills to track down the errors. That's no reason to shun automation, otherwise we'd still all be weaving our own clothes! > But if you set up a graph with lots of links, you should keep that under control. You > should know where the links are, and which are primary "owning" links and which > are secondary (or if in fact we can't have a concept of "owning" links because the > graph is too dynamic). Relying on garbage collection or RAII with destructors to > do the job for you is a trap. No, it's progress. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-05 19:50 -0700 |
| Message-ID | <2167a3c4-da6c-47f4-8169-5b6cc102036f@googlegroups.com> |
| In reply to | #94513 |
On Thursday, October 6, 2016 at 3:38:40 AM UTC+1, Ian Collins wrote: > On 10/ 5/16 11:12 PM, Malcolm McLean wrote: > > > "throw" is essentially C++'s way of implementing a chain of > > out_of_memory handlers. > > No, it isn't. It is a much more generic method for handling error > conditions. > But based on a fundamental misunderstanding. A Malcolm-function can fail because it runs out of memory. For no other reason. The only other failure modes are programming errors. In which case there can be no correct behaviour because the program itself is incorrect. C++ exceptions gloss over that fact. They encourage poor reasoning about code correctness and robustness. To use them for anything other that aborting Malcolm-functions on out of memory is to drive a coach and horses through structured programming. You can also have IO errors, which occur in Malcolm-procedures.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-06 16:25 +1300 |
| Message-ID | <e5luhcFkjf8U2@mid.individual.net> |
| In reply to | #94516 |
On 10/ 6/16 03:50 PM, Malcolm McLean wrote: > On Thursday, October 6, 2016 at 3:38:40 AM UTC+1, Ian Collins wrote: >> On 10/ 5/16 11:12 PM, Malcolm McLean wrote: >> >>> "throw" is essentially C++'s way of implementing a chain of >>> out_of_memory handlers. >> >> No, it isn't. It is a much more generic method for handling error >> conditions. >> > But based on a fundamental misunderstanding. > > A Malcolm-function can fail because it runs out of memory. For no > other reason. The only other failure modes are programming errors. > In which case there can be no correct behaviour because the program > itself is incorrect. Unlike real functions which can fail for many reasons do to the imperfections present in the rest of the world. > C++ exceptions gloss over that fact. They encourage poor reasoning > about code correctness and robustness. To use them for anything other > that aborting Malcolm-functions on out of memory is to drive a coach > and horses through structured programming. You can also have IO errors, > which occur in Malcolm-procedures. You can have many sources of error in Ian functions... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-05 21:19 -0700 |
| Message-ID | <31cf30f6-1b7a-4a27-bc79-44866f8473e5@googlegroups.com> |
| In reply to | #94519 |
On Thursday, October 6, 2016 at 4:25:41 AM UTC+1, Ian Collins wrote: > On 10/ 6/16 03:50 PM, Malcolm McLean wrote: > > > A Malcolm-function can fail because it runs out of memory. For no > > other reason. The only other failure modes are programming errors. > > In which case there can be no correct behaviour because the program > > itself is incorrect. > > Unlike real functions which can fail for many reasons do to the > imperfections present in the rest of the world. > A Malcolm-function maps a bit state on entry to a bit state on exit (usually we encapsulate them so that the bits we operate on are passed in and passed out, but that's not actually essential to a Malcolm-function, it can be defined to operate on global state). So we've got four possible outcomes. 1) the function operates as specified and bits on function return are arranged as the function specification says they will be arranged. 2) the function has been mis-coded and bits on function return are in a different state to that specified. 3) the function is called with an illegal pattern of bits (we could in theory eliminate this by saying that "on all other inputs the Malcolm-function returns -1", in practice in C you can't because you can't check pointers for validity) 4) the Malcolm-function runs out of memory. Assuming the computer works, there aren't any other possible outcomes. Now 1 is obviously unproblematic and hopefully by far the most common situation. 4 is fundamental feature of Turing machines and, whilst we can eliminate it for many individual Malcolm-functions, it's not something we can just get rid of. So we have special rules to handle this eventuality. 2 is a programming error in the Malcolm function itself, and 3 is a programming error in the function which calls the Malcolm function.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-10-06 18:11 +1300 |
| Message-ID | <e5m4odFmb1oU1@mid.individual.net> |
| In reply to | #94520 |
On 10/ 6/16 05:19 PM, Malcolm McLean wrote: > On Thursday, October 6, 2016 at 4:25:41 AM UTC+1, Ian Collins wrote: >> On 10/ 6/16 03:50 PM, Malcolm McLean wrote: >> >>> A Malcolm-function can fail because it runs out of memory. For no >>> other reason. The only other failure modes are programming errors. >>> In which case there can be no correct behaviour because the program >>> itself is incorrect. >> >> Unlike real functions which can fail for many reasons do to the >> imperfections present in the rest of the world. >> > A Malcolm-function maps a bit state on entry to a bit state on exit > (usually we encapsulate them so that the bits we operate on are > passed in and passed out, but that's not actually essential to a > Malcolm-function, it can be defined to operate on global state). Life would be oh so much easier if most functions were "Malcolm-functions"! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-10-06 06:38 +0100 |
| Message-ID | <87zimi595i.fsf@gmail.com> |
| In reply to | #94521 |
Ian Collins <ian-news@hotmail.com> writes: >> A Malcolm-function maps a bit state on entry to a bit state on exit >> (usually we encapsulate them so that the bits we operate on are >> passed in and passed out, but that's not actually essential to a >> Malcolm-function, it can be defined to operate on global state). > > Life would be oh so much easier if most functions were "Malcolm-functions"! To be honest, I don't know why we have to limit ourselves to Malcolm-functions, that can fail through out-of-memory. I use Pangloss-functions, which simply never fail at all. That makes my reasoning about error handling even more simple than Malcolm's (and only very marginally more wrong-headed.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-06 00:36 -0700 |
| Message-ID | <b83ecb7f-2eb5-44a7-ab6c-719c776e8f17@googlegroups.com> |
| In reply to | #94521 |
On Thursday, October 6, 2016 at 6:11:51 AM UTC+1, Ian Collins wrote: > On 10/ 6/16 05:19 PM, Malcolm McLean wrote: > > On Thursday, October 6, 2016 at 4:25:41 AM UTC+1, Ian Collins wrote: > >> On 10/ 6/16 03:50 PM, Malcolm McLean wrote: > >> > >>> A Malcolm-function can fail because it runs out of memory. For no > >>> other reason. The only other failure modes are programming errors. > >>> In which case there can be no correct behaviour because the program > >>> itself is incorrect. > >> > >> Unlike real functions which can fail for many reasons do to the > >> imperfections present in the rest of the world. > >> > > A Malcolm-function maps a bit state on entry to a bit state on exit > > (usually we encapsulate them so that the bits we operate on are > > passed in and passed out, but that's not actually essential to a > > Malcolm-function, it can be defined to operate on global state). > > Life would be oh so much easier if most functions were "Malcolm- > functions"! > Everything that is a "calculation" can be and almost always should be expressed as a Malcolm-function. But computers also "do things", like put up GUI dialogs or attack you with space invaders. Where it gets murky is with parallel processing.
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2016-10-06 07:33 -0700 |
| Message-ID | <4a66da60-0345-41f3-8f3d-6e9e1243e752@googlegroups.com> |
| In reply to | #94523 |
On Thursday, October 6, 2016 at 8:38:16 AM UTC+1, Malcolm McLean wrote: > Everything that is a "calculation" can be and almost always should > be expressed as a Malcolm-function. struct Matrix mat = generate_singular_matrix(); struct Matrix m2 = inverse(mat); struct Vector y; struct Matrix m = ill_conditioned_matrix(); struct Vector x = solve(m,y); Honestly Malcolm, do you *ever* even try and find counter-examples to your generalisations before posting them as facts?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-06 09:00 -0700 |
| Message-ID | <0ef78ab4-9cbb-465d-98d2-9d4aef7354ba@googlegroups.com> |
| In reply to | #94535 |
On Thursday, October 6, 2016 at 9:34:08 AM UTC-5, gwowen wrote: > Honestly Malcolm, do you *ever* even try and find counter-examples to your generalisations before posting them as facts? I wouldn't consider that much of a counter-example, given that such a function could easily be specified as never throwing exceptions but instead return NaN for every variable that does not have a unique solution. While the comparison semantics of NaN are IMHO poorly-conceived, being able to propagate a record of computational errors without disrupting program flow is a much cleaner approach than having to check for errors at every step or handle exceptions. Unfortunately, the C Standard doesn't allow integer types enough room to behave likewise (supporting 64-bit NaN efficiently on a 32-bit machine would require that all bit patterns with 0x800000000 as the upper 32 bits be considered NaN, but 64-bit signed integer types are only allowed to have at most one "weird" value), since doing so would make many kinds of calculation safer and more efficient. In many cases, what is important is not whether any overflows occurred in a calculation, but whether any overflows may have caused a calculation to yield an incorrect result. If a programmer adds 100 to a value and then subtracts 99, and sets an error flag if any result goes out of bounds, then a compiler would be required to perform all the individual computations. If instead a compiler promised to indicate somehow (whether via NaN or an error flag) that an overflow yielded a possibly-incorrect result, but were not required to report overflows which did not affect correctness, then a compiler could consolidate the two operations into "add 1 and check for overflow". Such an approach would yield nearly all of the benefits of overflow trapping, but at a fraction of the computational cost.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-07 00:32 -0700 |
| Message-ID | <57bbd999-fa67-4fc6-a355-8fb930220cae@googlegroups.com> |
| In reply to | #94537 |
On Thursday, October 6, 2016 at 5:01:08 PM UTC+1, supe...@casperkitty.com wrote: > On Thursday, October 6, 2016 at 9:34:08 AM UTC-5, gwowen wrote: > > Honestly Malcolm, do you *ever* even try and find counter-examples to your generalisations before posting them as facts? > > I wouldn't consider that much of a counter-example, given that such > a function could easily be specified as never throwing exceptions but > instead return NaN for every variable that does not have a unique > solution. > While the comparison semantics of NaN are IMHO poorly-conceived, > being able to propagate a record of computational errors without > disrupting program flow is a much cleaner approach than having to > check for errors at every step or handle exceptions. > > Unfortunately, the C Standard doesn't allow integer types enough room to > behave likewise (supporting 64-bit NaN efficiently on a 32-bit machine > would require that all bit patterns with 0x800000000 as the upper 32 bits > be considered NaN, but 64-bit signed integer types are only allowed to > have at most one "weird" value), since doing so would make many kinds of > calculation safer and more efficient. > Overflow is an issue. Whilst you can check every integer calculation for overflow, it's tedious. However overflow doesn't behave reliably or consistently in C. Thinking about this, the real answer is to say that our data is always real. Most numerical data represents measurements of analogue quanties in the real world (length, weight, time, soundwave pressure, light intensity etc). Where it's not (amounts of money, shoe sizes) we can usually still represent it as a double. For amounts of money, hold the cents as an integer, of course. So what are integers? The answer is that they are graph edges. We special case the graph which is a flat list, and represent it as an array in memory. Integers are then used to represent the edges in that graph. Think of it that way, and the overflow problem disappears.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-10-07 05:05 -0700 |
| Message-ID | <d93f821f-9d5c-48e1-bbc2-bf06c13562dc@googlegroups.com> |
| In reply to | #94547 |
On Friday, October 7, 2016 at 4:32:39 AM UTC-3, Malcolm McLean wrote: ... > Overflow is an issue. Whilst you can check every integer calculation > for overflow, it's tedious. However overflow doesn't behave reliably > or consistently in C. In case someone need, Microsoft has the header <intsafe.h> for this job. https://msdn.microsoft.com/en-us/library/windows/desktop/ff516460(v=vs.85).aspx If I had to use checked integers all the time, I would create a generator where the input is a expression and the output is the code controlling all intermediate operations. This generator could be improved to create optimizations and avoid unnecessary tests.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-07 08:13 -0700 |
| Message-ID | <fd829d0a-9d29-4897-a189-4ce720372ec2@googlegroups.com> |
| In reply to | #94550 |
On Friday, October 7, 2016 at 7:05:40 AM UTC-5, Thiago Adams wrote:
> If I had to use checked integers all the time, I would create a generator where the input is a expression and the output is the code controlling all intermediate operations. This generator could be improved to create optimizations and avoid unnecessary tests.
A compiler with logic to accommodate overflow checking with the semantics I
described (allowing for errors to be arbitrarily reported or not in cases
where an overflow occurs but not in a way that could cause incorrect results)
could generate more efficient code meeting those requirements than would be
possible in general using other means. If one wants to add a group of 1000
int32_t with such semantics, and a platform has an intrinsic
int32_t __safeadd32(int32_t x, int32_t y, int32_t *error);
which sets *error to 1 if an overflow occurs and otherwise leaves it
unaffected, the task might be performed most efficiently on some platforms
via:
int32_t sum=0,error=0;
for (int i=0; i<1000; i++)
sum = __safe_add32(sum, dat[i], &error);
and on other platforms via:
int32_t sum,error;
int64_t sum_temp=0;
for (int i=0; i<1000; i++)
sum_temp += dat[i];
error=(sum_temp < INT_MIN || sum_temp > INT_MAX)
sum = (int)sum_temp;
On some platforms, optimal code for the first would be twice as fast as
optimal code for the second, while on many high-performance platforms the
second would be much more efficient than the first. If the language had a
means of requesting the necessary semantics, a compiler could automatically
choose whichever approach would yield the best results in any particular
situation.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-07 00:20 -0700 |
| Message-ID | <37b0b934-8177-4b10-8f98-05ab8e60981b@googlegroups.com> |
| In reply to | #94535 |
On Thursday, October 6, 2016 at 3:34:08 PM UTC+1, gwowen wrote: > On Thursday, October 6, 2016 at 8:38:16 AM UTC+1, Malcolm McLean wrote: > > > Everything that is a "calculation" can be and almost always should > > be expressed as a Malcolm-function. > > struct Matrix mat = generate_singular_matrix(); > struct Matrix m2 = inverse(mat); > > struct Vector y; > struct Matrix m = ill_conditioned_matrix(); > struct Vector x = solve(m,y); > If if write a function to invert a matrix, generally it's not reasonable to specify that caller shall provide us with an invertible matrix. We return 0 on success or -1 on fail, but "fail" here doesn't mean that the function has failed. Maybe caller wants a singular matrix and so he calls the inverse function to check. So for him, -1 would be success, that's the result he wants. If we rewrite the function to return a bit buffer (just to make the situation obvious) then on entry - a matrix represented somehow, on exit, an unset bit followed by the inverse of the matrix if it is invertible, or a set bit followed by N clear bits if the inverse does not exist (or can't be calculated within numerical precision). So for every possible matrix, there is a set of output bits.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-10-07 17:01 +0100 |
| Message-ID | <87zimgtagq.fsf@gmail.com> |
| In reply to | #94546 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Thursday, October 6, 2016 at 3:34:08 PM UTC+1, gwowen wrote: >> On Thursday, October 6, 2016 at 8:38:16 AM UTC+1, Malcolm McLean wrote: >> >> > Everything that is a "calculation" can be and almost always should >> > be expressed as a Malcolm-function. >> >> struct Matrix mat = generate_singular_matrix(); >> struct Matrix m2 = inverse(mat); >> >> struct Vector y; >> struct Matrix m = ill_conditioned_matrix(); >> struct Vector x = solve(m,y); >> > If if write a function to invert a matrix, generally it's not > reasonable to specify that caller shall provide us with an > invertible matrix. We return 0 on success or -1 on fail, but > "fail" here doesn't mean that the function has failed. The defence rests, your honour.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-10-05 12:45 -0500 |
| Message-ID | <nt3dq0$jr$1@dont-email.me> |
| In reply to | #94471 |
Ian Collins wrote: > On 10/ 5/16 10:15 PM, Malcolm McLean wrote: <snip> > > That is the point on which we disagree. Let the language take care of > the trivia and leave the programmer to deal with the higher level problems. > The problem with "higher level" is that it isn't. Er, it isn't the same thing to everyone. "Higher" isn't purely a scalar; it's more akin to a vector. Possibly a fairly complicated vector. In watching the evolution of Rust, what it seems to do is encode common patterns from 'C' into constructs in the language. So as an activity, programming in Rust is more like buying a box of bespoke parts and assembling them ( not too much more, but more by a nonzero amount ). I'd say 'C' is more like using machine tools, where you make your own parts, then assemble them into a functional whole. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-05 11:12 +0100 |
| Message-ID | <87vax7yuis.fsf@bsb.me.uk> |
| In reply to | #94469 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > 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: <snip> >> > 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? That's not a good argument. Function calls, 'while' loops and 'if' statements also "hide the goto" and are all considered a good idea in part because they do just that. If some construct is bad because it hides a goto, the reason must be specific to that construct. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-10-05 03:15 -0700 |
| Message-ID | <74998db9-9055-48ed-8d39-4bf62e2f3a3d@googlegroups.com> |
| In reply to | #94473 |
On Wednesday, October 5, 2016 at 11:12:20 AM UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > You've hidden the goto. How do you think a C++ to C compiler implements > > throw? > > That's not a good argument. Function calls, 'while' loops and 'if' > statements also "hide the goto" and are all considered a good idea in > part because they do just that. If some construct is bad because it > hides a goto, the reason must be specific to that construct. > ifs and whiles are good idea because they don't allow the goto to jump out of or into a block. Not because the word 'goto" doesn't appear in the source.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-10-05 14:41 +0100 |
| Message-ID | <87k2dmzzez.fsf@bsb.me.uk> |
| In reply to | #94475 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Wednesday, October 5, 2016 at 11:12:20 AM UTC+1, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >> > You've hidden the goto. How do you think a C++ to C compiler implements >> > throw? >> >> That's not a good argument. Function calls, 'while' loops and 'if' >> statements also "hide the goto" and are all considered a good idea in >> part because they do just that. If some construct is bad because it >> hides a goto, the reason must be specific to that construct. >> > ifs and whiles are good idea because they don't allow the goto to jump out > of or into a block. Not because the word 'goto" doesn't appear in the > source. Right. So now I can work out your complaint about exceptions -- they let you "jump out of the block" (though in what most people would consider a relatively well-structured way). Yet you favour a goto which jumps out of the bock. Maybe these are Malcolm-blocks. I seem to remember that was a word you'd redefined from the usual meaning. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web