Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82003 > unrolled thread

I think references should have been const by default

Back to article view | Back to comp.lang.c++

Contents

  I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-21 05:23 +0000
    Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-21 08:54 +0200
      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-21 09:48 +0000
        Re: I think references should have been const by default Paavo Helde <myfirstname@osa.pri.ee> - 2021-10-21 12:55 +0300
        Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-21 12:57 +0200
          Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 13:40 +0000
            Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-21 15:04 +0100
              Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-21 16:41 +0200
                Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 14:57 +0000
              Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 14:51 +0000
              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-21 12:09 -0400
                Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-21 23:49 +0100
                  Re: I think references should have been const by default "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2021-10-21 16:21 -0700
                    Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-22 16:14 +0100
                      Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-22 12:04 -0700
                        Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-22 20:47 +0100
                          Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-22 13:29 -0700
                      Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 11:54 +0200
                        Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 11:22 +0100
                          Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 12:35 +0200
                        Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-23 13:23 +0100
                          Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 13:57 +0100
                            Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-23 21:02 +0100
                            Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-23 15:07 -0700
                              Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-23 21:15 -0700
                          Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-23 21:12 -0700
                Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-22 11:13 +0200
                  Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-22 19:18 -0400
              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:41 +0000
                Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-23 21:30 +0100
                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-25 04:51 +0000
                    Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-26 00:53 +0100
              Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-22 09:46 +0200
                Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-22 15:48 +0100
                  Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 12:21 +0200
                    Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 12:06 +0100
                      Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-23 18:45 +0200
                        Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-23 18:58 +0100
                          Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-24 12:11 +0200
                            Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-24 23:11 +0100
                              Re: I think references should have been const by default Öö Tiib <ootiib@hot.ee> - 2021-10-24 16:18 -0700
                                Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-25 00:58 +0100
                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 08:21 +0000
                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-25 09:47 +0000
                            Re: I think references should have been const by default Bo Persson <bo@bo-persson.se> - 2021-10-25 12:33 +0200
                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 14:19 +0000
                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 10:59 -0400
                                Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-25 17:56 +0200
                                  Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-25 11:11 -0700
                                    Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-26 17:15 +0200
                                      Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:41 -0700
                                Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 16:14 +0000
                                  Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 13:14 -0400
                                    Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 08:18 +0000
                                      Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 12:39 +0100
                                        Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-26 14:29 +0100
                                          Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 15:11 +0100
                                            Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 09:49 -0700
                                              Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 18:38 +0100
                                                Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 11:20 -0700
                                                  Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 20:32 +0100
                                                    Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 22:18 +0200
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 04:43 +0000
                                                Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 08:29 +0200
                                                Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:32 -0700
                                                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-11-01 06:12 +0000
                                                    Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-11-01 08:53 +0100
                                                    Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-01 11:26 -0400
                                                      Re: I think references should have been const by default "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-11-02 16:19 +0100
                                                        Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-02 12:54 -0400
                                                        Re: I think references should have been const by default Paavo Helde <myfirstname@osa.pri.ee> - 2021-11-02 23:49 +0200
                                                          Re: I think references should have been const by default "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-11-03 00:38 +0100
                                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:36 +0000
                                          Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 15:55 +0100
                                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 15:26 +0000
                                              Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-26 20:35 +0100
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 04:44 +0000
                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:27 -0400
                                      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 10:31 -0400
                                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:42 +0000
                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:22 -0400
                                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 15:30 +0000
                                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 12:23 -0400
                                                Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 12:51 -0400
                                                Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 14:34 -0400
                                                  Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-26 12:57 -0700
                                                Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-27 07:57 +0000
                                                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 08:47 +0000
                                                    Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 14:29 +0000
                                                      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-28 05:17 +0000
                                                        Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-28 09:30 +0000
                                                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-29 04:47 +0000
                                                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-29 05:11 +0000
                                                            Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-29 08:40 +0000
                                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-11-01 06:15 +0000
                                                  Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 11:07 +0200
                                                    Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 14:30 +0000
                                                      Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 17:30 +0200
                                                        Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 15:46 +0000
                                                        Re: I think references should have been const by default scott@slp53.sl.home (Scott Lurndal) - 2021-10-27 16:13 +0000
                                                      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 11:39 -0400
                                                        Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 15:51 +0000
                                                          Re: I think references should have been const by default Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-27 17:21 +0100
                                                            Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-28 09:29 +0000
                                                              Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-28 11:20 +0100
                                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 12:26 -0400
                                                            Re: I think references should have been const by default Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2021-10-31 09:22 -0700
                                                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-11-01 00:13 -0400
                                                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-28 05:20 +0000
                                                            Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-27 23:10 -0700
                                                            Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-28 09:30 +0000
                                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-29 04:51 +0000
                                                                Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-29 08:39 +0000
                                                                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-11-01 06:34 +0000
                                                    Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-27 17:41 +0100
                                                      Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-27 19:02 +0200
                                                        Re: I think references should have been const by default Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-10-27 18:21 +0100
                                                  Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 11:38 -0400
                                                    Re: I think references should have been const by default JohnnyCameLater@whatsthetime.net - 2021-10-27 15:49 +0000
                                                      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-27 12:36 -0400
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 04:57 +0000
                                  Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-25 18:19 +0100
                                  Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-25 10:48 -0700
                                    Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 08:21 +0000
                                      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 08:37 +0000
                                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 09:02 +0000
                                          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 11:14 +0000
                                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:35 +0000
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 05:01 +0000
                                            Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:34 -0700
                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 10:43 -0400
                                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 15:21 +0000
                                              Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 22:32 +0200
                                              Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-27 05:04 +0000
                                      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 10:42 -0400
                                        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 14:48 +0000
                                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:52 -0400
                                          Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 10:22 -0700
                                            Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-26 10:27 -0700
                                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 14:06 -0400
                                            Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-10-29 06:45 -0700
                                              Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-29 11:11 -0700
                                                Re: I think references should have been const by default Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 07:39 -0700
                                                  Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-25 10:59 -0700
                                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 05:29 +0000
                                    Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 08:53 +0200
                                    Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-26 08:23 +0000
                                      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 08:40 +0000
                                Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 05:18 +0000
                                  Re: I think references should have been const by default David Brown <david.brown@hesbynett.no> - 2021-10-26 09:07 +0200
                                  Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-26 11:03 -0400
                            Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 10:39 -0400
                              Re: I think references should have been const by default Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-25 10:56 -0700
                          Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 10:30 -0400
                            Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-25 14:39 +0000
                              Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-25 11:05 -0400
                          Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-25 12:45 -0700
                            Re: I think references should have been const by default "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-10-26 11:20 -0700
                  Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-25 05:00 +0000
                    Re: I think references should have been const by default Bart <bc@freeuk.com> - 2021-10-25 12:13 +0100
                      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-26 05:36 +0000
                    Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-25 16:58 +0200
      Re: I think references should have been const by default "daniel...@gmail.com" <danielaparker@gmail.com> - 2021-10-22 12:28 -0700
    Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 09:12 +0000
      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-21 09:52 +0000
        Re: I think references should have been const by default RacingRabbit@watershipdown.co.uk - 2021-10-21 10:36 +0000
          Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:45 +0000
      Re: I think references should have been const by default James Kuyper <jameskuyper@alumni.caltech.edu> - 2021-10-21 12:07 -0400
    Re: I think references should have been const by default Paavo Helde <myfirstname@osa.pri.ee> - 2021-10-21 12:18 +0300
    Re: I think references should have been const by default Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-21 13:13 +0200
      Re: I think references should have been const by default Bo Persson <bo@bo-persson.se> - 2021-10-21 15:08 +0200
      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:45 +0000
        Re: I think references should have been const by default Bonita Montero <Bonita.Montero@gmail.com> - 2021-10-22 07:55 +0200
          Re: I think references should have been const by default Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-22 11:21 +0000
    Re: I think references should have been const by default "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-10-21 13:22 +0200
      Re: I think references should have been const by default Juha Nieminen <nospam@thanks.invalid> - 2021-10-22 04:48 +0000
    Re: I think references should have been const by default Manfred <noname@add.invalid> - 2021-10-21 13:57 +0200
    Re: I think references should have been const by default Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-21 21:27 +0000
    Re: I think references should have been const by default Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-10-24 14:20 +0000

