Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140381 > unrolled thread
| Started by | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| First post | 2019-01-29 10:50 -0800 |
| Last post | 2019-02-19 18:19 -0600 |
| Articles | 20 on this page of 380 — 25 participants |
Back to article view | Back to comp.lang.c
"...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 10:50 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-01-29 20:30 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 14:47 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 16:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 18:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-01-30 05:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-30 14:06 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Manfred <noname@add.invalid> - 2019-01-30 15:07 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-30 06:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Manfred <noname@add.invalid> - 2019-01-30 17:12 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-30 14:42 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-30 11:19 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 11:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 14:32 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 16:24 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 12:13 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-29 12:20 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 15:08 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-29 21:38 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 19:01 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-30 11:27 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-30 04:18 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-30 11:00 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 14:18 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-30 14:34 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-30 23:12 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-01-31 15:44 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-30 19:00 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" scott@slp53.sl.home (Scott Lurndal) - 2019-01-31 14:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-31 09:44 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-01-31 23:15 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-30 15:11 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 14:12 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-29 22:46 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 14:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-01-29 16:27 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-01-29 16:48 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-29 16:13 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-01-30 16:57 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Manfred <noname@add.invalid> - 2019-01-30 18:04 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-30 17:35 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-01-30 19:23 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-01-31 03:25 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-01-31 08:53 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" scott@slp53.sl.home (Scott Lurndal) - 2019-01-31 14:35 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 12:52 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-01-31 18:19 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-31 09:55 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-01-31 19:53 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-02-01 13:24 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-01 12:15 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-02-04 12:08 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 11:14 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-04 03:40 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-02-04 15:24 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-04 12:03 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 22:34 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ike Naar <ike@sdf.lonestar.org> - 2019-02-04 22:00 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 21:32 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-04 12:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 22:06 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-04 23:30 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-05 13:27 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-05 14:36 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-05 16:50 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-05 18:44 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-06 08:23 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-05 12:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-06 09:51 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-05 13:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 01:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-06 22:44 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 02:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-02-06 17:39 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 10:39 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-07 07:58 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 22:45 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-26 08:44 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 08:03 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-26 15:29 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-07 07:59 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 12:07 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 03:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 13:36 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 04:44 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 05:40 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 05:50 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 06:03 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 06:22 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 15:54 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 10:40 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 05:56 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 16:04 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 00:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-07 09:39 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 10:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 19:55 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-07 23:27 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 16:35 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-08 02:02 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 16:10 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 02:37 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 14:06 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-07 12:01 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 21:55 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-07 23:17 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 16:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-08 02:04 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-08 01:39 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-08 11:42 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-08 03:07 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-08 03:10 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-08 13:43 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-08 06:47 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-08 17:56 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-08 10:27 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-10 05:01 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-10 16:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-10 09:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-11 02:34 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-11 09:54 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-11 12:35 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-11 14:03 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-11 14:53 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 16:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 02:57 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 22:24 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 14:25 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 08:50 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-11 01:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-11 13:53 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-11 08:01 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-11 17:01 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-11 11:30 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-12 01:40 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-12 01:51 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-12 12:13 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-12 03:39 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-12 16:27 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-12 07:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 09:50 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-12 21:13 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-02-12 21:52 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 01:30 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 11:52 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 03:29 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 13:26 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 11:41 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-13 05:26 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 05:32 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 14:34 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-12 16:09 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-12 08:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 04:40 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 02:05 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-13 02:55 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 03:32 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-13 03:36 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 13:32 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 06:30 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 16:10 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 07:21 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 16:38 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-13 11:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 21:27 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-14 00:55 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-14 02:41 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-14 03:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 15:12 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-14 07:28 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-15 01:06 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-24 20:47 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-24 13:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-25 02:26 -0800
Wow... (Was: "...the value becomes,indeterminate each time the declaration is reached") gazelle@shell.xmission.com (Kenny McCormack) - 2019-02-25 12:12 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 15:46 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-13 08:15 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 18:07 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-11 13:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-10 12:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-10 13:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-10 13:59 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-10 17:50 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 15:17 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-02-25 17:38 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 21:40 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-26 01:37 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-02-11 20:24 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 10:41 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 14:47 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-06 07:51 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 05:12 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 05:22 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-06 05:51 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-07 10:33 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-05 21:24 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 00:24 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-06 14:13 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 08:56 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-05 23:59 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-06 00:15 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 08:25 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-06 11:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 14:41 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-06 14:17 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-06 06:37 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-06 16:10 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-04 14:48 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-04 22:09 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-05 10:19 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-04 22:05 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 12:10 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-13 08:47 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-12 12:41 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 20:55 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-13 10:07 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 21:53 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-13 11:01 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-16 15:09 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-16 16:33 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-16 16:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-16 16:52 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-16 18:20 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-16 20:00 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-17 08:54 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-16 23:23 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-17 12:31 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-17 00:34 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-17 14:26 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-17 01:45 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-17 20:12 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-17 11:23 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-12 23:00 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-12 14:12 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 22:44 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-12 23:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-13 12:51 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 01:13 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-14 07:39 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 19:54 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-14 16:30 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 13:17 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 15:19 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 14:45 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 16:10 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 16:38 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 20:24 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-14 07:17 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 20:28 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-14 12:05 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-15 01:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-14 06:29 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-14 14:19 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-15 01:33 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Manfred <noname@invalid.add> - 2019-02-18 19:33 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-18 18:53 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-18 19:05 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-18 20:11 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-18 19:25 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-18 21:39 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-14 19:22 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-15 02:14 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 15:53 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-15 09:27 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 10:02 +0100
Just an end-user... (Was: "...the value becomes,indeterminate each time the declaration is) reached" gazelle@shell.xmission.com (Kenny McCormack) - 2019-02-13 09:13 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 11:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 13:37 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 14:21 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 16:32 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-13 15:18 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-13 16:36 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-13 23:09 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 01:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 02:35 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 10:00 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 12:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 15:22 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 15:02 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 16:23 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 17:03 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 20:41 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 21:23 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-15 10:38 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 22:53 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-14 08:19 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-14 20:45 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Öö Tiib <ootiib@hot.ee> - 2019-02-15 02:32 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-15 11:51 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 16:47 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 17:18 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 17:48 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 19:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" scott@slp53.sl.home (Scott Lurndal) - 2019-02-14 20:21 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 21:20 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-14 22:24 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-15 00:18 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-15 01:29 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-15 08:14 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-15 07:03 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-15 04:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" mark.bluemel@gmail.com - 2019-02-15 05:26 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-15 16:37 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 14:24 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-15 14:07 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-15 07:02 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-15 17:06 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-15 08:10 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 21:45 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 14:16 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 15:04 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-26 15:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-26 12:06 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-26 21:05 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-26 13:55 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-27 06:41 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-27 12:33 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Richard Damon <Richard@Damon-Family.org> - 2019-02-27 08:18 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-27 14:02 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 21:18 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-27 02:41 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" luser droog <luser.droog@gmail.com> - 2019-02-26 19:13 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 22:29 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-27 09:33 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-27 07:41 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-27 14:15 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-27 07:02 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-27 17:18 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-28 15:05 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-07 11:24 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-03-21 11:13 +0000
Re: Readability (was: "...the value becomes,indeterminate each time the declaration is reached") Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-21 23:25 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-24 03:01 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 16:03 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ian Collins <ian-news@hotmail.com> - 2019-02-26 17:38 +1300
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-04 21:31 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-02-01 02:38 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-02-01 01:57 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-02-01 13:26 +0300
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-01 07:18 -0500
The look of C (Was: "...the value becomes,indeterminate each time the declaration is) reached" gazelle@shell.xmission.com (Kenny McCormack) - 2019-02-01 14:26 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-01 14:32 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-01 06:54 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-01 16:42 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 09:56 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-01 18:09 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 10:31 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 10:58 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-01 12:47 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-02 16:18 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-01 21:52 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-01 23:52 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-02 01:00 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-01 16:41 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-02 02:00 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 15:10 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" scott@slp53.sl.home (Scott Lurndal) - 2019-02-01 14:36 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-01 07:05 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-02-25 22:30 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" gazelle@shell.xmission.com (Kenny McCormack) - 2019-02-26 12:37 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 09:09 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-26 05:50 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-06 09:06 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-06 10:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-03-23 10:27 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-03-25 12:14 -0700
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-02-01 09:43 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" nobody@example.org (Scott) - 2019-01-31 03:46 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-30 22:49 -0500
Re: "...the value becomes,indeterminate each time the declaration is reached" Andrey Tarasevich <andreytarasevich@hotmail.com> - 2019-01-30 20:08 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-02-10 09:11 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" John Bode <jfbode1029@gmail.com> - 2019-02-19 10:23 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-19 22:55 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-19 15:48 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" Bart <bc@freeuk.com> - 2019-02-20 00:10 +0000
Re: "...the value becomes,indeterminate each time the declaration is reached" Keith Thompson <kst-u@mib.org> - 2019-02-19 16:42 -0800
Re: "...the value becomes,indeterminate each time the declaration is reached" David Brown <david.brown@hesbynett.no> - 2019-02-20 13:05 +0100
Re: "...the value becomes,indeterminate each time the declaration is reached" Robert Wessel <robertwessel2@yahoo.com> - 2019-02-20 10:30 -0600
Re: "...the value becomes,indeterminate each time the declaration is reached" Robert Wessel <robertwessel2@yahoo.com> - 2019-02-19 16:05 -0600
Re: "...the value becomes,indeterminate each time the declaration is reached" Robert Wessel <robertwessel2@yahoo.com> - 2019-02-19 18:19 -0600
Page 4 of 19 — ← Prev page 1 2 3 [4] 5 6 … 19 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-04 22:06 +0100 |
| Message-ID | <q3a9fq$t2$1@dont-email.me> |
| In reply to | #140514 |
On 04/02/2019 13:32, Bart wrote: > On 04/02/2019 10:14, David Brown wrote: > >> And in my opinion, Bart's points fall into several categories (with many >> overlaps): > >> He also wants to limit his coding style to work with >> Windows Notepad, rather than better tools (there are only a few thousand >> better programmer's editors to choose from, assuming you restrict >> yourself to free Windows tools). > I use my own editor which works just the way I want (with hard stops at > the line ends etc) and which supports my own syntax. Pretty much all > other editors lack the hard stops (editing continues onto adjacent > lines) and none of them support my syntax. That makes it far more > valuable to me than any other editor. That's your choice, of course. There are lots of editors that can be configured for syntax highlighting of any language, including ones you make yourself. This will typically be somewhat simplistic (syntax highlighting for keywords, numbers, identifiers, comments, strings, etc.) but it might be enough for you. However, we were talking about C editors and IDEs. > >> Limited language - Bart uses only a subset of C, and rejects several >> features for reasons that presumably make sense to him, even though they >> make no sense to me. Amongst these is "const". I do not know if he >> rejects "const" because it would mean defining "const" variables when >> you are ready to initialise them rather than at the top of a function, >> or if he rejects mixing variable declarations and code because it would >> allow him to use "const". > > 'const' is too crude, it has limitations, it is not fail-safe, it > generates clutter, and tends to be overused in other people's code. > "const" is not perfect, I can agree on that. C++ "const" is better, but it too has its limitations (hence "constexpr", and upcoming "consteval"). However, those limitations seem a poor excuse not to use it - it is /vastly/ better and safer than not using it. > (I'm looking at better alternatives in a new language I'm putting > together. I don't reject the idea, only C's approach.) For designing a new language, you should learn about existing ones - learn what C's "const" is, what it does, why it is useful, and where it is limited. Learn about C++'s "const", and its pros and cons. /Then/ you can make a better one. (IMHO, you should start with the assumption that everything is immutable and constant unless specifically marked as variable.) > >> And then there are stylistic arguments - which are, of course, opinion >> and preference, and he is entitled to those. As far as I can see, the >> /single/ valid point Bart has made here is "I put local variable >> definitions at the start of code because it is a style that I am >> comfortable with - I find it easier to read the code and easier to write >> the code". There is no need to present a list of "justifications" for >> that, and certainly no benefit in giving a list like Bart's. > > Replace "I" with "most people". I could do that - but then I think it would be incorrect. Do you have any evidence to suggest that "most people" think putting definitions at the start of functions makes code more readable or easier to write? Note that it is not enough to show code samples here - a lot of C code is written to be C90 compatible, and thus cannot have mixed statements and declarations. So there it is a requirement, not a choice. I can't say I have any statistics, surveys, reports or studies saying which method is most popular, or if one has been shown to be better than the other. There are plenty of google hits of people asking which method is best, with the answer invariably being "define your variables when you need them, not at the start of the function". And for C++ (and other languages such as C# and Java) there is no doubt - you should /never/ define your local variables before you initialise them, unless it is unavoidable. > >> As with everything else in coding style, you either write in the style >> you are told to, or you write in the style you want to. > > I generally code in my own language. That also allows declarations > anywhere, so I don't reject the idea completely. But that's rarely used, > mainly for temporary debug code (and it has some limitations I won't go > into). > > There is one big difference however between my language and C: I don't > have block scopes. So if I have a variable "A" used in one place, and a > declaration for "A" in another, then I KNOW they refer to the same A. > If you don't have block scopes, then there is a reasonable argument for defining variables only at the top of functions - it will avoid the confusion of looking like you have block scope (or block lifetime). Of course, the real question is why don't you have block scopes? > If, in C, you had to document all the local variables, in general that > wouldn't be possible, because every block can define its own version of > "A". Block variables in C are actually anonymous (if there are two > instances of "A", how do you disambiguate them in speech or in text?) Of course it is possible to document your local variables, no matter what the scope. And it is possible to read code with block scope variables. However, unless you are seriously vision impaired (and blind programmers do exist), the idea of listening to code being spoken out loud, rather than reading it, is close to absurd. It was conceivable before email and the Internet was common, but you can't honestly expect anyone to believe you base coding style on how you read code out loud. If you want to, there is nothing stopping you using different names for your local variables in small scopes. You are even allowed to use several letters - you don't /have/ to call them all "A" just because the language allows that. > > BTW in my language, you don't need to declare all the locals at the top > of a function; you can put them all at the end if you like! > And do you think this is an improvement? If not, why do you allow it? > These out-of-order declarations, and the single function-wide scope, > takes care of several of my 13 points, and actually makes my language > more suitable than C if you do want to mix declarations with code. > You don't have block scope. That puts your language at the bottom of the heap.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-04 23:30 +0000 |
| Message-ID | <sW36E.455967$kE1.110872@fx20.am4> |
| In reply to | #140525 |
On 04/02/2019 21:06, David Brown wrote: > On 04/02/2019 13:32, Bart wrote: >> (I'm looking at better alternatives in a new language I'm putting >> together. I don't reject the idea, only C's approach.) > > For designing a new language, you should learn about existing ones - > learn what C's "const" is, what it does, why it is useful, and where it > is limited. I know how 'const' works (I've had to implement it). > Learn about C++'s "const", and its pros and cons. The one useful lesson to be learned from C++ is how not to design a language. (I think others have too as few new languages are as crazily complex.) > you can make a better one. (IMHO, you should start with the assumption > that everything is immutable and constant unless specifically marked as > variable.) (In my new syntax, every variable declaration starts with 'var'. I think that's enough of a clue that it might be variable.) > Of course, the real question is why don't you have block scopes? See below. But seriously, is it worth the bother for a 20-line function? Maybe one of the parameters is only used inside one block, but you can't make it visible only in that block. Does anybody care? No. So who cares about any other locals. (And note the name 'locals'; how much more local do they have to be!) I consider that a function where all locals share the one scope (instead of an infinite of scopes for variables, all of different types, an infinite number for struct/enum tags, and an infinite number for labels), is much easier to read. You spot "x" in one place, and "x" in another, and you KNOW they are the same variable with the same type; when you find a declaration for "x", you KNOW it's the right one. > Of course it is possible to document your local variables, no matter > what the scope. Remote from the function? How do you distinguish between 3 different locals all called "A"? > If you want to, there is nothing stopping you using different names for > your local variables in small scopes. You are even allowed to use > several letters - you don't /have/ to call them all "A" just because the > language allows that. "A" represents any name. "A" and "A" represent any two identical names. Etc. > And do you think this is an improvement? If not, why do you allow it? For the same reason that, when you define function F, you can add it at the start of a module, or at the end, or anywhere else, including inside other entities. If you are reading a book, then it is common for a glossary or index to go at the end. > You don't have block scope. That puts your language at the bottom of > the heap. Block scopes are an abomination (IMO). Why allow an infinite number of scopes inside functions that most people agree need to be kept compact anyway? And if you don't reuse the same name in different blocks, then there is less need to have them at all. In place of block scopes I have module scopes (where modules A and B can each share a function F, and modules C and D can also share a different function also called F). And I can put things inside their own name-space, which creates another scope (this is encroaching on C++ territory now). These other new scopes are far more useful than block scopes. And not just in IMO, because they enable some new things that are otherwise awkward to do, unlike block scopes which add nothing at all, apart from the dubious ability to overload the same identifier name.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-05 13:27 +0100 |
| Message-ID | <q3bvfe$u96$1@dont-email.me> |
| In reply to | #140530 |
On 05/02/2019 00:30, Bart wrote:
> On 04/02/2019 21:06, David Brown wrote:
>> On 04/02/2019 13:32, Bart wrote:
>
>>> (I'm looking at better alternatives in a new language I'm putting
>>> together. I don't reject the idea, only C's approach.)
>>
>> For designing a new language, you should learn about existing ones -
>> learn what C's "const" is, what it does, why it is useful, and where
>> it is limited.
>
> I know how 'const' works (I've had to implement it).
Your characteristic of it does not give that impression. (But that is
true of several features of C.)
>
>> Learn about C++'s "const", and its pros and cons.
>
> The one useful lesson to be learned from C++ is how not to design a
> language. (I think others have too as few new languages are as crazily
> complex.)
And there you have totally, and completely missed my point.
I did not say "copy C++". I did not even say "copy C++ const". I said
learn about it, and see what you can take from it. Running away in
panic because C++ code looks complicated is not a particularly helpful
attitude.
>
>> you can make a better one. (IMHO, you should start with the
>> assumption that everything is immutable and constant unless
>> specifically marked as variable.)
>
> (In my new syntax, every variable declaration starts with 'var'. I think
> that's enough of a clue that it might be variable.)
>
Yes, that is not a bad choice - as long as it is easy to make constant
immutable data, and that is encouraged by the language and by style.
Note that of course this means declarations need to be mixed with code.
One possibility here is that you could omit the need for explicit
definition for constants. Since they could only ever be set once (by
initialisation), and could only be used after this, there is no risk of
problems from typos that can be difficult to spot in languages like
Python where variable definitions and declarations are not needed. If
you distinguish variable assignment as "=" and initialisation as ":=",
and require variable declarations, then you get a syntax that makes
mistakes harder. Types could be inferred in most cases, with optional
explicit typing when you want it:
func sum_of_powers(count : integer, power : integer) : big_integer
{
var total : big_integer := 0;
for i in 1 .. count {
p : big_integer := i ** power;
total += p;
}
return total;
}
There is no need to declare "i" - it is constant within its scope
(inside the for loop). Similarly, there is no need to declare "p", but
here we give it a specific type. Only variables may be changed after
initialisation, and they need to be declared (with "var").
>> Of course, the real question is why don't you have block scopes?
>
> See below. But seriously, is it worth the bother for a 20-line function?
Yes.
> Maybe one of the parameters is only used inside one block, but you can't
> make it visible only in that block. Does anybody care? No.
Parameters are not small, local variables - they are part of the
interface of the function. (One thing that irritates me a little in C
is that parameters are not const by default. It does not irritate me
enough to declare them with const - that would add clutter.)
> So who cares
> about any other locals. (And note the name 'locals'; how much more local
> do they have to be!)
They should be local to a block.
One thing I would have liked to see in C would be the ability to
re-define a variable (or const) inside the same block:
{
int x = a + b;
foo(x);
int x = 2 * a + b;
foo(x);
}
I would like this to act exactly as if I had written:
{
int x1 = a + b;
foo(x1);
int x2 = 2 * a + b;
foo(x2);
}
I am not sure if this would have any repercussions - I have not thought
about it enough.
>
> I consider that a function where all locals share the one scope (instead
> of an infinite of scopes for variables, all of different types, an
> infinite number for struct/enum tags, and an infinite number for
> labels), is much easier to read. You spot "x" in one place, and "x" in
> another, and you KNOW they are the same variable with the same type;
> when you find a declaration for "x", you KNOW it's the right one.
>
>> Of course it is possible to document your local variables, no matter
>> what the scope.
>
> Remote from the function? How do you distinguish between 3 different
> locals all called "A"?
>
Why would you be doing that in the first place? If you have independent
documentation that goes into that level of detail about the function
implementation, then you probably have a poor choice of function
structuring - or functions that are too complicated. You have an
extremely high risk of getting the code and documentation out of sync.
Using doxygen (or similar tools) and comments in the code is likely to
be a much safer and simpler solution.
But if you /do/ want to make such documentation, just use different
names for your local variables. As noted below, you do not have to call
them all "A".
>> If you want to, there is nothing stopping you using different names
>> for your local variables in small scopes. You are even allowed to use
>> several letters - you don't /have/ to call them all "A" just because
>> the language allows that.
>
> "A" represents any name. "A" and "A" represent any two identical names.
> Etc.
Try - just for a laugh - to imagine that people can pick /different/
names. Block scope means you /can/ repeat the name - and that is a
convenient thing for loop variables called "i". It does not mean you
/must/ repeat the name.
>
>> And do you think this is an improvement? If not, why do you allow it?
>
> For the same reason that, when you define function F, you can add it at
> the start of a module, or at the end, or anywhere else, including inside
> other entities.
>
Defining local functions inside other functions can be nice (but it can
be a can of worms), but /only/ if the scope is local to the function.
Being able to order your file-level functions as you want, without
forward declarations, could be convenient for many people. It is not
something I feel is missing in C, in the way I code, but I can
appreciate people liking it.
Being able to order variable definitions within a function? I can't see
the point at all.
> If you are reading a book, then it is common for a glossary or index to
> go at the end.
That would make some vague sense (not much, but some) if it were
consistent - if your language insisted that variables were always
declared at the end of the function. But you allow them anywhere, in
any order - yet you complain that it is "chaotic" when C programmers
define them anywhere but the start of a function.
>
>> You don't have block scope. That puts your language at the bottom of
>> the heap.
>
> Block scopes are an abomination (IMO). Why allow an infinite number of
> scopes inside functions that most people agree need to be kept compact
> anyway?
Not all functions are so compact. And even when they are, what is the
point of /not/ allowing local scopes? Consider these two functions
(yes, I know the variable "p" could be eliminated - this is for show):
extern long int ipower(int x, int y);
long int sum_of_powers1(int count, int power)
{
long int total;
int i;
long int p;
total = 0;
for (i = 1; i <= count; i++) {
p = ipower(i, power);
total += p;
}
return total;
}
long int sum_of_powers2(int count, int power)
{
long int total = 0;
for (int i = 1; i <= count; i++) {
const int p = ipower(i, power);
total += p;
}
return total;
}
In what way is the first version better? It is longer, and pointlessly
separates definitions of variables from their use.
>
> And if you don't reuse the same name in different blocks, then there is
> less need to have them at all.
>
> In place of block scopes I have module scopes (where modules A and B can
> each share a function F, and modules C and D can also share a different
> function also called F). And I can put things inside their own
> name-space, which creates another scope (this is encroaching on C++
> territory now).
>
> These other new scopes are far more useful than block scopes. And not
> just in IMO, because they enable some new things that are otherwise
> awkward to do, unlike block scopes which add nothing at all, apart from
> the dubious ability to overload the same identifier name.
Additional scopes like this can definitely be a good thing. But that is
in addition to the scopes C has - they are not alternatives.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-05 14:36 +0000 |
| Message-ID | <ybh6E.591739$Y32.265491@fx19.am4> |
| In reply to | #140548 |
On 05/02/2019 12:27, David Brown wrote:
> On 05/02/2019 00:30, Bart wrote:
>> The one useful lesson to be learned from C++ is how not to design a
>> language. (I think others have too as few new languages are as crazily
>> complex.)
>
> And there you have totally, and completely missed my point.
>
> I did not say "copy C++". I did not even say "copy C++ const".
I know the sorts of things that C++ wants to make possible. I just
disagree with practically every aspect of their implementation and
syntax. I've heard that a C++ compiler is 10 man-years of effort (and
that quote was from a couple of decades ago when C++ was smaller); my
compilers need to be a matter of months, at most. That means careful
language design.
> func sum_of_powers(count : integer, power : integer) : big_integer
> {
> var total : big_integer := 0;
> for i in 1 .. count {
> p : big_integer := i ** power;
> total += p;
> }
> return total;
> }
>
> There is no need to declare "i" - it is constant within its scope
> (inside the for loop). Similarly, there is no need to declare "p", but
> here we give it a specific type. Only variables may be changed after
> initialisation, and they need to be declared (with "var").
(Not declaring variables used as a for-loop index, I already have. But
what I'm doing actually is combining a statically-typed language at
around the level of C, with a dynamically typed higher level one which
doesn't require declarations, and creating a single language. It wasn't
practical a decade or more ago; it might be now using my slick new tools.)
> Parameters are not small, local variables - they are part of the
> interface of the function.
Nevertheless, they might only be relevant in a small block.
> One thing I would have liked to see in C would be the ability to
> re-define a variable (or const) inside the same block:
>
> {
> int x = a + b;
> foo(x);
> int x = 2 * a + b;
> foo(x);
> }
>
> I would like this to act exactly as if I had written:
>
> {
> int x1 = a + b;
> foo(x1);
> int x2 = 2 * a + b;
> foo(x2);
> }
>
> I am not sure if this would have any repercussions - I have not thought
> about it enough.
It means it becomes impossible to detect duplicate declarations:
int x,x,x,x,x,x,x;
At least, without the compiler having to go into analysing mode trying
to figure out whether what you wrote was intentional or inadvertent.
It's much better for the language to say that it is not allowed.
BTW, why do you want to do this? You were having a go at me using
identical names in different blocks (as an example of the disadvantages
of block scope), now you want to have an infinite number of instances of
the same name in one block?
If you want to be allowed to assign to each x only once, then two 'int
x' won't stop that (you will need two 'const int x =...'). But even if
you used const:
const int x=123;
...
const int x=456;
...
That second declaration gives you exactly the ability of assigning to
assign to x (it doesn't matter which version) a second time.
>> Remote from the function? How do you distinguish between 3 different
>> locals all called "A"?
>
> Why would you be doing that in the first place?
(All the identifiers in my languages can be uniquely denoted by a dotted
name, eg. "m.fn.x" where x is a name defined in function fn which is in
module m. (Not necessarily for use by programs.) That is not possible
with anonymous block scopes.)
> Defining local functions inside other functions can be nice (but it can
> be a can of worms), but /only/ if the scope is local to the function.
No, I meant encapsulated within other types such as records (structs in
C). Nested functions too, but those are somewhat different. (See example
in sig.)
> Being able to order variable definitions within a function? I can't see
> the point at all.
I gave an example using enums the other day. Sometimes names are
references in circular patterns. But even if not, being able to do this:
const area = width*height
const width = 20, height = 10
can be handy. You shouldn't /have/ to rearrange your code especially;
you want to concentrate on doing real work.
> Not all functions are so compact. And even when they are, what is the
> point of /not/ allowing local scopes? Consider these two functions
> (yes, I know the variable "p" could be eliminated - this is for show):
>
> extern long int ipower(int x, int y);
>
> long int sum_of_powers1(int count, int power)
> {
> long int total;
> int i;
> long int p;
>
> total = 0;
> for (i = 1; i <= count; i++) {
> p = ipower(i, power);
> total += p;
> }
>
> return total;
> }
>
> long int sum_of_powers2(int count, int power)
> {
> long int total = 0;
> for (int i = 1; i <= count; i++) {
> const int p = ipower(i, power);
> total += p;
> }
>
> return total;
> }
>
> In what way is the first version better? It is longer, and pointlessly
> separates definitions of variables from their use.
In the first version, I can directly paste the 'p=ipower...' line into a
Python script, and run it without changes (given suitable values of i,
power, and ipower).
I can do the same with my language, if I first change "=" to ":=".
Probably I can do this trick with a number of languages without even
having to do that (they need to be OK with that trailing comma as the
above two are).
I can even take the same line, and paste into a different C program, one
where p is now a float, or an int64.
I can't do this with the version that has 'const int' bolted to the front.
The advantage is that it helps keep the actual function of the code
clearer. That line 'raises i to 'power' and assigns the result to p'.
The 'const int' is not a part of that.
BTW here's the same example in my syntax (still using the unnecessary
'p', and where int is 64 bits):
function sum_of_powers(int count, power)int=
int total:=0, p
for i to count do
p := i**power
total +:= p
od
return total;
end
Notice it's the same length as your preferred C version (could even be
1 line shorter), and is less cluttered, yet it doesn't use block scopes.
(The 'i' variable is implicitly declared.)
--
bart
record A =
proc hello= {println "Hello!"}
proc bye= {println "Bye!"}
end
record B =
proc hello= {println "Ciao!"}
proc bye= {println "Ciao as well!"}
end
proc start=
A.hello()
A.bye()
B.hello()
B.bye()
end
Output:
Hello!
Bye!
Ciao!
Ciao as well!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-05 16:50 +0100 |
| Message-ID | <q3cbch$73t$1@dont-email.me> |
| In reply to | #140556 |
On 05/02/2019 15:36, Bart wrote:
> On 05/02/2019 12:27, David Brown wrote:
>> On 05/02/2019 00:30, Bart wrote:
>
>>> The one useful lesson to be learned from C++ is how not to design a
>>> language. (I think others have too as few new languages are as crazily
>>> complex.)
>>
>> And there you have totally, and completely missed my point.
>>
>> I did not say "copy C++". I did not even say "copy C++ const".
>
> I know the sorts of things that C++ wants to make possible. I just
> disagree with practically every aspect of their implementation and
> syntax. I've heard that a C++ compiler is 10 man-years of effort (and
> that quote was from a couple of decades ago when C++ was smaller); my
> compilers need to be a matter of months, at most. That means careful
> language design.
Again, you have completely missed my point. If you manage to control
your knee-jerk panic attack whenever C++ is mentioned, you will get on
better.
>
>> func sum_of_powers(count : integer, power : integer) : big_integer
>> {
>> var total : big_integer := 0;
>> for i in 1 .. count {
>> p : big_integer := i ** power;
>> total += p;
>> }
>> return total;
>> }
>>
>> There is no need to declare "i" - it is constant within its scope
>> (inside the for loop). Similarly, there is no need to declare "p", but
>> here we give it a specific type. Only variables may be changed after
>> initialisation, and they need to be declared (with "var").
>
> (Not declaring variables used as a for-loop index, I already have. But
> what I'm doing actually is combining a statically-typed language at
> around the level of C, with a dynamically typed higher level one which
> doesn't require declarations, and creating a single language. It wasn't
> practical a decade or more ago; it might be now using my slick new tools.)
>
>> Parameters are not small, local variables - they are part of the
>> interface of the function.
>
> Nevertheless, they might only be relevant in a small block.
That is correct - and irrelevant.
>
>> One thing I would have liked to see in C would be the ability to
>> re-define a variable (or const) inside the same block:
>>
>> {
>> int x = a + b;
>> foo(x);
>> int x = 2 * a + b;
>> foo(x);
>> }
>>
>> I would like this to act exactly as if I had written:
>>
>> {
>> int x1 = a + b;
>> foo(x1);
>> int x2 = 2 * a + b;
>> foo(x2);
>> }
>>
>> I am not sure if this would have any repercussions - I have not thought
>> about it enough.
>
> It means it becomes impossible to detect duplicate declarations:
>
> int x,x,x,x,x,x,x;
>
No, they are quite easy to detect - compilers today have no problem
flagging unused variables as warnings. (We are only talking about local
non-static variables here.) It means that duplicate definitions would
not be an error. But it would have no logical impact on the code if you
wrote "int x, x, x, x;" - the first few x's would be shadowed. Since
they are never initialised, and never used, they do no harm - the
compiler would eliminate them immediately.
> At least, without the compiler having to go into analysing mode trying
> to figure out whether what you wrote was intentional or inadvertent.
> It's much better for the language to say that it is not allowed.
>
No, it is not "much better". I said I wanted this feature because it
would be useful and convenient. It would be fairly simple to implement
(just pretend that each such duplicate definition opens a new block), it
would be fairly simple to specify, it would not impact code generation
or optimisation, and any mistakes made with the feature would easily be
detected with common existing static analysis.
> BTW, why do you want to do this? You were having a go at me using
> identical names in different blocks (as an example of the disadvantages
> of block scope), now you want to have an infinite number of instances of
> the same name in one block?
I was not "having a go at you" - I was pointing out that if you want to
use different names for block-scope variables, you can do so. Many of
your arguments against block-scope variables was based on the assumption
that people would re-use the same name just because they could, even
when different names would make more sense.
And my programs are quite finite in length, not infinite.
I want to be able to re-define existing names because in some cases, it
can make patterns in code clearer:
int rr = x1 * x1 + y1 * y1;
foo(rr);
int rr = x2 * x2 + y2 * y2;
foo(rr);
("const int rr" would be better, but that might annoy you.)
>
> If you want to be allowed to assign to each x only once, then two 'int
> x' won't stop that (you will need two 'const int x =...').
You are mixing things up here.
> But even if
> you used const:
>
> const int x=123;
> ...
> const int x=456;
> ...
>
> That second declaration gives you exactly the ability of assigning to
> assign to x (it doesn't matter which version) a second time.
>
No, it gives the ability to create a second constant "x". Each "x" is
initialised exactly once (no assignments).
>>> Remote from the function? How do you distinguish between 3 different
>>> locals all called "A"?
>>
>> Why would you be doing that in the first place?
>
> (All the identifiers in my languages can be uniquely denoted by a dotted
> name, eg. "m.fn.x" where x is a name defined in function fn which is in
> module m. (Not necessarily for use by programs.) That is not possible
> with anonymous block scopes.)
Fair enough - but why would you want to do that? Locals in block scope
have limited lifetimes. It doesn't make sense to refer to them from
outside that scope, since they don't exist.
>
>> Defining local functions inside other functions can be nice (but it can
>> be a can of worms), but /only/ if the scope is local to the function.
>
> No, I meant encapsulated within other types such as records (structs in
> C). Nested functions too, but those are somewhat different. (See example
> in sig.)
>
>> Being able to order variable definitions within a function? I can't see
>> the point at all.
>
> I gave an example using enums the other day. Sometimes names are
> references in circular patterns. But even if not, being able to do this:
>
> const area = width*height
> const width = 20, height = 10
>
> can be handy. You shouldn't /have/ to rearrange your code especially;
> you want to concentrate on doing real work.
That does not look like something I'd want. I really do not want to do
calculations first, then define the data for the calculations. And like
your circular enums, this can only work in limited cases.
>
>> Not all functions are so compact. And even when they are, what is the
>> point of /not/ allowing local scopes? Consider these two functions
>> (yes, I know the variable "p" could be eliminated - this is for show):
>>
>> extern long int ipower(int x, int y);
>>
>> long int sum_of_powers1(int count, int power)
>> {
>> long int total;
>> int i;
>> long int p;
>>
>> total = 0;
>> for (i = 1; i <= count; i++) {
>> p = ipower(i, power);
>> total += p;
>> }
>>
>> return total;
>> }
>>
>> long int sum_of_powers2(int count, int power)
>> {
>> long int total = 0;
>> for (int i = 1; i <= count; i++) {
>> const int p = ipower(i, power);
>> total += p;
>> }
>>
>> return total;
>> }
>>
>> In what way is the first version better? It is longer, and pointlessly
>> separates definitions of variables from their use.
>
> In the first version, I can directly paste the 'p=ipower...' line into a
> Python script, and run it without changes (given suitable values of i,
> power, and ipower).
OK, so your argument is now that top-of-function declarations means
mildly less incompatibility between two totally different languages?
You really are scraping the barrel here.
>
> I can do the same with my language, if I first change "=" to ":=".
>
> Probably I can do this trick with a number of languages without even
> having to do that (they need to be OK with that trailing comma as the
> above two are).
>
> I can even take the same line, and paste into a different C program, one
> where p is now a float, or an int64.
>
With the declaration version, you can paste it into a different C
program that does not have "p" defined before - which is vastly more likely.
> I can't do this with the version that has 'const int' bolted to the front.
>
> The advantage is that it helps keep the actual function of the code
> clearer. That line 'raises i to 'power' and assigns the result to p'.
> The 'const int' is not a part of that.
>
Yes, it is.
> BTW here's the same example in my syntax (still using the unnecessary
> 'p', and where int is 64 bits):
>
> function sum_of_powers(int count, power)int=
> int total:=0, p
>
> for i to count do
> p := i**power
> total +:= p
> od
>
> return total;
> end
>
> Notice it's the same length as your preferred C version (could even be
> 1 line shorter), and is less cluttered, yet it doesn't use block scopes.
> (The 'i' variable is implicitly declared.)
>
What use is a comparison to your language here? We are comparing C
written in two different styles.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-05 18:44 +0000 |
| Message-ID | <nQk6E.362552$dp2.170508@fx18.am4> |
| In reply to | #140561 |
On 05/02/2019 15:50, David Brown wrote:
> On 05/02/2019 15:36, Bart wrote:
> Again, you have completely missed my point. If you manage to control
> your knee-jerk panic attack whenever C++ is mentioned, you will get on
> better.
And you've missed mine. C++ is one of the last languages you'd want want
to take tips from in language design.
However it seems to be common for C++ users not to see the issues.
"A C compiler takes roughly one to two man years to create, whereas a
C++ compiler takes 15 to 20"
"> Basically, writing a C++ front end takes 10 man years."
"This is insane. No language needs to be that complex. I guess that's
the power of backward compatibility: forcing an entire industry to dig
itself into an ever growing hole, because in the short term we move
faster by digging than by first clawing our way out."
>> That second declaration gives you exactly the ability of assigning to
>> assign to x (it doesn't matter which version) a second time.
>>
>
> No, it gives the ability to create a second constant "x". Each "x" is
> initialised exactly once (no assignments).
This is not allowed:
const int x=rand();
....
x=rand();
But with your new feature, you can just do this:
const int x=rand();
....
const int x=rand();
You are circumventing the 'const' restriction and allowing two
assignments to a const variable called 'x' within one block lifetime.
> Fair enough - but why would you want to do that? Locals in block scope
> have limited lifetimes. It doesn't make sense to refer to them from
> outside that scope, since they don't exist.
There are other things declared in block scopes: typedefs, structs,
enums, static variables, named constants [not C]. These have
program-wide lifetimes.
>> const area = width*height
>> const width = 20, height = 10
> That does not look like something I'd want. I really do not want to do
> calculations first, then define the data for the calculations. And like
> your circular enums, this can only work in limited cases.
This is not executing code, they are compile-time expressions, and not
necessarily evaluated in sequence. That they necessarily have to be
written in sequence might give the impression of some order, but that is
not the case.
>> The advantage is that it helps keep the actual function of the code
>> clearer. That line 'raises i to 'power' and assigns the result to p'.
>> The 'const int' is not a part of that.
>>
>
> Yes, it is.
Obviously, it isn't, because it is only relevant to C, and specific to
the way you decided to write it, even there. Such stuff is
language-specific metadata that I prefer to keep separate.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-06 08:23 +1300 |
| Message-ID | <gbu653Ffhg9U7@mid.individual.net> |
| In reply to | #140570 |
On 06/02/2019 07:44, Bart wrote: > On 05/02/2019 15:50, David Brown wrote: >> On 05/02/2019 15:36, Bart wrote: > >> Again, you have completely missed my point. If you manage to control >> your knee-jerk panic attack whenever C++ is mentioned, you will get on >> better. > > And you've missed mine. C++ is one of the last languages you'd want want > to take tips from in language design. You are being willfully obtuse, const in C++ is a significant improvement over const in C. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-05 12:43 -0800 |
| Message-ID | <4c59dca0-2449-4234-a935-b6d604088caf@googlegroups.com> |
| In reply to | #140573 |
On Tuesday, 5 February 2019 19:23:26 UTC, Ian Collins wrote: > > You are being willfully obtuse, const in C++ is a significant > improvement over const in C. > It's significantly more complex. It's no longer true, as it is in C, that a correct program cannot be turned into an incorrect program by const-qualifying or const- dequalifying identifiers.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-06 09:51 +1300 |
| Message-ID | <gbubb8Ffhg9U8@mid.individual.net> |
| In reply to | #140577 |
On 06/02/2019 09:43, Malcolm McLean wrote: > On Tuesday, 5 February 2019 19:23:26 UTC, Ian Collins wrote: >> >> You are being willfully obtuse, const in C++ is a significant >> improvement over const in C. >> > It's significantly more complex. For valid C variables, const in C++ is somewhat simpler than than C. A const is a compile time constant, simple. > It's no longer true, as it is in C, that a correct program cannot > be turned into an incorrect program by const-qualifying or const- > dequalifying identifiers. Apples and oranges. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-05 13:14 -0800 |
| Message-ID | <lnbm3quedw.fsf@kst-u.example.com> |
| In reply to | #140577 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Tuesday, 5 February 2019 19:23:26 UTC, Ian Collins wrote:
>> You are being willfully obtuse, const in C++ is a significant
>> improvement over const in C.
>>
> It's significantly more complex.
>
> It's no longer true, as it is in C, that a correct program cannot
> be turned into an incorrect program by const-qualifying or const-
> dequalifying identifiers.
Can you clarify what you mean by that?
I can turn this correct program:
int main(void) {
int n = 10;
n = 20;
}
into an incorrect program by const-qualifying n.
--
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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-06 01:42 -0800 |
| Message-ID | <84b47866-600b-48d2-85b6-1538f19b00df@googlegroups.com> |
| In reply to | #140581 |
On Tuesday, 5 February 2019 21:14:28 UTC, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> > On Tuesday, 5 February 2019 19:23:26 UTC, Ian Collins wrote:
> >> You are being willfully obtuse, const in C++ is a significant
> >> improvement over const in C.
> >>
> > It's significantly more complex.
> >
> > It's no longer true, as it is in C, that a correct program cannot
> > be turned into an incorrect program by const-qualifying or const-
> > dequalifying identifiers.
>
> Can you clarify what you mean by that?
>
> I can turn this correct program:
>
> int main(void) {
> int n = 10;
> n = 20;
> }
>
> into an incorrect program by const-qualifying n.
>
What I (actually Dennis Ritchie) meant is this.
We have
double total_salaries(const Employee *emp, int N);
The function works, and it doesn't corrupt the employee array.
Now we can take the const away, and the function must still work
correctly. We can add it again, and it still works correctly.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-06 22:44 +1300 |
| Message-ID | <gbvok4FgcocU1@mid.individual.net> |
| In reply to | #140601 |
On 06/02/2019 22:42, Malcolm McLean wrote:
> On Tuesday, 5 February 2019 21:14:28 UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>> On Tuesday, 5 February 2019 19:23:26 UTC, Ian Collins wrote:
>>>> You are being willfully obtuse, const in C++ is a significant
>>>> improvement over const in C.
>>>>
>>> It's significantly more complex.
>>>
>>> It's no longer true, as it is in C, that a correct program cannot
>>> be turned into an incorrect program by const-qualifying or const-
>>> dequalifying identifiers.
>>
>> Can you clarify what you mean by that?
>>
>> I can turn this correct program:
>>
>> int main(void) {
>> int n = 10;
>> n = 20;
>> }
>>
>> into an incorrect program by const-qualifying n.
>>
> What I (actually Dennis Ritchie) meant is this.
>
> We have
>
> double total_salaries(const Employee *emp, int N);
>
> The function works, and it doesn't corrupt the employee array.
> Now we can take the const away, and the function must still work
> correctly. We can add it again, and it still works correctly.
How is const, in the C subset of C++, any different?
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-06 02:36 -0800 |
| Message-ID | <25716101-347a-427a-bad0-6b0bcd434000@googlegroups.com> |
| In reply to | #140602 |
On Wednesday, 6 February 2019 09:44:45 UTC, Ian Collins wrote: > > > The function works, and it doesn't corrupt the employee array. > > Now we can take the const away, and the function must still work > > correctly. We can add it again, and it still works correctly. > > How is const, in the C subset of C++, any different? > That's a bit of a difficult question, because if we are talking about the C subset, then any behaviour different from C isn't in the subset. But C++ const overloads. So you can write two functions with the same name, differing only by const-qualification of a parameter, and with different behaviour.
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2019-02-06 17:39 +0000 |
| Message-ID | <5c5b1b39.844348891@news.xmission.com> |
| In reply to | #140602 |
On Wed, 6 Feb 2019 22:44:36 +1300, Ian Collins <ian-news@hotmail.com> wrote: >How is const, in the C subset of C++, any different? Is that what they're teaching nowadays? C is not a subset of C++. C came first, C++ was derived from it, and the two have diverged a good deal since then. It's trivial to write a correct C program that is a very, very wrong C++ program.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-06 10:39 -0800 |
| Message-ID | <4f75b849-ba91-4300-bc94-9e3d78bb3796@googlegroups.com> |
| In reply to | #140648 |
On Wednesday, February 6, 2019 at 12:37:07 PM UTC-5, Scott wrote: > On Wed, 6 Feb 2019 22:44:36 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > > >How is const, in the C subset of C++, any different? > > Is that what they're teaching nowadays? > > C is not a subset of C++. C came first, C++ was derived from it, and > the two have diverged a good deal since then. It's trivial to write a > correct C program that is a very, very wrong C++ program. True - but it's even easier to write code in such a way that it has precisely the same observable behavior when compiled with C++ as with C (without relying on the use of #ifdef __cplusplus). Code that has the same meaning in both languages is sometimes referred to as being in the common subset of C and C++, and I'd presume that's what he's actually referring to.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-07 07:58 +1300 |
| Message-ID | <gc0p2sFgcocU2@mid.individual.net> |
| In reply to | #140652 |
On 07/02/2019 07:39, James Kuyper wrote: > On Wednesday, February 6, 2019 at 12:37:07 PM UTC-5, Scott wrote: >> On Wed, 6 Feb 2019 22:44:36 +1300, Ian Collins <ian-news@hotmail.com> >> wrote: >> >>> How is const, in the C subset of C++, any different? >> >> Is that what they're teaching nowadays? >> >> C is not a subset of C++. C came first, C++ was derived from it, and >> the two have diverged a good deal since then. It's trivial to write a >> correct C program that is a very, very wrong C++ program. > > True - but it's even easier to write code in such a way that it has > precisely the same observable behavior when compiled with C++ as with C > (without relying on the use of #ifdef __cplusplus). Code that has the > same meaning in both languages is sometimes referred to as being in the > common subset of C and C++, and I'd presume that's what he's actually > referring to. It is, when discussing improving const rules in C, there's little point talking about bits of C++ that aren't also C. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 22:45 -0800 |
| Message-ID | <86va17avzl.fsf@mailhub.linuxsc.com> |
| In reply to | #140652 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Wednesday, February 6, 2019 at 12:37:07 PM UTC-5, Scott wrote: > >> On Wed, 6 Feb 2019 22:44:36 +1300, Ian Collins <ian-news@hotmail.com> >> wrote: >> >>> How is const, in the C subset of C++, any different? >> >> Is that what they're teaching nowadays? >> >> C is not a subset of C++. C came first, C++ was derived from it, >> and the two have diverged a good deal since then. It's trivial >> to write a correct C program that is a very, very wrong C++ >> program. > > True - but it's even easier to write code in such a way that it > has precisely the same observable behavior when compiled with C++ > as with C (without relying on the use of #ifdef __cplusplus). > [...] This statement is hyperbole, and it isn't even right. To write C code that is also valid C++ (and with the same meaning) takes learning a list of what language features/constructs to stay away from, and not using them in the C code. Not a huge effort. But to write C code that is not good C++ requires no effort at all. If I just write C code the way I normally do (and I think also many or most C developers who are used to C99, and even some who are used to C90), there is a good chance that the code will run afoul of some C++ change and/or limitation. Zero effort is always easier than any positive amount of effort.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-26 08:44 +0100 |
| Message-ID | <q52qof$jk0$1@dont-email.me> |
| In reply to | #141392 |
On 26/02/2019 07:45, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > >> On Wednesday, February 6, 2019 at 12:37:07 PM UTC-5, Scott wrote: >> >>> On Wed, 6 Feb 2019 22:44:36 +1300, Ian Collins <ian-news@hotmail.com> >>> wrote: >>> >>>> How is const, in the C subset of C++, any different? >>> >>> Is that what they're teaching nowadays? >>> >>> C is not a subset of C++. C came first, C++ was derived from it, >>> and the two have diverged a good deal since then. It's trivial >>> to write a correct C program that is a very, very wrong C++ >>> program. >> >> True - but it's even easier to write code in such a way that it >> has precisely the same observable behavior when compiled with C++ >> as with C (without relying on the use of #ifdef __cplusplus). >> [...] > > This statement is hyperbole, and it isn't even right. To write > C code that is also valid C++ (and with the same meaning) takes > learning a list of what language features/constructs to stay > away from, and not using them in the C code. Not a huge effort. > Agreed. > But to write C code that is not good C++ requires no effort at > all. If I just write C code the way I normally do (and I think > also many or most C developers who are used to C99, and even some > who are used to C90), there is a good chance that the code will > run afoul of some C++ change and/or limitation. Zero effort is > always easier than any positive amount of effort. > Writing code that is valid C code but invalid C++ is certainly trivially easy. Just make a variable called "new", and you're off. My interpretation of James' comment was in the context of code that can be compiled as C and C++ - that is to say, "a correct C program that is a very, very wrong C++ program" being code that compiles and runs correctly (according to programmer's intentions) as C, and when compiled as C++ it will compile but run incorrectly. It is entirely possible to write such programs - perhaps relying on "sizeof 'a' ". But it is not /easy/ to write such programs unless you are intentionally going out of your way to do so. It is highly unlikely to happen by accident in a normal C program. Of course, my interpretation here could be wrong. However, as you say, James' statement would be trivially wrong if interpreted as you have. Since James is not often trivially wrong, I assumed his statement was merely worded a little unclearly.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-26 08:03 -0500 |
| Message-ID | <q53dfd$1kn$1@dont-email.me> |
| In reply to | #141399 |
On 2/26/19 02:44, David Brown wrote: > On 26/02/2019 07:45, Tim Rentsch wrote: >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> >>> On Wednesday, February 6, 2019 at 12:37:07 PM UTC-5, Scott wrote: ... >>>> C is not a subset of C++. C came first, C++ was derived from it, >>>> and the two have diverged a good deal since then. It's trivial >>>> to write a correct C program that is a very, very wrong C++ >>>> program. >>> >>> True - but it's even easier to write code in such a way that it Tim is correct: "even easier" counts as hyperbole. Writing the kind of code I'm talking about is (very marginally) more difficult than writing correct C code. I was interpreting "very, very wrong C++" as referring to code that was carefully chosen to be "very, very wrong C++", which would require a fair amount of knowledge of C++. However, Tim is correct, it's entirely feasible to write such code purely by accident. >>> has precisely the same observable behavior when compiled with C++ >>> as with C (without relying on the use of #ifdef __cplusplus). Sorry, I left out a key word that I usually remember to insert when making that claim: "... required observable behavior". If either language fails to impose requirements on the behavior of a piece of code, then such code is not what I'm talking about. >> This statement is hyperbole, and it isn't even right. To write >> C code that is also valid C++ (and with the same meaning) takes >> learning a list of what language features/constructs to stay >> away from, and not using them in the C code. Not a huge effort. >> > > Agreed. > >> But to write C code that is not good C++ requires no effort at >> all. If I just write C code the way I normally do (and I think I wasn't talking about how "good" the code is - that's a subjective judgment that might involve issues of style and clarity which are irrelevant to what I was talking about. I'm only concerned here with the required observable behavior. >> also many or most C developers who are used to C99, and even some >> who are used to C90), there is a good chance that the code will >> run afoul of some C++ change and/or limitation. Zero effort is >> always easier than any positive amount of effort. While it's not actually easier to write such code, I believe that it isn't much harder. If you already know how to write correct C code, then Annex C of the C++ standard combined with a list of the keywords in each language will cover most of what you need to know to write such code. It has come up in other similar discussions that the person I was talking with misunderstood me as recommending that code be written that way. I do not. I think you should generally choose which language you're targeting, and write good code for that language - trying to target multiple languages with the same code is generally more trouble than it's worth, even if they are as closely related as C and C++. My point is only that it's possible to write such code - which is evidence that the lie which says "C is a subset of C++" is not entirely unjustified.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-26 15:29 +0100 |
| Message-ID | <q53ih0$2vk$1@dont-email.me> |
| In reply to | #141424 |
On 26/02/2019 14:03, James Kuyper wrote: > > While it's not actually easier to write such code, I believe that it > isn't much harder. If you already know how to write correct C code, then > Annex C of the C++ standard combined with a list of the keywords in each > language will cover most of what you need to know to write such code. > > It has come up in other similar discussions that the person I was > talking with misunderstood me as recommending that code be written that > way. I do not. I think you should generally choose which language you're > targeting, and write good code for that language - trying to target > multiple languages with the same code is generally more trouble than > it's worth, even if they are as closely related as C and C++. I have had customers who have asked for code that is valid as C and C++ code. One could argue if that was a good thing or not, but the one paying the bills is always right! As you say, it is not hard to do - but you miss some C features like designated initialisers. > > My point is only that it's possible to write such code - which is > evidence that the lie which says "C is a subset of C++" is not entirely > unjustified. >
[toc] | [prev] | [next] | [standalone]
Page 4 of 19 — ← Prev page 1 2 3 [4] 5 6 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web