Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #67978 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2019-08-28 16:11 -0500 |
| Last post | 2019-09-09 01:09 -0700 |
| Articles | 20 on this page of 165 — 31 participants |
Back to article view | Back to comp.lang.c++
"“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Lynn McGuire <lynnmcguire5@gmail.com> - 2019-08-28 16:11 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-29 02:36 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 11:02 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-29 22:21 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 13:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-29 23:35 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-29 20:00 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 13:29 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:04 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-08-29 23:11 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 10:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 07:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:54 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:07 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-08-29 05:14 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-29 06:08 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:10 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 01:00 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:16 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 01:26 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 06:30 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:59 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-30 07:42 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 14:44 +0000
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:07 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-03 17:13 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 14:53 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" gazelle@shell.xmission.com (Kenny McCormack) - 2019-08-29 13:14 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-29 15:38 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:09 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-04 08:31 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:55 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 13:28 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-06 02:36 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 08:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:38 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 08:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:18 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 10:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 10:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 11:41 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 11:56 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-30 13:08 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@invalid.add> - 2019-08-31 18:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 18:21 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 05:16 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-01 03:21 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 12:25 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 12:35 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-09-01 04:13 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-01 23:18 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 14:04 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 07:20 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-01 18:22 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-01 15:23 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 22:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 06:47 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 11:12 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 17:52 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-02 18:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 13:05 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-02 19:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-02 17:16 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 06:49 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 08:31 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 08:39 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 09:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 09:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 10:30 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Richard Damon <Richard@Damon-Family.org> - 2019-09-03 07:11 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 13:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 15:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:42 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 15:51 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-03 17:35 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 17:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 18:51 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:03 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:42 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-05 16:56 +0000
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 11:07 -0700
Re: Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-05 19:23 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-06 08:25 +0200
Re: Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-18 16:55 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-06 07:10 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-06 17:16 +1200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-03 20:33 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:38 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" antispam@math.uni.wroc.pl - 2019-09-03 22:08 +0000
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:41 +0200
Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:13 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 21:50 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-09-03 22:43 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Keith Thompson <kst-u@mib.org> - 2019-09-03 11:03 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-03 12:16 -0700
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-03 20:35 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-09-03 22:49 -0700
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-04 00:20 -0700
Re: Comments on third parties Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-09-07 06:59 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-05 17:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 09:03 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Manfred <noname@add.invalid> - 2019-09-05 20:18 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-05 17:16 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Daniel <danielaparker@gmail.com> - 2019-09-05 14:40 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-06 10:05 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:33 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-03 22:14 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Clifford Heath <no.spam@please.net> - 2019-09-04 10:47 +1000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-04 16:56 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-04 09:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2019-09-05 22:02 -0400
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-08-31 13:20 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-08-31 23:45 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 14:08 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 13:37 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 13:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-30 15:18 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 14:24 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:23 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-08-30 14:40 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 16:57 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 19:19 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Anton Shepelev <anton.txt@gmail.com> - 2019-08-31 03:05 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 12:18 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 11:43 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-08-31 17:17 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-31 16:28 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 00:06 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Paavo Helde <myfirstname@osa.pri.ee> - 2019-09-01 15:49 +0300
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-01 16:12 +0200
Error handling strategies (was: Rust is the future of systems programming C is the new Assembly) legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 20:14 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-08 20:29 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Mel <mel@zzzzz.com> - 2019-08-30 15:42 +0200
Re: "???Rust is the future of systems programming, C is the new Assembly???: Intel principal engineer, Josh Triplett" Juha Nieminen <nospam@thanks.invalid> - 2019-08-30 21:03 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-08-31 09:42 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-08-30 23:53 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 06:24 -0500
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-06 13:51 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-06 22:03 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@hotmail.com> - 2019-09-07 10:57 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:17 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-07 18:48 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Ian Collins <ian-news@hotmail.com> - 2019-09-08 12:40 +1200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" David Brown <david.brown@hesbynett.no> - 2019-09-09 08:59 +0200
Re: Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" scott@slp53.sl.home (Scott Lurndal) - 2019-09-09 16:35 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bart <bc@freeuk.com> - 2019-09-07 18:09 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" BGB <cr88192@gmail.com> - 2019-09-07 15:32 -0500
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Öö Tiib <ootiib@hot.ee> - 2019-08-31 04:50 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" legalize+jeeves@mail.xmission.com (Richard) - 2019-09-03 18:39 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-03 20:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-09-04 01:07 +0100
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" William Ahern <william@25thandClement.com> - 2019-09-03 20:04 -0700
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Bonita Montero <Bonita.Montero@gmail.com> - 2019-09-04 06:46 +0200
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" Melzzzzz <Melzzzzz@zzzzz.com> - 2019-09-04 04:48 +0000
Re: "“Rust is the future of systems programming, C is the new Assembly”: Intel principal engineer, Josh Triplett" "Chris M. Thomasson " <chris.m.thomasson.1@gmail.com> - 2019-09-09 01:09 -0700
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| 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 | #68078 |
> 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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-09-01 15:23 -0400 |
| Message-ID | <YUUaF.66291$id3.64167@fx12.iad> |
| In reply to | #68081 |
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 | #68083 |
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 | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-02 06:47 +0200 |
| Message-ID | <qki6t6$3cg$1@news.albasani.net> |
| In reply to | #68083 |
> 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 | #68095 |
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 | #68128 |
> 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 | #68130 |
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 | #68130 |
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 | #68132 |
> 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 | #68133 |
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 | #68139 |
>> 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 | #68146 |
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 | #68150 |
> 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 | #68151 |
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]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-03 09:19 +0200 |
| Message-ID | <qkl46k$2ht$1@news.albasani.net> |
| In reply to | #68152 |
> 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). I don't believe you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-03 10:30 +0200 |
| Message-ID | <qkl8al$kps$1@dont-email.me> |
| In reply to | #68153 |
On 03/09/2019 09:19, Bonita Montero wrote: >> 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). > > I don't believe you. > I don't care.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-09-03 07:11 -0400 |
| Message-ID | <mTrbF.97476$to5.77862@fx04.iad> |
| In reply to | #68153 |
On 9/3/19 3:19 AM, Bonita Montero wrote: >> 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). > > I don't believe you. > The fact that you haven't encountered significantly tight real-time requirements doesn't mean they don't exist. I can say from experience that there ARE cases with rules like this, and they have good grounds to exist. Exceptions work in many environments, but not all. Error code returns work in many environments too. Which methods are usable, and which methods are good to use, and which method is best, are VERY subject to the domain you are working in. To think that one method is best everywhere is very myopic, and says that one has been in just a small part of the total space of programming.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-03 13:17 +0200 |
| Message-ID | <qkli44$8ln$1@news.albasani.net> |
| In reply to | #68158 |
>> I don't believe you. > The fact that you haven't encountered significantly tight real-time > requirements doesn't mean they don't exist. The folks here are Nerds without any experience on that. And if there are any circumstances that would make error-handling through exception not feasible because they would be too slow, this would be very rare. Thus it is not credible that david would have many of such experiences. He is simply a liar!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-03 15:29 +0200 |
| Message-ID | <qklprd$oag$1@dont-email.me> |
| In reply to | #68159 |
On 03/09/2019 13:17, Bonita Montero wrote: >>> I don't believe you. > >> The fact that you haven't encountered significantly tight real-time >> requirements doesn't mean they don't exist. > > The folks here are Nerds without any experience on that. And you base that on what evidence? There are people in this group with experience of all sorts of systems. There are people who have programmed tiny systems. My own record for small devices was 1K flash and no ram (programmed in C with gcc). I have a project coming up with 2K flash and 128 byte ram on the device. There are people here who have programmed mainframes, supercomputers, operating systems, hypervisors, games, simulators, emulators, programming languages. There are people who have programmed safety-critical systems or high reliability systems (I have personally worked on a couple of systems where mistakes could cost lives, and several more where mistakes cost millions. I know I am not alone in that in this group). And of course there are also those who have "only" worked on PC software, or who are students, or hobby programmers, or academics. > And if there > are any circumstances that would make error-handling through exception > not feasible because they would be too slow, this would be very rare. No one has denied that it is unusual for the speed of exceptions to be the reason they can't be used in a project. It is far, far more important that the speed is unpredictable and you cannot (with any sane level of effort) be sure of the limits. You don't understand what "real time" means - please try to learn a little from other people, rather than parading your ignorance. > Thus it is not credible that david would have many of such experiences. > He is simply a liar! > Really? You have extrapolated from your own experiences and limited knowledge, and made wild and unjustified comments about programming domains well beyond your ken. You combine that with continuous and apparently wilful misreading of my posts, and that's your conclusion? So tell me, /why/ do you think I am lying? Do you think I am trying to appear impressive and gain respect? From whom? The people in this group whose opinion I respect are not impressed by lies or exaggerations, and are usually quite good at spotting them. It should be quite obvious that I have little respect for /you/ at the moment, and therefore no interest in trying to impress you. My interest in this discussion has been about sharing experiences and knowledge, and perhaps giving people something to think about or some ideas of programming issues beyond those that are familiar to them from before, and maybe correcting some misconceptions. That is usually what I look for myself in discussion threads. It is painfully clear, however, that you are unteachable - your reaction to being shown something new is denial and insults. This is a shame, and I hope you will realise it and make an effort to change.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-03 15:42 +0200 |
| Message-ID | <qklqkg$o37$1@news.albasani.net> |
| In reply to | #68160 |
Liar!
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c++
csiph-web