Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67978 > 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 165 — 31 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" 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" Ian Collins <ian-news@hotmail.com> - 2019-08-29 23:35 +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 20:00 +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" Öö Tiib <ootiib@hot.ee> - 2019-08-29 06:08 -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:10 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 01:00 -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 10:16 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 01:26 -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 10:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 06:30 -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 15:59 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 07:42 -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 14:44 +0000
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" Daniel <danielaparker@gmail.com> - 2019-09-05 13:28 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-06 02:36 -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: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" Manfred <noname@invalid.add> - 2019-08-31 18: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-08-31 18:21 +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" Öö Tiib <ootiib@hot.ee> - 2019-09-01 03:21 -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-01 12:25 +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 12:35 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-01 04:13 -0700
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-01 23:18 +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-09-01 14:04 +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-02 07:20 +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" 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" 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: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 11:07 -0700
Re: 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-05 19:23 +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-09-06 08:25 +0200
Re: 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-18 16:55 +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" Ian Collins <ian-news@hotmail.com> - 2019-09-06 17:16 +1200
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" Daniel <danielaparker@gmail.com> - 2019-09-03 12:16 -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:35 +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-03 22:49 -0700
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-04 00:20 -0700
Re: Comments on third parties Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-07 06:59 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-05 17:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 09:03 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-05 20:18 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-05 17:16 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 14:40 -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-06 10:05 +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:33 +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 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" 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" 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" 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" 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" 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
Error handling strategies (was: Rust is the future of systems programming C is the new Assembly) legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20: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-09-08 20:29 +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" Ian Collins <ian-news@hotmail.com> - 2019-09-08 12:40 +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-09 08:59 +0200
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-09 16:35 +0000
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" Öö Tiib <ootiib@hot.ee> - 2019-08-31 04:50 -0700
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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| Date | 2019-08-31 13:20 +0100 |
| Message-ID | <VBtaF.31507$VR.13450@fx03.fr7> |
| In reply to | #68030 |
On 30/08/2019 12:08, David Brown wrote: > > I'm happy with a claim "Table driven exceptions are generally faster, > when there are no errors, than other handling techniques for typical > code on PC's". What I am /not/ happy with is "Exception handling is > faster than other error return techniques". That statement just shows us that you are clueless on the subject of exceptions. Firstly exceptions are not just for errors. Secondly manually propagating an error code up the stack manually translating to make it suitable for one abstraction layer to the next is both an antiquated way of doing things and a fucktarded way of doing things. If you like error codes so much then stick to fucking C. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin “You won’t burn in hell. But be nice anyway.” – Ricky Gervais “I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-31 23:45 +0200 |
| Message-ID | <qkeppc$7ph$1@dont-email.me> |
| In reply to | #68054 |
On 31/08/2019 14:20, Mr Flibble wrote: > On 30/08/2019 12:08, David Brown wrote: >> >> I'm happy with a claim "Table driven exceptions are generally faster, >> when there are no errors, than other handling techniques for typical >> code on PC's". What I am /not/ happy with is "Exception handling is >> faster than other error return techniques". > > That statement just shows us that you are clueless on the subject of > exceptions. You are jumping in to a discussion without following the details. > Firstly exceptions are not just for errors. I realise that. The discussion was about error handling techniques, including alternatives to exceptions for handling errors. And of course, there is no single definition of "error" anyway - it means different things in different contexts. > Secondly > manually propagating an error code up the stack manually translating to > make it suitable for one abstraction layer to the next is both an > antiquated way of doing things and a fucktarded way of doing things. It is an excellent way of handling things in some cases. If you had been paying attention and read my posts before replying, you'd have seen I have argued that a variety of techniques can be useful in different cases - exceptions are often a good choice, but they are most certainly not always the right choice. > If > you like error codes so much then stick to fucking C. > Don't be such a child.
[toc] | [prev] | [next] | [standalone]
| 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 | #68026 |
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 | #68031 |
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 | #68032 |
> That's simply impossible. If I wouldn't know how it is possible I would think the same.
[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 | #68032 |
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 | #68035 |
> 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 | #68036 |
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 | #68039 |
>> 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 | #68041 |
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 | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 16:57 +0200 |
| Message-ID | <qkbdg8$uls$1@news.albasani.net> |
| In reply to | #68042 |
>> 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. We're talking abot Windows-computers and not Ardino Unos.
[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 | #68042 |
>> 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 | #68046 |
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 | #68050 |
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 | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-31 11:43 +0200 |
| Message-ID | <qkdfgs$mol$1@news.albasani.net> |
| In reply to | #68050 |
>> 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 | #68050 |
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 | #68055 |
> 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 | #68055 |
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 | #68061 |
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-01 16:12 +0200 |
| Message-ID | <qkgjk7$tat$1@dont-email.me> |
| In reply to | #68074 |
On 01/09/2019 14:49, Paavo Helde wrote: > 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. > Agreed. You need RAII - or, more specifically, deterministic destructors - for exceptions to work well. My point is merely that you get the RAII advantages no matter how you handle errors or unusual situations, whether it be C++ exceptions, future "zero overhead" or "checked" exceptions, error return codes, or anything else. >>> > 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. That can be true - but a key difference is that the reading function knows there can be errors. It might not handle those errors, but it does not ignore the possibility of their existence. > >> 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. > Sure, if exceptions are right for your code, use exceptions. I am not suggesting that exceptions are bad - merely that they are not always the best choice.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.c++
csiph-web