Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #145830 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2019-08-28 16:11 -0500 |
| Last post | 2019-09-09 01:09 -0700 |
| Articles | 20 on this page of 144 — 32 participants |
Back to article view | Back to comp.lang.c
"“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-28 16:11 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" already5chosen@yahoo.com - 2019-08-28 15:48 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-08-29 00:20 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Les Cargill <lcargill99@comcast.com> - 2019-09-01 17:31 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-29 02:36 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 11:02 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-29 22:21 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 13:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 13:29 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:04 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 23:11 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 10:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 07:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:54 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:07 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-08-29 05:14 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-08-29 15:00 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-08-29 10:39 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Thiago Adams <thiago.adams@gmail.com> - 2019-08-30 04:24 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-08-30 20:52 +0100
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:07 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-03 17:13 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:53 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" gazelle@shell.xmission.com (Kenny McCormack) - 2019-08-29 13:14 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 15:38 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:09 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-04 08:31 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:55 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:38 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:18 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 11:41 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 11:56 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 13:08 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 05:16 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 18:22 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-01 12:20 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-01 15:23 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 22:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-02 00:48 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 06:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 11:12 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 17:52 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-02 18:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 13:05 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 19:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 17:16 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 06:49 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 08:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 08:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 09:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 09:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 10:30 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-03 07:11 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 13:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 15:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-03 17:35 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 17:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 18:51 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:42 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:56 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-06 07:10 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-06 12:32 -0700
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-03 20:33 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:38 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" antispam@math.uni.wroc.pl - 2019-09-03 22:08 +0000
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:41 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:50 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 22:43 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-09-03 11:03 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 22:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Clifford Heath <no.spam@please.net> - 2019-09-04 10:47 +1000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-04 16:56 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-03 05:37 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Hans im Glück <hig68@gmx.at> - 2019-09-03 15:26 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-03 06:54 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 16:08 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-03 07:16 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 19:07 +0200
Re: Exceptions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-04 06:12 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-03 07:14 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-09-05 22:02 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-08-31 13:20 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:45 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 14:08 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 13:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-08-30 05:01 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 15:18 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 14:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:23 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 14:40 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" already5chosen@yahoo.com - 2019-08-30 07:56 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 15:08 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 19:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Anton Shepelev <anton.txt@gmail.com> - 2019-08-31 03:05 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 12:18 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-08-31 10:48 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 11:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-31 17:17 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 16:28 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 00:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-01 15:49 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:12 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" already5chosen@yahoo.com - 2019-09-08 10:23 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-08 20:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" My nuts hurt <cdalten@gmail.com> - 2019-09-09 12:51 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:57 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:42 +0200
Re: "???Rust is the future of systems programming, C is the new Assembly???: Intel principal engineer, Josh Triplett" Juha Nieminen <nospam@thanks.invalid> - 2019-08-30 21:03 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 09:42 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 23:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 06:24 -0500
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-06 13:51 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 22:03 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@hotmail.com> - 2019-09-07 10:57 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-09-07 18:09 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-07 15:32 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 18:39 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-09-04 01:07 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" William Ahern <william@25thandClement.com> - 2019-09-03 20:04 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-04 04:48 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" "Chris M. Thomasson " <chris.m.thomasson.1@gmail.com> - 2019-09-09 01:09 -0700
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-08-30 14:08 +0300 |
| Message-ID | <qkb040$o52$1@dont-email.me> |
| In reply to | #145858 |
On 30.08.2019 11:43, Mel wrote: > On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero >> The non-throw-case takes almost no or no performance. > > That's no true. You have to install handlers evrry time or prepare tbla > for each function at program start... >> Evaluating return-codes is simply a magnitude slower. > > This is especially not true. Your information is out of date for a couple of decades. The current C++ compilers have implemented zero cost exceptions (in the no-throw path) already long time ago.
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 13:37 +0200 |
| Message-ID | <almarsoft.8236667553927252078@news.albasani.net> |
| In reply to | #145863 |
On Fri, 30 Aug 2019 14:08:47 +0300, Paavo Helde <myfirstname@osa.pri.ee> wrote: > On 30.08.2019 11:43, Mel wrote: > > On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero > >> The non-throw-case takes almost no or no performance. > > > > That's no true. You have to install handlers evrry time or prepare tbla > > for each function at program start... > >> Evaluating return-codes is simply a magnitude slower. > > > > This is especially not true. > Your information is out of date for a couple of decades. The current C++ > compilers have implemented zero cost exceptions (in the no-throw path) > already long time ago. That's simply impossible. -- Press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 13:48 +0200 |
| Message-ID | <qkb2ev$fou$2@news.albasani.net> |
| In reply to | #145865 |
> That's simply impossible. If I wouldn't know how it is possible I would think the same.
[toc] | [prev] | [next] | [standalone]
| From | My nuts hurt <cdalten@gmail.com> |
|---|---|
| Date | 2019-08-30 05:01 -0700 |
| Message-ID | <f49c337c-d683-4491-a27b-012e718bbb47@googlegroups.com> |
| In reply to | #145867 |
I use try/exception blocks in Java when I want to capture the current state of a webpage that is being redirected. The performance probably sucks, but I don't know of any other way to get the current state of a webpage on a 302 response code.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-08-30 15:18 +0300 |
| Message-ID | <qkb46e$fsa$1@dont-email.me> |
| In reply to | #145865 |
On 30.08.2019 14:37, Mel wrote: > On Fri, 30 Aug 2019 14:08:47 +0300, Paavo Helde <myfirstname@osa.pri.ee> > wrote: >> On 30.08.2019 11:43, Mel wrote: >> > On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero >> >> The non-throw-case takes almost no or no performance. >> > >> > That's no true. You have to install handlers evrry time or > prepare tbla >> > for each function at program start... > > >> >> Evaluating return-codes is simply a magnitude slower. >> > >> > This is especially not true. > > >> Your information is out of date for a couple of decades. The > current C++ >> compilers have implemented zero cost exceptions (in the no-throw > path) >> already long time ago. > > That's simply impossible. > See e.g. http://www.ut.sco.com/developers/products/ehopt.pdf From that paper: "Most high-performance EH implementations use the commonly known table-driven approach. The goal of this approach is to present zero execution-time overhead, until and unless an exception is thrown." The paper acknowledges some deficiencies with this goal, mainly missing some optimization opportunities, then goes further to solve a part of them. Note this paper is from 1998. The compiler technology has moved forward meanwhile. It might be there is some minimal machine code needed for EH like a register load at function entrance. This does not make it non-zero cost because the alternative is to use an error return, which would also be at least a register load plus a branching instruction for checking it in the caller.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 14:24 +0200 |
| Message-ID | <qkb4ho$ba9$1@news.albasani.net> |
| In reply to | #145869 |
> Note this paper is from 1998. The compiler technology > has moved forward meanwhile. That this is from 1998 doesn't mean that it is relevant to each imple- mentation. Win32 had structured exception handling from the beginning with NT 3.1. And the exception-handling-implementation of the first Visual C++ version was built on top of that. So Microsoft hadn't any choice to revert that for newer version of VC++.
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 15:43 +0200 |
| Message-ID | <almarsoft.5459018346445189333@news.albasani.net> |
| In reply to | #145870 |
On Fri, 30 Aug 2019 14:24:24 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: > > Note this paper is from 1998. The compiler technology > > has moved forward meanwhile. > That this is from 1998 doesn't mean that it is relevant to each imple- > mentation. Win32 had structured exception handling from the beginning > with NT 3.1. And the exception-handling-implementation of the first > Visual C++ version was built on top of that. So Microsoft hadn't any > choice to revert that for newer version of VC++. Under windows there is run tme cost because of that... -- Press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 16:23 +0200 |
| Message-ID | <qkbbg5$d5c$1@news.albasani.net> |
| In reply to | #145872 |
>> That this is from 1998 doesn't mean that it is relevant to each >> implementation. Win32 had structured exception handling from the >> beginning with NT 3.1. And the exception-handling-implementation >> of the first Visual C++ version was built on top of that. So >> Microsoft hadn't any choice to revert that for newer version >> of VC++. > Under windows there is run tme cost because of that... No, structured exception handling an the C++ Eh built on top of that installs unwind-handleres linked through the stack on each call-level that needs special unwind-semantics. With the x64-Windows SEH was re-defined table-driven so that both SEH and C++-EH have an almost-zero-overhead.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-08-30 14:40 +0000 |
| Message-ID | <tzaaF.189399$_w5.78594@fx31.am4> |
| In reply to | #145873 |
On 2019-08-30, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> That this is from 1998 doesn't mean that it is relevant to each >>> implementation. Win32 had structured exception handling from the >>> beginning with NT 3.1. And the exception-handling-implementation >>> of the first Visual C++ version was built on top of that. So >>> Microsoft hadn't any choice to revert that for newer version >>> of VC++. > >> Under windows there is run tme cost because of that... > > No, structured exception handling an the C++ Eh built on top of that > installs unwind-handleres linked through the stack on each call-level > that needs special unwind-semantics. > With the x64-Windows SEH was re-defined table-driven so that both SEH > and C++-EH have an almost-zero-overhead. > Zero *run time* overhead at the cost of *space* overhead. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2019-08-30 07:56 -0700 |
| Message-ID | <086d2146-e2b8-4ec6-b8fd-f82c56f1aa16@googlegroups.com> |
| In reply to | #145874 |
On Friday, August 30, 2019 at 5:40:33 PM UTC+3, Melzzzzz wrote: > On 2019-08-30, Bonita Montero <Bonita.Montero@gmail.com> wrote: > >>> That this is from 1998 doesn't mean that it is relevant to each > >>> implementation. Win32 had structured exception handling from the > >>> beginning with NT 3.1. And the exception-handling-implementation > >>> of the first Visual C++ version was built on top of that. So > >>> Microsoft hadn't any choice to revert that for newer version > >>> of VC++. > > > >> Under windows there is run tme cost because of that... > > > > No, structured exception handling an the C++ Eh built on top of that > > installs unwind-handleres linked through the stack on each call-level > > that needs special unwind-semantics. > > With the x64-Windows SEH was re-defined table-driven so that both SEH > > and C++-EH have an almost-zero-overhead. > > > > Zero *run time* overhead at the cost of *space* overhead. > > > -- > press any key to continue or any other to quit... > U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec > Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi > bili naoruzani. -- Mladen Gogala IMHO, you are barking up the wrong tree. EH is bad not because it's slow or costly, but because of its messy semantics.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-08-30 15:08 +0000 |
| Message-ID | <8_aaF.127511$hJ3.15042@fx07.am4> |
| In reply to | #145875 |
On 2019-08-30, already5chosen@yahoo.com <already5chosen@yahoo.com> wrote: > On Friday, August 30, 2019 at 5:40:33 PM UTC+3, Melzzzzz wrote: >> On 2019-08-30, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> >>> That this is from 1998 doesn't mean that it is relevant to each >> >>> implementation. Win32 had structured exception handling from the >> >>> beginning with NT 3.1. And the exception-handling-implementation >> >>> of the first Visual C++ version was built on top of that. So >> >>> Microsoft hadn't any choice to revert that for newer version >> >>> of VC++. >> > >> >> Under windows there is run tme cost because of that... >> > >> > No, structured exception handling an the C++ Eh built on top of that >> > installs unwind-handleres linked through the stack on each call-level >> > that needs special unwind-semantics. >> > With the x64-Windows SEH was re-defined table-driven so that both SEH >> > and C++-EH have an almost-zero-overhead. >> > >> >> Zero *run time* overhead at the cost of *space* overhead. >> >> >> -- >> press any key to continue or any other to quit... >> U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec >> Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi >> bili naoruzani. -- Mladen Gogala > > IMHO, you are barking up the wrong tree. > EH is bad not because it's slow or costly, but because of its messy semantics. I don't even remember why we switched to this discussion. Right way is to do it with discriminated unions, latest Sutters proposal for C++ proves my point. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 19:19 +0200 |
| Message-ID | <qkblql$jld$1@news.albasani.net> |
| In reply to | #145875 |
>> press any key to continue or any other to quit... >> U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec >> Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi >> bili naoruzani. -- Mladen Gogala > IMHO, you are barking up the wrong tree. > EH is bad not because it's slow or costly, but because of its messy semantics. What's messy with the semantics?
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-08-31 03:05 +0300 |
| Message-ID | <20190831030515.3e92d06f46e1fe46e5d4e7a8@gmail.com> |
| In reply to | #145878 |
Bonita Montero to already5chosen: > > EH is bad not because it's slow or costly, but because > > of its messy semantics. > > What's messy with the semantics? By looking at any piece of contiguous code you can't say where its execution is going to be suddenly interrupted and jump to another unobvous place. Code with exceptions is not local because its execution depends on any try blocks anywhere up the call stack. Code with exceptions is not transparent, because it hides the error-handling part of the algorithm, and incomplete information is akin to a lie. -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-08-31 12:18 +1200 |
| Message-ID | <gstsn5FmknoU2@mid.individual.net> |
| In reply to | #145883 |
On 31/08/2019 12:05, Anton Shepelev wrote: > Bonita Montero to already5chosen: > >>> EH is bad not because it's slow or costly, but because >>> of its messy semantics. >> >> What's messy with the semantics? > > By looking at any piece of contiguous code you can't say > where its execution is going to be suddenly interrupted and > jump to another unobvous place. Code with exceptions is not > local because its execution depends on any try blocks > anywhere up the call stack. Code with exceptions is not > transparent, because it hides the error-handling part of the > algorithm, and incomplete information is akin to a lie. You could equally say that code with exceptions emphasises the error handling be concentrating it in one place. Often a process with many steps either works or fails, so handling the errors in one place makes sense. Throwing exceptions also makes the error handling easier to spot, you just look for the throws. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-08-31 10:48 -0700 |
| Message-ID | <86d9b049-18c7-446d-8405-599e8257478c@googlegroups.com> |
| In reply to | #145884 |
On Saturday, 31 August 2019 01:18:54 UTC+1, Ian Collins wrote: > On 31/08/2019 12:05, Anton Shepelev wrote: > > Bonita Montero to already5chosen: > > > >>> EH is bad not because it's slow or costly, but because > >>> of its messy semantics. > >> > >> What's messy with the semantics? > > > > By looking at any piece of contiguous code you can't say > > where its execution is going to be suddenly interrupted and > > jump to another unobvous place. Code with exceptions is not > > local because its execution depends on any try blocks > > anywhere up the call stack. Code with exceptions is not > > transparent, because it hides the error-handling part of the > > algorithm, and incomplete information is akin to a lie. > > You could equally say that code with exceptions emphasises the error > handling be concentrating it in one place. Often a process with many > steps either works or fails, so handling the errors in one place makes > sense. Throwing exceptions also makes the error handling easier to > spot, you just look for the throws. > The exceptions are part of the interface contract with the function. Just like the parameters it takes, the return value, and any globals or IO devices it manipulates. So by allowing exceptions we are complicating matters. Experience with C++ is that often exceptions are poorly documented. Also, some exceptional conditions are intermediate between errors and normal programming. If the user tries to enter too many characters into an edit box, should that be treated as an "error" or as "exceptional but normal flow control"? There's likely no definite answer. In fact you'll have a mix of handling via exceptions and handling via normal flow control.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-31 11:43 +0200 |
| Message-ID | <qkdfgs$mol$1@news.albasani.net> |
| In reply to | #145883 |
>> What's messy with the semantics? > By looking at any piece of contiguous code you can't say > where its execution is going to be suddenly interrupted > and jump to another unobvous place. The code that throws an exception doesn't need to know where the exception is caught.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-08-31 17:17 +0300 |
| Message-ID | <qkdvh1$bek$1@dont-email.me> |
| In reply to | #145883 |
On 31.08.2019 3:05, Anton Shepelev wrote: > Bonita Montero to already5chosen: > >>> EH is bad not because it's slow or costly, but because >>> of its messy semantics. >> >> What's messy with the semantics? > > By looking at any piece of contiguous code you can't say > where its execution is going to be suddenly interrupted and > jump to another unobvous place. In C++ this is a no-brainer, you don't need to know or care where the code execution can be interrupted. This is because every allocated resource is protected and released by RAII automatically, regardless of if there is an exception or not. This means using things like std::make_unique() instead of new, etc. IOW, in C++ you just code with the assumption that about every line can throw an exception, if not now, then in the future. There are only some special places where one needs to care about thrown exceptions, namely noexcept functions like destructors, swappers and like. With proper RAII very few classes need such functions. > Code with exceptions is not > local because its execution depends on any try blocks > anywhere up the call stack. Code with exceptions is not > transparent, because it hides the error-handling part of the > algorithm, and incomplete information is akin to a lie. This might sound nice in theory, but in reality the error handling part cannot be part of the actual code because more often than not this code has no idea how to react to the error. Let's say an input data file cannot be opened by some number-crunching library. How should it handle this error? Should it abort the whole program, or should it pop up a dialog asking the user to correct the problem and retry? What if it runs in a web server where there is no user to click on the dialog? The error handling logic is altogether at a different level than the low-level code which tries to open the file, and the low-level code cannot and should not contain any "handling" of such errors, it should just report them to the caller. Exceptions are the most convenient way for doing this, in particular they can easily encapsulate much more detailed information about the problem than just some cryptic error code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-31 16:28 +0200 |
| Message-ID | <qke072$qga$1@news.albasani.net> |
| In reply to | #145887 |
> Exceptions are the most convenient way > for doing this, in particular they can easily encapsulate much more > detailed information about the problem than just some cryptic error > code. What I don't like with C++ is that exceptions aren't usually concatenated as like in Java, which is good for debugginig-purposes. In Java you throw a highly specific checked exception-type at the point where the error occurs and the exception might get caught up the call-stack and concatenated into an more general exceptiont -type. I.e. a JDBC-driver might throw a I/O-error when the socket is dropped by the OS, there is a specific socket exception-class thrown and further up the call -levels this is wrapped in a more general JDBC-error-class; this is done in this way: "throw new OuterExceptionClass( inner );". In C++ this isn't directly possible because new might throw bad _alloc. The only way I can imagine to do this is to have thread -local / static exception-objects which are thrown when appropriate.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-01 00:06 +0200 |
| Message-ID | <qker0n$h4b$1@dont-email.me> |
| In reply to | #145887 |
On 31/08/2019 16:17, Paavo Helde wrote:
> On 31.08.2019 3:05, Anton Shepelev wrote:
>> Bonita Montero to already5chosen:
>>
>>>> EH is bad not because it's slow or costly, but because
>>>> of its messy semantics.
>>>
>>> What's messy with the semantics?
>>
>> By looking at any piece of contiguous code you can't say
>> where its execution is going to be suddenly interrupted and
>> jump to another unobvous place.
C++ exceptions have been described as "undocumented gotos". The
description is, I think, quite fair. That does not necessarily make
them a bad thing - they can often be a good choice in coding.
Different types of coding need different balances, and programming is
always a matter of picking appropriate balances. Sometimes you want
automatic and implicit, sometimes you want manual and explicit. C++
offers you much more flexibility than most languages in finding balances
that work well for the code you are writing - you learn the options and
their pros and cons, and make your choices.
>
> In C++ this is a no-brainer, you don't need to know or care where the
> code execution can be interrupted. This is because every allocated
> resource is protected and released by RAII automatically, regardless of
> if there is an exception or not. This means using things like
> std::make_unique() instead of new, etc.
RAII to protect resources is not remotely dependent on exceptions :
std::optional<int> foo(int x) {
auto a = std::make_unique<int>(x);
auto b = dosomething(a);
if (!b) return std::nullopt;
dosomethingelse(a, b);
return calc(a);
}
You don't need exceptions to avoid leaks and tidy up resources - RAII
gives you that regardless. Returning with error codes (or
std::optional, or new suggestions like "expected", or whatever) is just
as good from that viewpoint.
>
> IOW, in C++ you just code with the assumption that about every line can
> throw an exception, if not now, then in the future. There are only some
> special places where one needs to care about thrown exceptions, namely
> noexcept functions like destructors, swappers and like. With proper RAII
> very few classes need such functions.
>
> > Code with exceptions is not
>> local because its execution depends on any try blocks
>> anywhere up the call stack. Code with exceptions is not
>> transparent, because it hides the error-handling part of the
>> algorithm, and incomplete information is akin to a lie.
>
> This might sound nice in theory, but in reality the error handling part
> cannot be part of the actual code because more often than not this code
> has no idea how to react to the error.
And therein lies the problem, when you are concerned with being able to
be sure your code is correct (both by design, and by testing).
> Let's say an input data file
> cannot be opened by some number-crunching library. How should it handle
> this error? Should it abort the whole program, or should it pop up a
> dialog asking the user to correct the problem and retry? What if it runs
> in a web server where there is no user to click on the dialog?
Separate the concerns. Don't make a function (or class, or unit, or
whatever code size is appropriate) that reads data from a file and
crunches it. Make a function that reads data from the file. Make
another function that crunches data.
Or make a function that will attempt to read the data from the file and
crunch it, returning the correct result or some sort of error indicator
when a problem is found. That error indicator could be an error code, a
std::optional nullopt, a tuple field in the result - or a thrown exception.
But now, instead of having a function that lives in a happy, optimistic,
carefree and unrealistic world, with no sense of responsibility and an
"I don't care, it's someone else's problem" attitude, you've got a
function that is clear and complete. If there is a problem, it will
tell you - and it will do so in a way that you know about and
understand, and that you can test. Your function no longer has errors -
it has a wider scope of correct, specified, tested and documented,
behaviour. (And yes, you can use exceptions for this just as well as
other error techniques.)
>
> The error handling logic is altogether at a different level than the
> low-level code which tries to open the file, and the low-level code
> cannot and should not contain any "handling" of such errors, it should
> just report them to the caller. Exceptions are the most convenient way
> for doing this, in particular they can easily encapsulate much more
> detailed information about the problem than just some cryptic error code.
>
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-09-01 15:49 +0300 |
| Message-ID | <qkgeo3$15l$1@dont-email.me> |
| In reply to | #145892 |
On 1.09.2019 1:06, David Brown wrote: > On 31/08/2019 16:17, Paavo Helde wrote: >> On 31.08.2019 3:05, Anton Shepelev wrote: > > RAII to protect resources is not remotely dependent on exceptions : Sure, but exceptions are dependent on RAII. Without RAII it is not really feasible to use exceptions, as demonstrated by ugly, tedious and error-prone 'finally' clauses in C# and elsewhere. >> > Code with exceptions is not >>> local because its execution depends on any try blocks >>> anywhere up the call stack. Code with exceptions is not >>> transparent, because it hides the error-handling part of the >>> algorithm, and incomplete information is akin to a lie. >> >> This might sound nice in theory, but in reality the error handling >> part cannot be part of the actual code because more often than not >> this code has no idea how to react to the error. > > And therein lies the problem, when you are concerned with being able to > be sure your code is correct (both by design, and by testing). > >> Let's say an input data file cannot be opened by some number-crunching >> library. How should it handle this error? Should it abort the whole >> program, or should it pop up a dialog asking the user to correct the >> problem and retry? What if it runs in a web server where there is no >> user to click on the dialog? > > Separate the concerns. Don't make a function (or class, or unit, or > whatever code size is appropriate) that reads data from a file and > crunches it. Make a function that reads data from the file. Make > another function that crunches data. There is no difference, the function reading the data still has no clue how to "handle" an error. > Or make a function that will attempt to read the data from the file and > crunch it, returning the correct result or some sort of error indicator > when a problem is found. That error indicator could be an error code, a > std::optional nullopt, a tuple field in the result - or a thrown exception. Right, the function cannot handle the error by itself and reports it back to the caller. Ergo, the error handling code resides somewhere else than in this low-level function, ruining the dubious "transparency" ideal advocated by GP. The distance between error detection and handling is different in different kind of software. It might be that the error is handled 1 - 2 call stack frames up, making the error code approach pretty straightforward. In the code I usually work with this distance is typically 10 - 20 call stack frames, making the exceptions approach much more convenient.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web