Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #43061 > unrolled thread
| Started by | "BartC" <bc@freeuk.com> |
|---|---|
| First post | 2014-04-18 11:45 +0100 |
| Last post | 2014-04-21 09:08 +0200 |
| Articles | 20 on this page of 280 — 25 participants |
Back to article view | Back to comp.lang.c
Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 11:45 +0100
Re: Constant strings Richard Damon <Richard@Damon-Family.org> - 2014-04-18 07:34 -0400
Re: Constant strings G G <gdotone@gmail.com> - 2014-04-18 05:23 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 17:16 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 11:08 -0700
Re: Constant strings G G <gdotone@gmail.com> - 2014-04-18 13:11 -0700
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-18 10:21 -0400
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 08:45 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 16:48 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 09:21 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-19 09:09 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 23:53 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-18 23:06 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-19 03:57 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-19 23:41 +1200
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-19 06:21 -0700
Re: Constant strings Barry Schwarz <schwarzb@dqel.com> - 2014-04-19 10:04 -0700
Re: Constant strings Barry Schwarz <schwarzb@dqel.com> - 2014-04-19 16:54 -0700
Re: Constant strings Seungbeom Kim <musiphil@bawi.org> - 2014-04-19 17:54 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-19 13:20 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-19 23:32 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-19 23:38 +0000
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-19 17:28 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-20 10:53 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-20 14:29 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-20 23:41 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-21 11:14 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-21 13:05 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-21 11:11 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-20 19:44 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-21 10:51 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-21 13:29 -0400
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-21 11:04 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 11:31 +0100
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-22 06:24 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 13:34 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 09:19 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 15:00 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 07:53 -0700
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 12:48 -0400
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 07:28 -0400
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 05:46 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 07:45 -0700
Re: Constant strings Ike Naar <ike@iceland.freeshell.org> - 2014-04-22 16:34 +0000
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 10:10 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 11:50 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 18:48 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 14:02 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 19:48 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-22 15:28 -0400
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 19:48 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 11:56 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 12:59 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 08:21 -0400
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 14:09 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 14:19 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 08:40 -0400
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 11:56 -0400
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 11:10 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 19:19 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 19:19 -0700
Re: Constant strings Robert Wessel <robertwessel2@yahoo.com> - 2014-04-23 23:53 -0500
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 11:55 +0000
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 11:27 -0500
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-24 20:03 +0000
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 17:16 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 17:39 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 13:06 -0400
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-23 10:25 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 11:30 -0700
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-23 20:55 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-23 21:53 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-24 17:05 +1200
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-24 00:59 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 18:39 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 14:53 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 21:09 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-23 19:23 -0400
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-25 10:52 -0500
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 19:36 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 10:37 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-24 07:45 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 13:15 +0100
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-24 08:33 -0500
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-24 09:47 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 15:09 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-24 12:07 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 18:23 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-24 14:49 -0400
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 13:48 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 12:32 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 23:57 -0500
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-25 08:31 -0400
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-25 09:51 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-25 16:45 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 09:07 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-25 17:33 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 11:38 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 11:42 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-25 10:58 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 11:29 -0700
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-25 15:10 -0400
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-25 19:06 -0500
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-26 05:39 -0400
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-26 04:07 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-26 12:50 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-26 05:03 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-26 11:23 -0700
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-26 19:13 +0000
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-26 23:54 +0200
Re: Constant strings Richard Damon <Richard@Damon-Family.org> - 2014-04-26 18:47 -0400
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-26 23:01 +0000
Re: Constant strings Seungbeom Kim <musiphil@bawi.org> - 2014-04-26 18:09 -0700
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-27 01:22 +0000
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-27 04:09 +0200
Re: Constant strings David Thompson <dave.thompson2@verizon.net> - 2014-05-25 16:44 -0400
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-05-25 14:43 -0700
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-27 04:09 +0200
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 05:36 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-27 06:42 -0700
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-27 02:42 +0000
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-27 04:45 +0200
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-27 14:13 -0500
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-27 20:11 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 03:22 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-28 10:00 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 11:24 +0100
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 12:30 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 13:58 +0100
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 12:22 +0000
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-28 08:53 -0700
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-28 16:10 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 18:11 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 11:34 -0700
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 19:01 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 11:06 +0000
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-28 12:48 +0100
Re: Constant strings Richard Damon <Richard@Damon-Family.org> - 2014-04-28 08:11 -0400
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 14:04 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 12:55 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-28 13:23 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 13:47 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 06:01 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-29 08:43 +1200
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 21:08 +0000
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-29 09:32 +1200
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 22:41 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 22:00 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 23:18 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-28 15:43 -0700
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 23:23 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 22:47 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 23:17 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 01:18 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 00:31 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 01:58 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 01:13 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 03:19 +0100
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 03:31 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 04:21 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 04:29 +0000
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-29 09:14 +0200
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 14:05 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-29 00:37 -0700
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-29 13:36 +0200
Re: Constant strings ralph <nt_consulting@yahoo.com> - 2014-04-29 07:49 -0500
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-29 06:28 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-29 07:37 -0700
Re: Constant strings David Brown <david.brown@hesbynett.no> - 2014-04-29 17:15 +0200
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 20:58 +0000
Re: Constant strings David Brown <david.brown@hesbynett.no> - 2014-04-30 10:16 +0200
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 16:04 +0000
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-29 16:10 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-29 09:58 -0700
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-30 12:46 +0200
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 14:51 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-29 16:05 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 01:53 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-28 23:11 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 23:29 +0000
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-29 00:18 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 21:52 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-28 23:08 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-28 22:31 +0000
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-29 00:54 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-28 23:10 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-29 11:28 +1200
Re: Constant strings gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-27 06:31 +0000
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-26 12:27 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-26 13:11 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-26 13:50 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-26 11:26 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-27 02:21 +0100
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-26 08:05 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-26 11:39 -0700
Re: Constant strings Martin Shobe <martin.shobe@yahoo.com> - 2014-04-26 16:27 -0500
Re: Constant strings Ian Zimmerman <itz@buug.org> - 2014-04-27 10:46 -0700
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-26 22:46 -0400
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-27 10:08 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-27 07:35 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-27 16:35 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-27 12:28 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-27 12:36 +0100
Re: Constant strings James Kuyper <jameskuyper@verizon.net> - 2014-04-27 23:14 -0400
Re: Constant strings Seungbeom Kim <musiphil@bawi.org> - 2014-04-26 18:03 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-27 02:33 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 07:49 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-25 03:03 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-25 22:50 +0100
Re: Constant strings Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2014-04-24 20:20 -0600
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 23:31 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-25 15:24 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-25 08:31 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 07:58 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-26 13:38 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-26 11:50 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 07:42 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-24 08:43 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 11:28 -0700
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 18:42 +0000
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-24 14:03 -0500
Re: Constant strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-23 20:49 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 21:21 +0000
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 10:50 -0500
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 19:41 -0500
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 09:43 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 18:19 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 11:45 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 20:01 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 12:19 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-23 11:01 -0500
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 15:21 -0500
Re: Constant strings Richard <rgrdev_@gmail.com> - 2014-04-20 11:08 +0100
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 02:26 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-22 21:36 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 13:14 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 07:25 -0700
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 08:29 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 09:35 -0700
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 09:54 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 10:17 -0700
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 10:31 -0700
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 02:33 -0700
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-22 21:37 +1200
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-22 07:17 -0700
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-19 13:42 +0100
Re: Constant strings Ike Naar <ike@iceland.freeshell.org> - 2014-04-19 15:42 +0000
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-19 16:19 +0000
Re: Constant strings Seungbeom Kim <musiphil@bawi.org> - 2014-04-19 17:47 -0700
Re: Constant strings Stephen Sprunk <stephen@sprunk.org> - 2014-04-22 11:00 -0500
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 18:36 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-23 09:38 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-22 23:25 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-23 10:48 +1200
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 12:37 +0100
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-23 13:47 +0100
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 14:03 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-24 09:14 +1200
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-23 23:37 +0100
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-24 10:54 +1200
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-24 00:52 +0100
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-24 01:04 +0000
Re: Constant strings Ian Collins <ian-news@hotmail.com> - 2014-04-24 13:16 +1200
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 19:14 -0700
Re: Constant strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-04-24 03:41 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-23 16:04 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 08:53 -0700
Re: Constant strings Tim Rentsch <txr@alumni.caltech.edu> - 2014-04-20 16:02 -0700
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-18 16:13 +0000
Re: Constant strings "BartC" <bc@freeuk.com> - 2014-04-18 18:34 +0100
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-18 11:06 -0700
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-18 18:54 +0000
Re: Constant strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-18 14:15 -0700
Re: Constant strings Rosario193 <Rosario@invalid.invalid> - 2014-04-20 20:15 +0200
Re: Constant strings Rosario193 <Rosario@invalid.invalid> - 2014-04-20 22:13 +0200
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-20 14:31 -0700
Re: Constant strings Keith Thompson <kst-u@mib.org> - 2014-04-20 14:30 -0700
Re: Constant strings Rosario193 <Rosario@invalid.invalid> - 2014-04-21 02:43 +0200
Re: Constant strings Kaz Kylheku <kaz@kylheku.com> - 2014-04-21 03:12 +0000
Re: Constant strings Rosario193 <Rosario@invalid.invalid> - 2014-04-21 09:08 +0200
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-24 10:37 +0100 |
| Message-ID | <3Y46v.117235$%n2.57715@fx30.am4> |
| In reply to | #43478 |
"Stephen Sprunk" <stephen@sprunk.org> wrote in message news:lj9m9q$hjh$1@dont-email.me... > On 23-Apr-14 12:39, BartC wrote: [The meaning of 'const'] >> I think I have a pretty good idea what it does, > > Your responses in this thread seem to indicate otherwise. > > At minimum, you don't have a "pretty good idea" of how to use it. Let's see: (1) It really means 'read-only' (2) It's an attribute applied to a type (3) Such a type can be used pretty much everywhere that a non-const type can (4) Attempts to write to an l-value with a read-only attribute raise a compiler diagnostic, except: (5) An object with a read-only type attribute can be initialised in its declaration (even with a runtime value for a non-static object); and: (6) A function parameter with a read-only type attribute can be initialised from an argument that has non-read-only attribute (7) Implicit coercions from non-read-only to read-only versions of the same type ( T to const T) are allowed. (8) Implicit coercions from read-only to non-read-only versions of the same type (const T to T) raise a compiler diagnostic. (9) Read-only attributes can be used by the compiler as optimisation hints, as well helping to decide which kind of data segments static data can be stored in. (10) Read-only attributes can be applied to any level of any type-specification, which means a complex type-spec can have any number of read-only attributes (not including the multiple attributes that some compilers allow at each level) (11) Read-only attributes can be applied to scalars, structs and pointers, but not to arrays. (12) Casts can be used to convert read-only to non-read-only and vice versa If that lot (which is is off the top of my head, so apologies if the terms aren't quite right) isn't a 'pretty good' summary of how 'const' works, then I will admit I have absolutely no idea what it does. But I will also then suggest that its use is too subtle and unintuitive to be classed as a solid, useful language feature. I would still be interested in that case in seeing your own point-by-point explanation of what it really does. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-24 07:45 -0400 |
| Message-ID | <ljath7$ulm$1@dont-email.me> |
| In reply to | #43497 |
On 04/24/2014 05:37 AM, BartC wrote: > "Stephen Sprunk" <stephen@sprunk.org> wrote in message > news:lj9m9q$hjh$1@dont-email.me... >> On 23-Apr-14 12:39, BartC wrote: > > [The meaning of 'const'] >>> I think I have a pretty good idea what it does, >> >> Your responses in this thread seem to indicate otherwise. >> >> At minimum, you don't have a "pretty good idea" of how to use it. > > Let's see: > > (1) It really means 'read-only' For an object whose type is itself const-qualified, rather than being merely a pointer to a const-qualified type, it also means "cannot be modified after initialization with defined behavior". > (2) It's an attribute applied to a type > > (3) Such a type can be used pretty much everywhere that a non-const type can I would say that the following item constitutes an exception to the preceding item, and they should both therefore be re-written to acknowledge that relationship. > (4) Attempts to write to an l-value with a read-only attribute raise a > compiler diagnostic, except: This applies not only to explicit attempts to write to the object, but also to certain constructs that merely put the object at risk of being written to. The prime example of this is passing a 'const T*' to a function where the corresponding parameter has the type 'T*'. That means that the function could, without containing any constraint violations in the function itself, attempt to write through that parameter - so the function call itself has been made a constraint violation. This is perhaps the single most useful feature enabled by 'const'. Keep in mind that a diagnostic is required because such uses of const-qualified types are constraint violations. That also gives an implementation permission to reject the program. If the implementation chooses not to reject the program, and if the user chooses to execute the translated program, the behavior is also undefined. That's the most seriously negative thing that C standard says about any program construct. > (5) An object with a read-only type attribute can be initialised in its > declaration (even with a runtime value for a non-static object); and: > > (6) A function parameter with a read-only type attribute can be initialised > from an argument that has non-read-only attribute > > (7) Implicit coercions from non-read-only to read-only versions of the same > type ( T to const T) are allowed. > > (8) Implicit coercions from read-only to non-read-only versions of the same > type (const T to T) raise a compiler diagnostic. More accurately, such conversions do not occur implicitly at all. The diagnostic message is side-effect of the fact that the conversion did NOT occur. It is the use of a const-qualified type in a context where it is incompatible with the required type, that is the actual cause of the constraint violation. > (9) Read-only attributes can be used by the compiler as optimisation hints, > as well helping to decide which kind of data segments static data can be > stored in. That is a side-effect of the fact that the use a const-qualified types in certain contexts leaves the behavior of the entire program undefined, so that there is no such thing as incorrect behavior in those contexts. An implementor is therefore free to let the behavior in those contexts be whatever is most convenient, rather than whatever it is that the programmer might have thought was reasonable. > (10) Read-only attributes can be applied to any level of any > type-specification, which means a complex type-spec can have any number of > read-only attributes (not including the multiple attributes that some > compilers allow at each level) You should clarify that you're referring to levels of indirection. 'const' is a type-qualifier, and as such can only appear in locations where type-qualifiers are allowed by the syntax, though it can be mixed in with any of the other kinds of declaration specifiers; their relative order has no significance. What you're referring to is the fact that 'const' has a different meaning depending upon whether it appears to the left or to the right of any given '*' in the declaration. > (11) Read-only attributes can be applied to scalars, structs and pointers, > but not to arrays. <nitpick>That's redundant, since pointer types are scalar types. unions can also be declared 'const'.</nitpick> Could you provide a citation for the array exception? Perhaps you're thinking of the _Atomic type-qualifier, for which application to an array type would be a constraint violation (6.7.3p2)? > (12) Casts can be used to convert read-only to non-read-only and vice versa > > If that lot (which is is off the top of my head, so apologies if the terms > aren't quite right) isn't a 'pretty good' summary of how 'const' works, then > I will admit I have absolutely no idea what it does. It is a pretty good summary; the objections I've raised are relatively minor - if I wrote up my own summary I'd expect Keith, at least, to be able find at least as many minor errors in my summary. He's annoyingly good at finding such errors - but the annoyance is with myself, for making the errors, not with him, for finding them. Which makes it all the more confusing that you've said so many ridiculous things about 'const' that are not justified by any of the items from the above summary (I'm NOT referring to your subjective judgment that 'const' is useless). If you can't use the facts you've listed above to reach correct conclusions about how 'const' is used, then you don't really understand those facts, even if you can list them out correctly. Possibly your mistaken belief that use of 'const' calls for frequent use of (const T*) casts is merely due to your deliberate lack of experience with using 'const'. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-24 13:15 +0100 |
| Message-ID | <9t76v.90272$RZ3.49871@fx19.am4> |
| In reply to | #43498 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:ljath7$ulm$1@dont-email.me... > On 04/24/2014 05:37 AM, BartC wrote: >> (11) Read-only attributes can be applied to scalars, structs and >> pointers, >> but not to arrays. > > <nitpick>That's redundant, since pointer types are scalar types. unions > can also be declared 'const'.</nitpick> > > Could you provide a citation for the array exception? Perhaps you're > thinking of the _Atomic type-qualifier, for which application to an > array type would be a constraint violation (6.7.3p2)? I can't get CDECL to accept 'const array'. That might be a bug in CDECL, but also in the C type syntax there doesn't seem anywhere to put a const for an array. Maybe because 'array' doesn't really exist as an independent type, outside of a type-specification; the type of an expression can never start with 'array', so having 'const array' would have no benefit. > Which makes it all the more confusing that you've said so many > ridiculous things about 'const' that are not justified by any of the > items from the above summary (I'm NOT referring to your subjective > judgment that 'const' is useless). If you can't use the facts you've > listed above to reach correct conclusions about how 'const' is used, > then you don't really understand those facts, even if you can list them > out correctly. Maybe I'm simply trying to justify my own reasons for not implementing a parallel feature elsewhere. If I can play down its usefulness (and in fact I've never used it in my own code), then that's less work for me. But I do think it is a minor feature that is dispensable. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2014-04-24 08:33 -0500 |
| Message-ID | <ljb3qm$bck$1@dont-email.me> |
| In reply to | #43504 |
On 4/24/2014 7:15 AM, BartC wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:ljath7$ulm$1@dont-email.me...
>> On 04/24/2014 05:37 AM, BartC wrote:
>
>
>>> (11) Read-only attributes can be applied to scalars, structs and
>>> pointers,
>>> but not to arrays.
>>
>> <nitpick>That's redundant, since pointer types are scalar types. unions
>> can also be declared 'const'.</nitpick>
>>
>> Could you provide a citation for the array exception? Perhaps you're
>> thinking of the _Atomic type-qualifier, for which application to an
>> array type would be a constraint violation (6.7.3p2)?
>
> I can't get CDECL to accept 'const array'. That might be a bug in CDECL,
> but also in the C type syntax there doesn't seem anywhere to put a const
> for an array.
>
> Maybe because 'array' doesn't really exist as an independent type,
> outside of a type-specification; the type of an expression can never
> start with 'array', so having 'const array' would have no benefit.
In order to do this, you need to create a typedef. E.g.
typedef int foo_t[2];
int main()
{
foo_t const bar = { 0, 1 };
bar[0] = 2;
}
>> Which makes it all the more confusing that you've said so many
>> ridiculous things about 'const' that are not justified by any of the
>> items from the above summary (I'm NOT referring to your subjective
>> judgment that 'const' is useless). If you can't use the facts you've
>> listed above to reach correct conclusions about how 'const' is used,
>> then you don't really understand those facts, even if you can list them
>> out correctly.
>
> Maybe I'm simply trying to justify my own reasons for not implementing a
> parallel feature elsewhere. If I can play down its usefulness (and in
> fact I've never used it in my own code), then that's less work for me.
> But I do think it is a minor feature that is dispensable.
One only has to look at esoteric languages like Unlambda to realize that
most of the features in production languages are dispensable. It also
shows that just because something is dispensable, it doesn't mean it
should be removed.
I'll agree that it's minor. I've worked with languages that don't have
it and survived. I've also had to track down and fix bugs that would
have been caught by the compiler had const been used correctly.
Personally, I find it to brings more value than it costs.
Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-24 09:47 -0400 |
| Message-ID | <ljb4l9$h04$1@dont-email.me> |
| In reply to | #43504 |
On 04/24/2014 08:15 AM, BartC wrote: ... > I can't get CDECL to accept 'const array'. That might be a bug in CDECL, but > also in the C type syntax there doesn't seem anywhere to put a const for an > array. What does CDECL say about const int array[5]; -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-24 15:09 +0100 |
| Message-ID | <XW86v.55354$Xl1.41723@fx09.am4> |
| In reply to | #43506 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:ljb4l9$h04$1@dont-email.me... > On 04/24/2014 08:15 AM, BartC wrote: > ... >> I can't get CDECL to accept 'const array'. That might be a bug in CDECL, >> but >> also in the C type syntax there doesn't seem anywhere to put a const for >> an >> array. > > What does CDECL say about > > const int array[5]; 'const int ax[5]' results in ax (because 'array' is special) declared as: 'array 5 of const int' So you can apply const to elements, but not to arrays (at least not without the trick that Martin posted). Although a const array, and an array of const elements, achieve the same thing, it still appears the case that an array itself can't be const. (Even when using a typedef to apparently apply const to an array, I think it is applied instead to the elements.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-24 12:07 -0400 |
| Message-ID | <535936B5.2020000@verizon.net> |
| In reply to | #43507 |
On 04/24/2014 10:09 AM, BartC wrote: > > > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:ljb4l9$h04$1@dont-email.me... >> On 04/24/2014 08:15 AM, BartC wrote: >> ... >>> I can't get CDECL to accept 'const array'. That might be a bug in CDECL, >>> but >>> also in the C type syntax there doesn't seem anywhere to put a const for >>> an >>> array. >> >> What does CDECL say about >> >> const int array[5]; > > 'const int ax[5]' results in ax (because 'array' is special) declared as: > > 'array 5 of const int' > > So you can apply const to elements, but not to arrays (at least not without > the trick that Martin posted). What do you think it would mean for the array to be const, that is different from having the elements of the array being const?
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-24 18:23 +0100 |
| Message-ID | <SMb6v.97348$Qm2.28242@fx16.am4> |
| In reply to | #43514 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:535936B5.2020000@verizon.net... > On 04/24/2014 10:09 AM, BartC wrote: >> So you can apply const to elements, but not to arrays (at least not >> without >> the trick that Martin posted). > > What do you think it would mean for the array to be const, that is > different from having the elements of the array being const? I suppose a difference could be invented, especially if an array was a proper first class type (although I'm the wrong person to suggest a new use for const.) But I'm not demanding that arrays ought to have the const attribute. I was just pointing out a mild anomaly in the type system and the way that consts can be applied. So you have to say 'array of const T', and not 'const array of T' or 'const array of const T' (just to make doubly sure). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-24 14:49 -0400 |
| Message-ID | <53595CB6.60709@verizon.net> |
| In reply to | #43518 |
On 04/24/2014 01:23 PM, BartC wrote: > > > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:535936B5.2020000@verizon.net... ... >> What do you think it would mean for the array to be const, that is >> different from having the elements of the array being const? > > I suppose a difference could be invented, especially if an array was a > proper first class type (although I'm the wrong person to suggest a new use > for const.) > > But I'm not demanding that arrays ought to have the const attribute. I was > just pointing out a mild anomaly in the type system and the way that consts > can be applied. So you have to say 'array of const T', and not 'const array > of T' or 'const array of const T' (just to make doubly sure). The standard does identify "const T[]" as declaring an "array of const T" . However, I would consider "const array of T" to clearly be an alternative (though non-standard) way of describing the same type. "const array of const T, on the other hand, is simply meaningless.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-24 13:48 -0500 |
| Message-ID | <ljbm94$hlt$1@dont-email.me> |
| In reply to | #43514 |
On 24-Apr-14 11:07, James Kuyper wrote: > On 04/24/2014 10:09 AM, BartC wrote: >> So you can apply const to elements, but not to arrays (at least not >> without the trick that Martin posted). > > What do you think it would mean for the array to be const, that is > different from having the elements of the array being const? I'd expect a const array of int to decay to a const pointer to int, which is quite different from a pointer to const int. OTOH, you can't modify the decayed-to pointer anyway, so wouldn't that mean that they're already effectively const? S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-24 12:32 -0700 |
| Message-ID | <lnha5itten.fsf@nuthaus.mib.org> |
| In reply to | #43520 |
Stephen Sprunk <stephen@sprunk.org> writes:
> On 24-Apr-14 11:07, James Kuyper wrote:
>> On 04/24/2014 10:09 AM, BartC wrote:
>>> So you can apply const to elements, but not to arrays (at least not
>>> without the trick that Martin posted).
>>
>> What do you think it would mean for the array to be const, that is
>> different from having the elements of the array being const?
>
> I'd expect a const array of int to decay to a const pointer to int,
> which is quite different from a pointer to const int.
Really? I wouldn't expect that. If I had a read-only array, I'd
expect its elements to be read-only. The fact that C apparently
doesn't have a way to express "const array" is probably just an
accident of the syntax, and one that doesn't cause any harm since
we specifying "const" on the element type does the same thing.
(I haven't taken the time to think about whether typedefs affect
this.)
> OTOH, you can't modify the decayed-to pointer anyway, so wouldn't that
> mean that they're already effectively const?
The pointer to which an array expression decays is not an lvalue.
"const" is irrelevant for non-lvalues, since there's nothing to modify.
(42++?)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-24 23:57 -0500 |
| Message-ID | <ljcpvo$r8$1@dont-email.me> |
| In reply to | #43523 |
On 24-Apr-14 14:32, Keith Thompson wrote: > Stephen Sprunk <stephen@sprunk.org> writes: >> On 24-Apr-14 11:07, James Kuyper wrote: >>> On 04/24/2014 10:09 AM, BartC wrote: >>>> So you can apply const to elements, but not to arrays (at least >>>> not without the trick that Martin posted). >>> >>> What do you think it would mean for the array to be const, that >>> is different from having the elements of the array being const? >> >> I'd expect a const array of int to decay to a const pointer to >> int, which is quite different from a pointer to const int. > > Really? I wouldn't expect that. If I had a read-only array, I'd > expect its elements to be read-only. That'd be an array of const int, not a const array of int. > The fact that C apparently doesn't have a way to express "const array" > is probably just an accident of the syntax, Perhaps, though I think it's more historical artifact than accident. In B, an array was just a pointer to an unnamed object; one could modify an array to point elsewhere just like any other pointer. When arrays became a distinct type (arguably what makes C a different language), they became inherently unmodifiable, but they decayed to pointers in most contexts for backwards compatibility. That predated const, though, so perhaps arrays would have been described differently if that change had been later. I just noticed an interesting parallel to functions, which also decay to pointers in most contexts and can't meaningfully be declared const because they're already inherently unmodifiable. Two such similar accidents would be quite a coincidence. > and one that doesn't cause any harm since we specifying "const" on the > element type does the same thing. (I haven't taken the time to think > about whether typedefs affect this.) I think someone mentioned upthread that one can actually create a const array (rather than an array of const) using a typedef. I'm not sure how it could behave any differently from a non-const array, though. >> OTOH, you can't modify the decayed-to pointer anyway, so wouldn't >> that mean that they're already effectively const? > > The pointer to which an array expression decays is not an lvalue. > "const" is irrelevant for non-lvalues, since there's nothing to > modify. (42++?) That was my point. (But see above about B.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-25 08:31 -0400 |
| Message-ID | <ljdkjh$e3f$1@dont-email.me> |
| In reply to | #43540 |
On 04/25/2014 12:57 AM, Stephen Sprunk wrote: > On 24-Apr-14 14:32, Keith Thompson wrote: ... >> Really? I wouldn't expect that. If I had a read-only array, I'd >> expect its elements to be read-only. > > That'd be an array of const int, not a const array of int. So, what does "const array of int" mean to you? If it were possible to declare a const array of int, how would you describe the way in which it differs from an ordinary array of int? ... > I think someone mentioned upthread that one can actually create a const > array (rather than an array of const) using a typedef. I'm not sure how > it could behave any differently from a non-const array, though. That is the question I'd like answered. I don't understand what people think they mean by that term that makes it different from "array of const int". -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2014-04-25 09:51 -0500 |
| Message-ID | <ljdsqd$4o8$1@dont-email.me> |
| In reply to | #43552 |
On 4/25/2014 7:31 AM, James Kuyper wrote: > On 04/25/2014 12:57 AM, Stephen Sprunk wrote: >> On 24-Apr-14 14:32, Keith Thompson wrote: > ... >>> Really? I wouldn't expect that. If I had a read-only array, I'd >>> expect its elements to be read-only. >> >> That'd be an array of const int, not a const array of int. > > So, what does "const array of int" mean to you? If it were possible to > declare a const array of int, how would you describe the way in which it > differs from an ordinary array of int? > > ... >> I think someone mentioned upthread that one can actually create a const >> array (rather than an array of const) using a typedef. I'm not sure how >> it could behave any differently from a non-const array, though. > > That is the question I'd like answered. I don't understand what people > think they mean by that term that makes it different from "array of > const int". > As far as I can tell, the difference is conceptual. A "const array of int" would mean that the array, as a whole, would be const. An "array of const int" would mean the each element of the array would be const. I'm unaware of any practical differences. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-25 16:45 +0100 |
| Message-ID | <9qv6v.171469$Yq5.130589@fx28.am4> |
| In reply to | #43557 |
"Martin Shobe" <martin.shobe@yahoo.com> wrote in message
news:ljdsqd$4o8$1@dont-email.me...
> On 4/25/2014 7:31 AM, James Kuyper wrote:
>> That is the question I'd like answered. I don't understand what people
>> think they mean by that term that makes it different from "array of
>> const int".
>>
>
> As far as I can tell, the difference is conceptual. A "const array of int"
> would mean that the array, as a whole, would be const. An "array of const
> int" would mean the each element of the array would be const. I'm unaware
> of any practical differences.
'const array' could be allowed to fill an otherwise awkward hole in the type
system, so that every kind of type can have a const attribute.
Structs have similarities to arrays, and there you can have a const struct,
const members (none, any or all), or a combination, including a const struct
with all-const members, without that being reported as redundant.
You might, for example, have a typedef-ed array:
typedef int vector[4];
which you might want to use here:
vector A;
with read-write capabilities; and here:
const vector B = {...};
in read-only mode. For this to happen, the const attribute has to be brought
inside the vector to apply to its element type (without affecting the vector
element of A).
With a const array, this is not necessary; the const attribute is applied to
the element as needed, as it works with structs:
typedef struct {
int a, b;
const int c;
} record;
const record R;
R.a=10; // gcc reports writing to read-only object
R.c=20; // gcc reports writing to read-only member
So const arrays can be read-only arrays, and have a non-const element type,
and the elements can still be protected.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-25 09:07 -0700 |
| Message-ID | <lnsip1s88z.fsf@nuthaus.mib.org> |
| In reply to | #43565 |
"BartC" <bc@freeuk.com> writes:
> "Martin Shobe" <martin.shobe@yahoo.com> wrote in message
> news:ljdsqd$4o8$1@dont-email.me...
>> On 4/25/2014 7:31 AM, James Kuyper wrote:
>>> That is the question I'd like answered. I don't understand what people
>>> think they mean by that term that makes it different from "array of
>>> const int".
>>
>> As far as I can tell, the difference is conceptual. A "const array of int"
>> would mean that the array, as a whole, would be const. An "array of const
>> int" would mean the each element of the array would be const. I'm unaware
>> of any practical differences.
>
> 'const array' could be allowed to fill an otherwise awkward hole in the type
> system, so that every kind of type can have a const attribute.
How is it awkward? What actual benefit would programmers get from
adding "const array"? What syntax would be used to specify a const
array? Could such a syntax be invented that avoids conflicting with the
existing syntax for an array of const elements? Do we really need to
distinct ways of specifying that an array's elements are read-only?
I've been using C for a very long time, and until now I never even
noticed this "awkward hole".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-25 17:33 +0100 |
| Message-ID | <h8w6v.100371$t73.70362@fx14.am4> |
| In reply to | #43570 |
"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnsip1s88z.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
>> "Martin Shobe" <martin.shobe@yahoo.com> wrote in message
>> news:ljdsqd$4o8$1@dont-email.me...
>>> On 4/25/2014 7:31 AM, James Kuyper wrote:
>>>> That is the question I'd like answered. I don't understand what people
>>>> think they mean by that term that makes it different from "array of
>>>> const int".
>>>
>>> As far as I can tell, the difference is conceptual. A "const array of
>>> int"
>>> would mean that the array, as a whole, would be const. An "array of
>>> const
>>> int" would mean the each element of the array would be const. I'm
>>> unaware
>>> of any practical differences.
>>
>> 'const array' could be allowed to fill an otherwise awkward hole in the
>> type
>> system, so that every kind of type can have a const attribute.
>
> How is it awkward? What actual benefit would programmers get from
> adding "const array"? What syntax would be used to specify a const
> array? Could such a syntax be invented that avoids conflicting with the
> existing syntax for an array of const elements?
I'm not really advocating this. Someone posed a question as to how a const
array can be meaningful, and these are some ideas.
> Do we really need to
> distinct ways of specifying that an array's elements are read-only?
Going back to my example:
typedef int vector[4];
vector A;
const vector B = {...};
Are the elements of vector const or non-const? See, it's not so obvious!
> I've been using C for a very long time, and until now I never even
> noticed this "awkward hole".
I notice it all the time. Because you are not allowed to have array types
for expressions, to pass to functions and so on, there's some scene-shifting
done by C to try and pretend they don't exist.
As an example, what's the type of A here:
void somefunction(int A[5]);
and of A here:
int A[5];
which has exactly the same type-spec?
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-25 11:38 -0700 |
| Message-ID | <lnfvl1s19z.fsf@nuthaus.mib.org> |
| In reply to | #43571 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnsip1s88z.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>>> "Martin Shobe" <martin.shobe@yahoo.com> wrote in message
>>> news:ljdsqd$4o8$1@dont-email.me...
>>>> On 4/25/2014 7:31 AM, James Kuyper wrote:
>>>>> That is the question I'd like answered. I don't understand what people
>>>>> think they mean by that term that makes it different from "array of
>>>>> const int".
>>>>
>>>> As far as I can tell, the difference is conceptual. A "const array
>>>> of int" would mean that the array, as a whole, would be const. An
>>>> "array of const int" would mean the each element of the array would
>>>> be const. I'm unaware of any practical differences.
>>>
>>> 'const array' could be allowed to fill an otherwise awkward hole in
>>> the type system, so that every kind of type can have a const
>>> attribute.
>>
>> How is it awkward? What actual benefit would programmers get from
>> adding "const array"? What syntax would be used to specify a const
>> array? Could such a syntax be invented that avoids conflicting with the
>> existing syntax for an array of const elements?
>
> I'm not really advocating this. Someone posed a question as to how a const
> array can be meaningful, and these are some ideas.
>
>> Do we really need to
>> distinct ways of specifying that an array's elements are read-only?
(I meant "two", not "to".)
> Going back to my example:
>
> typedef int vector[4];
>
> vector A;
> const vector B = {...};
>
> Are the elements of vector const or non-const? See, it's not so obvious!
vector is a type. The elements of A are non-const. The elements of
B are const. Try writing "B[0] = 42;" and see what diagnostic you get.
It would be the same if you asked about the members of a const struct
rather than the elements of an array (though for slightly different
reasons).
I'm not 100% certain that a member of a const struct object is
*formally* considered to be "const" (it depends on the exact wording in
the standard, which I'm too lazy to check right now), but the effect is
the same.
>> I've been using C for a very long time, and until now I never even
>> noticed this "awkward hole".
>
> I notice it all the time. Because you are not allowed to have array types
> for expressions, to pass to functions and so on, there's some scene-shifting
> done by C to try and pretend they don't exist.
>
> As an example, what's the type of A here:
>
> void somefunction(int A[5]);
>
> and of A here:
>
> int A[5];
>
> which has exactly the same type-spec?
In the first case, A has type int*. In the second, A has type int[5].
I find this one of the more annoying features of C. I do not defend it;
I merely describe it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-25 11:42 -0700 |
| Message-ID | <lnbnvps12e.fsf@nuthaus.mib.org> |
| In reply to | #43565 |
"BartC" <bc@freeuk.com> writes:
[...]
> 'const array' could be allowed to fill an otherwise awkward hole in
> the type system, so that every kind of type can have a const
> attribute.
[...]
I forgot to mention: function types can't be "const" either.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-25 10:58 -0500 |
| Message-ID | <lje0nn$j6$1@dont-email.me> |
| In reply to | #43552 |
On 25-Apr-14 07:31, James Kuyper wrote: > On 04/25/2014 12:57 AM, Stephen Sprunk wrote: >> On 24-Apr-14 14:32, Keith Thompson wrote: >>> Really? I wouldn't expect that. If I had a read-only array, I'd >>> expect its elements to be read-only. >> >> That'd be an array of const int, not a const array of int. > > So, what does "const array of int" mean to you? If it were possible to > declare a const array of int, how would you describe the way in which it > differs from an ordinary array of int? > >> I think someone mentioned upthread that one can actually create a const >> array (rather than an array of const) using a typedef. I'm not sure how >> it could behave any differently from a non-const array, though. > > That is the question I'd like answered. I don't understand what people > think they mean by that term that makes it different from "array of > const int". As previously explained, arrays already seem to be effectively const, so adding an explicit "const" is a no-op. However, "const array of int" and "array of const int" read quite differently to me, and IMHO we shouldn't have two seemingly-different ways of saying the exact same thing. The latter better expresses both the intent and the behavior, so it should be the preferred form. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web