Page 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →

#82003 — I think references should have been const by default

Time and again I see beginner C++ programmers make the same mistake:
Make functions take objects by non-const reference, even when (in the
vast, vast majority of cases) the function doesn't modify those objects.

In one particularly egregious case some beginner programmer had written
a comparator lambda that took two std::string objects by reference,
wondered why he was getting a compiler error, and then removed the
references, so it was taking the objects by value. That way it compiled.
Then he wondered why it was so slow.

I think it was a mistake to make references non-const by default.
It's logical (and consistent with pointer syntax) of course, but I think
it was a mistake. In the vast, vast majority of cases if you create a
reference to something else, you want it to be const (and there are
many good reasons why it should be const). It's extremely rare to
explicitly want a non-const reference.

And the thing is, C++98 has a *perfect* keyword to explicitly denote
that you want a non-const reference, which could have been used for
this purpose, so no new keyword would be needed for this: 'mutable'.

In other words, I think C++ would have been better if it worked like
this:

  void foo1(std::string& str)
  {
      str = "hello"; // error: 'str' is const
  }

  void foo2(mutable std::string& str)
  {
      str = "hello"; // ok
  }

(You could still write "const std::string&", but it would just have
the exact same meaning as "std::string&", ie. in this case the
'const' is superfluous, a bit like how 'signed' is superfluous
in "signed int".)

[toc] | [next] | [standalone]

#82004

On 21/10/2021 07:23, Juha Nieminen wrote:
> Time and again I see beginner C++ programmers make the same mistake:
> Make functions take objects by non-const reference, even when (in the
> vast, vast majority of cases) the function doesn't modify those objects.
> 
> In one particularly egregious case some beginner programmer had written
> a comparator lambda that took two std::string objects by reference,
> wondered why he was getting a compiler error, and then removed the
> references, so it was taking the objects by value. That way it compiled.
> Then he wondered why it was so slow.
> 
> I think it was a mistake to make references non-const by default.
> It's logical (and consistent with pointer syntax) of course, but I think
> it was a mistake. In the vast, vast majority of cases if you create a
> reference to something else, you want it to be const (and there are
> many good reasons why it should be const). It's extremely rare to
> explicitly want a non-const reference.
> 
> And the thing is, C++98 has a *perfect* keyword to explicitly denote
> that you want a non-const reference, which could have been used for
> this purpose, so no new keyword would be needed for this: 'mutable'.
> 
> In other words, I think C++ would have been better if it worked like
> this:
> 
>   void foo1(std::string& str)
>   {
>       str = "hello"; // error: 'str' is const
>   }
> 
>   void foo2(mutable std::string& str)
>   {
>       str = "hello"; // ok
>   }
> 
> (You could still write "const std::string&", but it would just have
> the exact same meaning as "std::string&", ie. in this case the
> 'const' is superfluous, a bit like how 'signed' is superfluous
> in "signed int".)
> 

