Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #82003 > unrolled thread
| Started by | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| First post | 2021-10-21 05:23 +0000 |
| Last post | 2021-10-24 14:20 +0000 |
| Articles | 20 on this page of 179 — 23 participants |
Back to article view | Back to comp.lang.c++
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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-27 11:39 -0400 |
| Message-ID | <slbrr5$cuq$1@dont-email.me> |
| In reply to | #82144 |
On 10/27/21 10:30 AM, JohnnyCameLater@whatsthetime.net wrote: > On Wed, 27 Oct 2021 11:07:03 +0200 > David Brown <david.brown@hesbynett.no> wrote: ... >> Do you have trouble understanding the difference between an array, and a >> pointer to the first element of the array? > > Do you have trouble understanding plain English? The syntax declares an array, > the fact the compiler converts that into a pointer isn't the point. Pun > intended. "array" vs. "pointer is a matter of semantics. [] vs * is a matter of syntax. All you can say about the syntax is that it contains []. In most contexts, [] in the syntax of a declaration corresponds to array semantics. However, the standard is quite explicit about the fact that, in this context, what [] means is pointer semantics. This is not just quibbling. It determine which arguments can be passed to the function without violating a constraint. Two function prototypes are compatible only if the type that one of them declares for a given parameter is compatible with the type declared by the other for that same parameter. If one function prototype uses "int array[]" for one parameter, and the other uses "* int pointer" for the same parameter, those two prototypes are compatible.
[toc] | [prev] | [next] | [standalone]
| From | JohnnyCameLater@whatsthetime.net |
|---|---|
| Date | 2021-10-27 15:51 +0000 |
| Message-ID | <slbsi3$118k$1@gioia.aioe.org> |
| In reply to | #82147 |
On Wed, 27 Oct 2021 11:39:16 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 10/27/21 10:30 AM, JohnnyCameLater@whatsthetime.net wrote:
>> On Wed, 27 Oct 2021 11:07:03 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>....
>>> Do you have trouble understanding the difference between an array, and a
>>> pointer to the first element of the array?
>>
>> Do you have trouble understanding plain English? The syntax declares an
>array,
>> the fact the compiler converts that into a pointer isn't the point. Pun
>> intended.
>
>"array" vs. "pointer is a matter of semantics. [] vs * is a matter of
>syntax. All you can say about the syntax is that it contains []. In most
>contexts, [] in the syntax of a declaration corresponds to array
>semantics. However, the standard is quite explicit about the fact that,
>in this context, what [] means is pointer semantics.
Oh really?
fenris$ cat t.c
#include <stdio.h>
void func(int a[2][3])
{
a[10][50] = 123;
}
int main()
{
int a[2][3];
func(a);
return 0;
}
fenris$ cc t.c
t.c:5:2: warning: array index 50 is past the end of the array (which contains 3
elements) [-Warray-bounds]
a[10][50] = 123;
^ ~~
t.c:3:11: note: array 'a' declared here
void func(int a[2][3])
^
1 warning generated.
Nuff said.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2021-10-27 17:21 +0100 |
| Message-ID | <877ddyxwtt.fsf@bsb.me.uk> |
| In reply to | #82150 |
JohnnyCameLater@whatsthetime.net writes:
> On Wed, 27 Oct 2021 11:39:16 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>On 10/27/21 10:30 AM, JohnnyCameLater@whatsthetime.net wrote:
>>> On Wed, 27 Oct 2021 11:07:03 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>....
>>>> Do you have trouble understanding the difference between an array, and a
>>>> pointer to the first element of the array?
>>>
>>> Do you have trouble understanding plain English? The syntax declares an
>>array,
>>> the fact the compiler converts that into a pointer isn't the point. Pun
>>> intended.
>>
>>"array" vs. "pointer is a matter of semantics. [] vs * is a matter of
>>syntax. All you can say about the syntax is that it contains []. In most
>>contexts, [] in the syntax of a declaration corresponds to array
>>semantics. However, the standard is quite explicit about the fact that,
>>in this context, what [] means is pointer semantics.
>
> Oh really?
Yes.
> fenris$ cat t.c
> #include <stdio.h>
>
> void func(int a[2][3])
> {
> a[10][50] = 123;
> }
>
>
> int main()
> {
> int a[2][3];
> func(a);
> return 0;
> }
> fenris$ cc t.c
> t.c:5:2: warning: array index 50 is past the end of the array (which contains 3
> elements) [-Warray-bounds]
> a[10][50] = 123;
> ^ ~~
> t.c:3:11: note: array 'a' declared here
> void func(int a[2][3])
> ^
> 1 warning generated.
>
> Nuff said.
Not really. Note that the compiler does not complain about the first
index (10) being out of bounds. That's because (despite the badly
worded note) it's only the three-element objects pointed to by 'a' that
are in fact arrays with a known bound. Some compilers explain the issue
more clearly.
Here's gcc 11.2 giving much better, but identical, notes about these two
functions:
void func(int a[2][3])
{
a[10][50] = 123;
}
void func2(int (*a)[3])
{
a[10][50] = 123;
}
x.c: In function ‘func’:
x.c:3:11: warning: array subscript 50 is above array bounds of ‘int[3]’ [-Warray-bounds]
3 | a[10][50] = 123;
| ~~~~~^~~~
x.c:1:15: note: while referencing ‘a’
1 | void func(int a[2][3])
| ~~~~^~~~~~~
x.c: In function ‘func2’:
x.c:3:11: warning: array subscript 50 is above array bounds of ‘int[3]’ [-Warray-bounds]
3 | a[10][50] = 123;
| ~~~~~^~~~
x.c:6:18: note: while referencing ‘a’
6 | void func2(int (*a)[3])
| ~~~~~~^~~~~
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | JohnnyCameLater@whatsthetime.net |
|---|---|
| Date | 2021-10-28 09:29 +0000 |
| Message-ID | <sldqhm$14su$1@gioia.aioe.org> |
| In reply to | #82152 |
On Wed, 27 Oct 2021 17:21:34 +0100 Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >JohnnyCameLater@whatsthetime.net writes: >>>"array" vs. "pointer is a matter of semantics. [] vs * is a matter of >>>syntax. All you can say about the syntax is that it contains []. In most >>>contexts, [] in the syntax of a declaration corresponds to array >>>semantics. However, the standard is quite explicit about the fact that, >>>in this context, what [] means is pointer semantics. >> >> Oh really? > >Yes. No. >> fenris$ cc t.c >> t.c:5:2: warning: array index 50 is past the end of the array (which >contains 3 >> elements) [-Warray-bounds] >> a[10][50] = 123; >> ^ ~~ >> t.c:3:11: note: array 'a' declared here >> void func(int a[2][3]) >> ^ >> 1 warning generated. >> >> Nuff said. > >Not really. Note that the compiler does not complain about the first Yes really. The parser is treating it as an array and doing bounds checking. The fact it gets implicitely converted into a pointer later is irrelevant. >index (10) being out of bounds. That's because (despite the badly So what? Clang compilation generally stops at the first error it finds. >x.c:3:11: warning: array subscript 50 is above array bounds of ‘int[3]’ >[-Warray-bounds] > 3 | a[10][50] = 123; > | ~~~~~^~~~ >x.c:6:18: note: while referencing ‘a’ > 6 | void func2(int (*a)[3]) > | ~~~~~~^~~~~ > Thank you for proving my point that the gcc parser also treats it as an array.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-28 11:20 +0100 |
| Message-ID | <sldth6$4sp$1@dont-email.me> |
| In reply to | #82161 |
On 28/10/2021 10:29, JohnnyCameLater@whatsthetime.net wrote:
> On Wed, 27 Oct 2021 17:21:34 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> JohnnyCameLater@whatsthetime.net writes:
>>>> "array" vs. "pointer is a matter of semantics. [] vs * is a matter of
>>>> syntax. All you can say about the syntax is that it contains []. In most
>>>> contexts, [] in the syntax of a declaration corresponds to array
>>>> semantics. However, the standard is quite explicit about the fact that,
>>>> in this context, what [] means is pointer semantics.
>>>
>>> Oh really?
>>
>> Yes.
>
> No.
>
>>> fenris$ cc t.c
>>> t.c:5:2: warning: array index 50 is past the end of the array (which
>> contains 3
>>> elements) [-Warray-bounds]
>>> a[10][50] = 123;
>>> ^ ~~
>>> t.c:3:11: note: array 'a' declared here
>>> void func(int a[2][3])
>>> ^
>>> 1 warning generated.
>>>
>>> Nuff said.
>>
>> Not really. Note that the compiler does not complain about the first
>
> Yes really. The parser is treating it as an array and doing bounds checking.
> The fact it gets implicitely converted into a pointer later is irrelevant.
>
>> index (10) being out of bounds. That's because (despite the badly
>
> So what? Clang compilation generally stops at the first error it finds.
(Does it?)
>> x.c:3:11: warning: array subscript 50 is above array bounds of ‘int[3]’
>> [-Warray-bounds]
>> 3 | a[10][50] = 123;
>> | ~~~~~^~~~
>> x.c:6:18: note: while referencing ‘a’
>> 6 | void func2(int (*a)[3])
>> | ~~~~~~^~~~~
>>
>
> Thank you for proving my point that the gcc parser also treats it as an array.
In:
void func(int a[2][3]) ...
the type of 'a' is:
'pointer to array 3 of int'.
For parameters, the first level of a type starting T[] is reduced to T*,
a pointer: T[][] becomes T(*)[].
So arrays exist in the lower dimensions, but never in the primary one,
which is where it would be necessary for arrays to be passed by value.
But apart from that quibble, you're spot on. I can see now that you were
pretty much right about everything, and all the long-standing experts
here have no idea what they're talking about.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-27 12:26 -0400 |
| Message-ID | <slbuiv$3fa$1@dont-email.me> |
| In reply to | #82150 |
On 10/27/21 11:51 AM, JohnnyCameLater@whatsthetime.net wrote:
> On Wed, 27 Oct 2021 11:39:16 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
...
>> "array" vs. "pointer is a matter of semantics. [] vs * is a matter of
>> syntax. All you can say about the syntax is that it contains []. In most
>> contexts, [] in the syntax of a declaration corresponds to array
>> semantics. However, the standard is quite explicit about the fact that,
>> in this context, what [] means is pointer semantics.
>
> Oh really?
Yes, really.
> fenris$ cat t.c
> #include <stdio.h>
>
> void func(int a[2][3])
> {
> a[10][50] = 123;
> }
>
>
> int main()
> {
> int a[2][3];
> func(a);
> return 0;
> }
> fenris$ cc t.c
> t.c:5:2: warning: array index 50 is past the end of the array (which contains 3
> elements) [-Warray-bounds]
> a[10][50] = 123;> ^ ~~
> t.c:3:11: note: array 'a' declared here
> void func(int a[2][3])
> ^
> 1 warning generated.
The standard imposes no requirements on diagnostics - in particular, it
does not require them to correctly describe the problem - many
implementations occasionally generate incorrectly worded diagnostics,
even when describing legitimate errors, and this warning is one example.
The actual type of a is int(*)[3], not int[2][3], a fact that you can
confirm using sizeof(a) or &a (the difference between those types
disappears in all other contexts, due to the implicit array=>pointer
conversion).
This message is posted to C++. While C++ has many differences from C,
this isn't one of them, and in C++ a more convenient way to check the
type of a is to use typeid(a).name(). Unfortunately, the resulting
string is implementation-defined - on my machine it is a coded version
of the type, rather than a proper C++ type specification. However, if
you declare
int b(*)[3];
int c[2][3];
then you should find that typeid(a)==typeid(b), and typeid(a) !=
typeid(c). typeid(a).name() should be the same as typeid(b).name(), and
both should be different from the typeid(c).name(). Let me know what you
find when you try that.
There is an array bounds violation in your code, but it's not in a
itself, which is not an array. a is a pointer that can be used to point
at any unqualified array with an element type of int[3], regardless of
how large. However, whatever array you point a at, if a[10] refers to an
actual element of that array, then a[10][50] violates the bounds of the
3-element array that a[10] points at, not the bounds of a itself, which
has none.
You'll get the same error if you change a[10][50] to a[1][50], and there
wouldn't be any problem in func() itself if you changed it to a[10][2].
If you pass a pointer to func() which will still point at a different
element of the same array after 10 is added to it, then a[10][2] inside
of func() would also have defined behavior - which would be to change
the corresponding element of the pointed-at array, rather than the
corresponding element of a, which has none.
[toc] | [prev] | [next] | [standalone]
| From | Anand Hariharan <mailto.anand.hariharan@gmail.com> |
|---|---|
| Date | 2021-10-31 09:22 -0700 |
| Message-ID | <ca79f68c-dafc-4d5c-8f63-02c7df17a2e6n@googlegroups.com> |
| In reply to | #82153 |
On Wednesday, October 27, 2021 at 11:26:23 AM UTC-5, james...@alumni.caltech.edu wrote:
> On 10/27/21 11:51 AM, JohnnyC...@whatsthetime.net wrote:
> > On Wed, 27 Oct 2021 11:39:16 -0400
> >
> > void func(int a[2][3])
> > {
> > a[10][50] = 123;
> > }
> >
> >
> > int main()
> > {
> > int a[2][3];
> > func(a);
> > return 0;
> > }
> > fenris$ cc t.c
> > t.c:5:2: warning: array index 50 is past the end of the array (which contains 3
> > elements) [-Warray-bounds]
> > a[10][50] = 123;> ^ ~~
> > t.c:3:11: note: array 'a' declared here
> > void func(int a[2][3])
> > ^
> > 1 warning generated.
> The standard imposes no requirements on diagnostics - in particular, it
> does not require them to correctly describe the problem - many
> implementations occasionally generate incorrectly worded diagnostics,
> even when describing legitimate errors, and this warning is one example.
> The actual type of a is int(*)[3], not int[2][3], a fact that you can
> confirm using sizeof(a) or &a (the difference between those types
> disappears in all other contexts, due to the implicit array=>pointer
> conversion).
>
> This message is posted to C++. While C++ has many differences from C,
> this isn't one of them, and in C++ a more convenient way to check the
> type of a is to use typeid(a).name(). Unfortunately, the resulting
> string is implementation-defined - on my machine it is a coded version
> of the type, rather than a proper C++ type specification. However, if
> you declare
>
> int b(*)[3];
> int c[2][3];
>
> then you should find that typeid(a)==typeid(b), and typeid(a) !=
> typeid(c). typeid(a).name() should be the same as typeid(b).name(), and
> both should be different from the typeid(c).name(). Let me know what you
> find when you try that.
>
I may have missed a reply (either from someone else or even yourself) but the declaration of 'b' is a syntax error. Looks like you meant
int (*b)[3];
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-11-01 00:13 -0400 |
| Message-ID | <slnpgu$k00$1@dont-email.me> |
| In reply to | #82182 |
On 10/31/21 12:22 PM, Anand Hariharan wrote: > On Wednesday, October 27, 2021 at 11:26:23 AM UTC-5, james...@alumni.caltech.edu wrote: ... >> of the type, rather than a proper C++ type specification. However, if >> you declare >> >> int b(*)[3]; ... > I may have missed a reply (either from someone else or even yourself) but the declaration of 'b' is a syntax error. Looks like you meant > > int (*b)[3]; Correct - the fact that no one else brought it up implies that very few people are bothering to pay attention to this thread. I'd guess that a lot of them have him killfiled by now.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-28 05:20 +0000 |
| Message-ID | <sldbvi$1eol$2@gioia.aioe.org> |
| In reply to | #82150 |
JohnnyCameLater@whatsthetime.net wrote:
> void func(int a[2][3])
> {
> a[10][50] = 123;
> }
If 'a' there is an array, what will sizeof(a) be?
> int main()
> {
> int a[2][3];
Contrast that to what sizeof(a) will be here.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-10-27 23:10 -0700 |
| Message-ID | <sldetg$6eg$1@dont-email.me> |
| In reply to | #82159 |
On 10/27/2021 10:20 PM, Juha Nieminen wrote:
> JohnnyCameLater@whatsthetime.net wrote:
>> void func(int a[2][3])
>> {
>> a[10][50] = 123;
>> }
>
> If 'a' there is an array, what will sizeof(a) be?
It can be equal to sizeof(void*)...
>
>> int main()
>> {
>> int a[2][3];
>
> Contrast that to what sizeof(a) will be here.
>
[toc] | [prev] | [next] | [standalone]
| From | JohnnyCameLater@whatsthetime.net |
|---|---|
| Date | 2021-10-28 09:30 +0000 |
| Message-ID | <sldqk2$161s$1@gioia.aioe.org> |
| In reply to | #82159 |
On Thu, 28 Oct 2021 05:20:52 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>JohnnyCameLater@whatsthetime.net wrote:
>> void func(int a[2][3])
>> {
>> a[10][50] = 123;
>> }
>
>If 'a' there is an array, what will sizeof(a) be?
>
>> int main()
>> {
>> int a[2][3];
>
>Contrast that to what sizeof(a) will be here.
FFS man, do you even understand whats being discussed here?
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-29 04:51 +0000 |
| Message-ID | <slfulb$8v9$1@gioia.aioe.org> |
| In reply to | #82163 |
JohnnyCameLater@whatsthetime.net wrote:
> On Thu, 28 Oct 2021 05:20:52 -0000 (UTC)
> Juha Nieminen <nospam@thanks.invalid> wrote:
>>JohnnyCameLater@whatsthetime.net wrote:
>>> void func(int a[2][3])
>>> {
>>> a[10][50] = 123;
>>> }
>>
>>If 'a' there is an array, what will sizeof(a) be?
>>
>>> int main()
>>> {
>>> int a[2][3];
>>
>>Contrast that to what sizeof(a) will be here.
>
> FFS man, do you even understand whats being discussed here?
Yes. You claim that in func(int a[2][3]) that 'a' there is
declaring an array. According to you, it's declaring an array,
and it doesn't matter what's happening "under the hood".
If that were the case, if 'a' there were indeed an array, then
it would behave like an array, and be the size of an array,
just like that 'a' in the main() function.
Yet, it doesn't. It actually behaves exactly like a pointer,
not an array. Its size is that of a pointer, and its type is
that of a pointer, and the declaration is exactly that of a
pointer, at the language syntax level.
The fact that you refuse to even answer my question, ie.
what sizeof(a) is in those two cases, is telling.
[toc] | [prev] | [next] | [standalone]
| From | JohnnyCameLater@whatsthetime.net |
|---|---|
| Date | 2021-10-29 08:39 +0000 |
| Message-ID | <slgc0m$16o1$1@gioia.aioe.org> |
| In reply to | #82169 |
On Fri, 29 Oct 2021 04:51:57 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>JohnnyCameLater@whatsthetime.net wrote:
>> On Thu, 28 Oct 2021 05:20:52 -0000 (UTC)
>> Juha Nieminen <nospam@thanks.invalid> wrote:
>>>JohnnyCameLater@whatsthetime.net wrote:
>>>> void func(int a[2][3])
>>>> {
>>>> a[10][50] = 123;
>>>> }
>>>
>>>If 'a' there is an array, what will sizeof(a) be?
>>>
>>>> int main()
>>>> {
>>>> int a[2][3];
>>>
>>>Contrast that to what sizeof(a) will be here.
>>
>> FFS man, do you even understand whats being discussed here?
>
>Yes. You claim that in func(int a[2][3]) that 'a' there is
>declaring an array. According to you, it's declaring an array,
>and it doesn't matter what's happening "under the hood".
Do you understand the different stages of compilation? Have you heard of
lexical analysis vs parsing vs code generation? I'm guessing not.
>If that were the case, if 'a' there were indeed an array, then
>it would behave like an array, and be the size of an array,
>just like that 'a' in the main() function.
Honestly, I just give up.
Its amusing how you see yourself as some kind of expert :)
>The fact that you refuse to even answer my question, ie.
>what sizeof(a) is in those two cases, is telling.
I already answered it. Yes, it'll be the size of a pointer because BY THAT
POINT it'll be treated as a pointer.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-11-01 06:34 +0000 |
| Message-ID | <slo1pj$1bri$1@gioia.aioe.org> |
| In reply to | #82171 |
JohnnyCameLater@whatsthetime.net wrote: >>> FFS man, do you even understand whats being discussed here? >> >>Yes. You claim that in func(int a[2][3]) that 'a' there is >>declaring an array. According to you, it's declaring an array, >>and it doesn't matter what's happening "under the hood". > > Do you understand the different stages of compilation? Have you heard of > lexical analysis vs parsing vs code generation? I'm guessing not. No, it's you who is being confused by two alternative syntaxes to express the same thing. void foo(int a[10]) and void foo(int *a) are declaring the exact same function. There is zero difference between them, other than just two alternative syntaxes. It's no different than, for example: int i = 5; and: signed int i = 5; The characters in the two lines may differ, but they are doing the exact same thing. In the function declaration the "10" within the brackets is completely superfluous and does absolutely nothing. It has no syntactic nor semantic meaning. You could just as well write it as "/*10*/" and it would have the same effect. And the brackets themselves are just an alternative way of expressing the same thing as the asterisk. So no, in "void foo(int a[10])" the 'a' there is not declaring an array, at any level of syntax or parsing. It's declaring a pointer. You can declare a "pointer to an array of 10 elements", which is *slightly* closer to what you want. Even here there are likewise two alternative ways to specify it: void foo(int (*a)[10]); void foo(int a[][10]); void foo(int a[124567][10]); Again, all three of the above are completely identical, and the number inside the first pair of brackets has no meaning and is superfluous. One way to discern that they are identical is that in C++ those are not overloads. They all declare the same function. (If they were function definitions, you would get an error about duplicate definitions.) Also here 'a' is not an array. It's a pointer. Just because it happens to point to an array of 10 ints doesn't make it an array. It's a pointer in every possible sense, at every possible stage of parsing, at every possible level of syntax. (The difference between an "int *a" and an "int (*a)[10]" is that the "unit" for the element pointed to by that 'a' is one single 'int' in the first case, and 10 'ints' in the second case. Thus, for example, 'a+1' would give you (typically) a pointer that's increased by 4 bytes in the first case, and 40 bytes in the second case.) > Honestly, I just give up. I wish. > Its amusing how you see yourself as some kind of expert :) No, I think it's *you* who considers yourself some kind of "expert", invoking the Dunning-Kruger effect quite hard. >>The fact that you refuse to even answer my question, ie. >>what sizeof(a) is in those two cases, is telling. > > I already answered it. Yes, it'll be the size of a pointer because BY THAT > POINT it'll be treated as a pointer. There's no point at which it isn't considered a pointer.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2021-10-27 17:41 +0100 |
| Message-ID | <20211027174152.a993cfcc669ce9ccb1389339@cvine--nospam--.freeserve.co.uk> |
| In reply to | #82142 |
On Wed, 27 Oct 2021 11:07:03 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 27/10/2021 09:57, RacingRabbit@watershipdown.co.uk wrote:
> > On Tue, 26 Oct 2021 12:23:37 -0400
> > James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> >> On 10/26/21 11:30 AM, RacingRabbit@watershipdown.co.uk wrote:
> >>> You said arrays couldn't be declared as parameters.
> >>
> >> No, I said "it's not permitted to declare functions that take arrays as
> >> arguments, but it is permitted to declare a function parameter as if it
> >> were an array."
> >
> > There is no difference. As I said, what the compiler does with it under the
> > hood is not the point. The syntax declares an array.
> >
> >> When I run that program, it says "pointer". What do you get when you run it?
> >
> > Same. Not the point, its declared as an array.
> >
>
> Do you have trouble understanding the difference between an array, and a
> pointer to the first element of the array?
>
> C arrays are /never/ passed to functions as parameters, nor are they
> used directly in most expressions. (You can pass a struct that contains
> an array as a field, but that's a struct, not an array.) It is a major
> inconsistency in the type system of C, but one that works well in practice.
I know what you mean - they are never passed by value as parameters -
but they can be passed by reference as an array rather than as a pointer
to their first element. In C++ you have this available: there is no
pointer decay and it will print 10:
void func (char (&arr)[10]) {
std::cout << sizeof(arr) << std::endl;
}
int main() {
char arr9[9];
char arr10[10];
// func(arr9); // won't compile
func(arr10); // OK
}
In C and C++ you have this, which will also print 10:
void func (char (*arr)[10]) {
std::cout << sizeof(*arr) << std::endl;
}
int main() {
char arr9[9];
char arr10[10];
// func(&arr9); // won't compile
func(&arr10); // OK
}
None of this detracts from the fact that your nym-shifting correspondent
is not only clueless but also unable to learn.
> Do you know the difference between :
>
> int ar1[10];
>
> and
>
> std::array<int, 10> ar2;
>
> and how these may be passed to functions?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-27 19:02 +0200 |
| Message-ID | <slc0nn$l15$1@dont-email.me> |
| In reply to | #82155 |
On 27/10/2021 18:41, Chris Vine wrote:
> On Wed, 27 Oct 2021 11:07:03 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 27/10/2021 09:57, RacingRabbit@watershipdown.co.uk wrote:
>>> On Tue, 26 Oct 2021 12:23:37 -0400
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>> On 10/26/21 11:30 AM, RacingRabbit@watershipdown.co.uk wrote:
>>>>> You said arrays couldn't be declared as parameters.
>>>>
>>>> No, I said "it's not permitted to declare functions that take arrays as
>>>> arguments, but it is permitted to declare a function parameter as if it
>>>> were an array."
>>>
>>> There is no difference. As I said, what the compiler does with it under the
>>> hood is not the point. The syntax declares an array.
>>>
>>>> When I run that program, it says "pointer". What do you get when you run it?
>>>
>>> Same. Not the point, its declared as an array.
>>>
>>
>> Do you have trouble understanding the difference between an array, and a
>> pointer to the first element of the array?
>>
>> C arrays are /never/ passed to functions as parameters, nor are they
>> used directly in most expressions. (You can pass a struct that contains
>> an array as a field, but that's a struct, not an array.) It is a major
>> inconsistency in the type system of C, but one that works well in practice.
>
> I know what you mean - they are never passed by value as parameters -
> but they can be passed by reference as an array rather than as a pointer
> to their first element. In C++ you have this available: there is no
> pointer decay and it will print 10:
You can do that in C++, not in C. References in C++ are basically the
same concept as const pointers (as distinct from pointers to const),
just with a slightly different syntax. Your "func" here is not taking
an array as a value parameter (like C, you can't do that in C++ with
plain arrays), nor is it using array syntax as a means of specifying a
pointer to the first element. It is a pointer to an /array/.
>
> void func (char (&arr)[10]) {
> std::cout << sizeof(arr) << std::endl;
> }
>
> int main() {
> char arr9[9];
> char arr10[10];
> // func(arr9); // won't compile
> func(arr10); // OK
> }
>
> In C and C++ you have this, which will also print 10:
>
> void func (char (*arr)[10]) {
> std::cout << sizeof(*arr) << std::endl;
> }
>
Yes, that is much the same as a reference in C++ (though you'd be
slightly closer with "char (*arr)[10]" ).
(I think that references are often better than pointers - they can be
safer and clearer. But they are not fundamentally different, as can be
seen by looking at implementations - they are convenient syntactic sugar.)
>
> None of this detracts from the fact that your nym-shifting correspondent
> is not only clueless but also unable to learn.
>
Indeed.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2021-10-27 18:21 +0100 |
| Message-ID | <20211027182118.dcf1ae2f5cee5607ab62e1d2@cvine--nospam--.freeserve.co.uk> |
| In reply to | #82156 |
On Wed, 27 Oct 2021 19:02:46 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 27/10/2021 18:41, Chris Vine wrote:
> > On Wed, 27 Oct 2021 11:07:03 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
[snip]
> >> C arrays are /never/ passed to functions as parameters, nor are they
> >> used directly in most expressions. (You can pass a struct that contains
> >> an array as a field, but that's a struct, not an array.) It is a major
> >> inconsistency in the type system of C, but one that works well in practice.
> >
> > I know what you mean - they are never passed by value as parameters -
> > but they can be passed by reference as an array rather than as a pointer
> > to their first element. In C++ you have this available: there is no
> > pointer decay and it will print 10:
>
> You can do that in C++, not in C. References in C++ are basically the
> same concept as const pointers (as distinct from pointers to const),
> just with a slightly different syntax. Your "func" here is not taking
> an array as a value parameter (like C, you can't do that in C++ with
> plain arrays), nor is it using array syntax as a means of specifying a
> pointer to the first element. It is a pointer to an /array/.
> >
> > void func (char (&arr)[10]) {
> > std::cout << sizeof(arr) << std::endl;
> > }
> >
> > int main() {
> > char arr9[9];
> > char arr10[10];
> > // func(arr9); // won't compile
> > func(arr10); // OK
> > }
> >
> > In C and C++ you have this, which will also print 10:
> >
> > void func (char (*arr)[10]) {
> > std::cout << sizeof(*arr) << std::endl;
> > }
>
> Yes, that is much the same as a reference in C++ (though you'd be
> slightly closer with "char (*arr)[10]" ).
You are agreeing with me: I think you understand that although I am not
entirely sure.
The overarching point is that in the signature:
void func (char arr[10])
'arr' is not the name of an array at all but is the name of a pointer to
char. You can pass func the address of any char object, whether or not
a member of an array. This is the fundamental misunderstanding by the
person in question.
With:
void func (char (&arr)[10])
'arr' is a reference to an char array of size 10 and only that.
With:
void func (char (*arr)[10])
'arr' is a pointer to an char array of size 10 and only that.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-27 11:38 -0400 |
| Message-ID | <slbrqf$cn3$1@dont-email.me> |
| In reply to | #82140 |
On 10/27/21 3:57 AM, RacingRabbit@watershipdown.co.uk wrote: > On Tue, 26 Oct 2021 12:23:37 -0400 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> On 10/26/21 11:30 AM, RacingRabbit@watershipdown.co.uk wrote: >>> You said arrays couldn't be declared as parameters. >> >> No, I said "it's not permitted to declare functions that take arrays as >> arguments, but it is permitted to declare a function parameter as if it >> were an array." > > There is no difference. As I said, what the compiler does with it under the > hood is not the point. The syntax declares an array. The syntax uses [] rather than *. The semantics are those of a pointer, not an array. The semantics are NOT "under the hood" - they restrict what you can do with the function without violating a constraint. They determine what result you get when you apply the sizeof() or unary & operators to the parameter. Most importantly, they determine what happens if you write expressions such as "parameter[1] = 5". Getting back to my original statement, declaring a parameter with pointer semantics using the [] syntax does not allow you to pass an array as the corresponding argument in the function call. All you can pass is a pointer to the first element of the array - which is what any lvalue of array type will be converted into if passed as an argument to such a function. Since C uses "pass by value" exclusively, if you were able to pass an array as an argument, then the corresponding parameter would be a separate array object with a different address, initialized by copying from the array argument. Evaluation the expression "parameter[1] = 5" would only affect the parameter, it would have no effect on the array argument. You can get some idea of how C would behave if such declarations were possible, by declaring a struct type containing an array. Such a struct could be passed into or returned by a function by value. It's syntactically different from, but semantically equivalent to, passing around the array itself by value. The actual C semantics of such a function call are that the corresponding parameter is a separate pointer object filled in by copying the value of the pointer that the lvalue was converted to. Evaluating the expression "parameter[1] = 5" would set the second element of the array to 5.
[toc] | [prev] | [next] | [standalone]
| From | JohnnyCameLater@whatsthetime.net |
|---|---|
| Date | 2021-10-27 15:49 +0000 |
| Message-ID | <slbsdt$uk2$1@gioia.aioe.org> |
| In reply to | #82146 |
On Wed, 27 Oct 2021 11:38:54 -0400 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 10/27/21 3:57 AM, RacingRabbit@watershipdown.co.uk wrote: >> On Tue, 26 Oct 2021 12:23:37 -0400 >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> On 10/26/21 11:30 AM, RacingRabbit@watershipdown.co.uk wrote: >>>> You said arrays couldn't be declared as parameters. >>> >>> No, I said "it's not permitted to declare functions that take arrays as >>> arguments, but it is permitted to declare a function parameter as if it >>> were an array." >> >> There is no difference. As I said, what the compiler does with it under the >> hood is not the point. The syntax declares an array. > >The syntax uses [] rather than *. The semantics are those of a pointer, >not an array. The syntax defines an array. Why do you think you get compiler warnings if you go OOB with an index value? Try it. >The semantics are NOT "under the hood" - they restrict what you can do Yes, they are. tl;dr
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-27 12:36 -0400 |
| Message-ID | <slbv6k$7ff$1@dont-email.me> |
| In reply to | #82149 |
On 10/27/21 11:49 AM, JohnnyCameLater@whatsthetime.net wrote:
> On Wed, 27 Oct 2021 11:38:54 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 10/27/21 3:57 AM, RacingRabbit@watershipdown.co.uk wrote:
...
>>> There is no difference. As I said, what the compiler does with it under the
>>> hood is not the point. The syntax declares an array.
>>
>> The syntax uses [] rather than *. The semantics are those of a pointer,
>> not an array.
>
> The syntax defines an array. Why do you think you get compiler warnings if
> you go OOB with an index value? Try it.
I did try it, and I don't get a compiler warning if I violate the
supposed leading dimension of that array, which is the dimension that
gets "adjusted" into a pointer:
static void func (int a[2][3])
{
a[4][2] = 123;
}
int main(void)
{
int b[8][3] = 0;
func(b);
return b[4][2];
}
Subscripting with a[i][j] with j>2 would be just as much of an array
violation if the type of a is int(*)[3] as it would be if the type of a
were int[2][3].
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c++
csiph-web