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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-08-30 13:47 +0200 |
| Message-ID | <qkb2d8$fou$1@news.albasani.net> |
| In reply to | #145862 |
> 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. The case when an exception is thrown isn't performance-relevant as this occurs when there's an resource- or I/O-collapse. > Fair enough - though convenience is also a subjective matter. That's rather not subjective here because evaluating return-codes on every call-level is a lot of work. >> 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. Can you read what I told above? >> 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. No, correct. > Performance under the worst case is often a critical feature of high > reliability systems. When you have a resource or I/O-collapse, you don't have reliability anyway. >> 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. Almost the whole standard-libary uses an allocaor which might throw bad_alloc; not to use the standard-library isn't really C++.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-31 23:39 +0200 |
| Message-ID | <qkepfg$5u7$1@dont-email.me> |
| In reply to | #145866 |
On 30/08/2019 13:47, Bonita Montero wrote: >> 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. > > The case when an exception is thrown isn't performance-relevant > as this occurs when there's an resource- or I/O-collapse. As seems to be the case depressingly often, you are over-generalising from certain types of software. For some software, exceptions are ruled out as a technique because they take too long, and in particular, their timing is very hard to predict. For real-time programming, it doesn't matter how fast the usual situation runs. It matters that even in the worst case, you know how long the code will take. It is a world outside your experience and understanding, apparently, but it is a vital part of the modern world. > >> Fair enough - though convenience is also a subjective matter. > > That's rather not subjective here because evaluating return-codes on > every call-level is a lot of work. > Again, you don't see the big picture and think that your ideas cover everything. Dealing with return codes on every call level is only a lot of work if you have lots of call levels between identifying a problem and dealing with it. And using exceptions is a /huge/ amount of work for some kinds of analysis of code and possible code flows. By being explicit and clearly limited, return code error handling is far simpler to examine and understand, and it is far easier to test functions fully when you don't have to take into account the possibility of an unknown number of unknown exceptions passing through. As I have said, different ways of handling errors have their pros and cons, and there is no one way that is best for all cases. > >>> 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. > > Can you read what I told above? I elaborated on what you wrote. > >>> 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. > > No, correct. I'm sorry, but you are making bald statements with apparently no knowledge or experience in the area. > >> Performance under the worst case is often a critical feature of high >> reliability systems. > > When you have a resource or I/O-collapse, you don't have reliability > anyway. > You do understand that people use exceptions for a variety of reasons, don't you? You do realise that people sometimes write safe and reliable software that is designed to deal with problems in a reasonable fashion? If "throw an exception" simply means "there's been a disaster - give up on reliability, accept that the world has ended and it doesn't matter how slowly we act as the program is falling apart" then why have an exception system in the first place? Just call "abort()" and be done with it. > >>> 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. > > Almost the whole standard-libary uses an allocaor which might > throw bad_alloc; not to use the standard-library isn't really C++. That's bollocks on so many levels, it's not worth trying to explain them to you.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-01 05:16 +0200 |
| Message-ID | <qkfd6h$b1b$1@news.albasani.net> |
| In reply to | #145890 |
> For some software, exceptions are ruled out as a technique because they > take too long, and in particular, their timing is very hard to predict. Another time: the performance of resource- or I/O-collapse-handling is never relevant. >> That's rather not subjective here because evaluating return-codes on >> every call-level is a lot of work. > Again, you don't see the big picture and think that your ideas cover > everything. I see "the big picture" - you are not. > Dealing with return codes on every call level is only a lot of work if > you have lots of call levels between identifying a problem and dealing > with it. And using exceptions is a /huge/ amount of work for some kinds > of analysis of code and possible code flows. Wrong; you catch them in a central point and that's all. >> When you have a resource or I/O-collapse, you don't have reliability >> anyway. > You do understand that people use exceptions for a variety of reasons, > don't you? They are used for resource- or I/O-collapse - and nothing more. > f "throw an exception" simply means "there's been a disaster - give > up on reliability, accept that the world has ended and it doesn't matter > how slowly we act as the program is falling apart" then why have an > exception system in the first place? Just call "abort()" and be done > with it. You don't have any reliability any more at this point because the operation simply failed. The timing isn't relevant any more a this point.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-01 16:03 +0200 |
| Message-ID | <qkgj3r$pr9$1@dont-email.me> |
| In reply to | #145893 |
On 01/09/2019 05:16, Bonita Montero wrote: >> For some software, exceptions are ruled out as a technique because >> they take too long, and in particular, their timing is very hard to >> predict. > > Another time: the performance of resource- or I/O-collapse-handling > is never relevant. > All I can say is that I am glad I don't have to rely on your software. It's one thing to be ignorant - but your blind, stubborn, wilful and insistent ignorance is fortunately exceptional.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-01 18:22 +0200 |
| Message-ID | <qkgr86$mqd$1@news.albasani.net> |
| In reply to | #145895 |
> All I can say is that I am glad I don't have to rely on your software. > It's one thing to be ignorant - but your blind, stubborn, wilful and > insistent ignorance is fortunately exceptional. You're a mega-idiot as you don't understand that error-handling isn't performance-crucial.
[toc] | [prev] | [next] | [standalone]
| From | My nuts hurt <cdalten@gmail.com> |
|---|---|
| Date | 2019-09-01 12:20 -0700 |
| Message-ID | <1ab35df3-0c1e-4bcf-abe7-09861a2cbfc0@googlegroups.com> |
| In reply to | #145897 |
On Sunday, September 1, 2019 at 9:22:39 AM UTC-7, Bonita Montero wrote: > > All I can say is that I am glad I don't have to rely on your software. > > It's one thing to be ignorant - but your blind, stubborn, wilful and > > insistent ignorance is fortunately exceptional. > > You're a mega-idiot as you don't understand that error-handling isn't > performance-crucial. A long time ago the Stanford Linear Accelerator Group wanted to transmit videos in real time to the Scientists at CERN. They couldn't because TCP error checking after a certain range slowed down the connection so much that doing something like this was infeasible. So the engineers at the Stanford Linear Accelerator Group started to resort to things like the trapezoid and midpoint rule when the error checking started to impact the performance of the network. There was also a corresponding academic writeup that discussed this issue, along with solution, in fairly great detail.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-09-01 15:23 -0400 |
| Message-ID | <YUUaF.66291$id3.64167@fx12.iad> |
| In reply to | #145897 |
On 9/1/19 12:22 PM, Bonita Montero wrote: >> All I can say is that I am glad I don't have to rely on your software. >> It's one thing to be ignorant - but your blind, stubborn, wilful and >> insistent ignorance is fortunately exceptional. > > You're a mega-idiot as you don't understand that error-handling isn't > performance-crucial. > If the result of not handling the error in time is someone gets killed, maybe it is. 'Error' Handling often can be a critical part of the system (and sometimes it isn't). The issue is that 'Generic' answers aren't always right, sometimes certain things are important, and sometimes they are not. In many cases, the cost of the exception path isn't that important, but sometimes real WORSE case performance is, sometimes the error path may have relaxed requirements, but sometimes it still has definite requirements. Exceptions can't be true Zero overhead, they may be able to push the overhead into things that aren't important most of the time, but might be important in some cases. The shifting of exception cost to static data/code space and away from execution time is good in many cases, but it does raise the cost of the exception path, sometimes significantly (and perhaps too high of a cost). Error Return Values sometimes have the advantage that the cost is up front and more directly controllable, the cost of exceptions is very much fixed by the implementation, and not as controllable. If your usage matches the cases that the implementation optimized for, it can be good, if not, it may not be so good.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-01 22:39 +0200 |
| Message-ID | <qkha9t$fbc$1@dont-email.me> |
| In reply to | #145899 |
On 01/09/2019 21:23, Richard Damon wrote: > On 9/1/19 12:22 PM, Bonita Montero wrote: >>> All I can say is that I am glad I don't have to rely on your software. >>> It's one thing to be ignorant - but your blind, stubborn, wilful and >>> insistent ignorance is fortunately exceptional. >> >> You're a mega-idiot as you don't understand that error-handling isn't >> performance-crucial. >> > > If the result of not handling the error in time is someone gets killed, > maybe it is. And that is the point. (Though it is much broader than live-critical code.) Bonita seems to think the world runs on programs on desktops, where it is fine to have error messages popping up saying "There was an error saving the file to disk. Press OK to continue". For some programs, that kind of error handling is fine. But for some programs, it is /not/ fine at all, and /timely/ handling of errors is critical for your car to work, your telephone to work, your insulin pump to work, your cable TV service to work. > > 'Error' Handling often can be a critical part of the system (and > sometimes it isn't). > Yes. > The issue is that 'Generic' answers aren't always right, sometimes > certain things are important, and sometimes they are not. > I'd go further, and say that generic answers are wrong so often that they are simply "wrong". > In many cases, the cost of the exception path isn't that important, but > sometimes real WORSE case performance is, sometimes the error path may > have relaxed requirements, but sometimes it still has definite > requirements. > Exactly. A key concept here is "real time system". That is used to mean things happen within particular times - known, pre-determined times. Deadlines are hard - you don't get to miss them. It doesn't matter if a system is fast or slow, it matters that it is predictable and guaranteed. It doesn't matter if returning std::optional takes ten times as long as using exceptions in non-error situations, if it means you avoid the possibility of suddenly taking a thousand times as long, or the even worse possibility of not knowing how long the exception handling will take. Requirements about predictable and limited timing, even in the face of some kinds of problems or errors, are common in many types of coding. It doesn't have to be critical to live and health - it can be critical to business and economic effects too. And it can be critical to software being acceptable to users - games players are not keen on unexpected pauses in the middle of battles. > Exceptions can't be true Zero overhead, they may be able to push the > overhead into things that aren't important most of the time, but might > be important in some cases. The shifting of exception cost to static > data/code space and away from execution time is good in many cases, but > it does raise the cost of the exception path, sometimes significantly > (and perhaps too high of a cost). Error Return Values sometimes have the > advantage that the cost is up front and more directly controllable, the > cost of exceptions is very much fixed by the implementation, and not as > controllable. If your usage matches the cases that the implementation > optimized for, it can be good, if not, it may not be so good. > Absolutely.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-09-02 00:48 -0700 |
| Message-ID | <e522e802-417f-48ed-85e1-e5fccdd436bb@googlegroups.com> |
| In reply to | #145900 |
On Sunday, 1 September 2019 21:39:34 UTC+1, David Brown wrote: > On 01/09/2019 21:23, Richard Damon wrote: > > On 9/1/19 12:22 PM, Bonita Montero wrote: > > >> You're a mega-idiot as you don't understand that error-handling isn't > >> performance-crucial. > >> > > > > If the result of not handling the error in time is someone gets killed, > > maybe it is. > > > The issue is that 'Generic' answers aren't always right, sometimes > > certain things are important, and sometimes they are not. > > > > I'd go further, and say that generic answers are wrong so often that > they are simply "wrong". > Generally it's the case. If you need to be robust to an IO error on your insulin pump, you also need to be robust to a one second delay in reporting that error. However I'm sure that you can come up with some examples where performance in error handling code does make the difference between a functional and a non-functional system.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-02 06:47 +0200 |
| Message-ID | <qki6t6$3cg$1@news.albasani.net> |
| In reply to | #145899 |
> If the result of not handling the error in time is someone gets killed, > maybe it is. We're not discussing about error handling or not; wer're discussing the performance-impacts. > In many cases, the cost of the exception path isn't that important, but > sometimes real WORSE case performance is, sometimes the error path may > have relaxed requirements, but sometimes it still has definite > requirements. You don't have any clue what you're talking about. You simply fantasizing to emphasize your authority.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-09-02 11:12 -0400 |
| Message-ID | <kjabF.340436$oq9.177532@fx47.iad> |
| In reply to | #145902 |
On 9/2/19 12:47 AM, Bonita Montero wrote: >> If the result of not handling the error in time is someone gets killed, >> maybe it is. > > We're not discussing about error handling or not; > wer're discussing the performance-impacts. Yes, we are talking about the performance impact of error handling. > >> In many cases, the cost of the exception path isn't that important, but >> sometimes real WORSE case performance is, sometimes the error path may >> have relaxed requirements, but sometimes it still has definite >> requirements. > > You don't have any clue what you're talking about. > You simply fantasizing to emphasize your authority. > As an example, lets take sending data to the flight recorder in an airplane. Errors may well occur during this operation (perhaps one log fills so you need to switch to another). There may well be a piece of this in the critical control loops. If an error delays the loop, then perhaps some critical function fails, perhaps causing a loss of control of the system. Likely the critical control loop isn't directly communicating with the flight recorder, but with an intermediary operation to provide some buffering, but if the intermediary operation gets delayed too much in sending the data to the flight recorder, it might not service the control loop fast enough, causing the problems. I don't work on airplanes (but I do work with real time systems), so this exact case may not apply, but is a fairly graphic one which shows that in a real time system, even errors need to be handled within time limits. People who are used to 'PC' or 'Server' Class machines often don't understand the real time world, On the PC 0.1 second response is often good enough, maybe with a real-time interactive game it goes down to 0.01 seconds, and not meeting that time mark is just a minor 'performance' issue. In a true real time system the time period is often much shorter, and the cost of not meeting the time requirements are often much more significant, something stopped working.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-02 17:52 +0200 |
| Message-ID | <qkjdrt$l92$2@news.albasani.net> |
| In reply to | #145904 |
> As an example, lets take sending data to the flight recorder in an > airplane. Errors may well occur during this operation (perhaps one log > fills so you need to switch to another). There may well be a piece of > this in the critical control loops. If an error delays the loop, then > perhaps some critical function fails, perhaps causing a loss of control > of the system. Such systems have their critical resources allocated at startup that those situations don't occur.
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2019-09-02 18:43 +0200 |
| Message-ID | <qkjgre$1r9b$1@gioia.aioe.org> |
| In reply to | #145906 |
On 9/2/2019 5:52 PM, Bonita Montero wrote: >> As an example, lets take sending data to the flight recorder in an >> airplane. Errors may well occur during this operation (perhaps one log >> fills so you need to switch to another). There may well be a piece of >> this in the critical control loops. If an error delays the loop, then >> perhaps some critical function fails, perhaps causing a loss of control >> of the system. > > Such systems have their critical resources allocated at startup that > those situations don't occur. > You really can't get it, can you?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-09-02 13:05 -0400 |
| Message-ID | <DZbbF.173938$452.46165@fx02.iad> |
| In reply to | #145906 |
On 9/2/19 11:52 AM, Bonita Montero wrote: >> As an example, lets take sending data to the flight recorder in an >> airplane. Errors may well occur during this operation (perhaps one log >> fills so you need to switch to another). There may well be a piece of >> this in the critical control loops. If an error delays the loop, then >> perhaps some critical function fails, perhaps causing a loss of control >> of the system. > > Such systems have their critical resources allocated at startup that > those situations don't occur. > Out of Resources is not the only type of error that typcially generates an exception. Some would have critical I/O errors be reported back as exceptions (Remember the original discussion was Exceptions vs testing return values). If one write in a billion might generate the error condition, by many people that would be considered 'exceptional' and properly done with an exception. On a PC, if once every billion operations we got a slight additional delay to the user, that would be normally acceptable. If that one in a billion causes your airplane engine to stall in mid air, it wouldn't be.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-02 19:33 +0200 |
| Message-ID | <qkjjpm$nls$1@news.albasani.net> |
| In reply to | #145908 |
> Out of Resources is not the only type of error that typcially generates > an exception. Some would have critical I/O errors be reported back as > exceptions .. Have you considered the part of such an I/O-operation that might fail is the kernel-call that has a higher processing-overhead than the error -handling itself?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-09-02 17:16 -0400 |
| Message-ID | <bFfbF.152007$dp3.148953@fx05.iad> |
| In reply to | #145909 |
On 9/2/19 1:33 PM, Bonita Montero wrote: >> Out of Resources is not the only type of error that typcially generates >> an exception. Some would have critical I/O errors be reported back as >> exceptions .. > > Have you considered the part of such an I/O-operation that might fail > is the kernel-call that has a higher processing-overhead than the error > -handling itself? Kernel, what kernel. From my experience, most of the truly real time systems have nothing remotely like a *nix or Windows kernel anywhere in them. They are running on machines much smaller than your typical X86 processor which is focused on a particular job. I/O operations are quick an efficient, and there isn't the heavy security isolation of a large monolithic operating system. People whose world is all monolithic OS machines, with heavy isolation between processes and high costs of context switches to do many things may have trouble understanding the very different world of the smallish processor running much closer to bare metal to get the job done quickly, efficiently, and ON TIME. Different problems need different sorts of solutions which have different types of environments that they run under.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-03 06:49 +0200 |
| Message-ID | <qkkrcv$fui$2@news.albasani.net> |
| In reply to | #145912 |
>> Have you considered the part of such an I/O-operation that might fail >> is the kernel-call that has a higher processing-overhead than the error >> -handling itself? > Kernel, what kernel. From my experience, most of the truly real time > systems have nothing remotely like a *nix or Windows kernel anywhere > in them. He was talking about flight-computers. And almost every flight-computer uses VxWorks. And you don't have any "experience" on that.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-03 08:31 +0200 |
| Message-ID | <qkl1bm$ibe$1@dont-email.me> |
| In reply to | #145913 |
On 03/09/2019 06:49, Bonita Montero wrote: >>> Have you considered the part of such an I/O-operation that might fail >>> is the kernel-call that has a higher processing-overhead than the error >>> -handling itself? > >> Kernel, what kernel. From my experience, most of the truly real time >> systems have nothing remotely like a *nix or Windows kernel anywhere >> in them. > > He was talking about flight-computers. And almost every flight-computer > uses VxWorks. No, they don't. VxWorks is certainly a possible option for flight computers, but it is by no means dominant. Indeed, /no/ OS is dominant for such uses - you use redundant systems with different software and hardware. And he was talking about flight recorders (black boxes), not flight computers. > And you don't have any "experience" on that. Nor do you. The difference is, others understand their experiences and limitations, understand the differences in various fields of programming, and try to expand their knowledge beyond their fields (even when they never actually work on those systems). They don't extrapolate wildly from one small area of software, and they don't make wild claims with no evidence or reference.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-03 08:39 +0200 |
| Message-ID | <qkl1ro$746$1@news.albasani.net> |
| In reply to | #145914 |
> Nor do you. The difference is, others understand their experiences and > limitations, understand the differences in various fields of > programming, and try to expand their knowledge beyond their fields (even > when they never actually work on those systems). They don't extrapolate > wildly from one small area of software, and they don't make wild claims > with no evidence or reference. No one here has experience with systems where they think exception -handling should be inappropriate for performance-reasons; that's all pure phantasy.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-03 09:06 +0200 |
| Message-ID | <qkl3dk$ru6$1@dont-email.me> |
| In reply to | #145915 |
On 03/09/2019 08:39, Bonita Montero wrote: >> Nor do you. The difference is, others understand their experiences >> and limitations, understand the differences in various fields of >> programming, and try to expand their knowledge beyond their fields >> (even when they never actually work on those systems). They don't >> extrapolate wildly from one small area of software, and they don't >> make wild claims with no evidence or reference. > > No one here has experience with systems where they think exception > -handling should be inappropriate for performance-reasons; that's > all pure phantasy. Sorry, you are wrong again. I have worked on several systems where exception handling would have been ruled out for performance reasons (had the software been written in C++, rather than C). They would have been ruled out of those projects for several reasons, in fact - exceptions are often not suitable where you have tight safety requirements. (You'll be shocked to hear that dynamic memory is also banned in such software.) For most of my C++ projects, exceptions are not used at all. It would simply be unacceptable for there to be errors where throwing an exception could be at all useful - therefore any exception support is pure overhead, and they are disabled at the tool level.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web