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 17 of 19 — ← Prev page 1 … 15 16 [17] 18 19 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-27 02:41 +0000 |
| Message-ID | <871s3uymul.fsf@bsb.me.uk> |
| In reply to | #141467 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On 2/26/19 09:16, Ben Bacarisse wrote: <stuff about coding style> > This, however, confuses me. <cut> I'm sorry that I was so unclear. I knocked out a quick answer to a question but I don't think my preferences are really worth expending any more energy on. <cut> > I strongly suspect that your description of the thing you prefer is > incomplete. Agreed. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-02-26 19:13 -0800 |
| Message-ID | <4a8adad8-6be3-412e-8b08-ce54a4fc1dc0@googlegroups.com> |
| In reply to | #141467 |
On Tuesday, February 26, 2019 at 8:18:27 PM UTC-6, James Kuyper wrote:
> On 2/26/19 09:16, Ben Bacarisse wrote:
> > (e) I have no qualms about some side-effects in expressions. Not sure
>
> This, however, confuses me. Are there people who object to side-effects
> in expressions? I suspect that the kind of code that they object to
> requires additional description, because assignment expressions have
> side-effects, and I can't imagine anyone objecting to the use of
> assignment expressions.
>
I have encountered this opinion at least once. eg.
https://codereview.stackexchange.com/a/98850/5912
(first item under "Coding Style")
It's possible that I crossed a line by doing it twice.
switch(pre=nlo(x=*p++)){
...
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-26 22:29 -0500 |
| Message-ID | <q55071$r58$1@dont-email.me> |
| In reply to | #141470 |
On 2/26/19 22:13, luser droog wrote:
> On Tuesday, February 26, 2019 at 8:18:27 PM UTC-6, James Kuyper wrote:
>> On 2/26/19 09:16, Ben Bacarisse wrote:
>
>>> (e) I have no qualms about some side-effects in expressions. Not sure
>>
>> This, however, confuses me. Are there people who object to side-effects
>> in expressions? I suspect that the kind of code that they object to
>> requires additional description, because assignment expressions have
>> side-effects, and I can't imagine anyone objecting to the use of
>> assignment expressions.
>>
>
> I have encountered this opinion at least once. eg.
>
> https://codereview.stackexchange.com/a/98850/5912
> (first item under "Coding Style")
That complaint was not about side-effects as such, it was that "you
sacrifice clarity for brevity a lot.". Having three side-effects
occurring in a short piece of code is merely the particular way in which
that piece of code sacrifices clarity for brevity.
> It's possible that I crossed a line by doing it twice.
>
> switch(pre=nlo(x=*p++)){
> ...
I have to agree with the complaint. I'd write that as
x = *p++;
pre = nlo(x);
switch(pre)
{
Note that my re-write doesn't avoid any of the three side-effects, it
merely spreads them out a little for ease of comprehension. I suspect my
re-write would address his complaint. If so, that would indicate that
it's not the side-effects he was complaining about.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-27 09:33 +0100 |
| Message-ID | <q55i0c$a8n$1@dont-email.me> |
| In reply to | #141467 |
On 27/02/2019 03:18, James Kuyper wrote: >> (e) I have no qualms about some side-effects in expressions. Not sure > > This, however, confuses me. Are there people who object to side-effects > in expressions? I suspect that the kind of code that they object to > requires additional description, because assignment expressions have > side-effects, and I can't imagine anyone objecting to the use of > assignment expressions. > Obviously there are plenty of situations where side-effects in expressions are fine for everyone - without them, you would not get far in C! There are particular cases, however, where people (and/or coding standards) dislike some of the flexibility C provides, and thus avoid certain constructions. I can't see an easy way to describe these cases and form rules about "this is allowed" and "this is not allowed", especially because there are plenty of grey areas which some people/standards allow and others do not. Things like : if (x = foo()) ... is one that many dislike - it looks too much like a mistake, and that the programmer intended to write "==" instead of "=". Compilers can often warn about such constructs - "gcc -Wall" will complain unless you add extra parenthesis around it. A rule here might be "do not use the result of an assignment expression". That would also apply to "x = y = foo();", which you may or may not want to allow. One obvious rule would be that expressions should have the same result and effect regardless of the order of evaluation of the side-effects. You don't write "x = foo() + bar();" if you require the side-effects of foo() to happen before those of bar(). I suppose it might be possible to try to put limits on side-effects, such as to say that no more than one sub-expression within an expression should have a side-effect. On the other hand, idioms like "*p++ = *q++" are so common and convenient that it would be a shame to rule them out.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-27 07:41 -0500 |
| Message-ID | <q560h3$s1t$1@dont-email.me> |
| In reply to | #141473 |
On 2/27/19 03:33, David Brown wrote: > On 27/02/2019 03:18, James Kuyper wrote: > >>> (e) I have no qualms about some side-effects in expressions. Not sure >> >> This, however, confuses me. Are there people who object to side-effects >> in expressions? I suspect that the kind of code that they object to >> requires additional description, because assignment expressions have >> side-effects, and I can't imagine anyone objecting to the use of >> assignment expressions. >> > > Obviously there are plenty of situations where side-effects in > expressions are fine for everyone - without them, you would not get far > in C! > > There are particular cases, however, where people (and/or coding > standards) dislike some of the flexibility C provides, and thus avoid > certain constructions. I can't see an easy way to describe these cases > and form rules about "this is allowed" and "this is not allowed", > especially because there are plenty of grey areas which some > people/standards allow and others do not. > > Things like : > > if (x = foo()) ... > > is one that many dislike - it looks too much like a mistake, and that > the programmer intended to write "==" instead of "=". Compilers can > often warn about such constructs - "gcc -Wall" will complain unless you > add extra parenthesis around it. A rule here might be "do not use the > result of an assignment expression". That would also apply to "x = y = > foo();", which you may or may not want to allow. > > One obvious rule would be that expressions should have the same result > and effect regardless of the order of evaluation of the side-effects. > You don't write "x = foo() + bar();" if you require the side-effects of > foo() to happen before those of bar(). > > I suppose it might be possible to try to put limits on side-effects, > such as to say that no more than one sub-expression within an expression > should have a side-effect. On the other hand, idioms like "*p++ = *q++" > are so common and convenient that it would be a shame to rule them out. "If a side effect on a scalar object is unsequenced relative to either a different side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. If there are multiple allowable orderings of the subexpressions of an expression, the behavior is undefined if such an unsequenced side effect occurs in any of the orderings." (6.5p2). So you should never do that. If you have two or more expressions with side-effects, and it's important to you that those side-effects occur in a particular order, you should use one of the many different ways that C provides you for forcing those side-effects to be sequenced in the order that you want. Within a single thread, that just means inserting a sequence point between the evaluations, which might require the use of temporaries. If the expressions are evaluated in different threads, what you have to do to achieve that goal is a little more complicated. I can understand the desire to not use the value of an assignment expression - code which does that can be confusing. There are languages where you can't do that: where assignment would be described in C terms as a statement type rather than expression type. But the problem is the value of the assignment expression, not it's side-effect. If the problem were the side-effect, that could be fixed by simply replacing the assignment operator with a semi-colon (or, where that's not legal, a comma).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-27 14:15 +0100 |
| Message-ID | <q562hs$8ph$1@dont-email.me> |
| In reply to | #141477 |
On 27/02/2019 13:41, James Kuyper wrote: > On 2/27/19 03:33, David Brown wrote: >> On 27/02/2019 03:18, James Kuyper wrote: >> >>>> (e) I have no qualms about some side-effects in expressions. Not sure >>> >>> This, however, confuses me. Are there people who object to side-effects >>> in expressions? I suspect that the kind of code that they object to >>> requires additional description, because assignment expressions have >>> side-effects, and I can't imagine anyone objecting to the use of >>> assignment expressions. >>> >> >> Obviously there are plenty of situations where side-effects in >> expressions are fine for everyone - without them, you would not get far >> in C! >> >> There are particular cases, however, where people (and/or coding >> standards) dislike some of the flexibility C provides, and thus avoid >> certain constructions. I can't see an easy way to describe these cases >> and form rules about "this is allowed" and "this is not allowed", >> especially because there are plenty of grey areas which some >> people/standards allow and others do not. >> >> Things like : >> >> if (x = foo()) ... >> >> is one that many dislike - it looks too much like a mistake, and that >> the programmer intended to write "==" instead of "=". Compilers can >> often warn about such constructs - "gcc -Wall" will complain unless you >> add extra parenthesis around it. A rule here might be "do not use the >> result of an assignment expression". That would also apply to "x = y = >> foo();", which you may or may not want to allow. >> >> One obvious rule would be that expressions should have the same result >> and effect regardless of the order of evaluation of the side-effects. >> You don't write "x = foo() + bar();" if you require the side-effects of >> foo() to happen before those of bar(). >> >> I suppose it might be possible to try to put limits on side-effects, >> such as to say that no more than one sub-expression within an expression >> should have a side-effect. On the other hand, idioms like "*p++ = *q++" >> are so common and convenient that it would be a shame to rule them out. > > "If a side effect on a scalar object is unsequenced relative to either a > different side effect on the same scalar object or a value computation > using the value of the same scalar object, the behavior is undefined. If > there are multiple allowable orderings of the subexpressions of an > expression, the behavior is undefined if such an unsequenced side effect > occurs in any of the orderings." (6.5p2). > So you should never do that. My understanding of this paragraph is that "z = x + x++" is undefined (a side-effect is unsequenced relative to a use of the value), but that "z = x++ + y++" is defined, but with unspecified ordering. It is equivalent to either "z = x + y; x++; y++" or to "z = x + y; y++; x++" with the decision left to the compiler's choice. Have I got something wrong there? It is not uncommon in coding standards to disallow expressions where the side-effects can occur in an unspecified order (even if different orders have no impact on the program correctness). > > If you have two or more expressions with side-effects, and it's > important to you that those side-effects occur in a particular order, > you should use one of the many different ways that C provides you for > forcing those side-effects to be sequenced in the order that you want. Agreed. People don't always follow this advice, however, especially when the code works as expected on the tools they use (many compilers have fixed, and maybe even documented, orderings for these things). What you end up with is unclear code that is not portable, even though it works on the system in use. (For some projects, it can make sense for a coding standard to avoid non-portable code - but on others, non-portable code is fine or even necessary.) > Within a single thread, that just means inserting a sequence point > between the evaluations, which might require the use of temporaries. If > the expressions are evaluated in different threads, what you have to do > to achieve that goal is a little more complicated. > Yes. > I can understand the desire to not use the value of an assignment > expression - code which does that can be confusing. There are languages > where you can't do that: where assignment would be described in C terms > as a statement type rather than expression type. But the problem is the > value of the assignment expression, not it's side-effect. If the problem > were the side-effect, that could be fixed by simply replacing the > assignment operator with a semi-colon (or, where that's not legal, a comma). >
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-27 07:02 -0800 |
| Message-ID | <be548e49-b6fb-4020-81cf-e3ff39162bc2@googlegroups.com> |
| In reply to | #141478 |
On Wednesday, February 27, 2019 at 8:15:49 AM UTC-5, David Brown wrote: > On 27/02/2019 13:41, James Kuyper wrote: ... > > "If a side effect on a scalar object is unsequenced relative to either a > > different side effect on the same scalar object or a value computation > > using the value of the same scalar object, the behavior is undefined. If > > there are multiple allowable orderings of the subexpressions of an > > expression, the behavior is undefined if such an unsequenced side effect > > occurs in any of the orderings." (6.5p2). > > So you should never do that. > > My understanding of this paragraph is that "z = x + x++" is undefined (a > side-effect is unsequenced relative to a use of the value), ... Correct. > ... but that "z > = x++ + y++" is defined, but with unspecified ordering. It is > equivalent to either "z = x + y; x++; y++" or to "z = x + y; y++; x++" > with the decision left to the compiler's choice. Also correct. And, as far as the values of z, x, and y are concerned, it doesn't make any difference which of those orderings occurs (unless execution gets interrupted during execution of that expression). You could make the order matter by declaring those values volatile, or by replacing them with function calls that send output to a file.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-27 17:18 +0100 |
| Message-ID | <q56d96$d5v$1@dont-email.me> |
| In reply to | #141482 |
On 27/02/2019 16:02, James Kuyper wrote: > On Wednesday, February 27, 2019 at 8:15:49 AM UTC-5, David Brown wrote: >> On 27/02/2019 13:41, James Kuyper wrote: > ... >>> "If a side effect on a scalar object is unsequenced relative to either a >>> different side effect on the same scalar object or a value computation >>> using the value of the same scalar object, the behavior is undefined. If >>> there are multiple allowable orderings of the subexpressions of an >>> expression, the behavior is undefined if such an unsequenced side effect >>> occurs in any of the orderings." (6.5p2). >>> So you should never do that. >> >> My understanding of this paragraph is that "z = x + x++" is undefined (a >> side-effect is unsequenced relative to a use of the value), ... > > Correct. > >> ... but that "z >> = x++ + y++" is defined, but with unspecified ordering. It is >> equivalent to either "z = x + y; x++; y++" or to "z = x + y; y++; x++" >> with the decision left to the compiler's choice. > > Also correct. And, as far as the values of z, x, and y are concerned, it > doesn't make any difference which of those orderings occurs (unless > execution gets interrupted during execution of that expression). > > You could make the order matter by declaring those values volatile, or > by replacing them with function calls that send output to a file. > Yes. So such multiple side-effect expressions are definitely bad when there is undefined behaviour because you are accessing the same object in unsequenced ways (ref 6.5p2). They are probably bad when they have a visibly different unspecified ordering. And they are considered bad by some people even when the different orderings don't affect the program (because they may look like they are one of the first two cases, or may morph into them when other parts of the code change).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-28 15:05 +0100 |
| Message-ID | <q58ps0$nps$1@dont-email.me> |
| In reply to | #141477 |
On 28/02/2019 02:00, Stefan Ram wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> I can understand the desire to not use the value of an assignment >> expression - code which does that can be confusing. > > The Python folks just decided to add assignment expressions: > > www.python.org/dev/peps/pep-0572/ > > . Somehow this led to Guido's resignation: > > lwn.net/Articles/759654/ > Just to be clear here (for those that don't want to bother reading the links, but might be vaguely interested) - GvR resigned as Python's Benevolent Dictator for Life after having completed and pushed through this addition to the language. Your post made it look like he resigned because he didn't want assignment expressions - he /did/ want them. He resigned because he had had enough of fighting for features in Python that he wanted. I guess being a Dictator is not much fun if people insist on arguing with you instead of obeying your commands!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-07 11:24 -0800 |
| Message-ID | <867edatrn3.fsf@mailhub.linuxsc.com> |
| In reply to | #141430 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>> ...
>>
>>> My coding style (when not constrained by cooperation) appears to
>>> be widely disliked.
>
> (I was talking about C, of course)
>
>> Well that has me curious. Can you say what about your style
>> choices people dislike? Or post a small example (perhaps
>> with commentary)? I'm always interested to learn what
>> people react to.
>
> I've probably forgotten many, but
>
> (a) I like using multiple declarators in one declaration to collect
> related objects:
>
> double dest[SIZE], *dp = dest, *ep = (&dest)[1];
I'm completely with you on this one.
> (b) I don't mind using slightly obscure parts of the language if it
> seems right, like using (&dest)[1] above to avoid duplicating the
> use of SIZE.
The construct (&dest)[1] is a charming idiom. Every serious C
programmer should have that in their toolbag. Although, I'm
having trouble thinking of another example in this category (ie,
that you might be thinking of). Can you give another example
or two?
An idiom I use now and then, and which I'm sure some other people
would just hate, is 0[pointer-expression], to access the value
pointed to by the expression. I find the []'s help me chunkify
the expression more easily (ie, in some cases), than the similar
form using * and parentheses.
> (c) I don't like unnecessary {}s. I remove them when I find a compound
> statement has only one statement in it, and I put them back if
> editing adds more:
>
> void selection_sort(int n, T A[])
> {
> for (int i = 0; i < n - 1; i++) {
> int min = i;
> for (int j = i + 1; j < n; j++)
> if (less_than(A[j], A[min]))
> min = j;
> swap(&A[i], &A[min]);
> }
> }
I don't know what to make of this preference. I don't strongly
mind the braces being left off for small bodies (although I
don't do that myself), but for larger ones it seems wrong. Do
you think this is just because this is what you're used to, or
is there some other motivation/benefit that is driving this?
When there is a single controlled statement that fits on the
same line as the controlling part, I often choose to write
both parts together (and without braces) on a single line.
I pretty much always do this in the case of if() and some
sort of control transfer statement - break, continue, goto,
or return. But that's not the same as what you're saying.
> (I'd /like/ to be able to do this for function bodies too! The
> function above has only one statement in the body, but I am forced
> to write it in {}s. I think this last point comes from taking too
> much BCPL in my youth.)
Every programmer can have any single statement to define the
body of any function definition, as long as that statement is
a compound statement. (paraphrasing Henry Ford dictum about car
color.)
> (d) Ditto ()s in expressions. I don't always use minimal bracketing,
> but some extra ()s annoy me. && binding more tightly than || seems
> so natural to me that I don't like reminding myself with extra ()s.
Yeah I am fully on board here.
> (e) I have no qualms about some side-effects in expressions. Not sure
> exactly which are OK with me and which not, but the odd
>
> while ((c = *ptr++) != target) ...
>
> is certainly fine in my book.
Right. The key point is that some patterns are fine but there is
a line that is important not to cross. I'm not sure what this
means as it pertains to teaching new students.
> [... algol 68 related ...]
>
> As I say, there are probably loads more. The point is that pretty much
> every one of these has been met with opprobrium here at some time or
> other. Nothing wrong with that of course.
I think that depends on how much substance was offered, and how
much of the reaction was just "euuw, this is not what I'm used
to."
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-03-21 11:13 +0000 |
| Message-ID | <87r2b0xyy4.fsf@bsb.me.uk> |
| In reply to | #141790 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>> ...
>>>
>>>> My coding style (when not constrained by cooperation) appears to
>>>> be widely disliked.
>>
>> (I was talking about C, of course)
>>
>>> Well that has me curious. Can you say what about your style
>>> choices people dislike? Or post a small example (perhaps
>>> with commentary)? I'm always interested to learn what
>>> people react to.
>>
>> I've probably forgotten many, but
>>
>> (a) I like using multiple declarators in one declaration to collect
>> related objects:
>>
>> double dest[SIZE], *dp = dest, *ep = (&dest)[1];
>
> I'm completely with you on this one.
>
>
>> (b) I don't mind using slightly obscure parts of the language if it
>> seems right, like using (&dest)[1] above to avoid duplicating the
>> use of SIZE.
>
> The construct (&dest)[1] is a charming idiom. Every serious C
> programmer should have that in their toolbag. Although, I'm
> having trouble thinking of another example in this category (ie,
> that you might be thinking of). Can you give another example
> or two?
It rather depends on what's considered obscure. More than once, I've
used a typedef for a function type to declare functions where there are
many of them:
typedef value bin_operator(value, value);
bin_operator add, sub, mul, div, exp;
And I don't mind using an array of length one when an API requires that
all objects of some type must be passed using a pointer rather than by
copying. Even to the extent of using typedef again though I flip-flop
from decade to decade over whether that's hiding too much:
typedef struct actual_object object[1];
object a = {...}, b = {...}, c;
calc(c, a, b);
> An idiom I use now and then, and which I'm sure some other people
> would just hate, is 0[pointer-expression], to access the value
> pointed to by the expression. I find the []'s help me chunkify
> the expression more easily (ie, in some cases), than the similar
> form using * and parentheses.
I don't think I've been moved to use that though I haven't programmed in
C in earnest for a very long time now.
>> (c) I don't like unnecessary {}s. I remove them when I find a compound
>> statement has only one statement in it, and I put them back if
>> editing adds more:
>>
>> void selection_sort(int n, T A[])
>> {
>> for (int i = 0; i < n - 1; i++) {
>> int min = i;
>> for (int j = i + 1; j < n; j++)
>> if (less_than(A[j], A[min]))
>> min = j;
>> swap(&A[i], &A[min]);
>> }
>> }
>
> I don't know what to make of this preference. I don't strongly
> mind the braces being left off for small bodies (although I
> don't do that myself), but for larger ones it seems wrong. Do
> you think this is just because this is what you're used to, or
> is there some other motivation/benefit that is driving this?
I think some of it comes from saving vertical space on OHP slides from
the 80s and 90s.
> When there is a single controlled statement that fits on the
> same line as the controlling part, I often choose to write
> both parts together (and without braces) on a single line.
> I pretty much always do this in the case of if() and some
> sort of control transfer statement - break, continue, goto,
> or return. But that's not the same as what you're saying.
>
>> (I'd /like/ to be able to do this for function bodies too! The
>> function above has only one statement in the body, but I am forced
>> to write it in {}s. I think this last point comes from taking too
>> much BCPL in my youth.)
>
> Every programmer can have any single statement to define the
> body of any function definition, as long as that statement is
> a compound statement. (paraphrasing Henry Ford dictum about car
> color.)
Of course, but I think it's clear it's the {} that are in fact the
issue. Have I missed your point?
>> (d) Ditto ()s in expressions. I don't always use minimal bracketing,
>> but some extra ()s annoy me. && binding more tightly than || seems
>> so natural to me that I don't like reminding myself with extra ()s.
>
> Yeah I am fully on board here.
>
>
>> (e) I have no qualms about some side-effects in expressions. Not sure
>> exactly which are OK with me and which not, but the odd
>>
>> while ((c = *ptr++) != target) ...
>>
>> is certainly fine in my book.
>
> Right. The key point is that some patterns are fine but there is
> a line that is important not to cross. I'm not sure what this
> means as it pertains to teaching new students.
There are lots of lines in programming and they are rarely clear-cut. I
can't say what's beyond good taste here, but I know it when I see it (to
paraphrase Potter Stewart).
>> [... algol 68 related ...]
>>
>> As I say, there are probably loads more. The point is that pretty much
>> every one of these has been met with opprobrium here at some time or
>> other. Nothing wrong with that of course.
>
> I think that depends on how much substance was offered, and how
> much of the reaction was just "euuw, this is not what I'm used
> to."
I'm not so convinced that there can be much of substance offered, nor am
I so certain that "this is not what I'm used to" is not a good reason to
object to some code style. It's probable that, in some contexts,
programming in a style that a majority of people are used to is good
practice.
The best substance would come from serious studies of coding in a
professional context, and not simply from those that were prevalent at
one time, namely studies of how easily programmers (often students)
misunderstand single out of context program fragments. I suspect (with
no evidence) that there can be some benefit to writing "grown-up" code
in that it may be less likely to be fiddled with without proper study.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-21 23:25 -0700 |
| Subject | Re: Readability (was: "...the value becomes,indeterminate each time the declaration is reached") |
| Message-ID | <86o963o282.fsf@mailhub.linuxsc.com> |
| In reply to | #142169 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> I think some of [leaving braces off of controlled statements when
>> possible] comes from saving vertical space on OHP slides from the
>> 80s and 90s.
>
> I am using a video projector now, but it's the same point:
>
> When programs have many lines, I need to use a smaller font
> if I want the whole program to be visible on the screen, and
> then some participant will not be able to read the characters
> (of that small font) - or only a smaller part of the program
> can be displayed (with a larger font).
If a program has that many lines, it should be broken up
into smaller pieces that can each be understood individually.
> With my formatting style, however, I can insert braces
> /without/ consuming more vertical space:
>
> for( i = 0; i < 10; ++i )
> printf( "%d\n", i );
>
> becomes
>
> for( i = 0; i < 10; ++i )
> { printf( "%d\n", i ); }
>
> , and when another line is inserted:
>
> for( i = 0; i < 10; ++i )
> { printf( "%d\n", i );
> printf( "%d\n", i ); }
This style has other defects, glaringly obvious, that more than
overcome the comparatively minor benefit of taking one fewer
line. A splendid example of the tail wagging the dog.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-03-24 03:01 -0700 |
| Message-ID | <86y354mw04.fsf@mailhub.linuxsc.com> |
| In reply to | #142169 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[trimming...]
>>> (b) I don't mind using slightly obscure parts of the language if it
>>> seems right, like using (&dest)[1] above to avoid duplicating the
>>> use of SIZE.
>>
>> The construct (&dest)[1] is a charming idiom. Every serious C
>> programmer should have that in their toolbag. Although, I'm
>> having trouble thinking of another example in this category (ie,
>> that you might be thinking of). Can you give another example
>> or two?
>
> It rather depends on what's considered obscure. More than once, I've
> used a typedef for a function type to declare functions where there are
> many of them:
>
> typedef value bin_operator(value, value);
> bin_operator add, sub, mul, div, exp;
That's a good example. It isn't something I myself would call
obscure, but certainly it is not universal.
> And I don't mind using an array of length one when an API requires that
> all objects of some type must be passed using a pointer rather than by
> copying. Even to the extent of using typedef again though I flip-flop
> from decade to decade over whether that's hiding too much:
>
> typedef struct actual_object object[1];
> object a = {...}, b = {...}, c;
> calc(c, a, b);
A variation on this pattern that I have tried on occasion is an
incomplete array type:
typedef struct Object_struct Objects[];
Doing this allows the 'Objects' type to create one or more
instances, in an array (and also as a type for function
parameters, which I assume was likewise intended in your example).
Also it has the property that the automatic declarations must have
initializers, which is sometimes a plus and sometimes an
annoyance. (Here again I'm sure some C developers would hate
this typedef pattern.)
>> [asking about leaving off redundant braces]
>
> I think some of it comes from saving vertical space on OHP slides
> from the 80s and 90s.
Interesting. There is some sort of lesson in there, if I could
figure out what it is.
>>> (I'd /like/ to be able to [write single statement
>>> function bodies without needing the outermost braces].)
>>
>> Every programmer can have any single statement to define the
>> body of any function definition, as long as that statement is
>> a compound statement. (paraphrasing Henry Ford dictum about car
>> color.)
>
> Of course, but I think its clear its the {} that are in fact the
> issue. Have I missed your point?
Hmmm, yes, to the extent that there was a point. I was just
trying to be funny.
>>> (e) I have no qualms about some side-effects in expressions. Not
>>> sure exactly which are OK with me and which not, but the odd
>>>
>>> while ((c = *ptr++) != target) ...
>>>
>>> is certainly fine in my book.
>>
>> Right. The key point is that some patterns are fine but there is
>> a line that is important not to cross. I'm not sure what this
>> means as it pertains to teaching new students.
>
> There are lots of lines in programming and they are rarely
> clear-cut. I can't say what's beyond good taste here, but I know
> it when I see it (to paraphrase Potter Stewart).
For me the baseline is "Is there some reason for doing so beyond
just that the syntax allows it?". Following common idioms is one
reason. Reflecting some semantic invariant is another. Some
others could be listed, I feel sure. But I agree with what (I
think) you're saying, that this is an area that must rely to some
extent on judgment, and is not just formulaic.
>>> [... algol 68 related ...]
>>>
>>> As I say, there are probably loads more. The point is that pretty
>>> much every one of these has been met with opprobrium here at some
>>> time or other. Nothing wrong with that of course.
>>
>> I think that depends on how much substance was offered, and how
>> much of the reaction was just "euuw, this is not what I'm used
>> to."
>
> I'm not so convinced that there can be much of substance offered,
I think we have different ideas for what is meant by "substance"
here. For me there is substance if a reason expresses some
effect or condition external to the observer. An obvious example
is a reason you mentioned, a desire to save lines for slides in
an overhead projector. A more subtle example is (hypothetically
speaking) "while loops need more mental effort to understand than
for loops". Two points deserve mention here. One is that a
reason can be observer _dependent_ while still being _external_
to the observer: programmer Jack may find while() loops more
taxing at the same time that programmer Jill finds for() loops
more taxing, but both are (at least in principle) testable using
external measurement (as opposed to self-reporting). The second
point is that I don't insist on any data to support a proposed
reason (ie, for the purpose of judging whether it has substance).
I might not believe a proposed rationale has merit, but if it can
be externally measured then it has substance regardless of
whether it ends up being right or wrong.
> nor am I so certain that "this is not what I'm used to" is not a
> good reason to object to some code style.
What I'm interested in is not how "good" a reason is but how
informed I am by hearing it. "This isn't what I'm used to", "I
think this looks ugly", or "IMHO style X is better than style Y",
all don't tell me anything about the style. They might tell me
something about the person offering the reaction, but essentially
nothing about the style itself. People who offer nothing but
personal opinion are, with few exceptions, offering nothing of
value. (And the exceptions are not the sort of people who are
drawn to comp.lang.c.)
> It's probable that, in some contexts, programming in a style that
> a majority of people are used to is good practice.
Absolutely. Maybe the right takeaway from that is to remember to
ask people what their context is and how might their comments
apply in some other (perhaps unknown) contexts.
> The best substance would come from serious studies of coding in a
> professional context, and not simply from those that were
> prevalent at one time, namely studies of how easily programmers
> (often students) misunderstand single out of context program
> fragments.
Right. (I had to read this sentence a couple times to understand
what you were saying, but now having done that I will just say
"right".) Until we get those we just have to do the best we can
with the studies we have.
> I suspect (with no evidence) that there can be some
> benefit to writing "grown-up" code in that it may be less likely
> to be fiddled with without proper study.
Interesting hypothesis. I have some ideas about that but I think
it better to defer those to some (as yet undetermined) later
time.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-02-25 16:03 -0800 |
| Message-ID | <86pnrfct6b.fsf@mailhub.linuxsc.com> |
| In reply to | #140969 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bart <bc@freeuk.com> writes:
>
>> A local variable in C can have a scope starting halfway through a
>> block, so it cannot have a scope attached to that whole block:
>>
>> float A; // A1
>> {
>> S1;
>> S2;
>> int A; // A2
>> S3;
>> S4;
>> }
>>
>> Call those two As A1 and A2.
>
> Seems odd to do that since you are talking about names. Clearer
> to call them the float and the int.
>
>> The scope of A2 ranges from half-way through the block, to the
>> end of the block.
>
> A2 has no scope because there is no name A2. The name A is in
> scope at every line in your example. It refers to the float in
> the first 4 lines, and to the int the rest.
Your description isn't exactly in sync with how the Standard uses
the term scope, which variously applies both to names and to
entities to which the names refer. Section 6.2.1 p4 says this
(in part) about scopes and scope overlap:
If an identifier designates two different entities in the
same name space, the scopes might overlap. If so, the scope
of one entity (the inner scope) will end strictly before the
scope of the other entity (the outer scope). Within the
inner scope, the identifier designates the entity declared
in the inner scope; the entity declared in the outer scope
is hidden (and not visible) within the inner scope.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-26 17:38 +1300 |
| Message-ID | <gdju6aFf55rU1@mid.individual.net> |
| In reply to | #141379 |
On 26/02/2019 13:03, Tim Rentsch wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> A local variable in C can have a scope starting halfway through a
>>> block, so it cannot have a scope attached to that whole block:
>>>
>>> float A; // A1
>>> {
>>> S1;
>>> S2;
>>> int A; // A2
>>> S3;
>>> S4;
>>> }
>>>
>>> Call those two As A1 and A2.
>>
>> Seems odd to do that since you are talking about names. Clearer
>> to call them the float and the int.
>>
>>> The scope of A2 ranges from half-way through the block, to the
>>> end of the block.
>>
>> A2 has no scope because there is no name A2. The name A is in
>> scope at every line in your example. It refers to the float in
>> the first 4 lines, and to the int the rest.
>
> Your description isn't exactly in sync with how the Standard uses
> the term scope, which variously applies both to names and to
> entities to which the names refer. Section 6.2.1 p4 says this
> (in part) about scopes and scope overlap:
The standard's use of the term scope depends on the scope of the use?
:)
> If an identifier designates two different entities in the
> same name space, the scopes might overlap. If so, the scope
> of one entity (the inner scope) will end strictly before the
> scope of the other entity (the outer scope). Within the
> inner scope, the identifier designates the entity declared
> in the inner scope; the entity declared in the outer scope
> is hidden (and not visible) within the inner scope.
>
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-02-04 21:31 -0800 |
| Message-ID | <q3b73a$h6j$1@dont-email.me> |
| In reply to | #140440 |
On 1/31/2019 11:53 AM, Bart wrote:
>>
>> Even before C99 one'd typically use every opportunity to defeat that
>> terrible "declarations only at the beginning of the block" rule and
>> resort to "poor-man's" version of mixing declarations and code by
>> introducing redundant blocks in the middle of statement flow: just to
>> bring the declaration closer to the point of actual usage. C99
>> thankfully provided one with an immeasurably more natural feature for
>> achieving that objective.
>
> Problems with this (some already discussed in the past):
>
> (1) You declare a variable at the place you first assign to it. But then
> find that you need to access it in an outer scope.
>
> (2) The code that first assigns to a variable is conditional, so there
> are two different assignments. You can't have two declarations of the
> same variable.
>
> (3) You declare a variable in-place. But then that bit of code ends up
> being wrapped in a nested block. Now you can't access it from further on
> in the code. Worse, if that variable was shadowing an outer one, the
> later access now accesses the wrong variable.
The first three are basically the same point repeated three times.
However, it is completely unclear what the actual *point* is :), since
none of this in any way demonstrate any problems with the common good
practice of declaring the variable *as locally as possible*.
So, we can safely discard these three.
> (4) Your code uses variables 'float x,y,z' which are clearly related.
> But applying the rule to declare each one where it is first assigned to,
> there might now be three different 'float x' (or y or z) declarations
> scattered through the code, and the relationship is lost. (And was it x
> and y? No, you've just spotted a float z, so /maybe/ it was x and y and
> z, but who knows?)
You are perverting the guideline and obviously trying to sneak in a bit
of demagogy by using the term "assigned". Firstly, the "rule" never said
that you have to separate the declarations of these variables. Secondly,
"assigned" really? No, no, no! Not "assigned", but *initialized* (!).
float
x = /* initializer for x */,
y = /* initializer for y */,
z = /* initializer for z */;
That's how you normally do it.
> (5) You're reading someone's code (without benefit of one of David
> Brown's tools that does away with every problem with the C language) and
> come across a variable 'z'; what type is it?
Huh?
Firstly, if you really need to know the type of the variable, than this
is actually major point (!) *for* declaring the variables as locally as
possible. In such case the type is right here, well within your field of
view, not somewhere up there, at the beginning of the block or (God
forbid!) at the beginning of the function.
Secondly, this actually sounds like an argument made by those people who
insist on casting the result of `malloc` claiming that it helps them to
"know what the type is". No, if you want to write competent code, you
have to learn to do it *without* knowing the type of the variable. The
need "know the type" is like a crutch, like training wheels on a bike.
Yeah, it is "easier" to walk with crutches, but only if you never
learned to walk without them. A competent C programmer knows know to
write and read *type-agnostic* code. Learning to do this is a mast, an
absolutely critical skill (!) for a C programmer. At one point you have
to tell yourself that it is about time you ditched those training wheels
on your bicycle. You have to learn to program without keeping that
"death grip" on the *type* of the variable. Type does not matter. If you
feel that you have to know it at all times, you are doing it very very
wrongly.
> It's a very busy function, but if the style is to declare things just
> anywhere, then you /have/ to scan every line backwards until you
> encounter it. You can't just look at the top of the function. Even if
> you see it there, you can't be sure there isn't a closer declaration.
This is actually the most obviously incorrect part. It is much easier to
find the declaration of variable when it is localized nearby, as opposed
to when it is hidden in a pile of variable declarations at the beginning
of the block, or an even larger (!) pile of variable declarations at the
beginning of the function. Every C programmer knows that it is actually
virtually *impossible* to find a variable declarations in code that
declares all variables at the beginning of each function.
--
Best regards,
Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2019-02-01 02:38 +0000 |
| Message-ID | <5c53a3a0.354979516@news.xmission.com> |
| In reply to | #140438 |
On Thu, 31 Jan 2019 09:55:19 -0800, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote: >On 1/30/2019 10:23 AM, David Brown wrote: >> >> No, mixing declarations and code is not sloppy or lazy, not does it lead >> to puzzles. It leads to clearer and simpler code, with less chance of >> errors. > >Exactly. > >The ability to interleave declarations and statements gives one the >opportunity to supply a meaningful initializer at the point of >declaration. This alone immediately closes the debate: declarations >should be made locally, as close to the point of the actual usage as >possible. I agree that it's good style to declare objects in good proximity to the code that uses them. I consider it poor style to mix declarations with code (including gratuitous blocks). My conclusion is that if (a) you avoid mixing code with declarations, but (b) your declarations are too far removed from the code that uses them, then (c) your functions are too long and (generally, probably) need to be refactored. Kind of academic though. You code your code, I code my code, and if we're paid to code we code how the boss says to code.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-01 01:57 -0800 |
| Message-ID | <27407844-23e3-46dd-a122-cf2763c95cf3@googlegroups.com> |
| In reply to | #140442 |
On Friday, 1 February 2019 02:36:12 UTC, Scott wrote: > > Kind of academic though. You code your code, I code my code, and if > we're paid to code we code how the boss says to code. > No, because if you work for a small company or a small department, then you've got a good chance of having input into the house style guide.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2019-02-01 13:26 +0300 |
| Message-ID | <20190201132618.6ed57eb670bad5d4400ccbc8@g{oogle}mail.com> |
| In reply to | #140438 |
Andrey Tarasevich: >The ability to interleave declarations and statements gives >one the opportunity to supply a meaningful initializer at >the point of declaration. This alone immediately closes the >debate: declarations should be made locally, as close to >the point of the actual usage as possible. You can declare a variable at the top but initialise is immediately before use. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-02-01 07:18 -0500 |
| Message-ID | <q31df3$pkt$1@dont-email.me> |
| In reply to | #140445 |
On 2/1/19 05:26, Anton Shepelev wrote: > Andrey Tarasevich: > >> The ability to interleave declarations and statements gives >> one the opportunity to supply a meaningful initializer at >> the point of declaration. This alone immediately closes the >> debate: declarations should be made locally, as close to >> the point of the actual usage as possible. > > You can declare a variable at the top but initialise is > immediately before use. Thereby taking the risk of using the value of that variable before it's been initialized. I just don't see any reason (other than the fact that it didn't use to be permitted) why it's bad to intermingle statements and declarations, so delaying a declaration until it can be initialized with a value that's intended to be used seems entirely reasonable to me (assuming that a declaration in that place has enough scope to cover all the ways in which it will need to be used).
[toc] | [prev] | [next] | [standalone]
Page 17 of 19 — ← Prev page 1 … 15 16 [17] 18 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web