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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-26 20:32 +0100 |
| Message-ID | <sl9l3p$n8h$1@dont-email.me> |
| In reply to | #82123 |
On 26/10/2021 19:20, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 26/10/2021 17:49, Keith Thompson wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 26/10/2021 14:29, Ben Bacarisse wrote: >>>>> Bart <bc@freeuk.com> writes: >>> [...] >>>>>> char* s = "ABC"; >>>>> This relies on an a conversion that is valid (bad unwise) in C and >>>>> not >>>>> permitted in C++. >>>> >>>> I tried it in C++ before posting (as I'd thought that "ABC" would have >>>> type const char*) but it seemed to work. (Using -Wall -std=c++14.) >>> And you didn't bother to mention the diagnostic? I get >>> warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings] >>> And of course with "-pedantic-errors" it becomes a fatal error. >>> Did you not get a diagnostic? It's not all that interesting to see >>> what >>> you can get away with by ignoring warnings. >> >> I used rextester.com, which uses the default options I used. There >> were no diagnostics. > > Yes, there were. rextester.com didn't show them to you because you > didn't enable the "Show compiler warnings" checkbox. How about that? A professional-looking site, which, by default, enables warnings for all those compilers and at the same time, by default, chooses to hide those warnings!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-26 22:18 +0200 |
| Message-ID | <sl9nqe$d0f$1@dont-email.me> |
| In reply to | #82126 |
On 26/10/2021 21:32, Bart wrote: > On 26/10/2021 19:20, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >>> On 26/10/2021 17:49, Keith Thompson wrote: >>>> Bart <bc@freeuk.com> writes: >>>>> On 26/10/2021 14:29, Ben Bacarisse wrote: >>>>>> Bart <bc@freeuk.com> writes: >>>> [...] >>>>>>> char* s = "ABC"; >>>>>> This relies on an a conversion that is valid (bad unwise) in C and >>>>>> not >>>>>> permitted in C++. >>>>> >>>>> I tried it in C++ before posting (as I'd thought that "ABC" would have >>>>> type const char*) but it seemed to work. (Using -Wall -std=c++14.) >>>> And you didn't bother to mention the diagnostic? I get >>>> warning: ISO C++ forbids converting a string constant to >>>> ‘char*’ [-Wwrite-strings] >>>> And of course with "-pedantic-errors" it becomes a fatal error. >>>> Did you not get a diagnostic? It's not all that interesting to see >>>> what >>>> you can get away with by ignoring warnings. >>> >>> I used rextester.com, which uses the default options I used. There >>> were no diagnostics. >> >> Yes, there were. rextester.com didn't show them to you because you >> didn't enable the "Show compiler warnings" checkbox. > > How about that? A professional-looking site, which, by default, enables > warnings for all those compilers and at the same time, by default, > chooses to hide those warnings! > When it comes to websites, "professional-looking" is not a good indication of quality. I can't say much about that website, as I have no experience with it, but any professional programmer who doesn't enable warnings and pay attention to them should be looking for another career. (Of course the exact choice of warnings, and appropriate ways to handle them can vary by programmer style, project, and other factors. Hiding them all, however, is never appropriate.) I recommend <https://gotbolt.org> as having a wide selection of compilers, and showing generated code in a helpful format. (I haven't made a survey of alternatives and would be happy to hear of comparisons if someone has a suggestion that is better than godbolt.)
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-27 04:43 +0000 |
| Message-ID | <slald9$ogo$1@gioia.aioe.org> |
| In reply to | #82117 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> I tried it in C++ before posting (as I'd thought that "ABC" would have >> type const char*) but it seemed to work. (Using -Wall -std=c++14.) > > And you didn't bother to mention the diagnostic? I get > warning: ISO C++ forbids converting a string constant to ???char*??? [-Wwrite-strings] > And of course with "-pedantic-errors" it becomes a fatal error. If gcc (or whichever compiler this is) doesn't give an outright error from trying to assign a const pointer to a non-const one without an explicit cast, then it's non-standard-conforming and I would classify it as a defect in the compiler. I think that the compiler should be fully standard-conforming by default, and be more permissive and have non-standard extensions and behavior only when explicitly specified using command-line parameters. Not the other way around.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-10-27 08:29 +0200 |
| Message-ID | <slarjk$no2$1@dont-email.me> |
| In reply to | #82134 |
On 27/10/2021 06:43, Juha Nieminen wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>> I tried it in C++ before posting (as I'd thought that "ABC" would have >>> type const char*) but it seemed to work. (Using -Wall -std=c++14.) >> >> And you didn't bother to mention the diagnostic? I get >> warning: ISO C++ forbids converting a string constant to ???char*??? [-Wwrite-strings] >> And of course with "-pedantic-errors" it becomes a fatal error. > > If gcc (or whichever compiler this is) doesn't give an outright error from > trying to assign a const pointer to a non-const one without an explicit > cast, then it's non-standard-conforming and I would classify it as a > defect in the compiler. You may /prefer/ an error (stopping compilation) rather than a warning, but the standard does not require it. A diagnostic message is all that is needed on constraint errors. I guess someone decided that a warning (always enabled, without requiring any flags) is a good compromise for the convenience of people converting old C code to C++. (I personally would prefer a hard error on this and many other faults in code, requiring particular options to allow people to compile questionable code. But backwards compatibility applies to build systems as well - there is a strong feeling that where possible, code that could be compiled with particular flags before should continue to be compilable.) It's the website rextester.com that is at fault in hiding warnings by default. That is idiotic, IMHO. > > I think that the compiler should be fully standard-conforming by default, > and be more permissive and have non-standard extensions and behavior only > when explicitly specified using command-line parameters. Not the other > way around. > In this respect, gcc /is/ fully conforming. From C++14, 1.4p2 "Implementation compliance" """ If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this Standard as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message. """
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-10-29 06:32 -0700 |
| Message-ID | <86wnlwdkhj.fsf@linuxsc.com> |
| In reply to | #82134 |
Juha Nieminen <nospam@thanks.invalid> writes: > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > >>> I tried it in C++ before posting (as I'd thought that "ABC" would have >>> type const char*) but it seemed to work. (Using -Wall -std=c++14.) >> >> And you didn't bother to mention the diagnostic? I get >> warning: ISO C++ forbids converting a string constant to ???char*??? [-Wwrite-strings] >> And of course with "-pedantic-errors" it becomes a fatal error. > > If gcc (or whichever compiler this is) doesn't give an outright error from > trying to assign a const pointer to a non-const one without an explicit > cast, then it's non-standard-conforming [...] I belive that statement is not correct. Can you cite a passage (or passages) in the C++ standard that supports this assertion?
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-11-01 06:12 +0000 |
| Message-ID | <slo0h7$uqe$1@gioia.aioe.org> |
| In reply to | #82174 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Juha Nieminen <nospam@thanks.invalid> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> >>>> I tried it in C++ before posting (as I'd thought that "ABC" would have >>>> type const char*) but it seemed to work. (Using -Wall -std=c++14.) >>> >>> And you didn't bother to mention the diagnostic? I get >>> warning: ISO C++ forbids converting a string constant to ???char*??? [-Wwrite-strings] >>> And of course with "-pedantic-errors" it becomes a fatal error. >> >> If gcc (or whichever compiler this is) doesn't give an outright error from >> trying to assign a const pointer to a non-const one without an explicit >> cast, then it's non-standard-conforming [...] > > I belive that statement is not correct. Can you cite a passage (or > passages) in the C++ standard that supports this assertion? No. I made an assumption. I don't know if it's a true assumption.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-11-01 08:53 +0100 |
| Message-ID | <slo6e8$jlj$1@dont-email.me> |
| In reply to | #82184 |
On 01/11/2021 07:12, Juha Nieminen wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> Juha Nieminen <nospam@thanks.invalid> writes: >> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >>> >>>>> I tried it in C++ before posting (as I'd thought that "ABC" would have >>>>> type const char*) but it seemed to work. (Using -Wall -std=c++14.) >>>> >>>> And you didn't bother to mention the diagnostic? I get >>>> warning: ISO C++ forbids converting a string constant to ???char*??? [-Wwrite-strings] >>>> And of course with "-pedantic-errors" it becomes a fatal error. >>> >>> If gcc (or whichever compiler this is) doesn't give an outright error from >>> trying to assign a const pointer to a non-const one without an explicit >>> cast, then it's non-standard-conforming [...] >> >> I belive that statement is not correct. Can you cite a passage (or >> passages) in the C++ standard that supports this assertion? > > No. I made an assumption. I don't know if it's a true assumption. > Surely you mean you /didn't/ know if it was a true assumption. Now you know it is not true. If you think it should be true - that compilers should, by default, give fatal errors on this kind of thing, then you'll probably find many agree with you. A fatal error here would also have been conforming to the standards. Compiler writers always have a balance act here, especially in their default configurations without controlling flags - do they prioritise continued compilation of old code that worked with old tool versions despite flaws, or do they prioritise reducing the risk of flaws in current and future code by being stricter? There's no easy answer, and I expect for any such decision there will be people who believe they have made the wrong one. Language standards writers face similar dilemmas. All we can do is be careful about the compiler flags we choose ourselves, and encourage their use for others. And I suppose anyone who uses rextester.com could file a bug report for their site.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-11-01 11:26 -0400 |
| Message-ID | <slp0v7$npu$1@dont-email.me> |
| In reply to | #82184 |
On 11/1/21 2:12 AM, Juha Nieminen wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> Juha Nieminen <nospam@thanks.invalid> writes: ... >>> If gcc (or whichever compiler this is) doesn't give an outright error from >>> trying to assign a const pointer to a non-const one without an explicit >>> cast, then it's non-standard-conforming [...] >> >> I belive that statement is not correct. Can you cite a passage (or >> passages) in the C++ standard that supports this assertion? > > No. I made an assumption. I don't know if it's a true assumption. The C standard says: "The implementation shall not successfully translate a preprocessing translation unit containing a #error preprocessing directive unless it is part of a group skipped by conditional inclusion." (4p4). Ironically, any undefined behavior that a translation unit might have due to problems coming up during translation phases 1-4 might relieve an implementation of it's obligation to reject it. There's no other situation where it's prohibited for an implementation to successfully translate a program, no matter how many defects it contains, no matter how severe they are.
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-11-02 16:19 +0100 |
| Message-ID | <slrkup$fkb$1@dont-email.me> |
| In reply to | #82188 |
On 1 Nov 2021 16:26, James Kuyper wrote:
> On 11/1/21 2:12 AM, Juha Nieminen wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> Juha Nieminen <nospam@thanks.invalid> writes:
> ...
>>>> If gcc (or whichever compiler this is) doesn't give an outright error from
>>>> trying to assign a const pointer to a non-const one without an explicit
>>>> cast, then it's non-standard-conforming [...]
>>>
>>> I belive that statement is not correct. Can you cite a passage (or
>>> passages) in the C++ standard that supports this assertion?
>>
>> No. I made an assumption. I don't know if it's a true assumption.
>
> The C standard says:
>
> "The implementation shall not successfully translate a preprocessing
> translation unit containing a #error preprocessing directive unless it
> is part of a group skipped by conditional inclusion." (4p4).
>
> Ironically, any undefined behavior that a translation unit might have
> due to problems coming up during translation phases 1-4 might relieve an
> implementation of it's obligation to reject it.
>
> There's no other situation where it's prohibited for an implementation
> to successfully translate a program, no matter how many defects it
> contains, no matter how severe they are.
A bit of thread-warping, but these last years I've ended up doing like
#ifdef UNICODE
# error "UNICODE must not be defined for an UTF-8 based program."
# include <stop-compilation>
#endif
If only the C++ standard had some common means of stopping a compilation!
And if only it also had some common means of stating that "the execution
can and should never get here", apart from `for(;;){}`, which is not
idiomatic.
And, some way of saying "this parameter is intentionally unused and any
use should be diagnosed", other than an awkward block comment around the
name (yes I'm aware of C++17 `[[maybe_unused]]`, that thing sucks^1000).
Uhm, come to think of it, it only /C++ compilers/ were designed to stop
at first error, like I believe (think I remember) old Turbo C++ did.
They could be lightning fast -- like, Blaisingly fast!
- Alf
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-11-02 12:54 -0400 |
| Message-ID | <slrqg2$28r$1@dont-email.me> |
| In reply to | #82189 |
On 11/2/21 11:19 AM, Alf P. Steinbach wrote: > On 1 Nov 2021 16:26, James Kuyper wrote: >> On 11/1/21 2:12 AM, Juha Nieminen wrote: >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> Juha Nieminen <nospam@thanks.invalid> writes: >> ... >>>>> If gcc (or whichever compiler this is) doesn't give an outright error from >>>>> trying to assign a const pointer to a non-const one without an explicit >>>>> cast, then it's non-standard-conforming [...] >>>> >>>> I belive that statement is not correct. Can you cite a passage (or >>>> passages) in the C++ standard that supports this assertion? >>> >>> No. I made an assumption. I don't know if it's a true assumption. >> >> The C standard says: >> >> "The implementation shall not successfully translate a preprocessing >> translation unit containing a #error preprocessing directive unless it >> is part of a group skipped by conditional inclusion." (4p4). >> >> Ironically, any undefined behavior that a translation unit might have >> due to problems coming up during translation phases 1-4 might relieve an >> implementation of it's obligation to reject it. >> >> There's no other situation where it's prohibited for an implementation >> to successfully translate a program, no matter how many defects it >> contains, no matter how severe they are. > > A bit of thread-warping, but these last years I've ended up doing like > > #ifdef UNICODE > # error "UNICODE must not be defined for an UTF-8 based program." > # include <stop-compilation> > #endif > > If only the C++ standard had some common means of stopping a compilation! Sorry, ever since Bart's message with "Date: Thu, 21 Oct 2021 15:04:19 +0100", included a comment about const in C, most of my messages on this thread were in response to messages about C (even though most of my messages could have said much the same thing about C++, with correspondingly different citations). I failed to notice that Keith's message with "Date: Tue, 26 Oct 2021 09:49:34 -0700" had returned the topic of this sub-thread back to C++. Therefore, my response to Juha's comment was not relevant.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2021-11-02 23:49 +0200 |
| Message-ID | <slsbpi$89a$1@dont-email.me> |
| In reply to | #82189 |
02.11.2021 17:19 Alf P. Steinbach kirjutas: > > Uhm, come to think of it, it only /C++ compilers/ were designed to stop > at first error, like I believe (think I remember) old Turbo C++ did. Hmm, something like this? g++ -fmax-errors=1
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2021-11-03 00:38 +0100 |
| Message-ID | <slsi5t$h9p$1@dont-email.me> |
| In reply to | #82191 |
On 2 Nov 2021 22:49, Paavo Helde wrote: > 02.11.2021 17:19 Alf P. Steinbach kirjutas: >> >> Uhm, come to think of it, it only /C++ compilers/ were designed to >> stop at first error, like I believe (think I remember) old Turbo C++ did. > > Hmm, something like this? > > g++ -fmax-errors=1 At least some years ago, telling g++ to stop on error did not speed up things (e.g. it still prepares itself for re-synchronizing with the source and continuing spewing out diagnostics), and when the error message has supporting notes those subsequent lines are not shown. About same story with Visual C++, but I don't remember any details. The whole batch compilation idea is 1950-ish, as I see it. - Alf
[toc] | [prev] | [next] | [standalone]
| From | RacingRabbit@watershipdown.co.uk |
|---|---|
| Date | 2021-10-26 14:36 +0000 |
| Message-ID | <sl93q6$1kev$1@gioia.aioe.org> |
| In reply to | #82097 |
On Tue, 26 Oct 2021 12:39:54 +0100 Bart <bc@freeuk.com> wrote: >On 26/10/2021 09:18, RacingRabbit@watershipdown.co.uk wrote: >But * and [] types are modifable: > > char* s = "ABC"; > puts(s); > *s = 'Z'; > >This shows ABC the first time it's executed. The second time it shows >ZBC; the code has changed the string literal! Where the same literal iS I suggest you actually try running that code and see what happens.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-26 15:55 +0100 |
| Message-ID | <sl94te$ro8$1@dont-email.me> |
| In reply to | #82102 |
On 26/10/2021 15:36, RacingRabbit@watershipdown.co.uk wrote: > On Tue, 26 Oct 2021 12:39:54 +0100 > Bart <bc@freeuk.com> wrote: >> On 26/10/2021 09:18, RacingRabbit@watershipdown.co.uk wrote: >> But * and [] types are modifable: >> >> char* s = "ABC"; >> puts(s); >> *s = 'Z'; >> >> This shows ABC the first time it's executed. The second time it shows >> ZBC; the code has changed the string literal! Where the same literal iS > > I suggest you actually try running that code and see what happens. > > What makes you think I didn't? I actually listed the 7 compilers I tried it on, just at the point where you must have stopped reading. Oh, you mean you only tried it on one implementation?
[toc] | [prev] | [next] | [standalone]
| From | RacingRabbit@watershipdown.co.uk |
|---|---|
| Date | 2021-10-26 15:26 +0000 |
| Message-ID | <sl96mn$1612$1@gioia.aioe.org> |
| In reply to | #82107 |
On Tue, 26 Oct 2021 15:55:38 +0100 Bart <bc@freeuk.com> wrote: >On 26/10/2021 15:36, RacingRabbit@watershipdown.co.uk wrote: >> On Tue, 26 Oct 2021 12:39:54 +0100 >> Bart <bc@freeuk.com> wrote: >>> On 26/10/2021 09:18, RacingRabbit@watershipdown.co.uk wrote: >>> But * and [] types are modifable: >>> >>> char* s = "ABC"; >>> puts(s); >>> *s = 'Z'; >>> >>> This shows ABC the first time it's executed. The second time it shows >>> ZBC; the code has changed the string literal! Where the same literal iS >> >> I suggest you actually try running that code and see what happens. >> >> >What makes you think I didn't? > >I actually listed the 7 compilers I tried it on, just at the point where >you must have stopped reading. > >Oh, you mean you only tried it on one implementation? Sorry, I have limited tolerance for smart asses so yes, I stopped reading. They're all toy compilers apart from VC and I specifically was talking about *nix and yes, these days that means gcc or clang.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-10-26 20:35 +0100 |
| Message-ID | <sl9lb1$psj$1@dont-email.me> |
| In reply to | #82112 |
On 26/10/2021 16:26, RacingRabbit@watershipdown.co.uk wrote: > Sorry, I have limited tolerance for smart asses Funny, that, so do I! So I'll leave you to it.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2021-10-27 04:44 +0000 |
| Message-ID | <slalfg$ogo$2@gioia.aioe.org> |
| In reply to | #82112 |
RacingRabbit@watershipdown.co.uk wrote: > Sorry, I have limited tolerance for smart asses so yes, I stopped reading. Then why are you responding?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-26 11:27 -0400 |
| Message-ID | <sl96pf$aig$1@dont-email.me> |
| In reply to | #82102 |
On 10/26/21 10:36 AM, RacingRabbit@watershipdown.co.uk wrote: > On Tue, 26 Oct 2021 12:39:54 +0100 > Bart <bc@freeuk.com> wrote: >> On 26/10/2021 09:18, RacingRabbit@watershipdown.co.uk wrote: >> But * and [] types are modifable: >> >> char* s = "ABC"; >> puts(s); >> *s = 'Z'; >> >> This shows ABC the first time it's executed. The second time it shows >> ZBC; the code has changed the string literal! Where the same literal iS > > I suggest you actually try running that code and see what happens. The behavior of the code shown is undefined, and therefore very well might be exactly as he described - you would need to know precisely which compiler he used, on which platform, with which compiler options. That is in fact common behavior for such code. He claims that he did test it, and I know of no reason to disbelieve him.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2021-10-26 10:31 -0400 |
| Message-ID | <sl93ge$fne$1@dont-email.me> |
| In reply to | #82090 |
On 10/26/21 4:18 AM, RacingRabbit@watershipdown.co.uk wrote:
> On Mon, 25 Oct 2021 13:14:30 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 10/25/21 12:14 PM, RacingRabbit@watershipdown.co.uk wrote:
...
>>> ... It is implicit that its read only in C because
>>> C also provides the following initialisation which places the string
>>> (presumably) on the heap:
>>>
>>> char str[] = "hello world";
>>
>> Such code cannot result in the string being placed in read-only memory,
>> because it's perfectly legal to modify str. On the other hand, both of
>
> Yes, that was my point. [] means modifyable, * means read only in every
> C implementation I've ever used.
Incorrect. In most declarations, [] means array, and * means pointer.
Neither one means "read only".
I think you may be thinking of a different fact that has nothing to do
with read-only memory. Within the scope of an identifier that identifies
an array, that identifier can only ever identify that particular array.
An identifier that identifies a pointer to an object type need not point
at any actual object, and unless it itself is declared const, can be
changed to point at a different object. But that difference between
arrays and pointers has nothing to do with read-only memory. The address
of a named array is not necessarily stored in any pointer - it is
normally hard-coded into the machine language instructions that refer to
the array, so the fact that you can't change that address is not because
the address is stored in read-only memory.
Exception 1: 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. Such a declaration is automatically converting into a
declaration of a pointer to the element type of an array. Thus, the
following two function declarations are functionally identical, despite
being syntactically different:
void func(int array[]);
void func(int *ptr);
Exception 2: in a function parameter declaration, the construct [*]
marks the corresponding dimension of the relevant array as having a
variably modified type with an unknown length for that dimension. This
feature cannot be used in the defining declaration for a function,
because the function definition requires that the variable length be
explicitly specified. It is still an array, and not in any sense a
pointer (unless the relevant dimension is the top-most one, in which
case exception 1 described above also applies).
Any attempt to modify the contents of a string literal is undefined. Any
attempt to modify an object whose definition is const-qualified is also
undefined. Those facts permit, but do not require, that those objects be
stored in read-only memory.
[toc] | [prev] | [next] | [standalone]
| From | RacingRabbit@watershipdown.co.uk |
|---|---|
| Date | 2021-10-26 14:42 +0000 |
| Message-ID | <sl944f$1qlh$1@gioia.aioe.org> |
| In reply to | #82100 |
On Tue, 26 Oct 2021 10:31:41 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 10/26/21 4:18 AM, RacingRabbit@watershipdown.co.uk wrote:
>> On Mon, 25 Oct 2021 13:14:30 -0400
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> On 10/25/21 12:14 PM, RacingRabbit@watershipdown.co.uk wrote:
>....
>>>> ... It is implicit that its read only in C because
>>>> C also provides the following initialisation which places the string
>>>> (presumably) on the heap:
>>>>
>>>> char str[] = "hello world";
>>>
>>> Such code cannot result in the string being placed in read-only memory,
>>> because it's perfectly legal to modify str. On the other hand, both of
>>
>> Yes, that was my point. [] means modifyable, * means read only in every
>> C implementation I've ever used.
>
>Incorrect. In most declarations, [] means array, and * means pointer.
>Neither one means "read only".
>I think you may be thinking of a different fact that has nothing to do
>with read-only memory. Within the scope of an identifier that identifies
No I'm not. The pointer will be pointing to a string literal in the program
static text area which is usually non modifiable.
>Exception 1: it's not permitted to declare functions that take arrays as
>arguments,
Since when?
fenris$ cat t.c
#include <stdio.h>
void func(int a[2][3])
{
printf("%d\n",a[1][2]);
}
int main()
{
int a[2][3];
a[1][2] = 123;
func(a);
return 0;
}
fenris$ cc t.c; a.out
123
[toc] | [prev] | [next] | [standalone]
Page 4 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