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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | legalize+jeeves@mail.xmission.com (Richard) |
|---|---|
| Date | 2019-09-03 20:07 +0000 |
| Message-ID | <qkmh6s$sp4$1@news.xmission.com> |
| In reply to | #145836 |
[Please do not mail me a copy of your followup]
BGB <cr88192@gmail.com> spake the secret code
<qk88hr$uju$1@dont-email.me> thusly:
>How about, instead:
>We take C;
>We add some features to support things like bounds-checked arrays and
>similar;
>We mostly call it done.
Been there, done that, 30 years ago. It's called C++. You only pay
for bounds-checked arrays if you want to pay for it.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2019-09-03 17:13 -0500 |
| Message-ID | <qkmois$l9e$1@dont-email.me> |
| In reply to | #145947 |
On 9/3/2019 3:07 PM, Richard wrote: > [Please do not mail me a copy of your followup] > > BGB <cr88192@gmail.com> spake the secret code > <qk88hr$uju$1@dont-email.me> thusly: > >> How about, instead: >> We take C; >> We add some features to support things like bounds-checked arrays and >> similar; >> We mostly call it done. > > Been there, done that, 30 years ago. It's called C++. You only pay > for bounds-checked arrays if you want to pay for it. > I was meaning in a way which behaved more like a hybrid of Java-style arrays and raw pointers, and worked from C, rather than something like std::vector or std::array or similar, which has different semantics (the usual pointer fun doesn't work on them), and they require using C++... Or, if you mean doing something custom which can better approximate C style array/pointer semantics in C++, this could be doable. Granted, the big inescapable drawback with any of these options is that using them would come with a bit of a performance overhead (so may not ultimately solve all that much).
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-29 14:53 +0200 |
| Message-ID | <qk8hrh$ua3$1@news.albasani.net> |
| In reply to | #145830 |
Rust is nice, but Rust has no exceptions. I wouldn't like to evaluate this combined error- and return-values after each function-call that might fail.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-08-29 13:14 +0000 |
| Message-ID | <qk8j2u$mv9$1@news.xmission.com> |
| In reply to | #145839 |
In article <qk8hrh$ua3$1@news.albasani.net>, Bonita Montero <Bonita.Montero@gmail.com> wrote: >Rust is nice, but Rust has no exceptions. I wouldn't like to evaluate >this combined error- and return-values after each function-call that >might fail. > Why is this posted to CLC? Surely, the comparison is more valid to C++, given that C++ has things like exceptions and so on. It should have only been posted to CLC++. (Or, is there a parallel thread going on in CLC++ - that I am not (yet) aware of?) P.S. Of course there will be a blogs and stuff like this one (the one referred to in the OP) telling us that Rust is the next big thing and obviously the thing that is going to be just so absolutely neato keeno that you'll be unable to imagine how we ever got along with it. This is true for any new programming language. Look at it this way: If a new programming language came out and there was no blog post (or whatever) telling us with absolute authority that this is the absolute greatest thing since, well, ever - that language will have zero, zip, nada chance of ever being used by anyone. -- Pensacola - the thinking man's drink.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-29 15:38 +0200 |
| Message-ID | <qk8kgg$s5p$1@news.albasani.net> |
| In reply to | #145841 |
>> Rust is nice, but Rust has no exceptions. I wouldn't like to evaluate >> this combined error- and return-values after each function-call that >> might fail. > Why is this posted to CLC? ... Why do you post another Follow-Up there if you consider this as inadequate.
[toc] | [prev] | [next] | [standalone]
| From | legalize+jeeves@mail.xmission.com (Richard) |
|---|---|
| Date | 2019-09-03 20:09 +0000 |
| Message-ID | <qkmhak$sp4$2@news.xmission.com> |
| In reply to | #145841 |
[Please do not mail me a copy of your followup]
gazelle@shell.xmission.com (Kenny McCormack) spake the secret code
<qk8j2u$mv9$1@news.xmission.com> thusly:
>In article <qk8hrh$ua3$1@news.albasani.net>,
>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>Rust is nice, but Rust has no exceptions. I wouldn't like to evaluate
>>this combined error- and return-values after each function-call that
>>might fail.
>>
>
>Why is this posted to CLC? Surely, the comparison is more valid to
>C++, given that C++ has things like exceptions and so on. It should have
>only been posted to CLC++.
The author of the article barely mentions C++; instead all the
comparisons are to C.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-09-04 08:31 +0300 |
| Message-ID | <qkni7b$7r1$1@dont-email.me> |
| In reply to | #145948 |
On 3.09.2019 23:09, Richard wrote: > [Please do not mail me a copy of your followup] > > gazelle@shell.xmission.com (Kenny McCormack) spake the secret code > <qk8j2u$mv9$1@news.xmission.com> thusly: > >> In article <qk8hrh$ua3$1@news.albasani.net>, >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Rust is nice, but Rust has no exceptions. I wouldn't like to evaluate >>> this combined error- and return-values after each function-call that >>> might fail. >>> >> >> Why is this posted to CLC? Surely, the comparison is more valid to >> C++, given that C++ has things like exceptions and so on. It should have >> only been posted to CLC++. > > The author of the article barely mentions C++; instead all the > comparisons are to C. This is because the low-level bugs presumably solved by Rust, like out-of-bounds access and memory leaks, are pretty much non-issues in C++. In C++, it is hard to get an out-of-bounds access with for(auto iter=container.begin(); iter!=container.end(); ++i) and even harder with for(auto& ref: container) Similarly, it is much harder to get a memory leak or access-after-destruction if there is not a single owning raw pointer (as produced by malloc() or new) in the program.
[toc] | [prev] | [next] | [standalone]
| From | legalize+jeeves@mail.xmission.com (Richard) |
|---|---|
| Date | 2019-09-05 16:55 +0000 |
| Message-ID | <qkrel4$v22$1@news.xmission.com> |
| In reply to | #145964 |
[Please do not mail me a copy of your followup]
Paavo Helde <myfirstname@osa.pri.ee> spake the secret code
<qkni7b$7r1$1@dont-email.me> thusly:
>On 3.09.2019 23:09, Richard wrote:
>> gazelle@shell.xmission.com (Kenny McCormack) spake the secret code
>> <qk8j2u$mv9$1@news.xmission.com> thusly:
>>
>>> In article <qk8hrh$ua3$1@news.albasani.net>,
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Why is this posted to CLC? Surely, the comparison is more valid to
>>> C++, given that C++ has things like exceptions and so on. It should have
>>> only been posted to CLC++.
>>
>> The author of the article barely mentions C++; instead all the
>> comparisons are to C.
>
>This is because the low-level bugs presumably solved by Rust, like
>out-of-bounds access and memory leaks, are pretty much non-issues in C++.
Agreed. I find it interesting that all these proponents of other
languages keep pointing to problems that C++ has solved decades ago as
the reason why we need their language.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 08:13 +0200 |
| Message-ID | <almarsoft.8134279842288446008@news.albasani.net> |
| In reply to | #145839 |
On Thu, 29 Aug 2019 14:53:05 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Rust is nice, but Rust has no exceptions. I wouldn't like to evaluate > this combined error- and return-values after each function-call that > might fail. That's Rust advantage. Returnig discriminated union is right way for handling errors. Rust has syntactic sugar in that. Latest proposal for c++ exceptions leans toeard that solution. -- 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 08:38 +0200 |
| Message-ID | <qkag8d$gcn$1@news.albasani.net> |
| In reply to | #145850 |
> Returnig discriminated union is right way for handling errors. NO, that's a mess. Exceptions are by far more comfortable. The best variant are the distinction between checked and unchecked exceptions in Java.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 08:51 +0200 |
| Message-ID | <qkah19$fle$1@news.albasani.net> |
| In reply to | #145851 |
>> Returnig discriminated union is right way for handling errors. > NO, that's a mess. Exceptions are by far more comfortable. > The best variant are the distinction between checked and > unchecked exceptions in Java. And exceptions are more performant for the performance-relevant case that no exception is thrown with table-driven excepion-handling. The code-path that is processed when no exception is thrown is almost as efficient as if there isn't any exception-handling (nearly zero-over- head).
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 10:13 +0200 |
| Message-ID | <almarsoft.4160850627477538964@news.albasani.net> |
| In reply to | #145852 |
On Fri, 30 Aug 2019 08:51:21 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> Returnig discriminated union is right way for handling errors. > > NO, that's a mess. Exceptions are by far more comfortable. > > The best variant are the distinction between checked and > > unchecked exceptions in Java. > And exceptions are more performant for the performance-relevant case > that no exception is thrown with table-driven excepion-handling. The > code-path that is processed when no exception is thrown is almost as > efficient as if there isn't any exception-handling (nearly zero-over- > head). Exceptions take space or time, there is no escape, and they are non deterministic... -- 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 10:18 +0200 |
| Message-ID | <qkam3r$63e$1@news.albasani.net> |
| In reply to | #145853 |
>> And exceptions are more performant for the performance-relevant case >> that no exception is thrown with table-driven excepion-handling. The >> code-path that is processed when no exception is thrown is almost as >> efficient as if there isn't any exception-handling (nearly > zero-over- >> head). > Exceptions take space or time, there is no escape, and they are non > deterministic... Computers are always deterministic. ;-) But trowing exceptions is slow. But the case when we have a resouce- or I/O-collapse isn't performance-relevant, i.e. it doesn't matter if throwsing an exception lasts 10 or 1.000 clock-cycles.
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 10:31 +0200 |
| Message-ID | <almarsoft.9013647030560314716@news.albasani.net> |
| In reply to | #145855 |
On Fri, 30 Aug 2019 10:18:02 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> And exceptions are more performant for the performance-relevant case > >> that no exception is thrown with table-driven excepion-handling. The > >> code-path that is processed when no exception is thrown is almost as > >> efficient as if there isn't any exception-handling (nearly > > zero-over- > >> head). > > Exceptions take space or time, there is no escape, and they are non > > deterministic... > Computers are always deterministic. ;-) > But trowing exceptions is slow. But the case when we have a resouce- > or I/O-collapse isn't performance-relevant, i.e. it doesn't matter > if throwsing an exception lasts 10 or 1.000 clock-cycles. I am not talking when you throw. -- 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 10:39 +0200 |
| Message-ID | <qkanbn$3u7$1@news.albasani.net> |
| In reply to | #145856 |
>> Computers are always deterministic. ;-) >> But trowing exceptions is slow. But the case when we have a resouce- >> or I/O-collapse isn't performance-relevant, i.e. it doesn't matter >> if throwsing an exception lasts 10 or 1.000 clock-cycles. > I am not talking when you throw. The non-throw-case takes almost no or no performance. Evaluating return-codes is simply a magnitude slower.
[toc] | [prev] | [next] | [standalone]
| From | Mel <mel@zzzzz.com> |
|---|---|
| Date | 2019-08-30 10:43 +0200 |
| Message-ID | <almarsoft.188316418275962884@news.albasani.net> |
| In reply to | #145857 |
On Fri, 30 Aug 2019 10:39:19 +0200, Bonita Montero <Bonita.Montero@gmail.com> wrote: > >> Computers are always deterministic. ;-) > >> But trowing exceptions is slow. But the case when we have a resouce- > >> or I/O-collapse isn't performance-relevant, i.e. it doesn't matter > >> if throwsing an exception lasts 10 or 1.000 clock-cycles. > > I am not talking when you throw. > 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. -- 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 10:47 +0200 |
| Message-ID | <qkanqg$2lv$1@news.albasani.net> |
| In reply to | #145858 |
>> Evaluating return-codes is simply a magnitude slower. > This is especially not true. No, this is true. You don't simply unterstand the implications of table-driven exception handling or table-driven exception-handling at all.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-30 11:41 +0200 |
| Message-ID | <qkar0o$qke$1@dont-email.me> |
| In reply to | #145859 |
On 30/08/2019 10:47, Bonita Montero wrote: >>> Evaluating return-codes is simply a magnitude slower. > >> This is especially not true. > > No, this is true. I take it you have measured this yourself? You have sample code, measurements, statistics to back up this very specific claim? Or is it just based on "something you read somewhere", repeated in the hope that people will believe you more the second time? > You don't simply unterstand the implications of table-driven > exception handling or table-driven exception-handling at all. I expect Mel does understand it. I am less convinced /you/ do. Different error handling techniques have their pros and cons. Anyone claiming one method is faster, safer, clearer, easier than other methods is guaranteed to be /wrong/. They will have different balances, and there is no solution that is the "best" in all situations, or the best in all ways. Table-driven exception handling tends to be efficient at run-time when exceptions are not thrown, when you are running on larger processors (like x86), and when you have no issues with code space. That makes it a good choice (from the efficiency viewpoint) on PC programming. But you can also find that the possibility of exceptions passing through functions can affect their efficiency, even if they don't throw or catching anything directly - it can affect ordering and optimisation of the code by the compiler. It can affect the re-use of stack slots as the compiler has to track all possible exception points and be able to unwind correctly. On resource-constrainted systems, this kind of thing can lead to unwind tables that are bigger than the actual code size - a horrible level of inefficiency that is unacceptable in many cases. And while table-driven exception handling does not need extra instruction codes (just data tables) for functions that pass on exceptions without handling them, you need plenty of extra code - and run-time - when throwing the exception, or when catching it. Error handling via return codes, on the other hand, uses minimal extra code space in functions that raise or handle the errors - usually less overhead than for throwing or catching exceptions. It is certainly going to be much faster when errors do occur. But you have to have some way of passing on errors in functions between the "thrower" and the "catcher". That means more explicit source code, but more efficient object code. Each technique has, as I said, its pros and cons. And there are lots of reasons why one might pick one method over the other beyond efficiency - do you want your error handling clear and explicit, or automatic and hidden? Which is easier to get right, and which is harder to get wrong? But one thing we can be sure of - Sutter would not have started the process of getting "Zero-overhead deterministic exceptions" into C++ if current C++ exceptions were as ideal as suggested. And while Sutter's ideas here may come to naught, and he can be as wrong as anyone else, I am more inclined to listen to his thoughts than those of Bonita.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 11:56 +0200 |
| Message-ID | <qkarss$qsd$1@news.albasani.net> |
| In reply to | #145860 |
> I expect Mel does understand it. I am less convinced /you/ do.
Disassemble the code that calls a fuction that might throw an exceptions
with an without enabled EH. The difference is only, that the optimiza-
tions around that call might be slightly weakened; that's all. But that
usually doesn't outweigh the overhead against manually evaluating
return-codes.
> Different error handling techniques have their pros and cons. Anyone
> claiming one method is faster, safer, clearer, easier than other methods
> is guaranteed to be /wrong/.
1. Table-driven EH is usually faster.
2. I didn't say that it is safer or clearer,
but it is much more convenient.
3. When you come to the excepion-handling mechanism like in Java
with checked and unchecked exceptions, you get the best solution.
But for compatibility-reasons with C this isn't possible in C++.
> Table-driven exception handling tends to be efficient at run-time when
> exceptions are not thrown, when you are running on larger processors
> (like x86), and when you have no issues with code space. That makes it
> a good choice (from the efficiency viewpoint) on PC programming.
Almost right, but it doesn't depend on the performance of the CPU.
Even on small CPUs the performance of processing a resurce- or I/O
-collapse doesn't count.
> But you can also find that the possibility of exceptions passing through
> functions can affect their efficiency, even if they don't throw or
> catching anything directly - it can affect ordering and optimisation of
> the code by the compiler. It can affect the re-use of stack slots as
> the compiler has to track all possible exception points and be able to
> unwind correctly.
The loss of optimization-opportunities with table-driven exception
-handling is very slight. And the cost is of course not so high as
handling return-codes manually.
> On resource-constrainted systems, this kind of thing can lead to unwind
> tables that are bigger than the actual code size - a horrible level of
> inefficiency that is unacceptable in many cases.
That's true, but then you wouldn't use C++.
> Error handling via return codes, on the other hand, uses minimal extra
> code space in functions that raise or handle the errors - usually less
> overhead than for throwing or catching exceptions.
1. This case isn't performance relevant.
2. Yo cannot say that this is always true. The thing is simply that
there might be a number of return-codes evaluated at each call-level
which might result in a higher total CPU-time.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-30 13:08 +0200 |
| Message-ID | <qkb03o$o43$1@dont-email.me> |
| In reply to | #145861 |
On 30/08/2019 11:56, Bonita Montero wrote: >> I expect Mel does understand it. I am less convinced /you/ do. > > Disassemble the code that calls a fuction that might throw an exceptions > with an without enabled EH. The difference is only, that the optimiza- > tions around that call might be slightly weakened; that's all. But that > usually doesn't outweigh the overhead against manually evaluating > return-codes. There is no doubt that exceptions are aimed at having minimal run-time cost when they are not thrown. But it is important to realise that /minimal/ is not /zero/. > >> Different error handling techniques have their pros and cons. Anyone >> claiming one method is faster, safer, clearer, easier than other methods >> is guaranteed to be /wrong/. > > 1. Table-driven EH is usually faster. Usually it is faster when exceptions are not thrown, but a lot slower when they /are/ thrown. But "usually" is not "always". And for some situations, it is the worst case performance - the speed when there is a problem - that is critical. 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". > 2. I didn't say that it is safer or clearer, > but it is much more convenient. Fair enough - though convenience is also a subjective matter. > 3. When you come to the excepion-handling mechanism like in Java > with checked and unchecked exceptions, you get the best solution. > But for compatibility-reasons with C this isn't possible in C++. Checked exceptions - where the type of exceptions that a function may throw or pass on is part of the signature - are safer, clearer and more efficient. (Compilers can use tables or code branches, whichever is most convenient). But they involve more explicit information, which some people like and others dislike. And they can't pass through functions compiled without knowledge of the exceptions - such as C functions compiled by a C compiler. > >> Table-driven exception handling tends to be efficient at run-time when >> exceptions are not thrown, when you are running on larger processors >> (like x86), and when you have no issues with code space. That makes it >> a good choice (from the efficiency viewpoint) on PC programming. > > Almost right, but it doesn't depend on the performance of the CPU. > Even on small CPUs the performance of processing a resurce- or I/O > -collapse doesn't count. Incorrect. Performance under the worst case is often a critical feature of high reliability systems. It is precisely because the performance exception handling is difficult to predict or measure that exceptions are banned in most such systems. > >> But you can also find that the possibility of exceptions passing through >> functions can affect their efficiency, even if they don't throw or >> catching anything directly - it can affect ordering and optimisation of >> the code by the compiler. It can affect the re-use of stack slots as >> the compiler has to track all possible exception points and be able to >> unwind correctly. > > The loss of optimization-opportunities with table-driven exception > -handling is very slight. And the cost is of course not so high as > handling return-codes manually. > That may often be the case, but I would be very wary of generalising too much. >> On resource-constrainted systems, this kind of thing can lead to unwind >> tables that are bigger than the actual code size - a horrible level of >> inefficiency that is unacceptable in many cases. > > That's true, but then you wouldn't use C++. > Nonsense. There are many good reasons to use C++, and many features that can be used, without leading to any inefficiency or bloat. >> Error handling via return codes, on the other hand, uses minimal extra >> code space in functions that raise or handle the errors - usually less >> overhead than for throwing or catching exceptions. > > 1. This case isn't performance relevant. Often not - but you are wrong to generalise like that. And you can equally well argue that since exception handling is often used in cases where you are dealing with I/O, the performance cost of manual return code checks is negligible and therefore irrelevant with such code. > 2. Yo cannot say that this is always true. The thing is simply that > there might be a number of return-codes evaluated at each call-level > which might result in a higher total CPU-time. > Yes, I have already mentioned that return code checking usually involves some handling at functions along the chain between the "thrower" and the "catcher".
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web