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 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-06 00:15 +0000 |
| Message-ID | <oGp6E.260442$IF1.839@fx03.am4> |
| In reply to | #140585 |
On 05/02/2019 22:59, David Brown wrote:
> On 05/02/2019 19:44, Bart wrote:
> As I said, you have a knee-jerk panic reaction to C++.
I first looked at C++ in 1990s. Hardly knee-jerk over 25 years.
>> "A C compiler takes roughly one to two man years to create, whereas a
>> C++ compiler takes 15 to 20"
>
> No one is suggesting you write a C++ compiler.
I'm attempting a language that will do quite a big chunk of what C++ can
do, but it necessarily has to be simpler and more doable.
> So how do you deal with:
>
> const width = height * 2;
> const height = width / 2;
>
> That's just an easy example.
I've mentioned just such examples a few times. They are not allowed
because they are impossible to evaluate.
Such declarations must make sense; this doesn't make sense in C even if
you tried to rearrange it. If I actually try this:
C:\mapps>type t.m
const width = height*2
const height = width/2
C:\mapps>mm t
Compiling t.m to t.exe
On line 1 in file t.m
... Circular const reference detected
Where it does make sense, then declaration order shouldn't matter.
If you like declarations mixed with code, then you should appreciate
being able to move lines around without worrying if a reference to a
name now precedes its declaration.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 08:25 +0100 |
| Message-ID | <q3e25c$lui$1@dont-email.me> |
| In reply to | #140589 |
On 06/02/2019 01:15, Bart wrote: > On 05/02/2019 22:59, David Brown wrote: >> On 05/02/2019 19:44, Bart wrote: > >> As I said, you have a knee-jerk panic reaction to C++. > > I first looked at C++ in 1990s. Hardly knee-jerk over 25 years. You have a knee-jerk reaction to everything C++. It doesn't matter whether it started 25 years ago, or yesterday. There is nothing wrong with not liking C++, or not finding it a good match for the way you like to program, or thinking it is big and complex (that's plain fact). There /is/ something wrong with an attitude of "C++ does this, therefore it is a bad idea". > >>> "A C compiler takes roughly one to two man years to create, whereas a >>> C++ compiler takes 15 to 20" >> >> No one is suggesting you write a C++ compiler. > > I'm attempting a language that will do quite a big chunk of what C++ can > do, but it necessarily has to be simpler and more doable. > >> So how do you deal with: >> >> const width = height * 2; >> const height = width / 2; >> >> That's just an easy example. > > I've mentioned just such examples a few times. They are not allowed > because they are impossible to evaluate. > > Such declarations must make sense; this doesn't make sense in C even if > you tried to rearrange it. If I actually try this: > > C:\mapps>type t.m > const width = height*2 > const height = width/2 > > C:\mapps>mm t > Compiling t.m to t.exe > On line 1 in file t.m > ... Circular const reference detected > > Where it does make sense, then declaration order shouldn't matter. > > If you like declarations mixed with code, then you should appreciate > being able to move lines around without worrying if a reference to a > name now precedes its declaration. That does not follow at all. As I have said, I have nothing against being able to use functions in any order without forward declarations - it's not a feature that I miss in C, but I can well understand people liking it in other languages and I don't see it as a problem. That could be extended to variables, constants, and any other file-level declarations - again, it's not something I miss, but it seems a fine feature. (C++ has this within class definitions. This allows you to write inline methods in the class definition, referring to member variables or methods that are defined later. Thus you can put your "interface" part at the top of the class definition, and the "implementation" part later. The same could be done on a larger scale for other languages, covering files or modules. However, it is more important to find a good way to separate interface declarations and implementation definitions.) I do feel that it does not seem natural to have initialisations that depend on each other, and have them out of order. I am not convinced that level of flexibility and freedom helps - I think it can make it easier for people to write confusing code. But if you like it, then go for it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-06 11:51 +0000 |
| Message-ID | <nTz6E.393074$ZE1.13999@fx24.am4> |
| In reply to | #140599 |
On 06/02/2019 07:25, David Brown wrote:
> On 06/02/2019 01:15, Bart wrote:
>> On 05/02/2019 22:59, David Brown wrote:
>>> On 05/02/2019 19:44, Bart wrote:
>>
>>> As I said, you have a knee-jerk panic reaction to C++.
>>
>> I first looked at C++ in 1990s. Hardly knee-jerk over 25 years.
>
> You have a knee-jerk reaction to everything C++. It doesn't matter
> whether it started 25 years ago, or yesterday. There is nothing wrong
> with not liking C++, or not finding it a good match for the way you like
> to program, or thinking it is big and complex (that's plain fact). There
> /is/ something wrong with an attitude of "C++ does this, therefore it is
> a bad idea".
Many of its aims are good. The execution, not so much. Here's a very
mild example from https://en.cppreference.com/w/cpp/container/vector
(comments elided):
#include <iostream>
#include <vector>
int main()
{
std::vector<int> v = {7, 5, 16, 8};
v.push_back(25);
v.push_back(13);
for(int n : v) {
std::cout << n << '\n';
}
}
This actually isn't so bad. But this is the same program in my current
dynamic language:
proc start=
v := (7, 5, 16, 8)
v append:= 25
v append:= 13
forall n in v do
println n
od
end
Here's what it might be in my proposed /statically typed/ language (in
both, the entire program is shown):
proc start=
[*]int v := (7, 5, 16, 8)
v append:= 25
v append:= 13
forall n in v do
println n
od
end
(This last program could also be reduced to:
proc start=
println ([*]v:=(7,5,16,8); v &:=(25,16); v)
end
but here the output here will be '(7,5,16,8,25,16)'. In this language,
statements, declarations and expressions can all be interspersed.)
In both cases, such a data structure (flex array) is built-in and
requires no external template libraries nor are there extra overheads in
processing such a library.
And in both cases, the code is much cleaner than even this minimal C++
program.
Since the notion of a flexible array has been around since long before
C++ existed, what useful thing do you think I should take away from a
study of C++'s treatment of such arrays?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 14:41 +0100 |
| Message-ID | <q3eo76$c21$1@dont-email.me> |
| In reply to | #140611 |
On 06/02/2019 12:51, Bart wrote:
> On 06/02/2019 07:25, David Brown wrote:
>> On 06/02/2019 01:15, Bart wrote:
>>> On 05/02/2019 22:59, David Brown wrote:
>>>> On 05/02/2019 19:44, Bart wrote:
>>>
>>>> As I said, you have a knee-jerk panic reaction to C++.
>>>
>>> I first looked at C++ in 1990s. Hardly knee-jerk over 25 years.
>>
>> You have a knee-jerk reaction to everything C++. It doesn't matter
>> whether it started 25 years ago, or yesterday. There is nothing wrong
>> with not liking C++, or not finding it a good match for the way you
>> like to program, or thinking it is big and complex (that's plain
>> fact). There /is/ something wrong with an attitude of "C++ does this,
>> therefore it is a bad idea".
>
> Many of its aims are good. The execution, not so much. Here's a very
> mild example from https://en.cppreference.com/w/cpp/container/vector
> (comments elided):
>
> #include <iostream>
> #include <vector>
>
> int main()
> {
> std::vector<int> v = {7, 5, 16, 8};
>
> v.push_back(25);
> v.push_back(13);
>
> for(int n : v) {
> std::cout << n << '\n';
> }
> }
>
> This actually isn't so bad. But this is the same program in my current
> dynamic language:
>
> proc start=
> v := (7, 5, 16, 8)
>
> v append:= 25
> v append:= 13
>
> forall n in v do
> println n
> od
> end
Baring irrelevant details of syntax, the only difference here is that
your equivalent to a "std::vector<int>" is a built-in list type. That
can certainly be convenient for a common case, but does not help if you
want a vector of doubles here with initialisers that happen to be
integers, or if you want some completely different type as your
elements. It does not help if you want a list rather than a vector, or
an unorder map, or you want a different allocator for memory management.
It's good to make common use-cases simple. But C++ has a wider appeal -
it is not a one-man language. It has to cater for a large number of uses.
>
> Here's what it might be in my proposed /statically typed/ language (in
> both, the entire program is shown):
>
> proc start=
> [*]int v := (7, 5, 16, 8)
>
> v append:= 25
> v append:= 13
>
> forall n in v do
> println n
> od
> end
>
At this point, you do have control of the type within the vector, but
not of the vector. And your code is not practically different from the
C++ (no one cares about a little extra punctuation).
> (This last program could also be reduced to:
>
> proc start=
> println ([*]v:=(7,5,16,8); v &:=(25,16); v)
> end
>
> but here the output here will be '(7,5,16,8,25,16)'. In this language,
> statements, declarations and expressions can all be interspersed.)
>
If anyone thought that was a good idea, there is nothing to stop you
adding the relevant operators to C++ vectors and cout so that you could
write:
int main()
{
std::vector<int> v = {7, 5, 16, 8};
v += {25, 16};
std::cout << v;
}
Squeezing this all into one "std::cout << " statement would involve
either gcc extensions, or ugly lambdas, so there is little point.
However, since there is little point to this whole conversation other
than to discuss things, try things and learn things, I've tried it:
#include <vector>
#include <iostream>
#include <initializer_list>
void foo1(void) {
std::vector<int> v = {7, 5, 16, 8};
v.push_back(25);
v.push_back(13);
for(int n : v) {
std::cout << n << '\n';
}
}
template<typename T>
std::vector<T> operator+=(std::vector<T>& v,
const std::initializer_list<T> w)
{
for (auto x : w) {
v.push_back(x);
}
return v;
}
template<typename T, class CharT, class Traits>
std::basic_ostream<CharT, Traits>& operator<<(std::basic_ostream<CharT,
Traits>& os, std::vector<T> v)
{
os << "(";
for (auto x : v) {
os << x << ", ";
}
os << ")";
return os;
}
void foo2(void) {
std::vector<int> v = {7, 5, 16, 8};
v += {25, 13};
std::cout << v << '\n';
}
void foo3(void) {
std::cout << ({ std::vector<int> v = {7, 5, 16, 8};
v += {25, 13}; v; }) << '\n';
}
void foo4(void) {
std::cout << []{ std::vector<int> v = {7, 5, 16, 8};
v += {25, 13}; return v; }() << '\n';
}
These all give the same output (baring formatting). "foo3" uses gcc
extensions, while "foo4" uses a lambda.
To be honest, I think it would be reasonable for the C++ standard
library to provide operators like these for vectors. Maybe there are
some complications that I have not considered, or maybe no one has asked
loudly enough.
> In both cases, such a data structure (flex array) is built-in and
> requires no external template libraries nor are there extra overheads in
> processing such a library.
Having things built into the language makes those particular cases
efficient - but makes it harder to be general, and harder to update and
extend the language. (This is not much concern with a one-man language,
but a significant concern for a real language - changing std::vector
does not mean changing the compiler.)
>
> And in both cases, the code is much cleaner than even this minimal C++
> program.
"Clean" is very much in the eye of the beholder here, and that eye is
highly biased.
>
> Since the notion of a flexible array has been around since long before
> C++ existed, what useful thing do you think I should take away from a
> study of C++'s treatment of such arrays?
>
I did not at any point suggest that you considered C++'s arrays as a
source of inspiration. However, since you ask, the things you might
consider include:
Support for pre-allocated space.
Support for different allocators.
Automatic handling of constructors and destructors.
Use of "move" rather than "copy" when possible.
Iterators, forwards and backwards, constant and mutable.
Choice of fast or checked accesses.
Different types of arrays, hash maps, etc.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-06 14:17 +0000 |
| Message-ID | <P%B6E.864537$Fi6.801232@fx12.am4> |
| In reply to | #140621 |
On 06/02/2019 13:41, David Brown wrote:
> On 06/02/2019 12:51, Bart wrote:
> Squeezing this all into one "std::cout << " statement would involve
> either gcc extensions, or ugly lambdas, so there is little point.
> However, since there is little point to this whole conversation other
> than to discuss things, try things and learn things, I've tried it:
>
> #include <vector>
> #include <iostream>
> #include <initializer_list>
>
> void foo1(void) {
> std::vector<int> v = {7, 5, 16, 8};
>
> v.push_back(25);
> v.push_back(13);
>
> for(int n : v) {
> std::cout << n << '\n';
> }
> }
>
> template<typename T>
> std::vector<T> operator+=(std::vector<T>& v,
> const std::initializer_list<T> w)
> {
> for (auto x : w) {
> v.push_back(x);
> }
> return v;
> }
>
> template<typename T, class CharT, class Traits>
> std::basic_ostream<CharT, Traits>& operator<<(std::basic_ostream<CharT,
> Traits>& os, std::vector<T> v)
> {
...
> These all give the same output (baring formatting). "foo3" uses gcc
> extensions, while "foo4" uses a lambda.
Here you've shown why C++ compilers take so much longer to write, and
why C++ is viewed as a complex language.
>> Since the notion of a flexible array has been around since long before
>> C++ existed, what useful thing do you think I should take away from a
>> study of C++'s treatment of such arrays?
>>
>
> I did not at any point suggest that you considered C++'s arrays as a
> source of inspiration. However, since you ask, the things you might
> consider include:
The vector class was the first C++ feature I thought of, and a natural
next step to the fixed arrays and 'dynamic' arrays of C.
> Support for pre-allocated space.
> Support for different allocators.
> Automatic handling of constructors and destructors.
> Use of "move" rather than "copy" when possible.
> Iterators, forwards and backwards, constant and mutable.
> Choice of fast or checked accesses.
> Different types of arrays, hash maps, etc.
My implementation of these will initially come from my dynamic language,
which already has some of this stuff, and lots more of its own (bit
arrays, slicing and views, heterogeneous arrays (using variant
elements), data sharing, automatic memory management, garbage
collection, bounds-checking, mutability flags...)
That really isn't the problem.
The challenge is to make such features available effortlessly and simply
using a clean, friendly, non-intimidating syntax, and to have a language
that will also build effortlessly
For that, it is better to look for user-friendly script languages for
inspiration rather than one of the most insanely complex.
That's all I'm saying.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-02-06 06:37 -0800 |
| Message-ID | <df3f0cf0-e303-49ea-a193-2eae2adc06bf@googlegroups.com> |
| In reply to | #140628 |
On Wednesday, 6 February 2019 14:17:28 UTC, Bart wrote: > > My implementation of these will initially come from my dynamic language, > which already has some of this stuff, and lots more of its own (bit > arrays, slicing and views, heterogeneous arrays (using variant > elements), data sharing, automatic memory management, garbage > collection, bounds-checking, mutability flags...) > > That really isn't the problem. > > The challenge is to make such features available effortlessly and simply > using a clean, friendly, non-intimidating syntax, and to have a language > that will also build effortlessly > > For that, it is better to look for user-friendly script languages for > inspiration rather than one of the most insanely complex. > > That's all I'm saying. > You have to decide what the unique selling points of your language are. They seem to be that the compiler is simple enough to be implemented by one person, and compilation is very fast. In addition, the syntax is simple. So C++ is not your inspiration, I'd agree.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-06 16:10 +0100 |
| Message-ID | <q3etct$b1n$1@dont-email.me> |
| In reply to | #140628 |
On 06/02/2019 15:17, Bart wrote:
> On 06/02/2019 13:41, David Brown wrote:
>> On 06/02/2019 12:51, Bart wrote:
>
>> Squeezing this all into one "std::cout << " statement would involve
>> either gcc extensions, or ugly lambdas, so there is little point.
>> However, since there is little point to this whole conversation other
>> than to discuss things, try things and learn things, I've tried it:
>>
>> #include <vector>
>> #include <iostream>
>> #include <initializer_list>
>>
>> void foo1(void) {
>> std::vector<int> v = {7, 5, 16, 8};
>>
>> v.push_back(25);
>> v.push_back(13);
>>
>> for(int n : v) {
>> std::cout << n << '\n';
>> }
>> }
>>
>> template<typename T>
>> std::vector<T> operator+=(std::vector<T>& v,
>> const std::initializer_list<T> w)
>> {
>> for (auto x : w) {
>> v.push_back(x);
>> }
>> return v;
>> }
>>
>> template<typename T, class CharT, class Traits>
>> std::basic_ostream<CharT, Traits>& operator<<(std::basic_ostream<CharT,
>> Traits>& os, std::vector<T> v)
>> {
> ...
>> These all give the same output (baring formatting). "foo3" uses gcc
>> extensions, while "foo4" uses a lambda.
>
> Here you've shown why C++ compilers take so much longer to write, and
> why C++ is viewed as a complex language.
No one will argue that with you. C++ /is/ a complex language, and its
compilers (and standard libraries) are hard to write. I am showing a
little of what can be written in the language, not denying that it is
complex. (Nor do I deny that simplicity in a language is a good thing,
as long as it has the features you need, nor do I deny it is possible to
create a language with the important features of C++ but less of the
complexity - if you don't need the historical baggage and compatibility
of C++.)
>
>>> Since the notion of a flexible array has been around since long before
>>> C++ existed, what useful thing do you think I should take away from a
>>> study of C++'s treatment of such arrays?
>>>
>>
>> I did not at any point suggest that you considered C++'s arrays as a
>> source of inspiration. However, since you ask, the things you might
>> consider include:
>
> The vector class was the first C++ feature I thought of, and a natural
> next step to the fixed arrays and 'dynamic' arrays of C.
>
Fair enough.
I would not call C's VLA's "dynamic" - their size may be determined at
run-time, but they cannot be changed after creation, and have severe
limitations compared to "dymanic arrays" in many languages.
>> Support for pre-allocated space.
>> Support for different allocators.
>> Automatic handling of constructors and destructors.
>> Use of "move" rather than "copy" when possible.
>> Iterators, forwards and backwards, constant and mutable.
>> Choice of fast or checked accesses.
>> Different types of arrays, hash maps, etc.
>
> My implementation of these will initially come from my dynamic language,
> which already has some of this stuff, and lots more of its own (bit
> arrays, slicing and views, heterogeneous arrays (using variant
> elements), data sharing, automatic memory management, garbage
> collection, bounds-checking, mutability flags...)
>
> That really isn't the problem.
>
> The challenge is to make such features available effortlessly and simply
> using a clean, friendly, non-intimidating syntax, and to have a language
> that will also build effortlessly
>
OK.
> For that, it is better to look for user-friendly script languages for
> inspiration rather than one of the most insanely complex.
>
Certainly you should look at other languages too - I would not suggest
that C++ is the /only/ language you look at. I merely suggest that you
do look at it - it is an immensely popular and successful language, and
you should learn from it (including learning what you want to avoid).
That's all /I/ am saying.
> That's all I'm saying.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-04 14:48 +0000 |
| Message-ID | <SgY5E.545389$3si.525295@fx08.am4> |
| In reply to | #140510 |
On 04/02/2019 10:14, David Brown wrote: > Jumbled development - Bart gives the impression that writing C code is a > chaotic process with code moving around randomly, with lots of variables > being used in widely spread parts of code, and functions being written > by trial and error, with no thought or planning, with no structure and > long lengths. Any coding can be a chaotic process: * During development and debugging, when bits of code are continuously springing into existence then disappearing or being re-structured into something else. * When heavily revising code, when you don't know how much of the old structure will be left, and don't exactly know what the final structure will be, or which variables will need to be retired and which new ones introduced. In all cases, you usually want to keep the code itself as clean as is practicable. You don't want to prematurely commit to the narrowest possible scope of a variable whose usage and context is still volatile. So, for this purpose, you want to start with the widest scope. Ideally you don't want to bother with declarations at all. But if they are needed, then you don't want to further restrict them. Obviously this is not how you work, where you start at the top of a function then code you way downwards emitting final, polished code as you go, as you know exactly what it will look comprise. But some of us can't work like that.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-04 22:09 +0100 |
| Message-ID | <q3a9n4$2lm$1@dont-email.me> |
| In reply to | #140517 |
On 04/02/2019 15:48, Bart wrote: > On 04/02/2019 10:14, David Brown wrote: > >> Jumbled development - Bart gives the impression that writing C code is a >> chaotic process with code moving around randomly, with lots of variables >> being used in widely spread parts of code, and functions being written >> by trial and error, with no thought or planning, with no structure and >> long lengths. > > Any coding can be a chaotic process: > > * During development and debugging, when bits of code are continuously > springing into existence then disappearing or being re-structured into > something else. > > * When heavily revising code, when you don't know how much of the > old structure will be left, and don't exactly know what the final > structure will be, or which variables will need to be retired and > which new ones introduced. > > In all cases, you usually want to keep the code itself as clean as is > practicable. You don't want to prematurely commit to the narrowest > possible scope of a variable whose usage and context is still volatile. > Of course you want to keep your scope as narrow as reasonably practical! That helps you keep your changes concise and organised, not chaotic. And it keeps your changes tightly together, which is a huge advantage when you compare revisions. > So, for this purpose, you want to start with the widest scope. Ideally > you don't want to bother with declarations at all. But if they are > needed, then you don't want to further restrict them. > That strikes me as a counter-productive way to work. > > Obviously this is not how you work, where you start at the top of a > function then code you way downwards emitting final, polished code as > you go, as you know exactly what it will look comprise. > I certainly change my code as I work, but I don't have the kind of scatter-gun approach that you are suggesting. And small-scope variables are absolutely a key to being able to make concise and careful changes to code, without leaping back and forth. > But some of us can't work like that. > >
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-05 10:19 +1300 |
| Message-ID | <gbroj3Ffhg9U2@mid.individual.net> |
| In reply to | #140526 |
On 05/02/2019 10:09, David Brown wrote: > > I certainly change my code as I work, but I don't have the kind of > scatter-gun approach that you are suggesting. And small-scope variables > are absolutely a key to being able to make concise and careful changes > to code, without leaping back and forth. Especially if you are using a decent editor that supports extract function refactoring. The smaller the scope of variables, the fewer superfluous parameters you have to clean up in your extracted functions. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2019-02-04 22:05 -0800 |
| Message-ID | <q3b930$p0k$1@dont-email.me> |
| In reply to | #140446 |
On 2/1/2019 4:15 AM, Bart wrote: > There probably isn't that much more to say apart from observations: > > (6) Outside of a function, most declarations aren't made at the point of > first use. If a typedef T if first used by a function half-way through a > module, then you tend not to see typedefs interspersed with function > definitions. They are usually collected together at the top. Same with > module-scope functions. No, this won't fly. C language does not support concept of "first use" for external variable definitions at all. > (7) The parameter declarations in a function, necessarily have go at the > top. Although, if the style is to have declarations anywhere (I mean in > any nested block not necessarily halfway along a block) you may still > need to scan all the code to see if a parameter name has been reused. > > (With all declarations at the top of a function, not only would that be > a quicker check, but it would not be necessary as the scope is the same > as the parameter scope; you can't reuse a parameter name) Another miss. The key point here is actually that parameters will always begin their lives *with a meaningful initializer*, which is kinda the point of localized declarations. And the fact that they are declared at the top does not in any way contradict the idea of declaring as locally as possible. They are *parameters* after all. > (8) I don't personally like the style because it spoils the 'lines' of > the code, or the algorithm, having declarations cluttering it up. (My > own two languages, I frequently paste code between them, and it's the > same syntax. But one needs static type declarations like C, the other > once doesn't. Then having mixed declarations is a nuisance. Another miss. Firstly, declarations do not spoil the lines at all, since they usually occupy the same lines as former assignments. Secondly, mid-code declarations actually make code *self-contained*, thus making it much easier to rearrange code fragments. > (9) With the earlier float x,y,z example where the declarations are all > mixed up, the deciding to change them to double x,y,z is harder. First > you have to herd them all up, them you have to know that you've got them > all (was it float w,x,y,z?). This is just a consequence of the misleading statements you made in that "earlier float x,y,z example". Already covered there. > (10) It is (for me at least) a great help to have a convenient index of > all the local variables used in a function, in a place I can quickly > locate. (Note I don't use block scopes.) It also makes it a good place > to comment the use of some of them. (The analogy I've used is having a > cast of characters at the start of play, instead of having to construct > such a list by having to painstakingly schlepp through the whole text.) This is a fallacy. The need "to comment the use of some of them" in 9 cases out of 10 is actually a *direct consequence* of the very practice to pile up the declarations at the top :) Localized declarations, on the other hand, would be perfectly self-explanatory in most of those cases, thus eliminating the need for comments entirely. As for the "index"... I don't see the need for such index, or its "convenience" (for what?). It definitely looks like a solution looking for a problem, an unnecessary maintenance chore. > (11) With all declarations at the top a function (this is a style that > doesn't use block scopes), you can be sure that no variable names are > reused, causing problems and obscure bugs with inadvertent shadowing. Another major (!) miss. "Shadowing" is a feature, not a problem. Once you learn to localize the use of your variables, "shadowing" will *save* you from problems caused by accidental reuse of the same *name* (i.e. it becomes a non-problem). By declaring variable at the top of the function you are inviting a considerable greater danger of inadvertent reuse of the same variable, leading to incorrect assumptions about its current (latest) value, especially after rearranging the code (!). There are hundreds more bugs caused by this problem, that by "shadowing". As I mentioned before, localized declarations make local code self-contained, thus allowing one to rearrange is safely. > (12) The emphasis in this group has always been having functions as > small as possible. But in that case, what is the point of then striving > to have the smallest possible scope for any variable? The scope is > already small enough! No! A resounding "WRONG"! This is a major fallacy, a typical "freshman" rule, that should be discarded mercilessly at the "sophomore" year: thrown at the ground and killed with fire. Never think of functions in terms of how "small" or "large" they are. A function has to implement a well-rounded *abstraction* - this is The One and Only Rule. Whether implementing such a well-rounded abstraction will take a few lines of code, or a 1000 pages of code (yes, for just one function) is completely irrelevant. If you are splitting your functions into smaller ones without extracting adequate abstractions, just because the original functions are "too long", you are doing it very very wrong. "The emphasis in this group" has never been as ridiculously primitive as "having functions as small as possible". That would be is an insult to this group. More precisely, you probably misunderstood something along the way. > (13) I've touched on this, but during development, if striving to have > the smallest scope, then the scope would be constantly changing as lines > are added, moved, removed and modified. It would be chaotic. As has been stated many times before, this is actually an argument for localized declarations. It is not clear why you are presenting it here. Localized declarations makes local code self-sufficient and self-maintaining in terms of code addition, code removal and code reordering. Declarations "at the top" turn it into a chaotic maintenance nightmare because of the obvious need to perform synchronized maintenance in two places instead of one. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-12 12:10 +0000 |
| Message-ID | <AIy8E.1059193$Sj4.999061@fx15.am4> |
| In reply to | #140446 |
On 01/02/2019 12:15, Bart wrote: [Enumerating the issues with mixing declarations with code] > (1) .... > (13) I've touched on this, but during development, if striving to have > the smallest scope, then the scope would be constantly changing as lines > are added, moved, removed and modified. It would be chaotic. (14) In some non-C code, I've had to manually tweak every declaration in some modules for a change of syntax. This was easy to do because they're all at the top of a function. But I didn't realise /how/ easy that made it until I encountered errors because one or two were hidden in the function's code and had been missed. Imagine if most declarations had been like that. (15) The tweak was to require a 'var' prefix before each declaration. This has the side-effect of making the declaration block at the top of a function stand out even more, with a clearer demarcation as to where that block finishes and the code proper starts. However /now/ mixing declarations in the code would spoil the look of the code even more. I'm not against such mixing where appropriate, especially in a language without block-scopes. Declarations such as 'let' may necessarily need to be created in-place. But for smallish functions, for ordinary variables, and where there are block scopes so a possibility of overloading the same within the function, it is just unnecessary.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-13 08:47 +1300 |
| Message-ID | <gcgm6gFgcocU7@mid.individual.net> |
| In reply to | #140872 |
On 13/02/2019 01:10, Bart wrote: > On 01/02/2019 12:15, Bart wrote: > > > [Enumerating the issues with mixing declarations with code] > > > (1) .... > >> (13) I've touched on this, but during development, if striving to have >> the smallest scope, then the scope would be constantly changing as lines >> are added, moved, removed and modified. It would be chaotic. > > (14) In some non-C code, I've had to manually tweak every declaration in > some modules for a change of syntax. This was easy to do because they're > all at the top of a function. But I didn't realise /how/ easy that made > it until I encountered errors because one or two were hidden in the > function's code and had been missed. Imagine if most declarations had > been like that. C syntax doesn't change.... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-12 12:41 -0800 |
| Message-ID | <lnftssspsf.fsf@kst-u.example.com> |
| In reply to | #140877 |
Ian Collins <ian-news@hotmail.com> writes:
[...]
> C syntax doesn't change....
....much.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-12 20:55 +0000 |
| Message-ID | <BpG8E.225288$N14.182552@fx28.am4> |
| In reply to | #140877 |
On 12/02/2019 19:47, Ian Collins wrote: > On 13/02/2019 01:10, Bart wrote: >> On 01/02/2019 12:15, Bart wrote: >> >> >> [Enumerating the issues with mixing declarations with code] >> >> > (1) .... >> >>> (13) I've touched on this, but during development, if striving to have >>> the smallest scope, then the scope would be constantly changing as lines >>> are added, moved, removed and modified. It would be chaotic. >> >> (14) In some non-C code, I've had to manually tweak every declaration in >> some modules for a change of syntax. This was easy to do because they're >> all at the top of a function. But I didn't realise /how/ easy that made >> it until I encountered errors because one or two were hidden in the >> function's code and had been missed. Imagine if most declarations had >> been like that. > > C syntax doesn't change.... Actually the change I made could also be done to C, although there it wouldn't be binding. (Namely, adding an empty 'var' macro at the start of variable declarations.) And there are plenty of other things you can be doing that involves scanning through every declaration, that would be helped by having them grouped together. Like adding 'const' everywhere.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-13 10:07 +1300 |
| Message-ID | <gcgqtbFgcocU8@mid.individual.net> |
| In reply to | #140879 |
On 13/02/2019 09:55, Bart wrote: > On 12/02/2019 19:47, Ian Collins wrote: >> On 13/02/2019 01:10, Bart wrote: >>> On 01/02/2019 12:15, Bart wrote: >>> >>> >>> [Enumerating the issues with mixing declarations with code] >>> >>> > (1) .... >>> >>>> (13) I've touched on this, but during development, if striving to have >>>> the smallest scope, then the scope would be constantly changing as lines >>>> are added, moved, removed and modified. It would be chaotic. >>> >>> (14) In some non-C code, I've had to manually tweak every declaration in >>> some modules for a change of syntax. This was easy to do because they're >>> all at the top of a function. But I didn't realise /how/ easy that made >>> it until I encountered errors because one or two were hidden in the >>> function's code and had been missed. Imagine if most declarations had >>> been like that. >> >> C syntax doesn't change.... > > Actually the change I made could also be done to C, although there it > wouldn't be binding. (Namely, adding an empty 'var' macro at the start > of variable declarations.) > > And there are plenty of other things you can be doing that involves > scanning through every declaration, that would be helped by having them > grouped together. Like adding 'const' everywhere. Such a change would more sensibly be scripted and scripts don't care about how much they have to scan. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-12 21:53 +0000 |
| Message-ID | <CfH8E.319626$IF1.144883@fx03.am4> |
| In reply to | #140880 |
On 12/02/2019 21:07, Ian Collins wrote: > On 13/02/2019 09:55, Bart wrote: >> On 12/02/2019 19:47, Ian Collins wrote: >>> On 13/02/2019 01:10, Bart wrote: >>>> On 01/02/2019 12:15, Bart wrote: >>>> >>>> >>>> [Enumerating the issues with mixing declarations with code] >>>> >>>> > (1) .... >>>> >>>>> (13) I've touched on this, but during development, if striving to have >>>>> the smallest scope, then the scope would be constantly changing as >>>>> lines >>>>> are added, moved, removed and modified. It would be chaotic. >>>> >>>> (14) In some non-C code, I've had to manually tweak every >>>> declaration in >>>> some modules for a change of syntax. This was easy to do because >>>> they're >>>> all at the top of a function. But I didn't realise /how/ easy that made >>>> it until I encountered errors because one or two were hidden in the >>>> function's code and had been missed. Imagine if most declarations had >>>> been like that. >>> >>> C syntax doesn't change.... >> >> Actually the change I made could also be done to C, although there it >> wouldn't be binding. (Namely, adding an empty 'var' macro at the start >> of variable declarations.) >> >> And there are plenty of other things you can be doing that involves >> scanning through every declaration, that would be helped by having them >> grouped together. Like adding 'const' everywhere. > > Such a change would more sensibly be scripted and scripts don't care > about how much they have to scan. OK, what would a script look like that listed all the variable declarations in a C source file? Taking account of user types and macros. If you were going to do this stuff on a big scale, then you would indeed need automatic processes, but they could not be trivially written. Sometimes you just /are/ doing manual changes to source code, and having things arranged in certain locations will make life easier.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-02-13 11:01 +1300 |
| Message-ID | <gcgu26FgcocU9@mid.individual.net> |
| In reply to | #140882 |
On 13/02/2019 10:53, Bart wrote: > On 12/02/2019 21:07, Ian Collins wrote: >> On 13/02/2019 09:55, Bart wrote: >>> On 12/02/2019 19:47, Ian Collins wrote: >>>> On 13/02/2019 01:10, Bart wrote: >>>>> On 01/02/2019 12:15, Bart wrote: >>>>> >>>>> >>>>> [Enumerating the issues with mixing declarations with code] >>>>> >>>>> > (1) .... >>>>> >>>>>> (13) I've touched on this, but during development, if striving to have >>>>>> the smallest scope, then the scope would be constantly changing as >>>>>> lines >>>>>> are added, moved, removed and modified. It would be chaotic. >>>>> >>>>> (14) In some non-C code, I've had to manually tweak every >>>>> declaration in >>>>> some modules for a change of syntax. This was easy to do because >>>>> they're >>>>> all at the top of a function. But I didn't realise /how/ easy that made >>>>> it until I encountered errors because one or two were hidden in the >>>>> function's code and had been missed. Imagine if most declarations had >>>>> been like that. >>>> >>>> C syntax doesn't change.... >>> >>> Actually the change I made could also be done to C, although there it >>> wouldn't be binding. (Namely, adding an empty 'var' macro at the start >>> of variable declarations.) >>> >>> And there are plenty of other things you can be doing that involves >>> scanning through every declaration, that would be helped by having them >>> grouped together. Like adding 'const' everywhere. >> >> Such a change would more sensibly be scripted and scripts don't care >> about how much they have to scan. > > OK, what would a script look like that listed all the variable > declarations in a C source file? Taking account of user types and macros. Complex... less so if declarations weren't hidden in macros. I've never had to (and I can't see a case where I ever would) do such a thing. I have used sed to change specific types which is trivial. What I did miss is you contradicting your own argument by saying "Like adding 'const' everywhere"; you could only do that if variables were declared at the first point of use! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-16 15:09 +0000 |
| Message-ID | <XIV9E.507754$ux2.103598@fx25.am4> |
| In reply to | #140883 |
On 12/02/2019 22:01, Ian Collins wrote:
> On 13/02/2019 10:53, Bart wrote:
>> OK, what would a script look like that listed all the variable
>> declarations in a C source file? Taking account of user types and macros.
>
> What I did miss is you contradicting your own argument by saying "Like
> adding 'const' everywhere"; you could only do that if variables were
> declared at the first point of use!
Declaration at first point of use has a problem when a variable is first
assigned to, inside an expression. This is a very simple instance of that:
a = b = f();
If this is the first use of a, then your rule would require this:
int a = b = f();
But what if this is also the first use of b? (#16 in my list)
The ability to assign within an expression causes a conflict.
A gcc extension allows statements within expressions:
int a=({int b=f();b;});
But the result is anything but clear, and also this imposes a
restriction on the scope of b.
Sometimes, also, a first assignment is done indirectly:
setvar(&a);
You can't declare this in place (17), and neither can you use 'const' on
the declaration, if that's what you want.
(Actually, this last example will work with my script language:
proc setvar1(a) = {a^:=100} # by value
proc setvar2(&a) = {a:=200} # by reference
proc start=
setvar1(^a) # ^ is a posh version of &
setvar2(b)
print a,b # Output is 100 200
end
You tried to imply that my a, b are declared at first point of use, and
therefore they are like C's in-place declarations. They're not.
The mere use of a or b /anywhere/ in the function, if they are not
resolved by any global names, will force local names to be created. That
might be triggered by the first use of a or b, or the last (declaration
lists tend to be stored in reverse), or neither.)
I will post points (18), (19) and (20) if they arise, but from a
language viewpoint, such declarations (in nested blocks, in middle of a
block mixed with code, reusing names, always initialising, insisting on
minimal scope etc) do seem to already have a lot of issues.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-16 16:33 +0000 |
| Message-ID | <87y36fels1.fsf@bsb.me.uk> |
| In reply to | #141112 |
Bart <bc@freeuk.com> writes:
> Declaration at first point of use has a problem when a variable is
> first assigned to, inside an expression. This is a very simple
> instance of that:
>
> a = b = f();
>
> If this is the first use of a, then your rule would require this:
>
> int a = b = f();
>
> But what if this is also the first use of b? (#16 in my list)
>
> The ability to assign within an expression causes a conflict.
>
> A gcc extension allows statements within expressions:
>
> int a=({int b=f();b;});
>
> But the result is anything but clear, and also this imposes a
> restriction on the scope of b.
Apart from not being C, it's not the same at all (as you imply). In C
you would simply write:
int a = f(), b = a;
(BTW, I continue to not mark removed material because you did not like
my use of "<snip>". I've recently decided to switch to "<cut>". Shall
I go back to marking removed material? I think it was the word, not the
action, that you did not like.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web