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 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-28 13:23 +0100 |
| Message-ID | <hLr7v.164833$sa2.43402@fx33.am4> |
| In reply to | #43708 |
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message news:0.d9dc063c172708b96ce8.20140428125517BST.87r44h1xei.fsf@bsb.me.uk... > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> <snip, I wrote> >>>> Passing a pointer by value isn't much different, other than name, >>>> from pass by reference. >> >>> I suppose it depends on what you are used to. In the "olden days" (the >>> 70 and 80) when reading the reference manual for one of the seemingly >>> thousands of new programming languages that were popping up at the time, >>> if I read the phrase "arguments are passed by reference" or was told >>> that some syntax caused a argument to be "passed by reference", I would >>> assume that I need do nothing special in either the call or the function >>> body to get this effect. In C, I must arrange for the pointer to >>> passed, and I must pepper the function body with *s to refer to the >>> referenced object. >> >> For arrays, C makes it look pretty close, especially if you >> declare s[] instead of *s. (And as long as you don't change s.) > > See my reply to BartC: calling this pass by reference just complicates > the description of a language that has enough special cases already! > >> For scalars, yes, you put *s all over. Is there a better way? > > Better in what sense? Languages that actually have pass by reference > make it simpler, but the whole idea is in disrepute, so you might be > asking about ways to make a bad thing badder. 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. In which case he might mean a better way of doing the latter. As for being in disrepute, it seems unlikely to me that modern languages are all embracing pass-by-value exclusively. They will use pass-by-reference or equivalent behind the scenes, because it's more efficient for non-primitive types, but they might also introduce restrictions such as immutability to avoid this causing too many unexpected problems. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-28 13:47 +0100 |
| Message-ID | <0.dfb52f6af266482f9507.20140428134734BST.87iopt1uzd.fsf@bsb.me.uk> |
| In reply to | #43711 |
"BartC" <bc@freeuk.com> writes:
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.d9dc063c172708b96ce8.20140428125517BST.87r44h1xei.fsf@bsb.me.uk...
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> <snip, I wrote>
>>>>> Passing a pointer by value isn't much different, other than name,
>>>>> from pass by reference.
>>>
>>>> I suppose it depends on what you are used to. In the "olden days" (the
>>>> 70 and 80) when reading the reference manual for one of the seemingly
>>>> thousands of new programming languages that were popping up at the time,
>>>> if I read the phrase "arguments are passed by reference" or was told
>>>> that some syntax caused a argument to be "passed by reference", I would
>>>> assume that I need do nothing special in either the call or the function
>>>> body to get this effect. In C, I must arrange for the pointer to
>>>> passed, and I must pepper the function body with *s to refer to the
>>>> referenced object.
>>>
>>> For arrays, C makes it look pretty close, especially if you
>>> declare s[] instead of *s. (And as long as you don't change s.)
>>
>> See my reply to BartC: calling this pass by reference just complicates
>> the description of a language that has enough special cases already!
>>
>>> For scalars, yes, you put *s all over. Is there a better way?
>>
>> Better in what sense? Languages that actually have pass by reference
>> make it simpler, but the whole idea is in disrepute, so you might be
>> asking about ways to make a bad thing badder.
>
> 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.
... which are passed by value. I think you are keen to use the term
because it suits something about the way you think about programming
languages. For me, borrowing a phrase with a specific meaning ("pass by
reference") and using with a rather vague modifier ("uses") just makes a
mess. Do you object to the simple claim the C does not pass any
function arguments by reference?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-28 06:01 -0700 |
| Message-ID | <407cb120-ad29-4d8f-a66a-8af9c7857c58@googlegroups.com> |
| In reply to | #43711 |
On Monday, April 28, 2014 1:23:15 PM UTC+1, Bart wrote:
>
> As for being in disrepute, it seems unlikely to me that modern languages are
> all embracing pass-by-value exclusively. They will use pass-by-reference or
> equivalent behind the scenes, because it's more efficient for non-primitive
> types, but they might also introduce restrictions such as immutability to
> avoid this causing too many unexpected problems.
>
So called closures are getting popular.
This works along the lines of
function foo
{
variable foo_scope =0;
function bar
{
foo_scope = 42;
}
callsomethingthattakesafunction(bar);
/* foo_cope now 42 */
}
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-29 08:43 +1200 |
| Message-ID | <bs7srkFua2rU1@mid.individual.net> |
| In reply to | #43711 |
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.
For example in C++:
# cat x.cc
void ptr( const char i[5] ) {}
void ref( const char (&i)[5] ) {}
int main()
{
ptr("not 5 chars"); // Will decay to pointer.
ref("not 5 chars"); // Must be correct type.
}
# CC x.cc
"x.cc", line 8: Error: Formal argument i of type const char(&)[5] in
call to ref(const char(&)[5]) is being passed const char[12].
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-28 21:08 +0000 |
| Message-ID | <20140428135713.835@kylheku.com> |
| In reply to | #43725 |
On 2014-04-28, Ian Collins <ian-news@hotmail.com> wrote:
> 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.
I don't see any real misunderstanding in the above paragraph.
> For example in C++:
>
> # cat x.cc
> void ptr( const char i[5] ) {}
>
> void ref( const char (&i)[5] ) {}
>
> int main()
> {
> ptr("not 5 chars"); // Will decay to pointer.
> ref("not 5 chars"); // Must be correct type.
> }
This is apples and oranges: pointer to element, versus reference to array.
In C with pointers to array (the "other" way to pass the string by
reference):
void ptr2(char (*i)[5])
{
}
int main(void)
{
ptr2(&"abcd"); /* okay */
ptr2(&"abcde"); /* type mismatch */
return 0;
}
Hmm, never address-of on a string literal before. GCC likes it as a C90 compiler
(with -Wall -W -ansi -pedantic); I can't think of a reason why it wouldn't be
allowed.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-04-29 09:32 +1200 |
| Message-ID | <bs7vmgFua2rU2@mid.individual.net> |
| In reply to | #43731 |
Kaz Kylheku wrote:
> On 2014-04-28, Ian Collins <ian-news@hotmail.com> wrote:
>> 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.
>
> I don't see any real misunderstanding in the above paragraph.
>
>> For example in C++:
>>
>> # cat x.cc
>> void ptr( const char i[5] ) {}
>>
>> void ref( const char (&i)[5] ) {}
>>
>> int main()
>> {
>> ptr("not 5 chars"); // Will decay to pointer.
>> ref("not 5 chars"); // Must be correct type.
>> }
>
> This is apples and oranges: pointer to element, versus reference to array.
The point was to illustrate passing an array by reference compare to
what some claim is passing an array by reference (through the pointer to
it's first element) in C.
> 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.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-28 22:41 +0100 |
| Message-ID | <0.b0b84710755fd4ad0fc9.20140428224121BST.87r44hyvwe.fsf@bsb.me.uk> |
| In reply to | #43740 |
Ian Collins <ian-news@hotmail.com> writes:
> Kaz Kylheku wrote:
<snip>
>> 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.
This isn't pass by reference because an assignment to i, inside ptr2,
will not alter the object (if there was one) used as an argument in the
caller!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-28 22:00 +0000 |
| Message-ID | <20140428145713.974@kylheku.com> |
| In reply to | #43744 |
On 2014-04-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> Kaz Kylheku wrote:
><snip>
>>> 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.
>
> This isn't pass by reference because an assignment to i, inside ptr2,
> will not alter the object (if there was one) used as an argument in the
> caller!
Assignment to i resulting in changing a variable in the caller,
is a feature of "pass by transparent/invisible reference".
"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.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-28 23:18 +0100 |
| Message-ID | <0.5984a1ef4a744c952883.20140428231858BST.87eh0hyu5p.fsf@bsb.me.uk> |
| In reply to | #43751 |
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2014-04-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> Kaz Kylheku wrote:
>><snip>
>>>> 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.
>>
>> This isn't pass by reference because an assignment to i, inside ptr2,
>> will not alter the object (if there was one) used as an argument in the
>> caller!
>
> Assignment to i resulting in changing a variable in the caller,
> is a feature of "pass by transparent/invisible reference".
Did you just make that up or is it now a widely used term? I do like
to try to keep up if I can.
> "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.
No more than any assignment does. Some compilers do indeed generate an
address and de-reference it, but they don't have to. It is not
required in all cases. Fortran compilers used to be very good at
spotting aliasing and (in effect) exchanging the assignment to the
parameter for an assignment to the argument.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-28 15:43 -0700 |
| Message-ID | <87476f3b-38ac-4488-b4f4-367fd65cf58d@googlegroups.com> |
| In reply to | #43756 |
On Monday, April 28, 2014 11:18:58 PM UTC+1, Ben Bacarisse wrote: > > No more than any assignment does. Some compilers do indeed generate an > address and de-reference it, but they don't have to. It is not > required in all cases. Fortran compilers used to be very good at > spotting aliasing and (in effect) exchanging the assignment to the > parameter for an assignment to the argument. > Exactly. Fortran compilers also don't need to worry about pointer aliasing. But whilst its superbly efficient, it's also a lot harder to keep track of which variables are being set where, and there's no sort of hierarchy or grouping such as structures can impose. So it's less flexible, less easy to write programs whose main objective is data manipulation rather than calculations. You interface Fortran with C by passing pointers, however. A C function that is callable from Fortran takes pointers as parameters, a Fortran function callable from C is passed pointers.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-28 23:23 +0000 |
| Message-ID | <ljmnsl$8rb$1@speranza.aioe.org> |
| In reply to | #43763 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: (snip on call by reference and Fortran) > You interface Fortran with C by passing pointers, however. A C function > that is callable from Fortran takes pointers as parameters, a Fortran > function callable from C is passed pointers. Actually, Fortran now has the VALUE attribute, and so can also do call by value, when needed. It isn't the default, though. With the C interoprability feature now in Fortran, you can easily call between Fortran and C. If you pass an argument, and don't use the VALUE attribute, then a pointer is passed. You can also directly pass a TYPE(C_PTR) or the return value of C_LOC() by value to a called C function. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-28 22:47 +0000 |
| Message-ID | <20140428153226.858@kylheku.com> |
| In reply to | #43756 |
On 2014-04-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Kaz Kylheku <kaz@kylheku.com> writes:
>
>> On 2014-04-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>
>>>> Kaz Kylheku wrote:
>>><snip>
>>>>> 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.
>>>
>>> This isn't pass by reference because an assignment to i, inside ptr2,
>>> will not alter the object (if there was one) used as an argument in the
>>> caller!
>>
>> Assignment to i resulting in changing a variable in the caller,
>> is a feature of "pass by transparent/invisible reference".
>
> Did you just make that up or is it now a widely used term? I do like
> to try to keep up if I can.
I made it up. I didn't make up "transparent", "invisible" or "reference" of
course and aren't using them in any non-obvious way.
>> "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.
>
> No more than any assignment does.
Yes; and that is because there actually isn't any special "pass by"
data flow that is for functions only. Reducing an expression to a value
and using it to initialize a newly instantiated variable in a new function
invocation is a data flow. Assignment is another example of a data flow.
Both of these can be regarded as "passing" something.
Any time in C a reference to an object moves from one place in the program
graph to another, we use a value to represent that data flow, and have to
manually insert operators to source that kind of flow, and to recover the
referenced value at various "sinks" reached by that value.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-28 23:17 +0000 |
| Message-ID | <ljmnic$89u$1@speranza.aioe.org> |
| In reply to | #43756 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: (snip) > No more than any assignment does. Some compilers do indeed generate an > address and de-reference it, but they don't have to. It is not > required in all cases. Fortran compilers used to be very good at > spotting aliasing and (in effect) exchanging the assignment to the > parameter for an assignment to the argument. I am not so sure what that means, but Fortran has much stricter aliasing rules than C. For one, Fortran doesn't require call by reference, but also allows for call by value result (also known as copy-in/copy-out). The difference is very obvious in some aliasing cases. I have known Fortran compilers where the addresses of the arguments were passed, and the called routine copied the values in at the beginning, and copied them back before returning. On some machines, access to local variables is much faster than the indirect addressing to access through a reference. Though the actual gain depends on how often it is accessed. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-29 01:18 +0100 |
| Message-ID | <0.0afae8b0f55afa8aeaad.20140429011816BST.871twhyomv.fsf@bsb.me.uk> |
| In reply to | #43772 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > > (snip) > >> No more than any assignment does. Some compilers do indeed generate an >> address and de-reference it, but they don't have to. It is not >> required in all cases. Fortran compilers used to be very good at >> spotting aliasing and (in effect) exchanging the assignment to the >> parameter for an assignment to the argument. > > I am not so sure what that means, but Fortran has much stricter > aliasing rules than C. My point was that when a Fortran compiler is using call by reference, it is not required to pass a pointer and then dereference it. That was the claim Kaz made that I was replying to. In a fragment like this: J = 99 CALL T(J) ... SUBROUTINE T(I) I = 42 END the compiler can generate the same code (modulo the constant) for the assignment to I as it does for the assignment to J. Some compilers might pass an address then dereference it, but they are not required to do that in all situations. My remark "no more than any assignment does" is just a nod to the fact that any assignment implicitly involves an indirect access, but there need be no extra work simply because of the argument passing semantics. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-29 00:31 +0000 |
| Message-ID | <20140428172735.291@kylheku.com> |
| In reply to | #43790 |
On 2014-04-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>> (snip)
>>
>>> No more than any assignment does. Some compilers do indeed generate an
>>> address and de-reference it, but they don't have to. It is not
>>> required in all cases. Fortran compilers used to be very good at
>>> spotting aliasing and (in effect) exchanging the assignment to the
>>> parameter for an assignment to the argument.
>>
>> I am not so sure what that means, but Fortran has much stricter
>> aliasing rules than C.
>
> My point was that when a Fortran compiler is using call by reference, it
> is not required to pass a pointer and then dereference it. That was the
> claim Kaz made that I was replying to. In a fragment like this:
>
> J = 99
> CALL T(J)
> ...
> SUBROUTINE T(I)
> I = 42
> END
>
> the compiler can generate the same code (modulo the constant) for the
> assignment to I as it does for the assignment to J. Some compilers
> might pass an address then dereference it, but they are not required to
> do that in all situations.
How about:
inline assign_42(int *i)
{
*i = 42;
}
assign_42(&x); /* generates the same code as x = 42: no pointer */
If T is an external function in a separately compiled module,
I don't see how Fortran can achieve it without a reference datum
being passed indicating the location of I.
(Or worse: call-by-name thunk or its ilk.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-29 01:58 +0100 |
| Message-ID | <0.85035c67accfe11b5007.20140429015837BST.87r44hx876.fsf@bsb.me.uk> |
| In reply to | #43793 |
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2014-04-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>
>>> (snip)
>>>
>>>> No more than any assignment does. Some compilers do indeed generate an
>>>> address and de-reference it, but they don't have to. It is not
>>>> required in all cases. Fortran compilers used to be very good at
>>>> spotting aliasing and (in effect) exchanging the assignment to the
>>>> parameter for an assignment to the argument.
>>>
>>> I am not so sure what that means, but Fortran has much stricter
>>> aliasing rules than C.
>>
>> My point was that when a Fortran compiler is using call by reference, it
>> is not required to pass a pointer and then dereference it. That was the
>> claim Kaz made that I was replying to. In a fragment like this:
>>
>> J = 99
>> CALL T(J)
>> ...
>> SUBROUTINE T(I)
>> I = 42
>> END
>>
>> the compiler can generate the same code (modulo the constant) for the
>> assignment to I as it does for the assignment to J. Some compilers
>> might pass an address then dereference it, but they are not required to
>> do that in all situations.
>
> How about:
>
> inline assign_42(int *i)
> {
> *i = 42;
> }
>
> assign_42(&x); /* generates the same code as x = 42: no pointer */
Yes, and even when the function is not inline. Some compilers are very
clever.
> If T is an external function in a separately compiled module,
> I don't see how Fortran can achieve it without a reference datum
> being passed indicating the location of I.
> (Or worse: call-by-name thunk or its ilk.)
Neither can I (thought I would never second guess some clever linker
optimisation, especially given old Fortran's non-support of recursion).
I think we agree on the technicalities. Neither C nor Fortran require
passing an explicit pointer (even when it's explicit in the C code) and
there are situations in which neither of us can think of any reasonable
alternative for either language.
Trying to characterise a high-level language facility by what is
operationally required is, to my mind, unhelpful.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-29 01:13 +0000 |
| Message-ID | <20140428180307.117@kylheku.com> |
| In reply to | #43794 |
On 2014-04-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > Trying to characterise a high-level language facility by what is > operationally required is, to my mind, unhelpful. What's the difference between that and using an abstract machine model which can be optimized? If we are passing by reference, a reference (whatever that is) is operationally required; that is fine, isn't it?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-29 03:19 +0100 |
| Message-ID | <0.3ce501fc5ffd53f1c1f1.20140429031911BST.87k3a8yj1c.fsf@bsb.me.uk> |
| In reply to | #43795 |
Kaz Kylheku <kaz@kylheku.com> writes: > On 2014-04-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> Trying to characterise a high-level language facility by what is >> operationally required is, to my mind, unhelpful. > > What's the difference between that and using an abstract machine model > which can be optimized? > > If we are passing by reference, a reference (whatever that is) is > operationally required; that is fine, isn't it? Yes, that's fine, but I don't think that was ever in doubt. That passing by reference requires, in some abstract models, some form of reference seems so uncontroversial that I can only assume that what you said at some point seemed to me to be more than that. Otherwise, I can't imagine why I commented. Anyway, I prefer to agree on this point than to go back and try see why I disagreed. On the matter of terminology, I am not persuaded that simply passing a pointer should be called pass by reference. I realise that you won't be persuaded, so we can just agree to differ. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-29 03:31 +0000 |
| Message-ID | <ljn6do$4bj$1@speranza.aioe.org> |
| In reply to | #43797 |
Stefan Ram <ram@zedat.fu-berlin.de> wrote: > It always refers to the /argument expression/. When the > argument value already is an address of an object o, as in > f( &o ) > , then pass-by-reference would require a reference to »&o« > (not to »o«), because the argument expression is »&o« and > not »o«. C only has pass-by-value in function calls. Also > in »f( &o )«, the /value/ of »&o« is passed. > One can emulate some aspects of »call by reference« and > »call by name« using macros in C. Call by name would be pretty hard just using macros. As far as I know, you need actual callable functions to do it. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-29 04:21 +0000 |
| Message-ID | <20140428211415.679@kylheku.com> |
| In reply to | #43797 |
On 2014-04-29, Stefan Ram <ram@zedat.fu-berlin.de> wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>On the matter of terminology, I am not persuaded that simply passing a >>pointer should be called pass by reference. I realise that you won't be >>persuaded, so we can just agree to differ. > > It always refers to the /argument expression/. When the > argument value already is an address of an object o, as in > > f( &o ) > > , then pass-by-reference would require a reference to »&o« > (not to »o«), because the argument expression is »&o« and > not »o«. C only has pass-by-value in function calls. Also > in »f( &o )«, the /value/ of »&o« is passed. We can easily talk, informally, about o being passed by reference (not &o, of course). The variable o is the important value, and & is just a piece of "C fluff" to get the called function to be able to update o.
[toc] | [prev] | [next] | [standalone]
Page 8 of 14 — ← Prev page 1 … 6 7 [8] 9 10 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web