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 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-29 00:18 +0000 |
| Message-ID | <ljmr45$f33$1@speranza.aioe.org> |
| In reply to | #43779 |
Kaz Kylheku <kaz@kylheku.com> wrote: (snip, someone wrote) >>> "Pass by explicit/visible reference" requires that a dereferencing >>> operator be applied to the reference to designate the caller's object >>> from which the reference was obtained. (snip, then I wrote) >> So, the C [] operator is a visible dereference operator, but >> the Fortran () (dummy array subscript) is not? > Ah, but in the case of arrays being passed around as a pointer > to the first element, this operator is used everywhere: by the > caller and callee alike. > It is not an operator which is inserted only in the called function > specifically to dereference the parameter. > Arrays in fact look like "pass by invisible reference". > The invisibility comes from the implicit array-to-pointer decay, > and the way the array subscript works on the reference just as > well as on the array (so much so that all array subscripting > itself is defined that way). And further assisting the invisiblity > is that we can declare the function parameter using array syntax. > We call a function, giving the array as an argument: func(array). > In the function, we use the parameter as an array with subscripting, > and assignments to the element change the caller's array object. > It quacks almost like a duck, just with a slight goosey accent. And one way it can quack slightly different is if you change the local copy of the referece. Now, if you make the reference itself const, not the values it is refering to, then you pretty much have pass by reference. I think you can also make a Java argument final, in which case you also can't change the reference, but still change what it refers to. Java final is stronger than C const, as, I believe, you can't cast it away, and it is an error, not just a warning, to try to change one. >> But C is different from Fortran in the need for * (or [0]) >> on scalar arguments. > Or the non-scalar argument case of an array being passed > using a "pointer to array"! -- glen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-28 21:52 +0000 |
| Message-ID | <20140428144044.397@kylheku.com> |
| In reply to | #43740 |
On 2014-04-28, Ian Collins <ian-news@hotmail.com> wrote:
> Kaz Kylheku wrote:
>> In C with pointers to array (the "other" way to pass the string by
>> reference):
>>
>> void ptr2(char (*i)[5])
>> {
>> }
>
> But that isn't really passing by reference as you have to dereference i
> before using it as an array.
Since you have to take the address, and dereference the reference this could be
called "passing by visible reference". If you don't have to then, that is
"passing by transparent/invisible reference".
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-28 23:08 +0100 |
| Message-ID | <0.4179e610b3e63e2e8c33.20140428230839BST.87lhupyumw.fsf@bsb.me.uk> |
| In reply to | #43748 |
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2014-04-28, Ian Collins <ian-news@hotmail.com> wrote:
>> Kaz Kylheku wrote:
>>> In C with pointers to array (the "other" way to pass the string by
>>> reference):
>>>
>>> void ptr2(char (*i)[5])
>>> {
>>> }
>>
>> But that isn't really passing by reference as you have to dereference i
>> before using it as an array.
>
> Since you have to take the address, and dereference the reference this
> could be called "passing by visible reference". If you don't have to
> then, that is "passing by transparent/invisible reference".
You could also call it "passing a pointer by value". Do you object to
that way of talking about it? It seems to me less likely to confuse,
but there appears to be a widely-held view that passing something that
refers to something else must be called "pass *by* reference" -- despite
the fact that that phrase used to mean something else.
If I'm just being an old fogey -- clinging to a usage of language that
has been superseded -- I'll accept that, but please tell me what the new
term is for what Fortran does*.
(* In the absence of the relatively new VALUE attribute.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-28 22:31 +0000 |
| Message-ID | <20140428150945.155@kylheku.com> |
| In reply to | #43753 |
On 2014-04-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Kaz Kylheku <kaz@kylheku.com> writes:
>
>> On 2014-04-28, Ian Collins <ian-news@hotmail.com> wrote:
>>> Kaz Kylheku wrote:
>>>> In C with pointers to array (the "other" way to pass the string by
>>>> reference):
>>>>
>>>> void ptr2(char (*i)[5])
>>>> {
>>>> }
>>>
>>> But that isn't really passing by reference as you have to dereference i
>>> before using it as an array.
>>
>> Since you have to take the address, and dereference the reference this
>> could be called "passing by visible reference". If you don't have to
>> then, that is "passing by transparent/invisible reference".
>
> You could also call it "passing a pointer by value". Do you object to
> that way of talking about it?
No; I don't object with any multiple non-conflicting views of the same system
or situation but rather to the denial of any of those views.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-29 00:54 +0100 |
| Message-ID | <0.aba406164fd2c2731a04.20140429005422BST.878uqpypqp.fsf@bsb.me.uk> |
| In reply to | #43761 |
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2014-04-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Kaz Kylheku <kaz@kylheku.com> writes:
>>
>>> On 2014-04-28, Ian Collins <ian-news@hotmail.com> wrote:
>>>> Kaz Kylheku wrote:
>>>>> In C with pointers to array (the "other" way to pass the string by
>>>>> reference):
>>>>>
>>>>> void ptr2(char (*i)[5])
>>>>> {
>>>>> }
>>>>
>>>> But that isn't really passing by reference as you have to dereference i
>>>> before using it as an array.
>>>
>>> Since you have to take the address, and dereference the reference this
>>> could be called "passing by visible reference". If you don't have to
>>> then, that is "passing by transparent/invisible reference".
>>
>> You could also call it "passing a pointer by value". Do you object to
>> that way of talking about it?
>
> No; I don't object with any multiple non-conflicting views of the same system
> or situation but rather to the denial of any of those views.
Calling passing a pointer by value "pass by reference" conflicts with my
view of the situation that used to be called "pass by reference". I can
fix that by simply flipping "by" to "a" when talking with a member of
the C-has-pass-by-reference party, but it does not help others who may
not know your party affiliation.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-28 23:10 +0100 |
| Message-ID | <ilA7v.221108$hB4.65580@fx20.am4> |
| In reply to | #43725 |
"Ian Collins" <ian-news@hotmail.com> wrote in message
news:bs7srkFua2rU1@mid.individual.net...
> BartC wrote:
>>
>> If we're talking about C, then it doesn't /have/ formal
>> pass-by-reference,
>> but it /uses/ pass-by-reference extensively through explicit use of
>> pointers.
>
> You should spend some time with a statically typed language that does use
> pass by reference. That might help you understand the differences.
Good idea; just spent 30 minutes implementing the closest I have to
pass-by-reference on one of my static language compilers, so I can compare
what it does with your example.
> For example in C++:
>
> # cat x.cc
> void ptr( const char i[5] ) {}
>
> void ref( const char (&i)[5] ) {}
BTW your gratuitous use of 'const' is confusing matters here. (I've spent
half the thread saying that, but no-one believes me.)
> int main()
> {
> ptr("not 5 chars"); // Will decay to pointer.
> ref("not 5 chars"); // Must be correct type.
> }
Wasn't too sure either about the significance of the [5]; I expected ptr()
to work because it's passing by value (of the pointer to the string); and
ref() to fail (because it's passing by reference), although I don't know
what C++ does with constant strings).
What I think you're saying is that some obscure consequence of how
pass-by-reference works in C++ allows you to type-check a pointer to an
array. If you're implying that I don't understand that, then you're right!
I've done some tests in my own language, and the use of by-reference there
is far more straightforward and consistent. Use & on a formal parameter, and
you'd better pass it an l-value expression. A string constant isn't such an
expression.
So I understand how *I* want by-reference parameters to work, which might
have been be a good way of adding them to C. By-value parameter passing in
C is like this:
void charlie(double x) {
x = 23.03;
}
int main(void) {
double a=0.0;
charlie(a);
}
Change that to by-reference by:
(1) Turn the parameter type into a pointer
(2) Dereference the parameter in the body of the function
(3) Use the address-of operator (where needed) with the argument of the
call.
Which gives:
void charlie(double* x) {
*x = 23.03;
}
int main(void) {
double a=0.0;
charlie(&a);
}
Now charlie() can change the caller's value, which is exactly what we want.
Except we'd prefer to do it by simply writing:
void charlie(double &x) {
x = 23.03;
}
int main(void) {
double a=0.0;
charlie(a);
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-29 11:28 +1200 |
| Message-ID | <bs86g9Fua2rU3@mid.individual.net> |
| In reply to | #43754 |
BartC wrote:
>
>
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:bs7srkFua2rU1@mid.individual.net...
>> BartC wrote:
>>>
>>> If we're talking about C, then it doesn't /have/ formal
>>> pass-by-reference,
>>> but it /uses/ pass-by-reference extensively through explicit use of
>>> pointers.
>>
>> You should spend some time with a statically typed language that does use
>> pass by reference. That might help you understand the differences.
>
> Good idea; just spent 30 minutes implementing the closest I have to
> pass-by-reference on one of my static language compilers, so I can compare
> what it does with your example.
>
>> For example in C++:
>>
>> # cat x.cc
>> void ptr( const char i[5] ) {}
>>
>> void ref( const char (&i)[5] ) {}
>
> BTW your gratuitous use of 'const' is confusing matters here. (I've spent
> half the thread saying that, but no-one believes me.)
It isn't gratuitous, it is necessary. C++ had the good sense to make
string literals what they really are: const.
>> int main()
>> {
>> ptr("not 5 chars"); // Will decay to pointer.
>> ref("not 5 chars"); // Must be correct type.
>> }
>
> Wasn't too sure either about the significance of the [5]; I expected ptr()
> to work because it's passing by value (of the pointer to the string); and
> ref() to fail (because it's passing by reference), although I don't know
> what C++ does with constant strings).
>
> What I think you're saying is that some obscure consequence of how
> pass-by-reference works in C++ allows you to type-check a pointer to an
> array. If you're implying that I don't understand that, then you're right!
There's nothing obscure about it, the type passed to a reference
parameter has to match. "const char [12]" doesn't match "const char
[5]". Attempting to pass an object of type char to "void f( int& i )"
would also fail.
> I've done some tests in my own language, and the use of by-reference there
> is far more straightforward and consistent. Use & on a formal parameter, and
> you'd better pass it an l-value expression. A string constant isn't such an
> expression.
Exactly. C++ rules for passing by reference are straightforward and
consistent.
> So I understand how *I* want by-reference parameters to work, which might
> have been be a good way of adding them to C. By-value parameter passing in
> C is like this:
>
> void charlie(double x) {
> x = 23.03;
> }
>
> int main(void) {
> double a=0.0;
> charlie(a);
> }
>
> Change that to by-reference by:
>
> (1) Turn the parameter type into a pointer
> (2) Dereference the parameter in the body of the function
> (3) Use the address-of operator (where needed) with the argument of the
> call.
>
> Which gives:
>
> void charlie(double* x) {
> *x = 23.03;
> }
>
> int main(void) {
> double a=0.0;
> charlie(&a);
> }
>
> Now charlie() can change the caller's value, which is exactly what we want.
> Except we'd prefer to do it by simply writing:
>
> void charlie(double &x) {
> x = 23.03;
> }
>
> int main(void) {
> double a=0.0;
> charlie(a);
> }
Which is exactly how C++ does it! You really should look into C++ as
your base language, it looks to be a much better fit. Yes you can use
work arounds to make stuff work in C, but those kludges very often cost
you the ability to perform compile time type checking.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2014-04-27 06:31 +0000 |
| Message-ID | <lji88i$ga3$1@news.xmission.com> |
| In reply to | #43635 |
In article <20140426194123.529@kylheku.com>,
Kaz Kylheku <kaz@kylheku.com> wrote:
>On 2014-04-26, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <ln7g6crltv.fsf@nuthaus.mib.org>,
>> Keith Thompson <kst-u@mib.org> wrote:
>> ...
>>>In C as it is, you can't pass an array to a subroutine at all.
>>
>> (Pedantic, CLC-ish answer, which should make Kiki proud)
>>
>> Because C doesn't have "subroutines".
>
>The likely intended meaning is that C doesn't support passing arrays to
>functions, or returning arrays from functions.
1) Whooosh!!!
2) (But seriously folks...) But it does. In all senses that matter.
Only a Kikian (or one who is, like me in this thread, pretending to be so
for comedic effect) would argue otherwise.
3) Just to be clear, C supports passing arrays to functions and supports
returning arrays from functions - every bit as much as it supports
"subroutines". You can quote me on that.
--
The scent of awk programmers is a lot more attractive to women than
the scent of perl programmers.
(Mike Brennan, quoted in the "GAWK" manual)
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-26 12:27 +0100 |
| Message-ID | <eMM6v.334731$H82.155083@fx23.am4> |
| In reply to | #43591 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message
news:ljfurv$7tp$1@dont-email.me...
> On 04/25/2014 08:06 PM, Martin Shobe wrote:
>> ... To help do that I also told you something I thought it
>> wasn't. If that's "waffling" to you, so be it.
>
> Is there something you can do with a const array of int that you can't
> do with a array of const int? How about the other way around? It's easy
> to come up with answers to those questions if 'array' were replaced with
> 'pointer', but I have no idea what you think the answers would be for an
> array.
I was investigating the differences between const structs and const arrays,
and came across these puzzling results:
typedef struct {
const int x;
const int y;
const int z;
} cvector;
typedef struct {
int x;
int y;
int z;
} vector;
int main(void){
cvector a;
const cvector b;
vector c;
const vector d;
int e[3];
const int f[3];
memset(&a,0,sizeof(a)); // No warning ?
memset(&b,0,sizeof(b)); // Warning
memset(&c,0,sizeof(c)); // No warning
memset(&d,0,sizeof(d)); // Warning
memset(&e,0,sizeof(e)); // No warning
memset(&f,0,sizeof(f)); // No warning ?
}
This was compiled with gcc with default options.
The puzzling ones are the attempt to write to a (a struct of all-const
members), which gives no warning here, yet an attempt to assign to a does
so.
And the attempt to write to array f (an array of const int) gives no warning
either.
I understand this all depends on compiler and options used (probably with
enough options set, gcc can be made to reject anything). But with the /same/
set of options, one way to write to an array or struct is allowed, but
another isn't.
What's going on?
(This can interpreted as another dig at the alleged usefulness of 'const',
but it's not; I've lost interest in that argument.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-26 13:11 +0100 |
| Message-ID | <0.35e062d5b50f05f6f1a9.20140426131130BST.87fvl05lzh.fsf@bsb.me.uk> |
| In reply to | #43593 |
"BartC" <bc@freeuk.com> writes:
<snip>
> I was investigating the differences between const structs and const
> arrays, and came across these puzzling results:
>
> typedef struct {
> const int x;
> const int y;
> const int z;
> } cvector;
>
> typedef struct {
> int x;
> int y;
> int z;
> } vector;
>
> int main(void){
> cvector a;
> const cvector b;
> vector c;
> const vector d;
> int e[3];
> const int f[3];
>
> memset(&a,0,sizeof(a)); // No warning ?
> memset(&b,0,sizeof(b)); // Warning
> memset(&c,0,sizeof(c)); // No warning
> memset(&d,0,sizeof(d)); // Warning
> memset(&e,0,sizeof(e)); // No warning
> memset(&f,0,sizeof(f)); // No warning ?
> }
>
> This was compiled with gcc with default options.
>
> The puzzling ones are the attempt to write to a (a struct of all-const
> members), which gives no warning here, yet an attempt to assign to a
> does so.
>
> And the attempt to write to array f (an array of const int) gives no
> warning either.
>
> I understand this all depends on compiler and options used (probably
> with enough options set, gcc can be made to reject anything). But with
> the /same/ set of options, one way to write to an array or struct is
> allowed, but another isn't.
>
> What's going on?
The compiler is simply taking the easy option and obeying the minimal
rules of the language. In the two cases that puzzle you, the type of
the pointer 'target' is not const, so the pointers can be converted to
const void * (that memset wants) with no problem.
There are lots of things the compiler could help with. For example, a
compiler could tell you that you are in trouble after writing
cvector a;
const vector b;
because these are not initialised and you can now can't alter them
without invoking undefined behaviour.
Also, in the last case, it is more normal to simply pass f, rather than
&f, and in that case you would get a diagnostic.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-26 13:50 +0100 |
| Message-ID | <aZN6v.82805$vM2.27340@fx18.am4> |
| In reply to | #43596 |
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message news:0.35e062d5b50f05f6f1a9.20140426131130BST.87fvl05lzh.fsf@bsb.me.uk... > "BartC" <bc@freeuk.com> writes: >> int e[3]; >> const int f[3]; >> memset(&e,0,sizeof(e)); // No warning >> memset(&f,0,sizeof(f)); // No warning ? > Also, in the last case, it is more normal to simply pass f, rather than > &f, and in that case you would get a diagnostic. Yes, this was an oversight due to just copying the code for structs. Presumably, f has type 'pointer to const int', so it is easy to see that this pointer could be used to write to a const. But &f has type 'pointer to array of const int' so is not so obvious. (And which might finally be a way for const arrays to differ from arrays of consts, and to assert their usefulness: 'pointer to const array of int' is also a pointer with an obvious const target.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-26 11:26 -0700 |
| Message-ID | <ln38h0rlp8.fsf@nuthaus.mib.org> |
| In reply to | #43596 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> The compiler is simply taking the easy option and obeying the minimal
> rules of the language. In the two cases that puzzle you, the type of
> the pointer 'target' is not const, so the pointers can be converted to
> const void * (that memset wants) with no problem.
[...]
I think you meant "can be converted to (non-const) void*".
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-27 02:21 +0100 |
| Message-ID | <0.c377ff0be8f99c7290b2.20140427022156BST.874n1f5zyj.fsf@bsb.me.uk> |
| In reply to | #43603 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > [...] >> The compiler is simply taking the easy option and obeying the minimal >> rules of the language. In the two cases that puzzle you, the type of >> the pointer 'target' is not const, so the pointers can be converted to >> const void * (that memset wants) with no problem. > [...] > > I think you meant "can be converted to (non-const) void*". Yes, thanks. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2014-04-26 08:05 -0500 |
| Message-ID | <ljgavc$gof$1@dont-email.me> |
| In reply to | #43591 |
On 4/26/2014 4:39 AM, James Kuyper wrote: > On 04/25/2014 08:06 PM, Martin Shobe wrote: >> On 4/25/2014 2:10 PM, James Kuyper wrote: >>> On 04/25/2014 02:29 PM, Keith Thompson wrote: >>> >>>> If you think that "const array of int" is a distinct concept that should >>>> be expressible in C, I ask you to specify what it means and how it >>>> differs from "array of const int". >>> >>> I've already asked that question twice, and every response has ended up >>> waffling on the "how does it differ" question: >> >> I was trying to explain what I thought the difference between the two >> phrases was. > > You gave descriptions that contained different words in different > orders, but I couldn't figure out how they had actual meaningfully > different meanings. That could have been a failure on my part to > understand what you were saying, but for now I still don't understand > the distinction you were making. I don't know how to put it any more clearly. In the one case, the array as a whole is what's const, and in the other, it's the elements of the array that are const. >> ... To help do that I also told you something I thought it >> wasn't. If that's "waffling" to you, so be it. > > Is there something you can do with a const array of int that you can't > do with a array of const int? How about the other way around? It's easy > to come up with answers to those questions if 'array' were replaced with > 'pointer', but I have no idea what you think the answers would be for an > array. > Not that I know of. That doesn't mean there isn't a difference to the users of the phrase. That just means the difference isn't extensional. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-26 11:39 -0700 |
| Message-ID | <lny4ysq6jv.fsf@nuthaus.mib.org> |
| In reply to | #43599 |
Martin Shobe <martin.shobe@yahoo.com> writes:
> On 4/26/2014 4:39 AM, James Kuyper wrote:
[...]
> I don't know how to put it any more clearly. In the one case, the array
> as a whole is what's const, and in the other, it's the elements of the
> array that are const.
Isn't that circular? Perhaps it can't be put any more clearly
than that -- which implies, I think, that it's not a meaningful or
useful distinction.
[...]
>> Is there something you can do with a const array of int that you can't
>> do with a array of const int? How about the other way around? It's easy
>> to come up with answers to those questions if 'array' were replaced with
>> 'pointer', but I have no idea what you think the answers would be for an
>> array.
>
> Not that I know of. That doesn't mean there isn't a difference to the
> users of the phrase. That just means the difference isn't extensional.
Just in case I'm not the only one having trouble with the word
"extensional", I'll quote a definition from Wikipedia.
http://en.wikipedia.org/wiki/Extensional_definition
An extensional definition of a concept or term formulates its
meaning by specifying its extension, that is, every object that
falls under the definition of the concept or term in question.
For example, an extensional definition of the term "nation of
the world" might be given by listing all of the nations of the
world, or by giving some other means of recognizing the members
of the corresponding class.
I suggest that if there's no definition of "const array" vs. "array
of const elements" that lets us distinguish between them, then it's
neither a useful distinction nor a meaningful phrase.
I can imagine a C-like language that makes the distinction, perhaps
in a way that has implications for type compatibility. But I don't
think such a language would be any more expressive than C, and I
don't think it could be made compatible with C other than by adding
a new keyword like _Constarray, since any reasonable syntax for
defining a const array already defines an array of const elements.
Though it's still entirely possible that I'm missing something.
--
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 | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2014-04-26 16:27 -0500 |
| Message-ID | <ljh8cj$ohd$1@dont-email.me> |
| In reply to | #43604 |
On 4/26/2014 1:39 PM, Keith Thompson wrote: > Martin Shobe <martin.shobe@yahoo.com> writes: >> On 4/26/2014 4:39 AM, James Kuyper wrote: > [...] >> I don't know how to put it any more clearly. In the one case, the array >> as a whole is what's const, and in the other, it's the elements of the >> array that are const. > > Isn't that circular? Perhaps it can't be put any more clearly > than that -- which implies, I think, that it's not a meaningful or > useful distinction. I haven't expressed an opinion about how "meaningful", "useful", or "real" the difference is. I've just been trying (and failing) to explain it. Anyway, it's reached the point where it's not worth it to me to try any longer. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Ian Zimmerman <itz@buug.org> |
|---|---|
| Date | 2014-04-27 10:46 -0700 |
| Message-ID | <20140427104605.55a9610d.itz@buug.org> |
| In reply to | #43604 |
On Sat, 26 Apr 2014 11:39:16 -0700 Keith Thompson <kst-u@mib.org> wrote: > Just in case I'm not the only one having trouble with the word > "extensional", I'll quote a definition from Wikipedia. > http://en.wikipedia.org/wiki/Extensional_definition Wikipedia isn't as clear as it could be on this point. The best example I have seen was, I think, in some book by W. V. O. Quine, though he might have cribbed it from somewhere: Is there a difference between the morning star and the evening star? Answer: extensionally, there isn't. Intensionally, there is. -- Please *no* private copies of mailing list or newsgroup messages. gpg public key: 2048R/984A8AE4 fingerprint: 7953 ADA1 0E8E AB57 FB79 FFD2 360A 88B2 984A 8AE4 Funny pic: http://bit.ly/ZNE2MX
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2014-04-26 22:46 -0400 |
| Message-ID | <ljhr2r$vus$1@dont-email.me> |
| In reply to | #43599 |
On 04/26/2014 09:05 AM, Martin Shobe wrote: > On 4/26/2014 4:39 AM, James Kuyper wrote: ... >> You gave descriptions that contained different words in different >> orders, but I couldn't figure out how they had actual meaningfully >> different meanings. That could have been a failure on my part to >> understand what you were saying, but for now I still don't understand >> the distinction you were making. > > I don't know how to put it any more clearly. In the one case, the array > as a whole is what's const, and in the other, it's the elements of the > array that are const. No, that doesn't help. Without a specific consequence that follows from an array being const, that wouldn't follow from it's elements being const (or vice versa), it's just words being rearranged in pleasing patterns. I was prepared to hear that, if it an array's elements are not const, but only the array itself, then those element can be written to. That interpretation would make a "const array of int" indistinguishable from an "array of int". Given the history that's been given for "B", "C"'s ancestor, that would even make sense - the thing that was changeable in B is, in C, only changeable for pointers, not arrays, so all C arrays could b e considered 'const' in that sense. But you've made no such assertions. ... >> Is there something you can do with a const array of int that you can't >> do with a array of const int? How about the other way around? It's easy >> to come up with answers to those questions if 'array' were replaced with >> 'pointer', but I have no idea what you think the answers would be for an >> array. >> > > Not that I know of. That doesn't mean there isn't a difference to the > users of the phrase. That just means the difference isn't extensional. I've looked up the term "extensional" <http://en.wikipedia.org/wiki/Extensional>, which I've not seen used with this meaning before. The definitions I found left me just as confused about what you meant as I was before I read that definition. I can understand the examples given in that article - I don't see the applicability in this context. That article explains that, if Lois Lane believes that Clark Kent will be investigating a given case with her, then it is not true that she believes Superman will be investigating the case with her, because she's unaware that they're the same person. That's because statements about what her beliefs are, are inherently intensional. So, if someone believes that a const array of int is in some way different from an array of const int, the are intensionally different, even if that person is mistaken? If that's what you're talking about, then I don't see any point in worrying about intensional differences; only the extensional ones really matter to me. If there are intensional difference without corresponding extensional differences, that is an issue of great importance to those, such as teachers, whose job it is to correct that discrepancy, but even for them, the intensional difference is important only in a very negative sense. Since I don't remember having ever heard of these terms before, it could be I'm totally misunderstanding the extensional/intensional distinction, and therefore radically misusing it in the preceding paragraph. If so, I'd a appreciate a better explanation of it. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-27 10:08 +0100 |
| Message-ID | <AO37v.273841$Kx7.192494@fx26.am4> |
| In reply to | #43637 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:ljhr2r$vus$1@dont-email.me... > On 04/26/2014 09:05 AM, Martin Shobe wrote: >> On 4/26/2014 4:39 AM, James Kuyper wrote: > ... >>> You gave descriptions that contained different words in different >>> orders, but I couldn't figure out how they had actual meaningfully >>> different meanings. That could have been a failure on my part to >>> understand what you were saying, but for now I still don't understand >>> the distinction you were making. >> >> I don't know how to put it any more clearly. In the one case, the array >> as a whole is what's const, and in the other, it's the elements of the >> array that are const. > > No, that doesn't help. Without a specific consequence that follows from > an array being const, that wouldn't follow from it's elements being > const (or vice versa), it's just words being rearranged in pleasing > patterns. I've given at least one possible example elsewhere. Where A is 'const int A[]', then A as an expression as type 'pointer to const int' while &A as an expression has type 'pointer to array of const int'. This was sufficient to give a different diagnostic (when being passed as a void* parameter) on one well-known compiler. Not an official difference, but different behaviour nonetheless. Having 'pointer to const array of int' would likely have produced the same diagnostic as 'pointer to const int' (through making it easier to detect that a pointer has a const target, compared with a possible 'pointer to array of array of .... array of const T'). > I was prepared to hear that, if it an array's elements are not const, > but only the array itself, then those element can be written to. That > interpretation would make a "const array of int" indistinguishable from > an "array of int". Would the behaviour of such an array be different from that of a const struct with all-const members? What about a const struct with all non-const members, compared with a non-const struct with all-const members? My point (which I've mentioned at least once elsewhere) is that language allows structs to have const outside, (all) inside, or both (or none), which could have allowed the same for arrays, with similar semantics. -- Bartc Given the history that's been given for "B", "C"'s > ancestor, that would even make sense - the thing that was changeable in > B is, in C, only changeable for pointers, not arrays, so all C arrays > could b e considered 'const' in that sense. But you've made no such > assertions. > > ... >>> Is there something you can do with a const array of int that you can't >>> do with a array of const int? How about the other way around? It's easy >>> to come up with answers to those questions if 'array' were replaced with >>> 'pointer', but I have no idea what you think the answers would be for an >>> array. >>> >> >> Not that I know of. That doesn't mean there isn't a difference to the >> users of the phrase. That just means the difference isn't extensional. > > I've looked up the term "extensional" > <http://en.wikipedia.org/wiki/Extensional>, which I've not seen used > with this meaning before. The definitions I found left me just as > confused about what you meant as I was before I read that definition. I > can understand the examples given in that article - I don't see the > applicability in this context. That article explains that, if Lois Lane > believes that Clark Kent will be investigating a given case with her, > then it is not true that she believes Superman will be investigating the > case with her, because she's unaware that they're the same person. > That's because statements about what her beliefs are, are inherently > intensional. > > So, if someone believes that a const array of int is in some way > different from an array of const int, the are intensionally different, > even if that person is mistaken? If that's what you're talking about, > then I don't see any point in worrying about intensional differences; > only the extensional ones really matter to me. If there are intensional > difference without corresponding extensional differences, that is an > issue of great importance to those, such as teachers, whose job it is to > correct that discrepancy, but even for them, the intensional difference > is important only in a very negative sense. > > Since I don't remember having ever heard of these terms before, it could > be I'm totally misunderstanding the extensional/intensional distinction, > and therefore radically misusing it in the preceding paragraph. If so, > I'd a appreciate a better explanation of it. > -- > James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-27 07:35 -0700 |
| Message-ID | <lnlhuqrgb5.fsf@nuthaus.mib.org> |
| In reply to | #43641 |
"BartC" <bc@freeuk.com> writes:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:ljhr2r$vus$1@dont-email.me...
>> On 04/26/2014 09:05 AM, Martin Shobe wrote:
>>> On 4/26/2014 4:39 AM, James Kuyper wrote:
>> ...
>>>> You gave descriptions that contained different words in different
>>>> orders, but I couldn't figure out how they had actual meaningfully
>>>> different meanings. That could have been a failure on my part to
>>>> understand what you were saying, but for now I still don't understand
>>>> the distinction you were making.
>>>
>>> I don't know how to put it any more clearly. In the one case, the array
>>> as a whole is what's const, and in the other, it's the elements of the
>>> array that are const.
>>
>> No, that doesn't help. Without a specific consequence that follows from
>> an array being const, that wouldn't follow from it's elements being
>> const (or vice versa), it's just words being rearranged in pleasing
>> patterns.
>
> I've given at least one possible example elsewhere.
>
> Where A is 'const int A[]', then A as an expression as type 'pointer to
> const int' while &A as an expression has type 'pointer to array of const
> int'.
Yes, A is an array of const int.
> This was sufficient to give a different diagnostic (when being passed as a
> void* parameter) on one well-known compiler. Not an official difference, but
> different behaviour nonetheless.
Sorry, I'm confused. We're talking about the difference between an
array of const int and a (hypothetical) const array of int. There is no
const array of int in your example. What "different diagnostic" are you
referring to?
[...]
--
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]
Page 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web