I agree with you entirely.  But if we are going for wishful thinking
about how C++ could have been made better, I'd have preferred "const"
for all variables and required "mutable" to declare a variable that
could be modified.  (Of course that would mean you'd need something else
for class members that are today "mutable".  But I think it's a lot more
common for people to make variables that could have been "const" but
aren't, than to use mutable members.)

[toc] | [prev] | [next] | [standalone]

#82007

David Brown <david.brown@hesbynett.no> wrote:
> I agree with you entirely.  But if we are going for wishful thinking
> about how C++ could have been made better, I'd have preferred "const"
> for all variables and required "mutable" to declare a variable that
> could be modified.  (Of course that would mean you'd need something else
> for class members that are today "mutable".  But I think it's a lot more
> common for people to make variables that could have been "const" but
> aren't, than to use mutable members.)

That would quite quickly turn quite annoying, eg. with things like
for-loops:

  for(int i = 0; i < 10; ++i) // error, i is const

[toc] | [prev] | [next] | [standalone]

#82009

21.10.2021 12:48 Juha Nieminen kirjutas:
> David Brown <david.brown@hesbynett.no> wrote:
>> I agree with you entirely.  But if we are going for wishful thinking
>> about how C++ could have been made better, I'd have preferred "const"
>> for all variables and required "mutable" to declare a variable that
>> could be modified.  (Of course that would mean you'd need something else
>> for class members that are today "mutable".  But I think it's a lot more
>> common for people to make variables that could have been "const" but
>> aren't, than to use mutable members.)
> 
> That would quite quickly turn quite annoying, eg. with things like
> for-loops:
> 
>    for(int i = 0; i < 10; ++i) // error, i is const
> 

Solved by C++20:

     for (int i : std::ranges::iota(0, 10))

Having const default would mean additional bonus in that 'i' would be 
const inside the loop body.

[toc] | [prev] | [next] | [standalone]

#82011

On 21/10/2021 11:48, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> I agree with you entirely.  But if we are going for wishful thinking
>> about how C++ could have been made better, I'd have preferred "const"
>> for all variables and required "mutable" to declare a variable that
>> could be modified.  (Of course that would mean you'd need something else
>> for class members that are today "mutable".  But I think it's a lot more
>> common for people to make variables that could have been "const" but
>> aren't, than to use mutable members.)
> 
> That would quite quickly turn quite annoying, eg. with things like
> for-loops:
> 
>   for(int i = 0; i < 10; ++i) // error, i is const
> 

	for (mutable int i = 0; i < 10; ++i)

Yes, there are many places where you want variable variables - but I
think overall you typically have more that could be declared const than
have to be variable.  (The idea is not without precedence - there are
other modern languages with constant objects by default.)

For loops, I think the best solution would be a mixture - the loop
variable should be mutable within the controlling expressions, but
should be constant within the statement or block - as though you had
written:

	for (int i = 0; i < 10; i++) {
		const auto i_ = i;
		const auto i = i_;

		// Here, "i" is constant
	}

[toc] | [prev] | [next] | [standalone]

#82017

On Thu, 21 Oct 2021 12:57:05 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 21/10/2021 11:48, Juha Nieminen wrote:
>> David Brown <david.brown@hesbynett.no> wrote:
>>> I agree with you entirely.  But if we are going for wishful thinking
>>> about how C++ could have been made better, I'd have preferred "const"
>>> for all variables and required "mutable" to declare a variable that
>>> could be modified.  (Of course that would mean you'd need something else
>>> for class members that are today "mutable".  But I think it's a lot more
>>> common for people to make variables that could have been "const" but
>>> aren't, than to use mutable members.)
>> 
>> That would quite quickly turn quite annoying, eg. with things like
>> for-loops:
>> 
>>   for(int i = 0; i < 10; ++i) // error, i is const
>> 
>
>	for (mutable int i = 0; i < 10; ++i)
>
>Yes, there are many places where you want variable variables - but I
>think overall you typically have more that could be declared const than
>have to be variable.  (The idea is not without precedence - there are
>other modern languages with constant objects by default.)
>
>For loops, I think the best solution would be a mixture - the loop
>variable should be mutable within the controlling expressions, but
>should be constant within the statement or block - as though you had
>written:

I think const is a lot of fuss about nothing frankly. I barely use them
anyway and I can't remember the last time that I had a bug due to updating
a variable that shouldn't have been updated. For those who think its simply
an indication to other devs that a variable won't be changed then fair enough
but personally I find a lot of const/non const compilation errors related
to functions a PITA.

[toc] | [prev] | [next] | [standalone]

#82018

On 21/10/2021 14:40, RacingRabbit@watershipdown.co.uk wrote:
> On Thu, 21 Oct 2021 12:57:05 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 21/10/2021 11:48, Juha Nieminen wrote:
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> I agree with you entirely.  But if we are going for wishful thinking
>>>> about how C++ could have been made better, I'd have preferred "const"
>>>> for all variables and required "mutable" to declare a variable that
>>>> could be modified.  (Of course that would mean you'd need something else
>>>> for class members that are today "mutable".  But I think it's a lot more
>>>> common for people to make variables that could have been "const" but
>>>> aren't, than to use mutable members.)
>>>
>>> That would quite quickly turn quite annoying, eg. with things like
>>> for-loops:
>>>
>>>    for(int i = 0; i < 10; ++i) // error, i is const
>>>
>>
>> 	for (mutable int i = 0; i < 10; ++i)
>>
>> Yes, there are many places where you want variable variables - but I
>> think overall you typically have more that could be declared const than
>> have to be variable.  (The idea is not without precedence - there are
>> other modern languages with constant objects by default.)
>>
>> For loops, I think the best solution would be a mixture - the loop
>> variable should be mutable within the controlling expressions, but
>> should be constant within the statement or block - as though you had
>> written:
> 
> I think const is a lot of fuss about nothing frankly. I barely use them
> anyway and I can't remember the last time that I had a bug due to updating
> a variable that shouldn't have been updated. For those who think its simply
> an indication to other devs that a variable won't be changed then fair enough
> but personally I find a lot of const/non const compilation errors related
> to functions a PITA.
> 

I don't about C++, but in C, you can take a program, remove all the 
'const' qualifiers, and it will still compile and work.

Makes you think...

[toc] | [prev] | [next] | [standalone]

#82019

On 10/21/2021 4:04 PM, Bart wrote:
> On 21/10/2021 14:40, RacingRabbit@watershipdown.co.uk wrote:
>> On Thu, 21 Oct 2021 12:57:05 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 21/10/2021 11:48, Juha Nieminen wrote:
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> I agree with you entirely.  But if we are going for wishful thinking
>>>>> about how C++ could have been made better, I'd have preferred "const"
>>>>> for all variables and required "mutable" to declare a variable that
>>>>> could be modified.  (Of course that would mean you'd need something 
>>>>> else
>>>>> for class members that are today "mutable".  But I think it's a lot 
>>>>> more
>>>>> common for people to make variables that could have been "const" but
>>>>> aren't, than to use mutable members.)
>>>>
>>>> That would quite quickly turn quite annoying, eg. with things like
>>>> for-loops:
>>>>
>>>>    for(int i = 0; i < 10; ++i) // error, i is const
>>>>
>>>
>>>     for (mutable int i = 0; i < 10; ++i)
>>>
>>> Yes, there are many places where you want variable variables - but I
>>> think overall you typically have more that could be declared const than
>>> have to be variable.  (The idea is not without precedence - there are
>>> other modern languages with constant objects by default.)
>>>
>>> For loops, I think the best solution would be a mixture - the loop
>>> variable should be mutable within the controlling expressions, but
>>> should be constant within the statement or block - as though you had
>>> written:
>>
>> I think const is a lot of fuss about nothing frankly. I barely use them
>> anyway and I can't remember the last time that I had a bug due to 
>> updating
>> a variable that shouldn't have been updated. For those who think its 
>> simply
>> an indication to other devs that a variable won't be changed then fair 
>> enough
>> but personally I find a lot of const/non const compilation errors related
>> to functions a PITA.
>>
> 
> I don't about C++, but in C, you can take a program, remove all the 
> 'const' qualifiers, and it will still compile and work.
> 
> Makes you think...
> 

...mumble, obviously 'const' is almost exclusively for the programmer's 
convenience (some implementations may use it to map some const data to 
read only memory, but that's probably a minor use compared to the 
massive benefit in accurate modeling of a process).

The categories of immutable and mutable data are pretty relevant in 
process modeling, and since SW design is a lot about modeling, long live 
'const'.

[toc] | [prev] | [next] | [standalone]

#82022

On Thu, 21 Oct 2021 16:41:34 +0200
Manfred <noname@add.invalid> wrote:
>On 10/21/2021 4:04 PM, Bart wrote:
>> I don't about C++, but in C, you can take a program, remove all the 
>> 'const' qualifiers, and it will still compile and work.
>> 
>> Makes you think...
>> 
>
>....mumble, obviously 'const' is almost exclusively for the programmer's 
>convenience (some implementations may use it to map some const data to 
>read only memory, but that's probably a minor use compared to the 
>massive benefit in accurate modeling of a process).
>
>The categories of immutable and mutable data are pretty relevant in 
>process modeling, and since SW design is a lot about modeling, long live 
>'const'.

Tbh if you don't know which data should be left alone and which you can update
you probably shouldn't be working on the code until you learn it a bit better.
As for private/protected variables in library classes, that just pisses me off.
If I want to alter something then let me Mr Library Coder. Its not up to you
to decide what I can and can't alter in my own program and you're not going to
be able to think up every possible use case in which your "private" variable
might need to be accessed or changed.

I actually had this issue with an in house lib at a company but the muppet
who wrote it refused to make the variable public or even available via a
setter even though we needed to access it. In the end I got the address
of a public variable in the class, counted back in memory and dereferenced the 
pointer where his private var was stored. Worked a treat though very fragile. 
Eventually management made him add a getter function so that hack was removed.

[toc] | [prev] | [next] | [standalone]

#82020

On Thu, 21 Oct 2021 15:04:19 +0100
Bart <bc@freeuk.com> wrote:
>On 21/10/2021 14:40, RacingRabbit@watershipdown.co.uk wrote:
>> On Thu, 21 Oct 2021 12:57:05 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 21/10/2021 11:48, Juha Nieminen wrote:
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> I agree with you entirely.  But if we are going for wishful thinking
>>>>> about how C++ could have been made better, I'd have preferred "const"
>>>>> for all variables and required "mutable" to declare a variable that
>>>>> could be modified.  (Of course that would mean you'd need something else
>>>>> for class members that are today "mutable".  But I think it's a lot more
>>>>> common for people to make variables that could have been "const" but
>>>>> aren't, than to use mutable members.)
>>>>
>>>> That would quite quickly turn quite annoying, eg. with things like
>>>> for-loops:
>>>>
>>>>    for(int i = 0; i < 10; ++i) // error, i is const
>>>>
>>>
>>> 	for (mutable int i = 0; i < 10; ++i)
>>>
>>> Yes, there are many places where you want variable variables - but I
>>> think overall you typically have more that could be declared const than
>>> have to be variable.  (The idea is not without precedence - there are
>>> other modern languages with constant objects by default.)
>>>
>>> For loops, I think the best solution would be a mixture - the loop
>>> variable should be mutable within the controlling expressions, but
>>> should be constant within the statement or block - as though you had
>>> written:
>> 
>> I think const is a lot of fuss about nothing frankly. I barely use them
>> anyway and I can't remember the last time that I had a bug due to updating
>> a variable that shouldn't have been updated. For those who think its simply
>> an indication to other devs that a variable won't be changed then fair enough
>
>> but personally I find a lot of const/non const compilation errors related
>> to functions a PITA.
>> 
>
>I don't about C++, but in C, you can take a program, remove all the 
>'const' qualifiers, and it will still compile and work.
>
>Makes you think...

Well quite. But then I started out in C and const wasn't a thing so you had
to know what was going on and not always rely on the compiler to tell you.
But then C doesn't have references I suppose and its a bit difficult to 
accidentaly dereference a pointer and update it unlike a C++ reference. Even
so, I still don't like consts. But its just personal taste.

[toc] | [prev] | [next] | [standalone]

#82024

On Thu, 21 Oct 2021 15:04:19 +0100
Bart <bc@freeuk.com> wrote:
...
>I don't about C++, but in C, you can take a program, remove all the 
>'const' qualifiers, and it will still compile and work.
>
>Makes you think...

Keep in mind that this is strictly true in C only if you remove all the
"const" qualifiers from all of the #included header files, and you can't
do that with standard library headers. It would also be difficult to do
with the headers associated with third-party libraries.

More importantly, that's true only if the program would compile without
diagnostics before the removal of the 'const' qualifiers, and there's a
simple, blindingly obvious reason for that, which does NOT count as an
argument against the proper use of "const":

The declaration of an identifier containing the 'const' keyword
indicates that this identifier should not be used in any way that puts
the object qualified by that keyword in danger of being modified. The
purpose of that keyword is to enable diagnostic messages when the
identifier is used in an expression that could put that object in danger
of being modified. If your program generates no diagnostics, that means
that it contains no such expressions. Removing "const" from the entire
translation unit, including #included headers, will not change the fact
that there is no danger, and the program should therefore work just the
same as before. However, if you modify the program again after removing
all "const" keywords, that modification might create such a danger, but
the implementation no longer has any obligation of warning you about the
danger.

You said that you don't know about C++. Well there's an important
difference between C++ and C in this regard: function overloading. A
function can be overloaded based upon the difference in the way one or
more of its arguments is qualified. The overloads may do significantly
different things - if so, the non-const overload usually attempts to
modify the relevant object, whereas the const overload uses some
work-around to avoid the need to modify it. That work-around is usually
inconvenient in some way, otherwise there would have been no need to
declare the const overload. Therefore, at best, removing all use of the
"const" keyword would require that the non-const overload be dropped,
and that the less convenient const overload be used at all times.

That's "usually". Overloads are entirely under the programmer's control,
and the difference between them need not be "usual" - it very often
isn't. It would be trivial to create overloads that do significantly
different things with const and non-const arguments (most trivially,
they could print out "const" and "non-const" respectively). No single
function can replace both overloads, but it would have to do so if you
removed all occurances of the "const" keyword.

[toc] | [prev] | [next] | [standalone]

#82026

On 21/10/2021 17:09, James Kuyper wrote:
> On Thu, 21 Oct 2021 15:04:19 +0100
> Bart <bc@freeuk.com> wrote:
> ...
>> I don't about C++, but in C, you can take a program, remove all the
>> 'const' qualifiers, and it will still compile and work.
>>
>> Makes you think...
> 
> Keep in mind that this is strictly true in C only if you remove all the
> "const" qualifiers from all of the #included header files, and you can't
> do that with standard library headers. It would also be difficult to do
> with the headers associated with third-party libraries.
> 
> More importantly, that's true only if the program would compile without
> diagnostics before the removal of the 'const' qualifiers, and there's a
> simple, blindingly obvious reason for that, which does NOT count as an
> argument against the proper use of "const":
> 
> The declaration of an identifier containing the 'const' keyword
> indicates that this identifier should not be used in any way that puts
> the object qualified by that keyword in danger of being modified. The
> purpose of that keyword is to enable diagnostic messages when the
> identifier is used in an expression that could put that object in danger
> of being modified. If your program generates no diagnostics, that means
> that it contains no such expressions. Removing "const" from the entire
> translation unit, including #included headers, will not change the fact
> that there is no danger, and the program should therefore work just the
> same as before. However, if you modify the program again after removing
> all "const" keywords, that modification might create such a danger, but
> the implementation no longer has any obligation of warning you about the
> danger.
> 
> You said that you don't know about C++. Well there's an important
> difference between C++ and C in this regard: function overloading. A
> function can be overloaded based upon the difference in the way one or
> more of its arguments is qualified. The overloads may do significantly
> different things - if so, the non-const overload usually attempts to
> modify the relevant object, whereas the const overload uses some
> work-around to avoid the need to modify it. That work-around is usually
> inconvenient in some way, otherwise there would have been no need to
> declare the const overload. Therefore, at best, removing all use of the
> "const" keyword would require that the non-const overload be dropped,
> and that the less convenient const overload be used at all times.

Actually here's an example from C where const changes the behaviour:

   #include <stdio.h>
   #include <stdint.h>

   int main(void) {
       #define issigned(x) _Generic((x),\
        int8_t: "S",\
        int16_t: "S",\
        int32_t: "S",\
        const int32_t: "const S",\
        int64_t: "S",\
        uint8_t: "u",\
        uint16_t: "u",\
        uint32_t: "u",\
        uint64_t: "u",\
        default: "other")

       int32_t x;
//    const int32_t x;
       puts(issigned(x));
   }

The output is different when x has a const attribute.

[toc] | [prev] | [next] | [standalone]

#82027

On Thursday, October 21, 2021 at 6:49:29 PM UTC-4, Bart wrote:
> On 21/10/2021 17:09, James Kuyper wrote: 
> > On Thu, 21 Oct 2021 15:04:19 +0100 
> > Bart <b...@freeuk.com> wrote: 
> > ... 
> >> I don't about C++, but in C, you can take a program, remove all the 
> >> 'const' qualifiers, and it will still compile and work. 
> >> 
> >> Makes you think... 
> > 
> > Keep in mind that this is strictly true in C only if you remove all the 
> > "const" qualifiers from all of the #included header files, and you can't 
> > do that with standard library headers. It would also be difficult to do 
> > with the headers associated with third-party libraries. 
...
> > You said that you don't know about C++. Well there's an important 
> > difference between C++ and C in this regard: function overloading. A 
> > function can be overloaded based upon the difference in the way one or 
> > more of its arguments is qualified. The overloads may do significantly 
> > different things - if so, the non-const overload usually attempts to 
> > modify the relevant object, whereas the const overload uses some 
> > work-around to avoid the need to modify it. That work-around is usually 
> > inconvenient in some way, otherwise there would have been no need to 
> > declare the const overload. Therefore, at best, removing all use of the 
> > "const" keyword would require that the non-const overload be dropped, 
> > and that the less convenient const overload be used at all times.
> Actually here's an example from C where const changes the behaviour: 
> 
> #include <stdio.h> 
> #include <stdint.h> 
> 
> int main(void) { 
> #define issigned(x) _Generic((x),\ 
> int8_t: "S",\ 
> int16_t: "S",\ 
> int32_t: "S",\ 
> const int32_t: "const S",\ 
> int64_t: "S",\ 
> uint8_t: "u",\ 
> uint16_t: "u",\ 
> uint32_t: "u",\ 
> uint64_t: "u",\ 
> default: "other") 
> 
> int32_t x; 
> // const int32_t x; 
> puts(issigned(x)); 
> } 
> 
> The output is different when x has a const attribute.

You're correct, I forgot about that. _Generic provides a capability similar to but much more restricted than function overloading, and as such allows the behavior to depend upon the qualifiers.

[toc] | [prev] | [next] | [standalone]

#82038

On 22/10/2021 00:21, james...@alumni.caltech.edu wrote:
> On Thursday, October 21, 2021 at 6:49:29 PM UTC-4, Bart wrote:
>> On 21/10/2021 17:09, James Kuyper wrote:
>>> On Thu, 21 Oct 2021 15:04:19 +0100
>>> Bart <b...@freeuk.com> wrote:
>>> ...
>>>> I don't about C++, but in C, you can take a program, remove all the
>>>> 'const' qualifiers, and it will still compile and work.
>>>>
>>>> Makes you think...
>>>
>>> Keep in mind that this is strictly true in C only if you remove all the
>>> "const" qualifiers from all of the #included header files, and you can't
>>> do that with standard library headers. It would also be difficult to do
>>> with the headers associated with third-party libraries.
> ...
>>> You said that you don't know about C++. Well there's an important
>>> difference between C++ and C in this regard: function overloading. A
>>> function can be overloaded based upon the difference in the way one or
>>> more of its arguments is qualified. The overloads may do significantly
>>> different things - if so, the non-const overload usually attempts to
>>> modify the relevant object, whereas the const overload uses some
>>> work-around to avoid the need to modify it. That work-around is usually
>>> inconvenient in some way, otherwise there would have been no need to
>>> declare the const overload. Therefore, at best, removing all use of the
>>> "const" keyword would require that the non-const overload be dropped,
>>> and that the less convenient const overload be used at all times.
>> Actually here's an example from C where const changes the behaviour:
>>
>> #include <stdio.h>
>> #include <stdint.h>
>>
>> int main(void) {
>> #define issigned(x) _Generic((x),\
>> int8_t: "S",\
>> int16_t: "S",\
>> int32_t: "S",\
>> const int32_t: "const S",\
>> int64_t: "S",\
>> uint8_t: "u",\
>> uint16_t: "u",\
>> uint32_t: "u",\
>> uint64_t: "u",\
>> default: "other")
>>
>> int32_t x;
>> // const int32_t x;
>> puts(issigned(x));
>> }
>>
>> The output is different when x has a const attribute.
> 
> You're correct, I forgot about that. _Generic provides a capability similar to but much more restricted than function overloading, and as such allows the behavior to depend upon the qualifiers.

That program only behaves as I said when I use my own compiler.

With gcc and others that support _Generic, any 'const' attributes of the 
types of controlling expressions appear to be stripped away.

I'm not sure why that is. It looked to be a bug in gcc, but other 
compilers do the same. Maybe they are all copying gcc's behaviour, but I 
don't what C itself says about it.

With the version below, gcc et al display:

   int
   int

With mine, it displays:

   int
   const int

--------------------------------

   #include <stdio.h>

   int main(void) {
       #define strtype(x) _Generic((x),\
        int: "int",\
        const int: "const int")

       int x;
       const int y;
       puts(strtype(x));
       puts(strtype(y));
   }

[toc] | [prev] | [next] | [standalone]

#82039

Bart <bc@freeuk.com> writes:
[...]
> That program only behaves as I said when I use my own compiler.
>
> With gcc and others that support _Generic, any 'const' attributes of
> the types of controlling expressions appear to be stripped away.
>
> I'm not sure why that is. It looked to be a bug in gcc, but other
> compilers do the same. Maybe they are all copying gcc's behaviour, but
> I don't what C itself says about it.
[...]

_Generic is a C feature that does not appear in C++.

The first operand of _Generic is an expression, not an object, and it
determines the type of that expression.  If the expression happens to be
an lvalue, it undergoes *lvalue conversion* (N1570 6.3.2.1p2), which
strips any qualifiers.  So if the operand of _Generic is the name of an
object of type const int, the type of that *expression* is int, not
const int.  (Something like _Generic that operates on lvalues rather
than expressions might have been useful, but I've never had a need for
it.)

Consider an expression like (n + 1).  Would you expect it to have a
different type depending on whether n was defined as const or not?

C++ overloading, unlike C's _Generic, can use references to distinguish
between const and non-const objects.  You can't have two overloaded
functions that differ only in their parameter type, int vs. const int,
but you can have overloaded functions with parameters of type int& and
const int&.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#82041

On 22/10/2021 20:04, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> That program only behaves as I said when I use my own compiler.
>>
>> With gcc and others that support _Generic, any 'const' attributes of
>> the types of controlling expressions appear to be stripped away.
>>
>> I'm not sure why that is. It looked to be a bug in gcc, but other
>> compilers do the same. Maybe they are all copying gcc's behaviour, but
>> I don't what C itself says about it.
> [...]
> 
> _Generic is a C feature that does not appear in C++.
> 
> The first operand of _Generic is an expression, not an object, and it
> determines the type of that expression.  If the expression happens to be
> an lvalue, it undergoes *lvalue conversion* (N1570 6.3.2.1p2), which
> strips any qualifiers.  So if the operand of _Generic is the name of an
> object of type const int, the type of that *expression* is int, not
> const int.  (Something like _Generic that operates on lvalues rather
> than expressions might have been useful, but I've never had a need for
> it.)
> 
> Consider an expression like (n + 1).  Would you expect it to have a
> different type depending on whether n was defined as const or not?

If I get my C compiler to display the type, then for 'const int n', n 
has type 'const int', and n+1 has type 'int'.

But let me ask you, if p has type 'const int* p', do you expect 'p+1' to 
have a different type from 'p'? (Namely, 'int*' instead of 'const int*'.)

I understand now that the const qualifiers are only removed at the top 
level, so only the leftmost 'const' if types were written left to right 
(my const int* p example would have it after 'pointer to').

This still makes the way _Generic works unintuitive.

[toc] | [prev] | [next] | [standalone]

#82042

Bart <bc@freeuk.com> writes:
> On 22/10/2021 20:04, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> That program only behaves as I said when I use my own compiler.
>>>
>>> With gcc and others that support _Generic, any 'const' attributes of
>>> the types of controlling expressions appear to be stripped away.
>>>
>>> I'm not sure why that is. It looked to be a bug in gcc, but other
>>> compilers do the same. Maybe they are all copying gcc's behaviour, but
>>> I don't what C itself says about it.
>> [...]
>> _Generic is a C feature that does not appear in C++.
>> The first operand of _Generic is an expression, not an object, and
>> it
>> determines the type of that expression.  If the expression happens to be
>> an lvalue, it undergoes *lvalue conversion* (N1570 6.3.2.1p2), which
>> strips any qualifiers.  So if the operand of _Generic is the name of an
>> object of type const int, the type of that *expression* is int, not
>> const int.  (Something like _Generic that operates on lvalues rather
>> than expressions might have been useful, but I've never had a need for
>> it.)
>> Consider an expression like (n + 1).  Would you expect it to have a
>> different type depending on whether n was defined as const or not?
>
> If I get my C compiler to display the type, then for 'const int n', n
> has type 'const int', and n+1 has type 'int'.

If your C compiler displays the type using some non-standard extension,
then of course that extension can do anything you like.

> But let me ask you, if p has type 'const int* p', do you expect 'p+1'
> to have a different type from 'p'? (Namely, 'int*' instead of 'const
> int*'.)

No, p+1 would have type const int* (pointer to const int).

> I understand now that the const qualifiers are only removed at the top
> level, so only the leftmost 'const' if types were written left to
> right (my const int* p example would have it after 'pointer to').
>
> This still makes the way _Generic works unintuitive.

I find it intuitive, but perhaps not immediately so.  I had to remind
myself about the lvalue conversion, and that its operand is an
expression, not an object, for it to make sense.

If you want to continue discussing this, I suggest starting a new thread
in comp.lang.c.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#82044

On 22/10/2021 17:14, Bart wrote:
> On 22/10/2021 00:21, james...@alumni.caltech.edu wrote:
>> On Thursday, October 21, 2021 at 6:49:29 PM UTC-4, Bart wrote:
>>> On 21/10/2021 17:09, James Kuyper wrote:
>>>> On Thu, 21 Oct 2021 15:04:19 +0100
>>>> Bart <b...@freeuk.com> wrote:
>>>> ...
>>>>> I don't about C++, but in C, you can take a program, remove all the
>>>>> 'const' qualifiers, and it will still compile and work.
>>>>>
>>>>> Makes you think...
>>>>
>>>> Keep in mind that this is strictly true in C only if you remove all the
>>>> "const" qualifiers from all of the #included header files, and you
>>>> can't
>>>> do that with standard library headers. It would also be difficult to do
>>>> with the headers associated with third-party libraries.
>> ...
>>>> You said that you don't know about C++. Well there's an important
>>>> difference between C++ and C in this regard: function overloading. A
>>>> function can be overloaded based upon the difference in the way one or
>>>> more of its arguments is qualified. The overloads may do significantly
>>>> different things - if so, the non-const overload usually attempts to
>>>> modify the relevant object, whereas the const overload uses some
>>>> work-around to avoid the need to modify it. That work-around is usually
>>>> inconvenient in some way, otherwise there would have been no need to
>>>> declare the const overload. Therefore, at best, removing all use of the
>>>> "const" keyword would require that the non-const overload be dropped,
>>>> and that the less convenient const overload be used at all times.
>>> Actually here's an example from C where const changes the behaviour:
>>>
>>> #include <stdio.h>
>>> #include <stdint.h>
>>>
>>> int main(void) {
>>> #define issigned(x) _Generic((x),\
>>> int8_t: "S",\
>>> int16_t: "S",\
>>> int32_t: "S",\
>>> const int32_t: "const S",\
>>> int64_t: "S",\
>>> uint8_t: "u",\
>>> uint16_t: "u",\
>>> uint32_t: "u",\
>>> uint64_t: "u",\
>>> default: "other")
>>>
>>> int32_t x;
>>> // const int32_t x;
>>> puts(issigned(x));
>>> }
>>>
>>> The output is different when x has a const attribute.
>>
>> You're correct, I forgot about that. _Generic provides a capability
>> similar to but much more restricted than function overloading, and as
>> such allows the behavior to depend upon the qualifiers.
> 
> That program only behaves as I said when I use my own compiler.
> 
> With gcc and others that support _Generic, any 'const' attributes of the
> types of controlling expressions appear to be stripped away.
> 
> I'm not sure why that is. It looked to be a bug in gcc, but other
> compilers do the same. Maybe they are all copying gcc's behaviour, but I
> don't what C itself says about it.
> 
> With the version below, gcc et al display:
> 
>   int
>   int
> 
> With mine, it displays:
> 
>   int
>   const int

It turns out - who would have guessed? - that gcc is correct.  The gcc
developers these days tend to be very careful and strict about this kind
of thing.

As Keith says, the controlling expression undergoes "lvalue conversion"
(this is in 6.5.1.1p2, if you want to look it up).  C18 helpfully adds a
footnote that did not exist in C11, saying "An lvalue conversion drops
type qualifiers".  (I think the standard could benefit from more of such
explanatory footnotes.)

I think it is odd, however, that you can have qualified types in the
generic association list, since they can't ever match anything (AFAICS).

[toc] | [prev] | [next] | [standalone]

#82046

On 23/10/2021 10:54, David Brown wrote:
> On 22/10/2021 17:14, Bart wrote:
>> On 22/10/2021 00:21, james...@alumni.caltech.edu wrote:
>>> On Thursday, October 21, 2021 at 6:49:29 PM UTC-4, Bart wrote:
>>>> On 21/10/2021 17:09, James Kuyper wrote:
>>>>> On Thu, 21 Oct 2021 15:04:19 +0100
>>>>> Bart <b...@freeuk.com> wrote:
>>>>> ...
>>>>>> I don't about C++, but in C, you can take a program, remove all the
>>>>>> 'const' qualifiers, and it will still compile and work.
>>>>>>
>>>>>> Makes you think...
>>>>>
>>>>> Keep in mind that this is strictly true in C only if you remove all the
>>>>> "const" qualifiers from all of the #included header files, and you
>>>>> can't
>>>>> do that with standard library headers. It would also be difficult to do
>>>>> with the headers associated with third-party libraries.
>>> ...
>>>>> You said that you don't know about C++. Well there's an important
>>>>> difference between C++ and C in this regard: function overloading. A
>>>>> function can be overloaded based upon the difference in the way one or
>>>>> more of its arguments is qualified. The overloads may do significantly
>>>>> different things - if so, the non-const overload usually attempts to
>>>>> modify the relevant object, whereas the const overload uses some
>>>>> work-around to avoid the need to modify it. That work-around is usually
>>>>> inconvenient in some way, otherwise there would have been no need to
>>>>> declare the const overload. Therefore, at best, removing all use of the
>>>>> "const" keyword would require that the non-const overload be dropped,
>>>>> and that the less convenient const overload be used at all times.
>>>> Actually here's an example from C where const changes the behaviour:
>>>>
>>>> #include <stdio.h>
>>>> #include <stdint.h>
>>>>
>>>> int main(void) {
>>>> #define issigned(x) _Generic((x),\
>>>> int8_t: "S",\
>>>> int16_t: "S",\
>>>> int32_t: "S",\
>>>> const int32_t: "const S",\
>>>> int64_t: "S",\
>>>> uint8_t: "u",\
>>>> uint16_t: "u",\
>>>> uint32_t: "u",\
>>>> uint64_t: "u",\
>>>> default: "other")
>>>>
>>>> int32_t x;
>>>> // const int32_t x;
>>>> puts(issigned(x));
>>>> }
>>>>
>>>> The output is different when x has a const attribute.
>>>
>>> You're correct, I forgot about that. _Generic provides a capability
>>> similar to but much more restricted than function overloading, and as
>>> such allows the behavior to depend upon the qualifiers.
>>
>> That program only behaves as I said when I use my own compiler.
>>
>> With gcc and others that support _Generic, any 'const' attributes of the
>> types of controlling expressions appear to be stripped away.
>>
>> I'm not sure why that is. It looked to be a bug in gcc, but other
>> compilers do the same. Maybe they are all copying gcc's behaviour, but I
>> don't what C itself says about it.
>>
>> With the version below, gcc et al display:
>>
>>    int
>>    int
>>
>> With mine, it displays:
>>
>>    int
>>    const int
> 
> It turns out - who would have guessed? - that gcc is correct.  The gcc
> developers these days tend to be very careful and strict about this kind
> of thing.
> 
> As Keith says, the controlling expression undergoes "lvalue conversion"
> (this is in 6.5.1.1p2, if you want to look it up).  C18 helpfully adds a
> footnote that did not exist in C11, saying "An lvalue conversion drops
> type qualifiers".  (I think the standard could benefit from more of such
> explanatory footnotes.)
> 
> I think it is odd, however, that you can have qualified types in the
> generic association list, since they can't ever match anything (AFAICS).
> 
> 

They can be used in examples like this:

   #include <stdio.h>

   #define strtypeof(t) _Generic(t,\
       const int*: "pointer to const int",\
       int*:       "pointer to int",\
       default:    "other")

   int main(void) {
       int * p;
       const int * q;

       puts(strtypeof(p));
       puts(strtypeof(q));
   }

