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 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-27 02:42 +0000 |
| Message-ID | <20140426194123.529@kylheku.com> |
| In reply to | #43608 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard <rgrdev_@gmail.com> |
|---|---|
| Date | 2014-04-27 04:45 +0200 |
| Message-ID | <8761lv7anv.fsf@gmail.com> |
| In reply to | #43635 |
Kaz Kylheku <kaz@kylheku.com> writes: > 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. Of course you can pass an array ... the fact its not copied is neither here nor there. A pointer to the first element of the array is "the array"..... So passing the pointer is passing the array.... -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2014-04-27 14:13 -0500 |
| Message-ID | <ljjkse$shn$2@dont-email.me> |
| In reply to | #43636 |
On 26-Apr-14 21:45, Richard wrote: > Kaz Kylheku <kaz@kylheku.com> writes: >> The likely intended meaning is that C doesn't support passing >> arrays to functions, or returning arrays from functions. > > Of course you can pass an array ... the fact its not copied is > neither here nor there. You can try to pass an array, but in fact it decays to a pointer. > A pointer to the first element of the array is "the array"..... Try telling that to sizeof. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-27 20:11 +0000 |
| Message-ID | <ljjoa5$q25$1@speranza.aioe.org> |
| In reply to | #43669 |
Stephen Sprunk <stephen@sprunk.org> wrote: (snip) >> Of course you can pass an array ... the fact its not copied is >> neither here nor there. > You can try to pass an array, but in fact it decays to a pointer. Unless it is inside a struct, in which case it can be passed by value, along with the rest of the struct. Passing a pointer by value isn't much different, other than name, from pass by reference. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-28 03:22 +0100 |
| Message-ID | <0.8880f72dbfb6b4376648.20140428032221BST.87fvky2nxe.fsf@bsb.me.uk> |
| In reply to | #43677 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: <snip> > 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. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-28 10:00 +0100 |
| Message-ID | <sNo7v.205617$lM4.137382@fx34.am4> |
| In reply to | #43694 |
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message news:0.8880f72dbfb6b4376648.20140428032221BST.87fvky2nxe.fsf@bsb.me.uk... > glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > <snip> >> 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. > With function names and arrays, these are effectively passed by reference in C without needing to use & in the caller or * in the callee (when using () or [] operators). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-28 11:24 +0100 |
| Message-ID | <0.7baf4480859251e4b3b9.20140428112412BST.87a9b53g6r.fsf@bsb.me.uk> |
| In reply to | #43700 |
"BartC" <bc@freeuk.com> writes: > "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message > news:0.8880f72dbfb6b4376648.20140428032221BST.87fvky2nxe.fsf@bsb.me.uk... >> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: >> <snip> >>> 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. > > With function names and arrays, these are effectively passed by > reference in C without needing to use & in the caller or * in the > callee (when using () or [] operators). Yes, but you get to chose how you talk about this particular case. Does C have pass by reference in some very limited situations (where we pretend that () is not an operator on function pointers, and that [] is not a shorthand for * with arithmetic) or do you say that C has a single, simple, method of passing arguments but that it has special rules for arrays and function that apply in lots of other situations, not just in function calls? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-28 12:30 +0000 |
| Message-ID | <ljlhkk$r4g$1@speranza.aioe.org> |
| In reply to | #43703 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
(snip, someone wrote)
>> With function names and arrays, these are effectively passed by
>> reference in C without needing to use & in the caller or * in the
>> callee (when using () or [] operators).
> Yes, but you get to chose how you talk about this particular case.
> Does C have pass by reference in some very limited situations (where we
> pretend that () is not an operator on function pointers, and that [] is
> not a shorthand for * with arithmetic) or do you say that C has a
> single, simple, method of passing arguments but that it has special
> rules for arrays and function that apply in lots of other situations,
> not just in function calls?
As in the previous post, as long as you don't change the pointer, the
effect is as it would be with call by reference. But only with call
by value can you change the reference in the called routine.
int f(int x[]) {
int a[10];
x[3]=3;
x=a;
x[3]=3;
return x[3];
}
or something similar with function pointers.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-28 13:58 +0100 |
| Message-ID | <0.04a29f85317e2f0cf923.20140428135858BST.87d2g11ugd.fsf@bsb.me.uk> |
| In reply to | #43712 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > > (snip, someone wrote) >>> With function names and arrays, these are effectively passed by >>> reference in C without needing to use & in the caller or * in the >>> callee (when using () or [] operators). > >> Yes, but you get to chose how you talk about this particular case. >> Does C have pass by reference in some very limited situations (where we >> pretend that () is not an operator on function pointers, and that [] is >> not a shorthand for * with arithmetic) or do you say that C has a >> single, simple, method of passing arguments but that it has special >> rules for arrays and function that apply in lots of other situations, >> not just in function calls? > > As in the previous post, as long as you don't change the pointer, the > effect is as it would be with call by reference. That's a peculiar view. The only way in which arguments passed by reference differ from the norm is if you change them! You are ruling out the one thing that makes pass by reference detectable. The fact that things reachable via the argument can be changed is shared by languages that have pass by reference and those that don't. I find all this a little odd. Is there a "freedom to say C has pass by reference" political party? What's wrong with the simple explanation of how values are passed from caller to callee? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-28 12:22 +0000 |
| Message-ID | <ljlh63$p9p$2@speranza.aioe.org> |
| In reply to | #43700 |
BartC <bc@freeuk.com> wrote: > "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message > news:0.8880f72dbfb6b4376648.20140428032221BST.87fvky2nxe.fsf@bsb.me.uk... >> 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. > With function names and arrays, these are effectively passed by reference in > C without needing to use & in the caller or * in the callee (when using () > or [] operators). As long as you don't change the pointer in the called routine. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-04-28 08:53 -0700 |
| Message-ID | <lnioptpi1g.fsf@nuthaus.mib.org> |
| In reply to | #43700 |
"BartC" <bc@freeuk.com> writes:
[...]
> With function names and arrays, these are effectively passed by
> reference in C without needing to use & in the caller or * in the
> callee (when using () or [] operators).
Referring to the way C handles arrays in function calls as "pass by
reference" glosses over the fact that the behavior is based on rules
that apply to arrays in general. The decay of array expressions
to pointers has nothing specifically to do with function calls;
it applies equally to assignment, initialization, array indexing,
and so forth. The other relevant rule, that an array parameter is
"adjusted" to a pointer parameter, is specific to functions, but
I'd call it a kind of syntactic sugar, not something fundamental
to the semantics of the language as pass-by-reference would be.
Saying that arrays are "passed by reference" has led too many
inexperienced C programmers to assume, quite reasonably, that sizeof
applied to an array parameter should yield the size of the array.
C has pass-by-reference in the same sense that C has linked lists.
It provides tools (pointers) from which you can build code that
has the effect of pass-by-reference, or of linked lists, but it
has neither as a feature of the language.
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2014-04-28 16:10 +0000 |
| Message-ID | <ljluhq$ikc$1@news.xmission.com> |
| In reply to | #43718 |
In article <lnioptpi1g.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> wrote: ... >C has pass-by-reference in the same sense that C has linked lists. >It provides tools (pointers) from which you can build code that >has the effect of pass-by-reference, or of linked lists, but it >has neither as a feature of the language. Nor does it have "subroutines". Which was my point all along. Thank you; my work here is done. -- A liberal, a moderate, and a conservative walk into a bar... Bartender says, "Hi, Mitt!"
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-28 18:11 +0000 |
| Message-ID | <20140428105321.7@kylheku.com> |
| In reply to | #43718 |
On 2014-04-28, Keith Thompson <kst-u@mib.org> wrote: > "BartC" <bc@freeuk.com> writes: > [...] >> With function names and arrays, these are effectively passed by >> reference in C without needing to use & in the caller or * in the >> callee (when using () or [] operators). > > Referring to the way C handles arrays in function calls as "pass by > reference" glosses over the fact that the behavior is based on rules > that apply to arrays in general. The right language for that is that arrays are communicated by reference in the general sense of any data flow that occurs in the program, not only across function boundaries; in other words: that arrays have de-facto reference semantics in C. > C has pass-by-reference in the same sense that C has linked lists. No because we can make linked lists in umpteen different, mutually incompatible ways in C, the use of any of which can be justified. The conventions for passing by reference aren't nearly that numerous. There aren't umpteen answers to the question "I have an int variable in this scope here, and I want to communicate it into a function such that the function can modify the original variable." (There is one right answer, and maybe a couple of others contrived just to have the last word in this argument, and thus not technically justifiable in the same way that different linked list approaches are justifiable.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2014-04-28 11:34 -0700 |
| Message-ID | <cdea026a-6b5c-4215-bd88-f26a4016268c@googlegroups.com> |
| In reply to | #43720 |
On Monday, April 28, 2014 7:11:39 PM UTC+1, Kaz Kylheku wrote:
>
> There aren't umpteen answers to the question "I have an int variable in this
> scope here, and I want to communicate it into a function such that the function
> can modify the original variable." (There is one right answer, and maybe a
> couple of others contrived just to have the last word in this argument, and
> thus not technically justifiable in the same way that different linked list
> approaches are justifiable.)
>
I can't resist.
void wrap(int *x, int dim)
{
if(*x < 0)
*x += dim;
if(* x >= dim)
*x -= dim;
}
#define wrap(x, dim) (x = x < dim ? x + dim : x >= dim ? x - dim : x)
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-28 19:01 +0000 |
| Message-ID | <ljm8hl$ru$1@speranza.aioe.org> |
| In reply to | #43718 |
Keith Thompson <kst-u@mib.org> wrote: > "BartC" <bc@freeuk.com> writes: > [...] >> With function names and arrays, these are effectively passed by >> reference in C without needing to use & in the caller or * in the >> callee (when using () or [] operators). > Referring to the way C handles arrays in function calls as "pass by > reference" glosses over the fact that the behavior is based on rules > that apply to arrays in general. The decay of array expressions > to pointers has nothing specifically to do with function calls; > it applies equally to assignment, initialization, array indexing, > and so forth. The other relevant rule, that an array parameter is > "adjusted" to a pointer parameter, is specific to functions, but > I'd call it a kind of syntactic sugar, not something fundamental > to the semantics of the language as pass-by-reference would be. I was trying to explain in a previous post the difference between pass by reference and passing a reference by value. I am not sure Bart was convinced. > Saying that arrays are "passed by reference" has led too many > inexperienced C programmers to assume, quite reasonably, that > sizeof applied to an array parameter should yield the size > of the array. In Java, an array reference, passed by value, has a .length member which does give the length. You can change array elements, or you can change the local copy of the array reference to refer to a different array. The latter you normally can't do with pass by reference. > C has pass-by-reference in the same sense that C has linked lists. > It provides tools (pointers) from which you can build code that > has the effect of pass-by-reference, or of linked lists, but it > has neither as a feature of the language. Sounds about right to me. -- glen >
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2014-04-28 11:06 +0000 |
| Message-ID | <ljlcn8$e2k$1@speranza.aioe.org> |
| In reply to | #43694 |
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.) For scalars, yes, you put *s all over. Is there a better way? You have to have some way to distinguish pointer and pointee. For PL/I, you give them different names. Maybe not so bad. Fortran has a different assignment operator to assign a pointer value. A little less convenient, as you can't access the pointer value in all contexts. In Java, you dereference a reference object variable with either the [] or . operator, where . acts more like C's -> operator. Objects are always described using object references, so there is no need for something like the C . operator. If I really get tired of writing *s all over, #define S (*s) fixes it. -- glen
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2014-04-28 12:48 +0100 |
| Message-ID | <Rfr7v.204233$gV7.49655@fx21.am4> |
| In reply to | #43705 |
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:ljlcn8$e2k$1@speranza.aioe.org... > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: >> 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.) > > For scalars, yes, you put *s all over. Is there a better way? [Warning: the following statements are about a private language which is not C and for which no formal spec exists online **] One language of mine allows parameters to be marked as being by reference (I use a & prefix on the formal parameter). This has the affect of automatically causing & to be placed in front of any arguments, and automatically dereferencing the parameter in the body of the function. It seems to work well (although I haven't yet tried it on a static-typed C-like language). (Another, older method, that /was/ used for a static language, was to have a pointer attribute to automatically dereference it. In the argot it used, 'ref int' was a normal pointer to int, while 'ref. int' was a pointer that would always deference - up to the dot position. I can't remember if this also took care of function arguments or not.) [/warning] Doubtless there must be plenty of other ways of doing the same in other languages. ... Or do you mean a better way in C? > If I really get tired of writing *s all over, > > #define S (*s) > > fixes it. Ie. a kludge (as a lot of these things are when using macros to fix language short-comings). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2014-04-28 08:11 -0400 |
| Message-ID | <aAr7v.65059$yc2.22689@en-nntp-16.dc1.easynews.com> |
| In reply to | #43706 |
On 4/28/14, 7:48 AM, BartC wrote: > > [Warning: the following statements are about a private language which is > not > C and for which no formal spec exists online **] > > One language of mine allows parameters to be marked as being by > reference (I > use a & prefix on the formal parameter). This has the affect of > automatically causing & to be placed in front of any arguments, and > automatically dereferencing the parameter in the body of the function. It > seems to work well (although I haven't yet tried it on a static-typed > C-like > language). Which is also used in a very popular, and formally defined, static-typed language, C++. It isn't formally defined to be that way, but in all implementations I know, that is how it works. void function foo(int &bar) will cause a "reference" to bar to be passed, that reference being in effect a constant pointer that is automatically dereferenced on use.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2014-04-28 14:04 +0000 |
| Message-ID | <20140428065605.355@kylheku.com> |
| In reply to | #43706 |
On 2014-04-28, BartC <bc@freeuk.com> wrote: > [Warning: the following statements are about a private language which is not > C and for which no formal spec exists online **] You wrote a formal spec and expect users to actually read it? Irony ...
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2014-04-28 12:55 +0100 |
| Message-ID | <0.d9dc063c172708b96ce8.20140428125517BST.87r44h1xei.fsf@bsb.me.uk> |
| In reply to | #43705 |
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. > You have to have some way to distinguish pointer and pointee. Yup. That's one reason why passing a pointer is not pass by reference. In the "olden days" it had a relatively clear meaning: it meant that an assignment to a parameter altered the argument in the caller. Because modern languages don't have pass by reference, I forget that I should probably say more clearly what it is. Some readers will never have used a language that has it (I know you have). Because passing a reference (or a pointer) and pass by reference sound a bit similar, the meanings have got all tangled up. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 7 of 14 — ← Prev page 1 … 5 6 [7] 8 9 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web