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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-04 09:13 +0200 |
| Subject | Re: "?Rust is the future of systems programming, C is the new Assembly?: Intel principal engineer, Josh Triplett" |
| Message-ID | <qkno65$3bs$1@dont-email.me> |
| In reply to | #145952 |
On 04/09/2019 00:08, antispam@math.uni.wroc.pl wrote: > In comp.lang.c Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> have a project coming up with 2K flash and 128 byte ram on the device. >> >>> Such a device sounds fucktarded this day and age. Get a better device >>> or ask your employer to stop trolling you. >> >> On such a device C++ doesn't make sense. You can't use any heap so >> most of the standard-library can be omitted, stack is very limited >> also if there is any and won't get more maintainability over C. > > Look at Arduino. I will not argue that Arduino make sense. But > Arduino is used and Arduino uses C++ features. Quick check shows > that LED blinker example takes 1066 bytes of code. It uses > 9 bytes of static allocated RAM. I did not check RAM use for stack, > but there is good chance that stack + static use will fit in 128 > bytes. > > Arduino tries to make coding easy at cost of efficiency. There > are similar approaches getting more efficient and smaller code. > In particular there are examples which are much more complicated > that LED blinker that still fit into 2k code and 128 bytes RAM. > The Arduino libraries are, as you say, made with ease of use in mind. They use C++ primarily for encapsulation. So you open the serial port with "Serial.begin(9600);" and you send out data with "Serial.print(x);", where the "print" method is overloaded for different types. There is a lot to dislike about the Arduino libraries and software development environment - they are inefficient, limited, and hide a lot of detail and flexibility that would be useful to more experienced users. But they are for ease of use, rather than efficiency, and they are aimed at beginners, not experienced embedded programmers. > Coming back to C++, with small devices the idea is that you have > largish library of useful utility routines. Largish in the sense > that whole library is larger than the device. Writing program > you specialize library to specific purpose. Classes and templates > allow combinig parts of library in interesting ways. Inlining > and compiler optimizations allow reasonbly small object code. > Similar approach can be used with plain C, but then one may need > a "program generator" as first step. > Yes. There are lots of features of C++ that have no cost whatsoever in terms of code space, data space or run time. (Indeed the language is aimed at zero cost - a "std::vector" may take a lot of code space and require a heap, but so would the equivalent functionality in C.) Many features of C++ are more significant for larger code bases, but that doesn't mean they can't be useful for small code bases.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-03 21:50 +0200 |
| Message-ID | <qkmg64$2ln$1@dont-email.me> |
| In reply to | #145939 |
On 03/09/2019 19:51, Mr Flibble wrote: > On 03/09/2019 14:29, David Brown wrote: >> have a project coming up with 2K flash and 128 byte ram on the device. > > Such a device sounds fucktarded this day and age. Get a better device or > ask your employer to stop trolling you. > It is an entirely suitable device for the task in hand. It has plenty of flash and ram, has the required peripherals, is physically small (but not /too/ small), and costs about $0.35. There is a good, free C and C++ compiler (not entirely standards conforming, as you might expect - such as no exception support). It is the best device for the job. That's why I picked it. However, if you know my job better than me, know the microcontroller world better than me, know my customer better than me, and know this particular project and its requirements better than me, then maybe I should follow your advice. What would you recommend? An embedded Linux card, for example, so that it can run your gui library? It shouldn't increase the cost of the system by more than a few orders of magnitude, and the customer will surely be happy with a wallet-sized solution rather than a coin-sized solution. Or perhaps you simply haven't the faintest idea what you are talking about?
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| Date | 2019-09-03 22:43 +0100 |
| Message-ID | <U7BbF.103692$3s7.92204@fx01.fr7> |
| In reply to | #145945 |
On 03/09/2019 20:50, David Brown wrote: > On 03/09/2019 19:51, Mr Flibble wrote: >> On 03/09/2019 14:29, David Brown wrote: >>> have a project coming up with 2K flash and 128 byte ram on the device. >> >> Such a device sounds fucktarded this day and age. Get a better device or >> ask your employer to stop trolling you. >> > > It is an entirely suitable device for the task in hand. It has plenty of > flash and ram, has the required peripherals, is physically small (but not > /too/ small), and costs about $0.35. There is a good, free C and C++ > compiler (not entirely standards conforming, as you might expect - such as > no exception support). It is the best device for the job. That's why I > picked it. > > However, if you know my job better than me, know the microcontroller world > better than me, know my customer better than me, and know this particular > project and its requirements better than me, then maybe I should follow > your advice. What would you recommend? An embedded Linux card, for > example, so that it can run your gui library? It shouldn't increase the > cost of the system by more than a few orders of magnitude, and the > customer will surely be happy with a wallet-sized solution rather than a > coin-sized solution. > > Or perhaps you simply haven't the faintest idea what you are talking about? No I don't think you should choose a solution just so you can use a "gui library" as that would be just as fucktarded as your decision to use this antiquated technology. You chose wrong. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin “You won’t burn in hell. But be nice anyway.” – Ricky Gervais “I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-04 09:24 +0200 |
| Message-ID | <qknoqo$6sk$1@dont-email.me> |
| In reply to | #145951 |
On 03/09/2019 23:43, Mr Flibble wrote: > On 03/09/2019 20:50, David Brown wrote: >> On 03/09/2019 19:51, Mr Flibble wrote: >>> On 03/09/2019 14:29, David Brown wrote: >>>> have a project coming up with 2K flash and 128 byte ram on the device. >>> >>> Such a device sounds fucktarded this day and age. Get a better device >>> or ask your employer to stop trolling you. >>> >> >> It is an entirely suitable device for the task in hand. It has plenty >> of flash and ram, has the required peripherals, is physically small >> (but not /too/ small), and costs about $0.35. There is a good, free C >> and C++ compiler (not entirely standards conforming, as you might >> expect - such as no exception support). It is the best device for the >> job. That's why I picked it. >> >> However, if you know my job better than me, know the microcontroller >> world better than me, know my customer better than me, and know this >> particular project and its requirements better than me, then maybe I >> should follow your advice. What would you recommend? An embedded >> Linux card, for example, so that it can run your gui library? It >> shouldn't increase the cost of the system by more than a few orders of >> magnitude, and the customer will surely be happy with a wallet-sized >> solution rather than a coin-sized solution. >> >> Or perhaps you simply haven't the faintest idea what you are talking >> about? > > No I don't think you should choose a solution just so you can use a "gui > library" as that would be just as fucktarded as your decision to use > this antiquated technology. You chose wrong. > The device I picked is less than two years old. It is okay to be ignorant of technology outside your usual field. It is not okay to assume that you do, when it is clearly totally alien to you. Now you get to choose. You can accept that some people are knowledgeable and experienced in fields that are beyond your own understanding. Or you can write another silly, rude, arrogant response to further confirm that you don't appreciate your own limitations.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-09-03 11:03 -0700 |
| Message-ID | <lnftldw93b.fsf@kst-u.example.com> |
| In reply to | #145925 |
David Brown <david.brown@hesbynett.no> writes:
> 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?
[...]
David, might I suggest you not waste everyone's time arguing with this
person?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-03 22:14 +0200 |
| Message-ID | <qkmhi9$bhe$1@dont-email.me> |
| In reply to | #145941 |
On 03/09/2019 20:03, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> 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? > [...] > > David, might I suggest you not waste everyone's time arguing with this > person? > Yes, I think that is probably a good idea. I am not particularly happy with some of the posts in this thread, but I have still been trying to correct factual errors or fill in missing information.
[toc] | [prev] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2019-09-04 10:47 +1000 |
| Message-ID | <kQDbF.185496$Yo.136042@fx08.iad> |
| In reply to | #145925 |
On 3/9/19 11:29 pm, David Brown wrote: > 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. David, respect. Your reputation remains untarnished with me. But please, "someone is wrong on the Internet" is not a good reason to continue this. Bonita has that special kind of ignorance - willful ignorance. There's none so ignorant as one who chooses to be so. Clifford Heath
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-09-04 16:56 +1200 |
| Message-ID | <gt8ug0FnafoU1@mid.individual.net> |
| In reply to | #145955 |
On 04/09/2019 12:47, Clifford Heath wrote: > On 3/9/19 11:29 pm, David Brown wrote: >> 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. > > David, respect. Your reputation remains untarnished with me. > > But please, "someone is wrong on the Internet" is not a good reason to > continue this. Bonita has that special kind of ignorance - willful > ignorance. There's none so ignorant as one who chooses to be so. Well said! The snipping of attributions is a clear sign of willful ignorance which makes engagement pointless. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-09-04 09:37 +0200 |
| Message-ID | <qknpkh$ape$1@dont-email.me> |
| In reply to | #145955 |
On 04/09/2019 02:47, Clifford Heath wrote: > On 3/9/19 11:29 pm, David Brown wrote: >> 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. > > David, respect. Your reputation remains untarnished with me. > > But please, "someone is wrong on the Internet" is not a good reason to > continue this. Bonita has that special kind of ignorance - willful > ignorance. There's none so ignorant as one who chooses to be so. > > Clifford Heath <https://xkcd.com/386/> I'll continue with posts in reply to other people, but cut out my replies to Bonita (in this thread at least).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-09-03 05:37 -0700 |
| Message-ID | <86y2z5y2qx.fsf@mailhub.linuxsc.com> |
| In reply to | #145919 |
Richard Damon <Richard@Damon-Family.org> writes: > Exceptions work in many environments, but not all. [...] Could people please leave comp.lang.c off the list of newsgroups in threads discussing exceptions? Thank you.
[toc] | [prev] | [next] | [standalone]
| From | Hans im Glück <hig68@gmx.at> |
|---|---|
| Date | 2019-09-03 15:26 +0200 |
| Message-ID | <qklplm$qh0$1@news.albasani.net> |
| In reply to | #145921 |
>> Exceptions work in many environments, but not all. [...] > Could people please leave comp.lang.c off the list of newsgroups > in threads discussing exceptions? Thank you. Why? C is also an exceptional language! ;-)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-09-03 06:54 -0700 |
| Message-ID | <26c100df-4149-4ba2-8831-b0e2137d7df0@googlegroups.com> |
| In reply to | #145924 |
On Tuesday, 3 September 2019 14:26:22 UTC+1, Hans im Glück wrote: > >> Exceptions work in many environments, but not all. [...] > > > Could people please leave comp.lang.c off the list of newsgroups > > in threads discussing exceptions? Thank you. > > Why? C is also an exceptional language! ;-) > For C exceptions, we impose a rule that every function that can fail returns an error code. Then you use this pattern char *buffer = 0; int err = 0; err = foo(blah, blah, de, blah); if(err) goto error_exit; err = memoryallocation(blah, &buffer); if(err) goto error_exit; ... return 0; /* normal return */ error_exit: free(buffer): /* unwind the stack */ return err; /* return the error code */ } In theory C++ exceptions can beat this for efficiency, but in practice I doubt that they do so very often. The C++ destructors still need to be registered and called when the exception is thrown. However where C++ wins is that the code is clearer, and less likely that the programmer will make an error.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-03 16:08 +0200 |
| Message-ID | <qkls5m$n2g$1@news.albasani.net> |
| In reply to | #145930 |
>> Why? C is also an exceptional language! ;-)
#
> For C exceptions, we impose a rule that every function that can fail returns
> an error code.
>
> Then you use this pattern
>
> char *buffer = 0;
> int err = 0;
>
> err = foo(blah, blah, de, blah);
> if(err)
> goto error_exit;
> err = memoryallocation(blah, &buffer);
> if(err)
> goto error_exit;
>
> ...
>
> return 0; /* normal return */
> error_exit:
> free(buffer): /* unwind the stack */
> return err; /* return the error code */
> }
>
> In theory C++ exceptions can beat this for efficiency, but in practice
> I doubt that they do so very often.
Table-driven EH is always more efficient. With a proper implementation
the case of a non-thrown exception is zero.
And in C you would possibly change the type of return-code at every call
-level because the return-code of an inner function might not make sense
for the function calling the outer function.
The best exception-handling for my taste has Java.
1. It has checked exceptions. So you must handle an exception inside a
function or declare it as to be thrown to the calling function unless
it is a RuntimeException.
2. Exceptions can be concatenated, i.e. a function getting an exception
from another function can encapsulate it via
"throw new OuterException( inner )"; that's very convenient to
debug.
> I doubt that they do so very often. The C++ destructors still need to be
> registered and called when the exception is thrown.
Destructors won't have to be registered. They would be unwound by the
code at the end of the function or by the code handling an exception
which is referred to by the function-tables for table-driven EH; so
this are two distinct code-paths.
Before table-driven exception-handling the stack-frames of the functions
were concatenated with a linked list with a pointer to an unind handler.
A pointer to the top of this linked list is stored as thread-local.
[toc] | [prev] | [next] | [standalone]
| From | My nuts hurt <cdalten@gmail.com> |
|---|---|
| Date | 2019-09-03 07:16 -0700 |
| Message-ID | <3d2585fb-0c79-4181-a8ce-e332e567438d@googlegroups.com> |
| In reply to | #145924 |
On Tuesday, September 3, 2019 at 6:26:22 AM UTC-7, Hans im Glück wrote: > >> Exceptions work in many environments, but not all. [...] > > > Could people please leave comp.lang.c off the list of newsgroups > > in threads discussing exceptions? Thank you. > > Why? C is also an exceptional language! ;-) The language is exceptional at ramming you up the ass if you don't handle the memory deallocation crap correctly. This is why I use stuff like Python, PHP, and Java for a lot of my projects.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-09-03 19:07 +0200 |
| Message-ID | <qkm6jk$57b$1@news.albasani.net> |
| In reply to | #145934 |
>> Why? C is also an exceptional language! ;-) > The language is exceptional at ramming you up the ass if you don't handle the memory deallocation crap correctly. This is why I use stuff like Python, PHP, and Java for a lot of my projects. Ok, when you have such a desire to make painful and error-prone work, then program everything in assembly.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-09-04 06:12 -0700 |
| Subject | Re: Exceptions |
| Message-ID | <86d0ggxl1p.fsf_-_@mailhub.linuxsc.com> |
| In reply to | #145924 |
Hans <hig68@gmx.at> writes: >>> Exceptions work in many environments, but not all. [...] >> >> Could people please leave comp.lang.c off the list of newsgroups >> in threads discussing exceptions? Thank you. > > Why? C is also an exceptional language! ;-) It is customary in netnews postings to give attributions for quoted text. I am offering a polite request that you do so in future responses.
[toc] | [prev] | [next] | [standalone]
| From | My nuts hurt <cdalten@gmail.com> |
|---|---|
| Date | 2019-09-03 07:14 -0700 |
| Message-ID | <4e79861f-85b5-493e-9f96-4efd1f485fe5@googlegroups.com> |
| In reply to | #145916 |
On Tuesday, September 3, 2019 at 12:06:37 AM UTC-7, David Brown wrote: > 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. You obviously have never worked on any large scale, multi tier systems. Because the one that I worked out, I had to use exceptions because I needed to capture the state of a redirected webpage. If I didn't trap the exception, I would get the state of the original page, which in turn out have produced incorrect results. In addition, certain types of web browsers don't handle the bookmark icon correctly. Not handling this type of exception could not only lead to performance issues, but in addition, it could result in a possible security hole.
[toc] | [prev] | [next] | [standalone]
| From | Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> |
|---|---|
| Date | 2019-09-05 22:02 -0400 |
| Message-ID | <E7jcF.128337$GI3.37526@fx03.iad> |
| In reply to | #145915 |
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. Well, let's see here.. EPOC32 by Psion (later known as Symbian by Symbian consortium) was a decent RTOS for the time (could reliably mete out some 10 micros jobs at some 5-10 Mhz CPU -- not a small feat). "Decent" in a sense of well-written kernel and API *features* that is. The system gained a lot of traction, was running successful and significant consumer electronics (e.g. Psion Series 5 palmtop computer (more powerful than 16-bit Palm Pilot) and the Nokia "Communicators" series -- first seriously smart phones). BUT, they made an unfortunate decision to use a proprietary C++ API for accessing OS services (later they added some C POSIX level as an after-thought but it was half-hearted and too late so it did not save the baby). What was worse than just using C++ API and probably the crux of their problems and eventual death is that they decided (I am guessing that it was at advice of some C++ exception aficionado "expert") is to use exceptions exclusively to communicate OS call failures (remember, all these calls were C++ APIs). That is, the app programmers (hereinafter users) did not have a choice of using error code -- unless they did not use any OS services in their apps -- that was, well, never in my experience (killed a couple of years developing for the OS). To relate to your many times reiterated point that exception is something to use at I/O failure or resource exhaustion only, in my experience 99+% of system call failures fall squarely to this category. So I hope you agree (but please feel free to correct me if I am wrong) that the EPOC32 decision to use C++ exceptions to communicate system call failures shall agree with your recipe to C++ exception applications. Here is what happened next: Early in the game someone at Psion figured out (presumably from hard experience) that a) standard C++ exception handling mechanism with stack unwinding was too slow for RTOS, I/O errors or not b) that C++ lack of compile-time-checked exceptions was an invitation for unsafe, poorly tested and inscrutable software. Not to be scared (the origins of the system was British and then two Scandinavian nations and Japan jumped in so I guess Tor and samurai spirit were with them), they devised a solution to both of the above minor issues: -- They modified their embedded gcc port to not unwind C++ stack automatically (trust me this people knew a thing or two about performance and their RTOS beat all competition of GUI-capable RTOSes with accessible API at the time -- I should know because I did the comparison before deciding to go for it so they must have had a good reason to do such a labor consuming and controversial thing). Instead they provided a user-controlled API to "cleanup stack" where people would manually place their resources. This was supposed to cure a) (and I guess it did). -- they created a special naming convention for all functions whereas the function was affixed with L and/or C letters (by now I forgot whether they were prefices or suffices) to indicate whether a function may "leave" (in normal C++ terms, throw an exception) or must take care of its portion of cleanup stack at normal exit. This was supposed to mitigate b); you are free to guess how well it worked. ---- To HELP people in following the conventions, they created some code checker to check that L- functions can only be called from C- functions or whatever the implications were (can't recall this crap precisely now); and ---- To ENFORCE the convention in deployed APPs (and not give their pristine OS a bad name by sloppy app programming) they introduced (possibly for the first time in history or maybe it is just me who met this first with them) some production-ids that one had to receive from Psion (later, probably, Symbian consortium) after they verified the code for these (and other) conventions AND INDEPENDENTLY TESTED BY EPOC32 engineers and only apps with such production ids could be deployed on the devices and sold (this was mainly enforced legally, I think; but you can see Apple is no way first in this kind of bureaucracy in accepting an app for the platform; the only difference was, it did not cost this much with EPOC32 IIRC). Well, the results of these efforts is history. From my experience, C++-with-exceptions system API was absolutely the biggest reason for their death. From what I remember from their support mailing lists (that time social media), the C++ exceptions were by far most hated feature of the RTOS (truly, it did not have much else to complain about; much later it started to lag, mainly in GUI features; but this was obviously due to narrow acceptance by users (app developers) that in turn caused money issues). A failed (too late, too little) attempt to provide an alternative limited POSIX API (which is no way perfect in my opinion, even if they implemented complete POSX; but it would be infinitely better than C++ API with exceptions) is a proof that the management got it, too, eventually -- but too late to save it. What did it leave me with? Bitter after-taste for two lost could-be-productive years (well, almost, I designed non-EPOC32 software during that time, too) and life-long resolution to never use C++ exceptions for anything. Have been happy so far following it, never had to look back. Sometimes I start to think Java-style compile-time-checked exceptions would not be a bad addition to C++; but then I start to recall that, in practice, exception handling in Java was always wordier and not necessarily more readable than scoped status collectors and return codes in C++ (and measurably slower than return codes, even for Java land) and such my stupid thought leaves me. Now that std::optional and std::variant are being standardized (I guess, being borrowed from Haskel's Maybe and Either and Scala's Option and result) I feel like I almost have more tools under my belt for error handling than I will ever need. Bye-bye C++ exceptions, rest in peace.. -Pavel
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| Date | 2019-08-31 13:20 +0100 |
| Message-ID | <VBtaF.31507$VR.13450@fx03.fr7> |
| In reply to | #145862 |
On 30/08/2019 12:08, David Brown wrote: > > I'm happy with a claim "Table driven exceptions are generally faster, > when there are no errors, than other handling techniques for typical > code on PC's". What I am /not/ happy with is "Exception handling is > faster than other error return techniques". That statement just shows us that you are clueless on the subject of exceptions. Firstly exceptions are not just for errors. Secondly manually propagating an error code up the stack manually translating to make it suitable for one abstraction layer to the next is both an antiquated way of doing things and a fucktarded way of doing things. If you like error codes so much then stick to fucking C. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin “You won’t burn in hell. But be nice anyway.” – Ricky Gervais “I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-08-31 23:45 +0200 |
| Message-ID | <qkeppc$7ph$1@dont-email.me> |
| In reply to | #145886 |
On 31/08/2019 14:20, Mr Flibble wrote: > On 30/08/2019 12:08, David Brown wrote: >> >> I'm happy with a claim "Table driven exceptions are generally faster, >> when there are no errors, than other handling techniques for typical >> code on PC's". What I am /not/ happy with is "Exception handling is >> faster than other error return techniques". > > That statement just shows us that you are clueless on the subject of > exceptions. You are jumping in to a discussion without following the details. > Firstly exceptions are not just for errors. I realise that. The discussion was about error handling techniques, including alternatives to exceptions for handling errors. And of course, there is no single definition of "error" anyway - it means different things in different contexts. > Secondly > manually propagating an error code up the stack manually translating to > make it suitable for one abstraction layer to the next is both an > antiquated way of doing things and a fucktarded way of doing things. It is an excellent way of handling things in some cases. If you had been paying attention and read my posts before replying, you'd have seen I have argued that a variety of techniques can be useful in different cases - exceptions are often a good choice, but they are most certainly not always the right choice. > If > you like error codes so much then stick to fucking C. > Don't be such a child.
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web