All compilers that support _Generic show:

     pointer to int
     pointer to const int

This suggests a way to maintain those top level qualifiers, by wrapping 
a pointer around a type. But it would be an ungainly workaround (and the 
fact that typeof() also drops those qualifiers would might make it 
impractical).

[toc] | [prev] | [next] | [standalone]

#82047

On 23/10/2021 12:22, Bart wrote:
> On 23/10/2021 10:54, David Brown wrote:
>> On 22/10/2021 17:14, Bart wrote:
>>> On 22/10/2021 00:21, james...@alumni.caltech.edu wrote:
>>>> On Thursday, October 21, 2021 at 6:49:29 PM UTC-4, Bart wrote:
>>>>> On 21/10/2021 17:09, James Kuyper wrote:
>>>>>> On Thu, 21 Oct 2021 15:04:19 +0100
>>>>>> Bart <b...@freeuk.com> wrote:
>>>>>> ...
>>>>>>> I don't about C++, but in C, you can take a program, remove all the
>>>>>>> 'const' qualifiers, and it will still compile and work.
>>>>>>>
>>>>>>> Makes you think...
>>>>>>
>>>>>> Keep in mind that this is strictly true in C only if you remove
>>>>>> all the
>>>>>> "const" qualifiers from all of the #included header files, and you
>>>>>> can't
>>>>>> do that with standard library headers. It would also be difficult
>>>>>> to do
>>>>>> with the headers associated with third-party libraries.
>>>> ...
>>>>>> You said that you don't know about C++. Well there's an important
>>>>>> difference between C++ and C in this regard: function overloading. A
>>>>>> function can be overloaded based upon the difference in the way
>>>>>> one or
>>>>>> more of its arguments is qualified. The overloads may do
>>>>>> significantly
>>>>>> different things - if so, the non-const overload usually attempts to
>>>>>> modify the relevant object, whereas the const overload uses some
>>>>>> work-around to avoid the need to modify it. That work-around is
>>>>>> usually
>>>>>> inconvenient in some way, otherwise there would have been no need to
>>>>>> declare the const overload. Therefore, at best, removing all use
>>>>>> of the
>>>>>> "const" keyword would require that the non-const overload be dropped,
>>>>>> and that the less convenient const overload be used at all times.
>>>>> Actually here's an example from C where const changes the behaviour:
>>>>>
>>>>> #include <stdio.h>
>>>>> #include <stdint.h>
>>>>>
>>>>> int main(void) {
>>>>> #define issigned(x) _Generic((x),\
>>>>> int8_t: "S",\
>>>>> int16_t: "S",\
>>>>> int32_t: "S",\
>>>>> const int32_t: "const S",\
>>>>> int64_t: "S",\
>>>>> uint8_t: "u",\
>>>>> uint16_t: "u",\
>>>>> uint32_t: "u",\
>>>>> uint64_t: "u",\
>>>>> default: "other")
>>>>>
>>>>> int32_t x;
>>>>> // const int32_t x;
>>>>> puts(issigned(x));
>>>>> }
>>>>>
>>>>> The output is different when x has a const attribute.
>>>>
>>>> You're correct, I forgot about that. _Generic provides a capability
>>>> similar to but much more restricted than function overloading, and as
>>>> such allows the behavior to depend upon the qualifiers.
>>>
>>> That program only behaves as I said when I use my own compiler.
>>>
>>> With gcc and others that support _Generic, any 'const' attributes of the
>>> types of controlling expressions appear to be stripped away.
>>>
>>> I'm not sure why that is. It looked to be a bug in gcc, but other
>>> compilers do the same. Maybe they are all copying gcc's behaviour, but I
>>> don't what C itself says about it.
>>>
>>> With the version below, gcc et al display:
>>>
>>>    int
>>>    int
>>>
>>> With mine, it displays:
>>>
>>>    int
>>>    const int
>>
>> It turns out - who would have guessed? - that gcc is correct.  The gcc
>> developers these days tend to be very careful and strict about this kind
>> of thing.
>>
>> As Keith says, the controlling expression undergoes "lvalue conversion"
>> (this is in 6.5.1.1p2, if you want to look it up).  C18 helpfully adds a
>> footnote that did not exist in C11, saying "An lvalue conversion drops
>> type qualifiers".  (I think the standard could benefit from more of such
>> explanatory footnotes.)
>>
>> I think it is odd, however, that you can have qualified types in the
>> generic association list, since they can't ever match anything (AFAICS).
>>
>>
> 
> They can be used in examples like this:
> 
>   #include <stdio.h>
> 
>   #define strtypeof(t) _Generic(t,\
>       const int*: "pointer to const int",\
>       int*:       "pointer to int",\
>       default:    "other")
> 
>   int main(void) {
>       int * p;
>       const int * q;
> 
>       puts(strtypeof(p));
>       puts(strtypeof(q));
>   }

Yes - but those are not qualified types.  Using your preferred ordering,
a "pointer to int" and "pointer to const int" are different types.

> 
> All compilers that support _Generic show:
> 
>     pointer to int
>     pointer to const int
> 
> This suggests a way to maintain those top level qualifiers, by wrapping
> a pointer around a type. But it would be an ungainly workaround (and the
> fact that typeof() also drops those qualifiers would might make it
> impractical).

Why are you inventing an ugly workaround for a non-existent problem?
_Generic in C looks at the unqualified type of an expression - there
isn't a problem.

It turns out your compiler has a bug due to a slight misunderstanding of
_Generic.  I'm glad you've found it, and can correct it (assuming you
want to be closer to following the standards).  But no one is looking
for a "workaround" here.  (Especially not /here/, in c.l.c++ !)

[toc] | [prev] | [next] | [standalone]

Page 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →

Back to top | Article view | comp.lang.c++

csiph-web