Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #89160 > unrolled thread
| Started by | Muttley@dastardlyhq.com |
|---|---|
| First post | 2023-02-20 16:45 +0000 |
| Last post | 2023-02-21 08:15 -0800 |
| Articles | 20 on this page of 203 — 22 participants |
Back to article view | Back to comp.lang.c++
Is this safe? Muttley@dastardlyhq.com - 2023-02-20 16:45 +0000
Re: Is this safe? Bonita Montero <Bonita.Montero@gmail.com> - 2023-02-20 18:34 +0100
Re: Is this safe? Chris Vine <vine24683579@gmail.com> - 2023-02-20 11:16 -0800
Re: Is this safe? Bonita Montero <Bonita.Montero@gmail.com> - 2023-02-20 21:39 +0100
Re: Is this safe? Chris Vine <vine24683579@gmail.com> - 2023-02-20 12:56 -0800
Re: Is this safe? Tony Oliver <guinness.tony@gmail.com> - 2023-02-20 16:17 -0800
Re: Is this safe? Manu Raju <MR@invalid.invalid> - 2023-02-21 01:57 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 09:15 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 12:31 +0200
Re: Is this safe? Bonita Montero <Bonita.Montero@gmail.com> - 2023-02-21 05:36 +0100
Re: Is this safe? Chris Vine <vine24683579@gmail.com> - 2023-02-21 02:19 -0800
Re: Is this safe? Bonita Montero <Bonita.Montero@gmail.com> - 2023-02-21 14:16 +0100
Re: Is this safe? Ralf Goertz <me@myprovider.invalid> - 2023-02-21 14:40 +0100
Re: Is this safe? Chris Vine <vine24683579@gmail.com> - 2023-02-21 05:51 -0800
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 15:58 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 14:55 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 19:02 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 17:13 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 19:58 +0200
Re: Is this safe? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-02-21 12:15 -0800
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-21 23:41 +0200
Re: Is this safe? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-03-03 12:57 -0800
Re: Is this safe? Tony Oliver <guinness.tony@gmail.com> - 2023-02-20 16:14 -0800
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-20 23:48 -0500
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-02-21 00:05 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 09:14 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-20 21:18 -0500
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-20 20:38 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 09:18 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-21 15:12 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-21 14:53 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-21 10:35 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-22 09:25 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-22 22:33 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 09:25 +0000
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-23 07:05 -0800
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-22 21:21 -0800
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 09:39 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 09:35 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 12:30 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 10:34 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 13:20 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:00 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 18:24 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:28 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 19:01 +0200
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-23 11:57 -0500
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-23 19:12 +0200
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-23 11:57 -0500
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 12:20 -0500
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-02-24 02:15 +0000
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-24 15:24 -0800
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-24 02:14 -0500
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 07:18 -0500
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:01 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 11:50 -0500
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 14:41 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-23 19:44 +0100
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-23 15:02 +0100
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-02-23 14:49 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-23 16:25 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:10 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-23 20:46 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-23 20:05 +0000
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 14:48 -0800
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 22:12 -0500
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-24 10:49 +0200
Re: Is this safe? Ralf Fassel <ralfixx@gmx.de> - 2023-02-24 11:36 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-24 15:39 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 10:29 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 17:20 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 17:09 +0000
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-24 17:32 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-25 11:56 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-25 16:04 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-25 15:47 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-25 19:13 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-25 19:00 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-27 08:43 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-27 10:31 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-25 16:40 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 18:42 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-25 11:58 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-25 16:25 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-25 15:45 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-25 19:15 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-27 08:44 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-27 10:40 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-27 10:24 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-27 18:31 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-28 08:38 +0000
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-02-28 01:33 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-28 10:17 +0000
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-02-28 02:43 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 16:50 +0100
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-28 03:19 -0800
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-28 08:10 -0500
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-28 05:42 -0800
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-28 09:39 -0500
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-28 07:12 -0800
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-28 11:29 -0500
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 16:45 +0100
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-02-28 11:31 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 20:59 +0100
Re: Is this safe? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-03-01 14:29 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 16:37 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-28 15:56 +0000
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-28 18:34 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-01 09:37 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-01 02:29 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-01 19:56 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-01 12:53 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-01 21:13 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-02 01:48 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-03 21:44 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-03 20:16 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-04 22:55 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-05 07:11 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-05 20:44 +0000
Re: Is this safe? Mr Flibble <flibble2@reddwarf.jmc.corp> - 2023-03-05 21:00 +0000
Re: Is this safe? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-03-05 13:59 -0800
Re: Is this safe? Mr Flibble <flibble2@reddwarf.jmc.corp> - 2023-03-05 23:07 +0000
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-06 00:22 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-05 14:26 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-06 00:51 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-06 02:17 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-05 08:13 -0800
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-05 09:05 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-14 09:47 -0700
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 14:40 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-02 09:07 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-03-01 21:37 -0500
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-03-01 22:30 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-03-01 14:27 +0100
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 10:48 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-03-02 10:29 +0100
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-01 19:53 +0000
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-02 09:08 +0000
Re: Is this safe? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-03-02 01:32 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-02 09:56 +0000
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-03-02 04:02 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-03-02 15:00 +0100
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-03-02 07:59 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-02 15:38 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-03-02 11:16 -0800
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-03-02 11:08 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-03-03 09:53 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-03-04 06:47 -0800
Re: Is this safe? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-03-02 19:35 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-28 17:40 +0100
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-24 12:16 -0500
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 18:39 +0100
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-24 10:03 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 19:59 +0100
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-25 06:47 +0100
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-25 10:23 +0200
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-23 07:16 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 14:31 -0800
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-23 16:34 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 16:15 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-24 12:17 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 12:24 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-24 15:18 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 15:55 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-24 18:20 +0200
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 17:05 +0000
Re: Is this safe? Paavo Helde <eesnimi@osa.pri.ee> - 2023-02-24 19:24 +0200
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-24 09:46 -0800
Re: Is this safe? David Brown <david.brown@hesbynett.no> - 2023-02-24 17:30 +0100
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-23 17:12 +0000
Re: Is this safe? Öö Tiib <ootiib@hot.ee> - 2023-02-23 02:47 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 15:59 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 11:55 -0500
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-23 08:37 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 14:19 -0800
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-23 17:09 +0000
Re: Is this safe? Richard Damon <Richard@Damon-Family.org> - 2023-02-23 12:21 -0500
Re: Is this safe? scott@slp53.sl.home (Scott Lurndal) - 2023-02-23 17:55 +0000
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 13:57 -0800
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-23 17:28 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 21:44 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-24 08:48 -0800
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-21 10:58 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-22 09:26 +0000
Re: Is this safe? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-02-22 22:34 +0100
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 09:29 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-23 08:28 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 17:16 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-23 22:24 -0800
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-22 21:30 -0800
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-23 09:31 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-23 22:00 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-23 22:20 -0800
Re: Is this safe? James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-24 01:34 -0500
Re: Is this safe? Muttley@dastardlyhq.com - 2023-02-24 10:32 +0000
Re: Is this safe? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-02-25 00:19 -0800
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-22 08:09 -0800
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-21 22:32 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-22 08:32 -0800
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-22 09:17 -0800
Re: Is this safe? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-04-04 23:28 -0700
Re: Is this safe? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-04-05 11:08 -0700
Re: Is this safe? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-21 08:15 -0800
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-02-23 21:44 -0800 |
| Message-ID | <87sfevobwg.fsf@nosuchdomain.example.com> |
| In reply to | #89265 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 02/23/23 1:57 PM, Keith Thompson wrote:
>> (The standard requires EOF to have a negative value. This is a good
>> reason for it to be exactly -1, and I've never heard of an
>> implementation where EOF != -1.)
>
> https://github.com/xinu-os/xinu/blob/master/include/stddef.h
Well, now I have.
From the link:
#define EOF (-2) /**< End-of-file (usually from read) */
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-02-24 08:48 -0800 |
| Message-ID | <867cw7au2j.fsf@linuxsc.com> |
| In reply to | #89268 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Andrey Tarasevich <andreytarasevich@hotmail.com> writes: > >> On 02/23/23 1:57 PM, Keith Thompson wrote: >> >>> (The standard requires EOF to have a negative value. This is a good >>> reason for it to be exactly -1, and I've never heard of an >>> implementation where EOF != -1.) >> >> https://github.com/xinu-os/xinu/blob/master/include/stddef.h > > Well, now I have. > > From the link: > > #define EOF (-2) /**< End-of-file (usually from read) */ On implementations that have 8-bit chars, a reasonable choice for EOF is -SCHAR_MAX-2.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-21 10:58 -0800 |
| Message-ID | <396d495c-628c-47a4-aabc-3464d3edba38n@googlegroups.com> |
| In reply to | #89183 |
On Tuesday, February 21, 2023 at 9:53:23 AM UTC-5, Mut...@dastardlyhq.com wrote: > On Tue, 21 Feb 2023 15:12:39 +0100 > "Alf P. Steinbach" <alf.p.s...@gmail.com> wrote: > >On 2023-02-21 10:18 AM, Mut...@dastardlyhq.com wrote: > >> Ok, is this safe: > >> > >> for(auto &c: s) c = 'x'; > >> > >> Or will it screw up the string object or have no effect in some cases just > >> as altering the contents returned by the c_str() pointer can sometimes have? > > > >Demonstrates the need for making examples short and to the point, to not > >introduce extraneous issues. > 3 lines is short and I didn't introduce any extranious issues. Other posters > created them. > >`c` is a reference to an item in the string, within the string bounds, > >i.e. it can't be a reference to the null-item that since C++11 is > >effectively required past the end of the string. > Ok. However in the past with some implementations of std::string, modifying > the contents of the buffer returned by c_str() can have undefined consequences. > I simply wondered if this was a similar situation. > >Not what you're asking, but the common convention in C++ is to separate > >the type specification from the variable, i.e. `auto& c` not `auto &c`. > Whose common convention? The convention you're using is popular for simple declarations, because it uses the space to separate the sequence of declaration specifiers from the list of declarators. That's a helpful distinction to be aware of, because if there is more than one declarator, they all share the declaration specifiers. However, this is a different context, the range declaration for a range-based for statement. If followed by a comma-delimited list of identifiers, i it would be parsed as a structured binding declaration, and in that context & would be shared by all of those identifiers, so it makes sense to separate it from them, and combine it with the preceding specifiers, which they would also share.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-02-22 09:26 +0000 |
| Message-ID | <tt4n51$1fp4g$1@dont-email.me> |
| In reply to | #89194 |
On Tue, 21 Feb 2023 10:58:31 -0800 (PST) "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote: >On Tuesday, February 21, 2023 at 9:53:23 AM UTC-5, Mut...@dastardlyhq.com >wrote: >> created them. >> >`c` is a reference to an item in the string, within the string bounds, >> >i.e. it can't be a reference to the null-item that since C++11 is >> >effectively required past the end of the string. >> Ok. However in the past with some implementations of std::string, modifying >> the contents of the buffer returned by c_str() can have undefined >consequences. >> I simply wondered if this was a similar situation. >> >Not what you're asking, but the common convention in C++ is to separate >> >the type specification from the variable, i.e. `auto& c` not `auto &c`. >> Whose common convention? > >The convention you're using is popular for simple declarations, because it uses > >the space to separate the sequence of declaration specifiers from the list of >declarators. That's a helpful distinction to be aware of, because if there is >more >than one declarator, they all share the declaration specifiers. >However, this is a different context, the range declaration for a range-based >for >statement. If followed by a comma-delimited list of identifiers, i it would be >parsed as a structured binding declaration, and in that context & would be No it wouldn't. Whitespace is not significant in C++ (ok, apart from the > > vs >>) template syntax hack up until 2011.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2023-02-22 22:34 +0100 |
| Message-ID | <tt61pd$1karm$2@dont-email.me> |
| In reply to | #89199 |
On 2023-02-22 10:26 AM, Muttley@dastardlyhq.com wrote: > On Tue, 21 Feb 2023 10:58:31 -0800 (PST) > "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote: >> On Tuesday, February 21, 2023 at 9:53:23 AM UTC-5, Mut...@dastardlyhq.com >> wrote: >>> created them. >>>> `c` is a reference to an item in the string, within the string bounds, >>>> i.e. it can't be a reference to the null-item that since C++11 is >>>> effectively required past the end of the string. >>> Ok. However in the past with some implementations of std::string, modifying >>> the contents of the buffer returned by c_str() can have undefined >> consequences. >>> I simply wondered if this was a similar situation. >>>> Not what you're asking, but the common convention in C++ is to separate >>>> the type specification from the variable, i.e. `auto& c` not `auto &c`. >>> Whose common convention? >> >> The convention you're using is popular for simple declarations, because it uses >> >> the space to separate the sequence of declaration specifiers from the list of >> declarators. That's a helpful distinction to be aware of, because if there is >> more >> than one declarator, they all share the declaration specifiers. >> However, this is a different context, the range declaration for a range-based >> for >> statement. If followed by a comma-delimited list of identifiers, i it would be >> parsed as a structured binding declaration, and in that context & would be > > No it wouldn't. Whitespace is not significant in C++ (ok, apart from the > > > vs >>) template syntax hack up until 2011. > Either you missed the point, or you understood and deliberately snipped what you quoted to create a misleading impression. - Alf
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-02-23 09:29 +0000 |
| Message-ID | <tt7bmn$1r5ns$1@dont-email.me> |
| In reply to | #89210 |
On Wed, 22 Feb 2023 22:34:37 +0100 "Alf P. Steinbach" <alf.p.steinbach@gmail.com> wrote: >On 2023-02-22 10:26 AM, Muttley@dastardlyhq.com wrote: >> On Tue, 21 Feb 2023 10:58:31 -0800 (PST) >>> than one declarator, they all share the declaration specifiers. >>> However, this is a different context, the range declaration for a >range-based >>> for >>> statement. If followed by a comma-delimited list of identifiers, i it would >be >>> parsed as a structured binding declaration, and in that context & would be >> >> No it wouldn't. Whitespace is not significant in C++ (ok, apart from the > > >> vs >>) template syntax hack up until 2011. >> > >Either you missed the point, or you understood and deliberately snipped >what you quoted to create a misleading impression. I didn't miss the point at all. You implied that the positioning of the whitespace in a declaration makes a difference. It doesn't.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-23 08:28 -0800 |
| Message-ID | <7f99e189-8c71-4744-b484-94f57affd8e3n@googlegroups.com> |
| In reply to | #89218 |
On Thursday, February 23, 2023 at 4:30:14 AM UTC-5, Mut...@dastardlyhq.com wrote: > On Wed, 22 Feb 2023 22:34:37 +0100 > "Alf P. Steinbach" <alf.p.s...@gmail.com> wrote: > >On 2023-02-22 10:26 AM, Mut...@dastardlyhq.com wrote: ... > >> No it wouldn't. Whitespace is not significant in C++ (ok, apart from the > > > >> vs >>) template syntax hack up until 2011. > >> > > > >Either you missed the point, or you understood and deliberately snipped > >what you quoted to create a misleading impression. > I didn't miss the point at all. You implied that the positioning of the > whitespace in a declaration makes a difference. It doesn't. The fact that it doesn't matter to the implementation doesn't mean that it makes no difference. Conventions like this one are for humans, not compilers, and the convention you use can make a difference in how easy it is for a human to understand the code.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-02-23 17:16 +0000 |
| Message-ID | <tt8713$1u1oh$1@dont-email.me> |
| In reply to | #89241 |
On Thu, 23 Feb 2023 08:28:58 -0800 (PST) "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote: >On Thursday, February 23, 2023 at 4:30:14 AM UTC-5, Mut...@dastardlyhq.com >wrote: >> On Wed, 22 Feb 2023 22:34:37 +0100 >> "Alf P. Steinbach" <alf.p.s...@gmail.com> wrote: >> >On 2023-02-22 10:26 AM, Mut...@dastardlyhq.com wrote: >.... >> >> No it wouldn't. Whitespace is not significant in C++ (ok, apart from the >> > >> >> vs >>) template syntax hack up until 2011. >> >> >> > >> >Either you missed the point, or you understood and deliberately snipped >> >what you quoted to create a misleading impression. >> I didn't miss the point at all. You implied that the positioning of the >> whitespace in a declaration makes a difference. It doesn't. > >The fact that it doesn't matter to the implementation doesn't mean that it >makes no >difference. Conventions like this one are for humans, not compilers, and the >convention you use can make a difference in how easy it is for a human to >understand the code. Ok, you're just redefining the meaning of significant whitespace then. So how would you describe how python treats whitespace?
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-23 22:24 -0800 |
| Message-ID | <655a0293-f1e8-4733-955b-cd5138a935cfn@googlegroups.com> |
| In reply to | #89251 |
On Thursday, February 23, 2023 at 12:16:33 PM UTC-5, Mut...@dastardlyhq.com wrote: > On Thu, 23 Feb 2023 08:28:58 -0800 (PST) > "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote: ... > >The fact that it doesn't matter to the implementation doesn't mean that it > >makes no > >difference. Conventions like this one are for humans, not compilers, and the > >convention you use can make a difference in how easy it is for a human to > >understand the code. > Ok, you're just redefining the meaning of significant whitespace then. So how > would you describe how python treats whitespace? No, I'm not re-defining the meaning of "significant white-space", I'm distinguishing between what is significant to the implementation, and what is significant to the human reader. We call things "coding conventions" precisely because they are not significant to the implementation, but are significant to the human reader. If they were significant to the implementation, we would refer to them as "the correct syntax", or some similar phrase. I'm not very familiar with python. My seven-year-old son has shown an interest in the Scratch programming language, and my wife is insisting that I introduce him to a "real" programming language as well. I chose Python, because it would give me an opportunity to learn the language while teaching it to him, and because I'd heard that it's substantially easier to learn than C or C++. My wife also insisted that I buy a book for him to study Python, rather than using online sources, which is what I recommended. I chose "Learn Python" by Eric Wall, which came well-recommended on Amazon. I have no idea why. It is filled with typos, misprints, poor wording, misleading wording, and downright incorrect information. It also has no index, which I've usually found indispensible for books of this type. Most relevant to your comment, it contains example code that needs to be correctly indented in order to work properly, and isn't. It makes no mention of the fact that indentation is needed. Luckily, the Python interpreter that I installed on his computer provided helpful error messages. I would greatly appreciate recommendations for an alternative source of instruction in Python, suitable for a 7-year-old (and his 64-year old dad).
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-22 21:30 -0800 |
| Message-ID | <3981d84f-d55f-4d41-b3ea-be90f46ef7e6n@googlegroups.com> |
| In reply to | #89199 |
On Wednesday, February 22, 2023 at 4:27:12 AM UTC-5, Mut...@dastardlyhq.com wrote: > On Tue, 21 Feb 2023 10:58:31 -0800 (PST) > "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote: ... > >The convention you're using is popular for simple declarations, because it uses > > > >the space to separate the sequence of declaration specifiers from the list of > >declarators. That's a helpful distinction to be aware of, because if there is > >more > >than one declarator, they all share the declaration specifiers. > >However, this is a different context, the range declaration for a range-based > >for > >statement. If followed by a comma-delimited list of identifiers, i it would be > >parsed as a structured binding declaration, and in that context & would be > No it wouldn't. Whitespace is not significant in C++ (ok, apart from the > > > vs >>) template syntax hack up until 2011. If white-space between tokens were significant after translation phase 5, the way in which people used it wouldn't qualify as a "convention", but as a necessity for correct code. Such conventions are chosen to make code easier for humans to understand, not because they are needed to ensure that compilers handle the code correctly. Note: white-space within tokens is always significant, and white-space between tokens can be significant in translation phase 4 and earlier.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-02-23 09:31 +0000 |
| Message-ID | <tt7bqf$1r6fg$1@dont-email.me> |
| In reply to | #89214 |
On Wed, 22 Feb 2023 21:30:04 -0800 (PST) "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote: >On Wednesday, February 22, 2023 at 4:27:12 AM UTC-5, Mut...@dastardlyhq.com >wrote: >> No it wouldn't. Whitespace is not significant in C++ (ok, apart from the > > > >> vs >>) template syntax hack up until 2011. > >If white-space between tokens were significant after translation phase 5, the >way in >which people used it wouldn't qualify as a "convention", but as a necessity for > >correct code. Such conventions are chosen to make code easier for humans to >understand, not because they are needed to ensure that compilers handle the >code >correctly. > >Note: white-space within tokens is always significant, and white-space between >tokens can be significant in translation phase 4 and earlier. Quite obviously a program with no whitespace won't compile. That doesn't mean the whitespace is significant in the programming sense.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-23 22:00 -0800 |
| Message-ID | <7a710042-b823-418a-aed5-a8f6fb4702a8n@googlegroups.com> |
| In reply to | #89219 |
On Thursday, February 23, 2023 at 4:32:13 AM UTC-5, Mut...@dastardlyhq.com wrote: > On Wed, 22 Feb 2023 21:30:04 -0800 (PST) > "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote: > >On Wednesday, February 22, 2023 at 4:27:12 AM UTC-5, Mut...@dastardlyhq.com > >wrote: > >> No it wouldn't. Whitespace is not significant in C++ (ok, apart from the > > > > > >> vs >>) template syntax hack up until 2011. > > > >If white-space between tokens were significant after translation phase 5, the > >way in > >which people used it wouldn't qualify as a "convention", but as a necessity for > > > >correct code. Such conventions are chosen to make code easier for humans to > >understand, not because they are needed to ensure that compilers handle the > >code > >correctly. > > > >Note: white-space within tokens is always significant, and white-space between > >tokens can be significant in translation phase 4 and earlier. > Quite obviously a program with no whitespace won't compile. ... It is in fact quite commonly the case that white space in C++ code serves mainly to separate tokens, and it doesn't matter which kind of white-space it is, nor how much of it there is. In many cases it doesn't even matter whether or not it is present, but you're quite right - there's also many cases where white-space that serves solely to separate tokens cannot be removed entirely. That is NOT what I'm talking about. > ... That doesn't mean > the whitespace is significant in the programming sense. As I said above, the key fact that makes your claim basically correct is that, starting with translation phase 5, white space separating tokens is no longer significant. But a careful examination of that statement will reveal that there are several contexts in which white space does more than merely separate tokens. First of all, there's three kinds of tokens which are allowed to contain white-space: header-names, character literals, and string literals. None of those can contain a new-line character, but they can contain any other kind of white-space. Which white-space characters they contain, and how many they contain, can directly affect the behavior of the program. Secondly, white-space characters that do separate tokens remains significant during translation phase 4, in four different ways: 1. It matters very much that the only white-space allowed between pre-processing tokens in a pre-processing directive are spaces and horizontal tabs (15.1p5), and that the white-space separating such a directive from the surrounding code must be an unescaped new-line. 2. Duplicate #defines for the same identifier are allowed only if the white-space separations in the replacement lists are equivalent (15.6p2). 3. The lparen immediately following a function-like macro's name, either in the definition or invocation of the macro, must NOT be preceded by white-space. It is quite common for people to write code which relies upon this fact to suppress invocation of a function-like macro, requiring that an actual function be called instead. 4. When a function-like macro's parameter is the operand of an stringizing operator, each sequence of white-space characters separating the pre-processing tokens in that argument is replace by a single space character, which survives in the resulting string literal, and as a result can affect the behavior of the program.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-02-23 22:20 -0800 |
| Message-ID | <87o7pjoa94.fsf@nosuchdomain.example.com> |
| In reply to | #89269 |
"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
[...]
> 3. The lparen immediately following a function-like macro's name, either in the
> definition or invocation of the macro, must NOT be preceded by white-space. It is
> quite common for people to write code which relies upon this fact to suppress
> invocation of a function-like macro, requiring that an actual function be called
> instead.
[...]
The '(' must immediately follow the macro name only in the definition,
not in an invocation.
#include <iostream>
#define PLUS1(x) ((x) + 1)
int main() {
std::cout << PLUS1 ( 42 ) << "\n";
}
(Output is 43.)
The whole point is that a function-like macro can be used as if it were
a function. The '(' has to immediately follow the name in the
definition to distinguish a function-like macro from a macro with no
parameters whose expansion happens to start with a '(' token.
If PLUS1 were defined both as a macro and as a function, the way to
bypass the macro definition would be `(PLUS)(42)` (with arbitrary
whitespace).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-24 01:34 -0500 |
| Message-ID | <tt9lpl$24rgo$1@dont-email.me> |
| In reply to | #89270 |
On 2/24/23 01:20, Keith Thompson wrote:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
> [...]
>> 3. The lparen immediately following a function-like macro's name, either in the
>> definition or invocation of the macro, must NOT be preceded by white-space. It is
>> quite common for people to write code which relies upon this fact to suppress
>> invocation of a function-like macro, requiring that an actual function be called
>> instead.
> [...]
>
> The '(' must immediately follow the macro name only in the definition,
> not in an invocation.
>
> #include <iostream>
> #define PLUS1(x) ((x) + 1)
> int main() {
> std::cout << PLUS1 ( 42 ) << "\n";
> }
>
> (Output is 43.)
>
> The whole point is that a function-like macro can be used as if it were
> a function. The '(' has to immediately follow the name in the
> definition to distinguish a function-like macro from a macro with no
> parameters whose expansion happens to start with a '(' token.
>
> If PLUS1 were defined both as a macro and as a function, the way to
> bypass the macro definition would be `(PLUS)(42)` (with arbitrary
> whitespace).
You're correct, I got that mixed up.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2023-02-24 10:32 +0000 |
| Message-ID | <tta3o4$26i3k$1@dont-email.me> |
| In reply to | #89269 |
On Thu, 23 Feb 2023 22:00:17 -0800 (PST) "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> wrote: >First of all, there's three kinds of tokens which are allowed to contain >white-space: >header-names, character literals, and string literals. None of those can >contain a >new-line character, but they can contain any other kind of white-space. Which char *str = "hello\ world\n"; 2 newlines in there. >white-space characters they contain, and how many they contain, can directly >affect the behavior of the program. Significant whitespace means significant in and of itself, not simply as a kind of seperator. However you're not going to admit you were wrong so lets call it a day.
[toc] | [prev] | [next] | [standalone]
| From | "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-25 00:19 -0800 |
| Message-ID | <2edf6717-16ae-4218-80d7-b53e28424e4an@googlegroups.com> |
| In reply to | #89277 |
On Friday, February 24, 2023 at 5:32:50 AM UTC-5, Mut...@dastardlyhq.com wrote:
> On Thu, 23 Feb 2023 22:00:17 -0800 (PST)
> "james...@alumni.caltech.edu" <james...@alumni.caltech.edu> wrote:
> >First of all, there's three kinds of tokens which are allowed to contain
> >white-space:
> >header-names, character literals, and string literals. None of those can
> >contain a
> >new-line character, but they can contain any other kind of white-space. Which
> char *str = "hello\
> world\n";
> 2 newlines in there.
The escaped newline character is not part of the string literal, it gets removed in
translation phase 2. "\n" is an escape sequence that codes for a newline, but is not
itself a newline character. You can include a space, horizontal tab, vertical tab, or a
formfeed directly into a header name, character literal, or string literal, but you can't
do so with a newline character. That's because of the following explicit language
from the standard:
5.8: Header Names
h-char :
any member of the source character set except new-line and >
...
q-char :
any member of the source character set except new-line and "
Neither an h-char nor a q-char is allowed to be a new-line.
5.13.3: Character literals
c-char :
any member of the basic source character set except the single-quote ’,
backslash \, or new-line character
escape-sequence
universal-character-name
5.13.5: String Literals
s-char :
any member of the basic source character set except the double-quote ",
backslash \, or new-line character
escape-sequence
universal-character-name
> >white-space characters they contain, and how many they contain, can directly
> >affect the behavior of the program.
> Significant whitespace means significant in and of itself, not simply as
> a kind of seperator. However you're not going to admit you were wrong so
> lets call it a day.
The following code is a minimalist example containing one instance of every case
I described earlier. It contains the following significant white-space: one space
character, one horizontal tab character, one vertical tab character, and one form
feed character. Since it can be hard to identify different kinds of white-space
characters in usenet messages, I've associated each of those characters with text
which clarifies which one it is:
(95) cat horizontal\ tab.h
const char *form_feed = "
";
(96) cat a\ space.h
char vertical_tab = ' ';
(97) cat whitespace.cc
#define STR(a) #a
#define STRSTR(b) STR(b)
#include STR(a space.h)
#include <horizontal tab.h>
#include <iostream>
int main(void)
{
std::cout << "vertical" << vertical_tab <<
"tab,form" << form_feed << "feed" << std::endl;
return 0;
}
(98) g++ -std=c++17 -pedantic -Wall -O2 -Wpointer-arith -Wcast-align -fno-enforce-eh-specs -fno-gnu-keywords -fno-nonansi-builtins -Wctor-dtor-privacy -Wnon-virtual-dtor -Wold-style-cast -Woverloaded-virtual -I./ -Wsign-promo whitespace.cc -o whitespace
(99) ./whitespace
vertical tab,form
feed
This code merely demonstrates my point, and is not in anyway reasonable code.
However, reasonable code routinely relies upon significant white space in
character and string literals, and significant white-space in header names, while
far more obscure, is almost certainly used by somebody.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2023-02-22 08:09 -0800 |
| Message-ID | <tt5en3$1i7ap$1@dont-email.me> |
| In reply to | #89194 |
On 02/21/23 10:58 AM, james...@alumni.caltech.edu wrote: > However, this is a different context, the range declaration for a range-based for > statement. If followed by a comma-delimited list of identifiers, i it would be > parsed as a structured binding declaration, and in that context & would be shared > by all of those identifiers, so it makes sense to separate it from them, and > combine it with the preceding specifiers, which they would also share. In a structured binding declaration it is not just a "comma-delimited list of identifiers". It is actually a []-enclosed comma-delimited list of identifiers (!). The presence of that `[]` is already perfectly sufficient to clearly convey the fact that the `&` applies to all identifiers in the list. Since a structured binding declaration always contains exactly one []-enclosed "declarator", the placement of spacing around `&` is moot. No reason to change the formatting rules from an ordinary declaration. Just keep aligning it to the right: `auto &[a, b]`. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2023-02-21 22:32 -0800 |
| Message-ID | <tt4ctc$1eq0d$1@dont-email.me> |
| In reply to | #89182 |
On 02/21/23 6:12 AM, Alf P. Steinbach wrote: > > Not what you're asking, but the common convention in C++ is to separate > the type specification from the variable, i.e. `auto& c` not `auto &c`. > > But on the third and gripping hand, in this case I'd write `char& c`, > since there's no advantage in `auto` here and it obscures things. Not really. This is a misleading "convention" that has no reason to exist. In this case the `&` is a part of an individual declarator, not a part of decl-specifier-seq. There's no reason to group the syntactic elements differently. It achieves nothing. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-02-22 08:32 -0800 |
| Message-ID | <86k009bqyu.fsf@linuxsc.com> |
| In reply to | #89197 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes: > On 02/21/23 6:12 AM, Alf P. Steinbach wrote: > >> Not what you're asking, but the common convention in C++ is to >> separate the type specification from the variable, i.e. `auto& c` >> not `auto &c`. >> >> But on the third and gripping hand, in this case I'd write `char& >> c`, since there's no advantage in `auto` here and it obscures >> things. > > Not really. This is a misleading "convention" that has no reason to > exist. In this case the `&` is a part of an individual declarator, > not a part of decl-specifier-seq. There's no reason to group the > syntactic elements differently. It achieves nothing. I would say it achieves less than nothing, because it's misleading. It's like writing a+b * c ; the grouping suggested by the spacing doesn't match the actual precedence. In almost all cases it's a mistake to use "contra-syntactic" spacing, and attaching '&' or '*' to a type specifier is definitely one of those mistakes.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-02-22 09:17 -0800 |
| Message-ID | <87pma1pqlh.fsf@nosuchdomain.example.com> |
| In reply to | #89207 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>> On 02/21/23 6:12 AM, Alf P. Steinbach wrote:
>>> Not what you're asking, but the common convention in C++ is to
>>> separate the type specification from the variable, i.e. `auto& c`
>>> not `auto &c`.
>>>
>>> But on the third and gripping hand, in this case I'd write `char&
>>> c`, since there's no advantage in `auto` here and it obscures
>>> things.
>>
>> Not really. This is a misleading "convention" that has no reason to
>> exist. In this case the `&` is a part of an individual declarator,
>> not a part of decl-specifier-seq. There's no reason to group the
>> syntactic elements differently. It achieves nothing.
>
> I would say it achieves less than nothing, because it's misleading.
> It's like writing a+b * c ; the grouping suggested by the spacing
> doesn't match the actual precedence. In almost all cases it's a
> mistake to use "contra-syntactic" spacing, and attaching '&' or '*'
> to a type specifier is definitely one of those mistakes.
I prefer the "int *foo;" spacing (conventional in C) because it follows
the syntax, but the "int* foo;" spacing has become a convention in C++
(probably because Stroustrup uses it in his books), and I use it in C++
for that reason. I also avoid declarations where it would make a
difference to a human reader, like "int* foo, bar;".
Most development is on existing code. It would be poor practice to use
the "better" spacing on new code while leaving the existing code (which
most likely uses the C++ conventional spacing) as it is. It would also
be poor practice to change all the spacing in a large body of existing
code.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web