Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #55280 > unrolled thread
| Started by | Dexterr <dejangru@gmail.com> |
|---|---|
| First post | 2014-12-22 06:08 -0800 |
| Last post | 2015-03-31 09:12 +0200 |
| Articles | 20 on this page of 208 — 29 participants |
Back to article view | Back to comp.lang.c
my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 06:08 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 14:21 +0000
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 06:55 -0800
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-22 07:36 -0800
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 07:43 -0800
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 15:49 +0000
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 08:01 -0800
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 16:34 +0000
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 08:46 -0800
Re: my solution for Pascal strings Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-12-25 15:36 +0100
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-25 13:14 -0800
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-22 09:24 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 17:49 +0000
Re: my solution for Pascal strings Dexterr <dejangru@gmail.com> - 2014-12-22 10:55 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 19:33 +0000
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 19:41 +0000
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 22:35 +0000
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 22:41 +0000
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-22 16:16 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 13:18 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-23 01:33 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 14:41 +1300
Re: my solution for Pascal strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-23 10:07 +0000
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-23 02:36 -0800
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-23 07:44 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-24 09:00 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-23 10:42 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-24 08:50 +1300
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-23 20:02 +0000
Re: my solution for Pascal strings "Chris M. Thomasson" <no@spam.invalid> - 2014-12-23 12:30 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-23 21:12 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-24 10:50 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-23 14:06 -0800
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2014-12-23 22:22 +0000
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 00:10 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-24 14:21 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 11:19 +0000
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 04:55 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 08:28 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 12:27 -0800
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:48 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 10:29 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 14:59 -0800
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2014-12-24 13:32 -0600
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:16 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-24 09:22 -0700
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:57 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-24 12:42 -0700
Re: my solution for Pascal strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-24 20:02 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-24 13:59 -0700
Re: my solution for Pascal strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-24 21:56 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-24 16:02 -0700
Re: my solution for Pascal strings Robert Wessel <robertwessel2@yahoo.com> - 2015-03-25 01:51 -0500
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:50 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-25 14:53 -0700
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:43 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-25 15:32 -0700
Re: my solution for Pascal strings Phil Carmody <pc+usenet@asdf.org> - 2015-04-09 02:05 +0300
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-25 15:43 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-25 20:46 -0500
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-25 23:33 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 03:02 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:34 -0500
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-27 12:38 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-28 12:02 +1300
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-27 16:39 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-27 17:18 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-28 13:34 +1300
Re: my solution for Pascal strings Richard Damon <Richard@Damon-Family.org> - 2015-03-27 22:09 -0400
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-28 05:41 -0700
Re: my solution for Pascal strings raltbos@xs4all.nl (Richard Bos) - 2015-03-29 15:24 +0000
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-26 10:37 +0000
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 05:56 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 06:23 -0700
Re: my solution for Pascal strings asetofsymbols@gmail.com - 2015-03-26 10:07 -0700
Re: my solution for Pascal strings asetofsymbols@gmail.com - 2015-03-26 10:16 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 06:30 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-26 08:39 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 09:26 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-26 10:53 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-26 18:19 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-26 11:33 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-26 12:08 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 12:24 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:46 -0500
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:44 -0500
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2015-03-27 04:53 +0000
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:42 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-27 07:04 +0000
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-27 10:43 +0000
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-27 10:50 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-27 08:23 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-27 12:54 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-28 16:20 -0500
Re: my solution for Pascal strings Melzzzzz <mel@zzzzz.com> - 2015-03-28 22:23 +0100
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 10:28 +1300
Re: my solution for Pascal strings Melzzzzz <mel@zzzzz.com> - 2015-03-28 22:29 +0100
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 10:35 +1300
Re: my solution for Pascal strings Melzzzzz <mel@zzzzz.com> - 2015-03-28 22:44 +0100
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 10:57 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-28 15:09 -0700
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-28 21:46 +0000
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-29 09:54 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-29 15:54 +0100
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-29 19:04 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 08:00 +0100
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 07:58 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 14:29 +0100
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:35 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-27 16:14 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-27 12:15 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-28 08:30 +1300
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 14:56 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:10 +1300
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-28 20:04 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-29 17:14 +1300
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 13:03 -0700
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:40 +1300
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-26 23:31 -0500
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-26 23:42 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-29 19:00 -0500
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-30 08:15 -0700
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 18:23 -0500
Re: my solution for Pascal strings James Kuyper <jameskuyper@verizon.net> - 2015-03-30 12:26 -0400
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-30 09:42 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-30 10:28 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-30 10:50 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-30 12:09 -0700
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-30 12:21 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-30 19:37 +0100
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-30 12:20 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-30 20:49 +0100
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-30 13:20 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-30 21:32 +0100
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-03-30 14:07 -0700
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-30 12:55 -0700
Re: my solution for Pascal strings Bartc <bc@freeuk.com> - 2015-03-30 21:27 +0100
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2015-03-26 23:47 -0700
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-27 07:11 +0000
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-29 19:01 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 07:57 +0100
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 18:32 -0500
Re: my solution for Pascal strings James Kuyper <jameskuyper@verizon.net> - 2015-03-30 19:59 -0400
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 19:22 -0500
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2015-03-30 23:53 +0000
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2015-03-30 19:25 -0500
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 01:12 +0000
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 07:04 +0100
Re: my solution for Pascal strings Robert Wessel <robertwessel2@yahoo.com> - 2015-03-31 01:24 -0500
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 07:46 +0100
Re: my solution for Pascal strings Les Cargill <lcargill99@comcast.com> - 2014-12-24 13:18 -0600
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 08:19 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 20:05 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:18 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 20:39 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:57 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 21:22 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 14:53 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-24 23:46 +0000
Re: my solution for Pascal strings Phil Carmody <pc+usenet@asdf.org> - 2015-01-03 01:48 +0200
Re: my solution for Pascal strings Phil Carmody <pc+usenet@asdf.org> - 2015-01-03 01:43 +0200
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:05 -0800
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-24 20:20 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 12:34 -0800
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 12:37 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 10:15 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 13:43 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 10:52 +1300
Re: my solution for Pascal strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-12-24 15:02 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-25 16:51 +1300
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-24 21:28 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 02:21 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 02:39 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 02:52 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 03:09 -0800
Re: my solution for Pascal strings Richard Damon <Richard@Damon-Family.org> - 2014-12-25 09:32 -0500
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 06:50 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 11:59 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 11:38 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 11:55 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 03:33 -0800
Re: my solution for Pascal strings fir <profesor.fir@gmail.com> - 2014-12-25 02:56 -0800
Re: my solution for Pascal strings David Thompson <dave.thompson2@verizon.net> - 2015-01-12 15:33 -0500
Re: my solution for Pascal strings Kaz Kylheku <kaz@kylheku.com> - 2014-12-23 05:17 +0000
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2014-12-23 07:43 -0800
Re: my solution for Pascal strings raltbos@xs4all.nl (Richard Bos) - 2014-12-23 20:42 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 11:48 +1300
Re: my solution for Pascal strings Richard Heathfield <invalid@see.sig.invalid> - 2014-12-22 23:55 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 13:21 +1300
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 11:55 +1300
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 12:12 +1300
Re: my solution for Pascal strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-12-22 23:33 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-23 12:59 +1300
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-22 23:03 +0000
Re: my solution for Pascal strings CHIN Dihedral <dihedral88888@gmail.com> - 2015-03-26 04:04 -0700
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-03-26 11:22 +0000
Re: my solution for Pascal strings dmaxime66@gmail.com - 2014-12-28 09:37 -0800
Re: my solution for Pascal strings BartC <bc@freeuk.com> - 2014-12-28 18:17 +0000
Re: my solution for Pascal strings dmaxime66@gmail.com - 2014-12-30 05:28 -0800
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-31 08:29 +1300
Re: my solution for Pascal strings glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-12-30 23:56 +0000
Re: my solution for Pascal strings Ian Collins <ian-news@hotmail.com> - 2014-12-29 07:59 +1300
Re: my solution for Pascal strings Max <dmaxime66@gmail.com> - 2014-12-30 05:24 -0800
Re: my solution for Pascal strings James Kuyper <jameskuyper@verizon.net> - 2014-12-30 11:29 -0500
Re: my solution for Pascal strings Max <dmaxime66@gmail.com> - 2014-12-30 10:23 -0800
Re: my solution for Pascal strings James Kuyper <jameskuyper@verizon.net> - 2014-12-30 14:22 -0500
Re: my solution for Pascal strings "D. Aaron Sawyer" <aaron@110.net> - 2014-12-22 12:32 -0400
Re: my solution for Pascal strings "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-03-31 09:12 +0200
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-30 07:57 +0100 |
| Message-ID | <mfas3v$rhb$1@dont-email.me> |
| In reply to | #59240 |
On 30/03/15 01:01, Les Cargill wrote: > Richard Heathfield wrote: >> On 27/03/15 04:31, Les Cargill wrote: >>> fir wrote: >> >> <snip> >> >>>> >>>> could maybe someone remember me if given >>>> value can be 'consted' in half way thru code >>>> (for example you pass non const to fu and >>>> fu argument changes it to const so in fu it is const, outside not) [?] >>>> >>> >>> Yes. You would need to cast the thing to a "const" type before calling >>> fu. >> >> Why? >> <example snipped> >> >> Why would you need to add a cast? >> >> <snip> > > you would not for that case, assuming your declaration of > strstr() does not require it. Can you demonstrate an example of passing a non-const to a function that /does/ support your claim by requiring a cast to add the const qualifier? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-30 18:32 -0500 |
| Message-ID | <mfcm4d$oaj$1@dont-email.me> |
| In reply to | #59248 |
Richard Heathfield wrote: > On 30/03/15 01:01, Les Cargill wrote: >> Richard Heathfield wrote: >>> On 27/03/15 04:31, Les Cargill wrote: >>>> fir wrote: >>> >>> <snip> >>> >>>>> >>>>> could maybe someone remember me if given >>>>> value can be 'consted' in half way thru code >>>>> (for example you pass non const to fu and >>>>> fu argument changes it to const so in fu it is const, outside not) [?] >>>>> >>>> >>>> Yes. You would need to cast the thing to a "const" type before calling >>>> fu. >>> >>> Why? >>> > <example snipped> >>> >>> Why would you need to add a cast? >>> >>> <snip> >> >> you would not for that case, assuming your declaration of >> strstr() does not require it. > > > Can you demonstrate an example of passing a non-const to a function that > /does/ support your claim by requiring a cast to add the const qualifier? > Not that happens under Mingw, which is all I have here. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-03-30 19:59 -0400 |
| Message-ID | <5519E358.5070800@verizon.net> |
| In reply to | #59315 |
On 03/30/2015 07:32 PM, Les Cargill wrote: > Richard Heathfield wrote: ... >> Can you demonstrate an example of passing a non-const to a function that >> /does/ support your claim by requiring a cast to add the const qualifier? >> > > Not that happens under Mingw, which is all I have here. That shouldn't matter. None of the relevant features of C is allowed to vary from one conforming implementation of C to another, and an example that depends upon a failure to conform isn't relevant to the question. Obviously, a compiler could choose to issue a non-mandatory diagnostic unless the cast is used - but that doesn't make the cast necessary - it just makes that compiler annoying. A compiler could also issue a non-mandatory diagnostic if you choose a variable name that cannot be found in "Green Eggs and Ham". That doesn't mean that you have to restrict your variable names to those 50 words.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-30 19:22 -0500 |
| Message-ID | <mfcp18$1bk$1@dont-email.me> |
| In reply to | #59318 |
James Kuyper wrote: > On 03/30/2015 07:32 PM, Les Cargill wrote: >> Richard Heathfield wrote: > ... >>> Can you demonstrate an example of passing a non-const to a function that >>> /does/ support your claim by requiring a cast to add the const qualifier? >>> >> >> Not that happens under Mingw, which is all I have here. > > That shouldn't matter. None of the relevant features of C is allowed to > vary from one conforming implementation of C to another, and an example > that depends upon a failure to conform isn't relevant to the question. > > Obviously, a compiler could choose to issue a non-mandatory diagnostic > unless the cast is used - but that doesn't make the cast necessary - it > just makes that compiler annoying. > :) I have seen this happen at least once. I agree - it *SHOULD NOT* be required; I thought I had typed things carefully enough to indicate that "if it's a problem then..." but you never know how much cadging is required. > A compiler could also issue a non-mandatory diagnostic if you choose a > variable name that cannot be found in "Green Eggs and Ham". That doesn't > mean that you have to restrict your variable names to those 50 words. > Indeed. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-03-30 23:53 +0000 |
| Message-ID | <20150330164943.981@kylheku.com> |
| In reply to | #59240 |
On 2015-03-30, Les Cargill <lcargill99@comcast.com> wrote:
> Richard Heathfield wrote:
>> int main(void)
>> {
>> char nonconststra[] = "needle";
>> char nonconststrb[] =
>> "greatbighaystackthatneedlesstosaymaycontainaneedleortwo";
>> char *p = strstr(nonconststrb, nonconststra);
>> if(p != NULL)
>> {
>> printf("%s\n", p);
>> }
>> return 0;
>> }
>>
>> Why would you need to add a cast?
>>
>> <snip>
>>
>
> you would not for that case, assuming your declaration of
> strstr() does not require it.
What declaration of strstr works silently with arguments
cast to (const char *), but causes (char *) arguments to be diagnosed?
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-30 19:25 -0500 |
| Message-ID | <mfcp6u$1bk$2@dont-email.me> |
| In reply to | #59317 |
Kaz Kylheku wrote:
> On 2015-03-30, Les Cargill <lcargill99@comcast.com> wrote:
>> Richard Heathfield wrote:
>>> int main(void)
>>> {
>>> char nonconststra[] = "needle";
>>> char nonconststrb[] =
>>> "greatbighaystackthatneedlesstosaymaycontainaneedleortwo";
>>> char *p = strstr(nonconststrb, nonconststra);
>>> if(p != NULL)
>>> {
>>> printf("%s\n", p);
>>> }
>>> return 0;
>>> }
>>>
>>> Why would you need to add a cast?
>>>
>>> <snip>
>>>
>>
>> you would not for that case, assuming your declaration of
>> strstr() does not require it.
>
> What declaration of strstr works silently with arguments
> cast to (const char *), but causes (char *) arguments to be diagnosed?
>
I've seen cases where casts of const were required of some call or an
other, but I am at a loss for details. Usually you spend a lot of
money for something like Coverity to get that level of annoying behavior.
Just to clarify; I'd rather not cast unnecessarily ( who would? ) but
*IF* there's a warning, you're better off fixing it than
leaving it in.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-03-31 01:12 +0000 |
| Message-ID | <20150330180624.204@kylheku.com> |
| In reply to | #59320 |
On 2015-03-31, Les Cargill <lcargill99@comcast.com> wrote:
> Kaz Kylheku wrote:
>> On 2015-03-30, Les Cargill <lcargill99@comcast.com> wrote:
>>> Richard Heathfield wrote:
>>>> int main(void)
>>>> {
>>>> char nonconststra[] = "needle";
>>>> char nonconststrb[] =
>>>> "greatbighaystackthatneedlesstosaymaycontainaneedleortwo";
>>>> char *p = strstr(nonconststrb, nonconststra);
>>>> if(p != NULL)
>>>> {
>>>> printf("%s\n", p);
>>>> }
>>>> return 0;
>>>> }
>>>>
>>>> Why would you need to add a cast?
>>>>
>>>> <snip>
>>>>
>>>
>>> you would not for that case, assuming your declaration of
>>> strstr() does not require it.
>>
>> What declaration of strstr works silently with arguments
>> cast to (const char *), but causes (char *) arguments to be diagnosed?
>>
>
> I've seen cases where casts of const were required of some call or an
> other, but I am at a loss for details.
Well, sure:
error_t lookup_foobar_name(const char **pstr);
Here, you must pass in the address of a const char *.
char *foobar_name;
/* diagnostic required: there is no cast-free conversion
from char ** to const char ** */
if (lookup_foobar_name(&foobar_name) == ...)
(We can "shut up the compiler" with a (const char **) cast,
which isn't necessarily right.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-31 07:04 +0100 |
| Message-ID | <mfddb1$h6b$1@dont-email.me> |
| In reply to | #59320 |
On 31/03/15 01:25, Les Cargill wrote: <snip> > Just to clarify; I'd rather not cast unnecessarily ( who would? ) but Nobody, I hope. > *IF* there's a warning, you're better off fixing it than > leaving it in. I used to think that, too. A guy from Chicago once complained to me (after I'd set up some project guidelines that included "clean MSVC compile at level 4") that a clean compile at that level of strictness was 'impahssible' - but for me it was not only possible, but routine. I couldn't understand the fuss. (Still can't, really, despite what follows.) Since I started using gcc a lot more often, though, I've found that it issues so many diagnostic messages for so many different situations that there are occasions where it seems the only way to shut up one diagnostic message is to invoke another one. That's a silly game, and it is in situations like this that a really first-class comment is worth far more than a bunch of artificial workarounds (such as casts). -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-31 01:24 -0500 |
| Message-ID | <i2fkhah33garlkgad30r5sshm79qikuicp@4ax.com> |
| In reply to | #59327 |
On Tue, 31 Mar 2015 07:04:05 +0100, Richard Heathfield <rjh@cpax.org.uk> wrote: >On 31/03/15 01:25, Les Cargill wrote: > ><snip> > >> Just to clarify; I'd rather not cast unnecessarily ( who would? ) but > >Nobody, I hope. > >> *IF* there's a warning, you're better off fixing it than >> leaving it in. > > >I used to think that, too. A guy from Chicago once complained to me >(after I'd set up some project guidelines that included "clean MSVC >compile at level 4") that a clean compile at that level of strictness >was 'impahssible' - but for me it was not only possible, but routine. I >couldn't understand the fuss. (Still can't, really, despite what follows.) Wasn't me, although that is my neighborhood... But for a long time, -W4 was very difficult to use with MSVC, at least for applications targeting the WinAPI, since the Windows headers weren't -W4 clean. That's been fixed for quite some time now, though. At least back to VS05, likely earlier.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-31 07:46 +0100 |
| Message-ID | <mfdfpp$nn6$1@dont-email.me> |
| In reply to | #59328 |
On 31/03/15 07:24, Robert Wessel wrote: > On Tue, 31 Mar 2015 07:04:05 +0100, Richard Heathfield > <rjh@cpax.org.uk> wrote: > >>On 31/03/15 01:25, Les Cargill wrote: <snip> >>> *IF* there's a warning, you're better off fixing it than >>> leaving it in. >> >> >>I used to think that, too. A guy from Chicago once complained to me >>(after I'd set up some project guidelines that included "clean MSVC >>compile at level 4") that a clean compile at that level of strictness >>was 'impahssible' - but for me it was not only possible, but routine. I >>couldn't understand the fuss. (Still can't, really, despite what follows.) > > > Wasn't me, although that is my neighborhood... It was in fact a Robert (IIRC), but not a Wessel (IISRC). > But for a long time, -W4 was very difficult to use with MSVC, at least > for applications targeting the WinAPI, since the Windows headers > weren't -W4 clean. In those days, just about everything I ever wrote had to compile on a mainframe as well as a PC, so the WinAPI wasn't really an issue as such. But I do recall that <math.h> had a BCPL comment in it, which irritated me no end (even unto the point that I was sorely tempted to fix it). -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2014-12-24 13:18 -0600 |
| Message-ID | <m7f3cv$i0b$1@dont-email.me> |
| In reply to | #55380 |
BartC wrote: > On 24/12/2014 01:21, Ian Collins wrote: >> BartC wrote: > >>> Simplest then to use char*, and leave it to the caller code, if it's so >>> paranoid it can't trust itself to not corrupt strings it shouldn't be >>> writing to, to apply any const casts if it has to. >> >> No, all that gives you is a gateway to subtle and hard to find memory >> corruption bugs. Why introduce a new gets()? If you want the string to >> be mutable, provide the functions to do this, don't expose the guts of >> the object. Consider what happens if you write past the end, or.. > > OK, we're obviously never going to agree. My main concern is avoiding a > proliferation of 'const' everywhere that will introduce clutter and > obscure the clarity of the code. > But "const" is a perfectly good thing to use. If nothing else, it communicates to the caller "I've thought about safety issues with this call." > Since most string parameters are going to be 'in' parameters, not 'out' > or 'inout' ones, then they /will/ be everywhere using your method. > > And take an innocuous-looking function as strstr(), which returns a > location in its first string parameter. Its prototype is like this: > > char* strstr(const char* str, const char* searchstr); > > While it takes pains to show that it doesn't write to the 'str' > parameter, it then proceeds to return a writeable pointer into that string! > Which is fine. I forget exactly in which cases you get type promotion to const, but it's not a big pain to use. If you think of a call as an operator, nailing down "const" on a parameter identifies it as an R-value only. > If we try and make the result const char*, then we run into problems > when we *do* need to write to that part of str. > Yes we do. <snip> -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2014-12-25 08:19 +1300 |
| Message-ID | <cg0huaFim7bU17@mid.individual.net> |
| In reply to | #55380 |
BartC wrote:
> On 24/12/2014 01:21, Ian Collins wrote:
>> BartC wrote:
>
>>> Simplest then to use char*, and leave it to the caller code, if it's so
>>> paranoid it can't trust itself to not corrupt strings it shouldn't be
>>> writing to, to apply any const casts if it has to.
>>
>> No, all that gives you is a gateway to subtle and hard to find memory
>> corruption bugs. Why introduce a new gets()? If you want the string to
>> be mutable, provide the functions to do this, don't expose the guts of
>> the object. Consider what happens if you write past the end, or..
>
> OK, we're obviously never going to agree. My main concern is avoiding a
> proliferation of 'const' everywhere that will introduce clutter and
> obscure the clarity of the code.
If anything, it adds clarity. At least if a pointer parameter is to a
const object, the programmer (and perhaps more importantly, the
compiler) knows the function isn't going to modify the object. There
are also cases where data is const, string literals for example.
> Since most string parameters are going to be 'in' parameters, not 'out'
> or 'inout' ones, then they /will/ be everywhere using your method.
Good. It is also the method used by every coding standard I have ever used.
> And take an innocuous-looking function as strstr(), which returns a
> location in its first string parameter. Its prototype is like this:
>
> char* strstr(const char* str, const char* searchstr);
>
> While it takes pains to show that it doesn't write to the 'str'
> parameter, it then proceeds to return a writeable pointer into that string!
This was obviously a zero day bug :)
> If we try and make the result const char*, then we run into problems
> when we *do* need to write to that part of str.
>
> To get around this is C++, apparently two overloads are used, one with a
> char* result, and one with a const char* result. This is too achieve
> what we could have got without bothering with const in the first place!
If the original didn't use const, it couldn't have been used with string
literals...
>> ..the implementation does in fact use a short string optimisation, say
>> it's something like
>>
>> struct String
>> {
>> uint8_t size;
>> char shortString[7];
>> char* data;
>> }
>
> (Not a particular efficient way of implementing a short string. I used a
> scheme, in a language that normally uses counted strings, where I can
> have a short string field inside a struct that can store up to 8
> characters, in a field width of 8 characters!)
So the greater efficiency came form the extra character?
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-24 20:05 +0000 |
| Message-ID | <Q%Emw.253239$976.233136@fx37.am4> |
| In reply to | #55393 |
On 24/12/2014 19:19, Ian Collins wrote:
> BartC wrote:
>> On 24/12/2014 01:21, Ian Collins wrote:
>>> BartC wrote:
>>
>>>> Simplest then to use char*, and leave it to the caller code, if it's so
>>>> paranoid it can't trust itself to not corrupt strings it shouldn't be
>>>> writing to, to apply any const casts if it has to.
>>>
>>> No, all that gives you is a gateway to subtle and hard to find memory
>>> corruption bugs. Why introduce a new gets()? If you want the string to
>>> be mutable, provide the functions to do this, don't expose the guts of
>>> the object. Consider what happens if you write past the end, or..
>>
>> OK, we're obviously never going to agree. My main concern is avoiding a
>> proliferation of 'const' everywhere that will introduce clutter and
>> obscure the clarity of the code.
>
> If anything, it adds clarity. At least if a pointer parameter is to a
> const object, the programmer (and perhaps more importantly, the
> compiler) knows the function isn't going to modify the object.
With more complicated examples, that is not so clear. See examples
below. While I thought it was bad form to have to write optimisation
hints for the compiler within the code. (That's what /I/ need to do with
my unsophisticated compilers, but not what I expect of advanced C
compilers.)
>> Since most string parameters are going to be 'in' parameters, not 'out'
>> or 'inout' ones, then they /will/ be everywhere using your method.
>
> Good. It is also the method used by every coding standard I have ever
> used.
If it means writing code like this:
> int getnumber( int * const number, int const min, int const top )
then that's a complete joke. Also consider calls like this :
typedef struct {char *p *q;} rec;
int** testfn( rec *p; char** x);
If these parameters are not written to, then presumably they would need
to be written as:
int** testfn( const rec *p; const char* const* x);
(With that last parameter taking four attempts with Cdecl to get it
right!) And maybe, in some cases it would need to be this:
const int* const * testfn( const rec *p; const char* const* x);
If people think this is clearer, then they're delusional. Then there are
all the eight combinations of:
const char * const * const x
char * const * const x
const char ** const x
const char * const *x
char ** const x
const char **x
char **x
The last one is obvious, but what is anyone to make of all the other
combinations? A bit of head-scratching is needed to understand what they
even mean.
Another problem is that const doesn't do the whole job: have a look at
those char* members of the 'rec' struct: they are not protected with
const. It's not possible without changing the struct definition, which
will make it extremely awkward to use the struct at all!
It's also possible to put together other examples where the type isn't
spelled out directly, but is hidden in a typedef etc where it's not
going to be possible to stick any consts in. So, type abstraction now
has to be sacrificed.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-24 12:18 -0800 |
| Message-ID | <lnh9wk244o.fsf@nuthaus.mib.org> |
| In reply to | #55397 |
BartC <bc@freeuk.com> writes:
> On 24/12/2014 19:19, Ian Collins wrote:
>> BartC wrote:
>>> On 24/12/2014 01:21, Ian Collins wrote:
>>>> BartC wrote:
>>>
>>>>> Simplest then to use char*, and leave it to the caller code, if it's so
>>>>> paranoid it can't trust itself to not corrupt strings it shouldn't be
>>>>> writing to, to apply any const casts if it has to.
>>>>
>>>> No, all that gives you is a gateway to subtle and hard to find memory
>>>> corruption bugs. Why introduce a new gets()? If you want the string to
>>>> be mutable, provide the functions to do this, don't expose the guts of
>>>> the object. Consider what happens if you write past the end, or..
>>>
>>> OK, we're obviously never going to agree. My main concern is avoiding a
>>> proliferation of 'const' everywhere that will introduce clutter and
>>> obscure the clarity of the code.
>>
>> If anything, it adds clarity. At least if a pointer parameter is to a
>> const object, the programmer (and perhaps more importantly, the
>> compiler) knows the function isn't going to modify the object.
>
> With more complicated examples, that is not so clear. See examples
> below. While I thought it was bad form to have to write optimisation
> hints for the compiler within the code. (That's what /I/ need to do with
> my unsophisticated compilers, but not what I expect of advanced C
> compilers.)
const isn't primarily an optimization hint. It's a *semantics* hint.
It lets the compiler enforce programmer-defined read-only semantics, so
that if you incorrectly pass a pointer to a read-only object to a
function that may modify that object, the compiler can diagnose the
error.
>>> Since most string parameters are going to be 'in' parameters, not 'out'
>>> or 'inout' ones, then they /will/ be everywhere using your method.
>>
>> Good. It is also the method used by every coding standard I have ever
>> used.
>
> If it means writing code like this:
>
> > int getnumber( int * const number, int const min, int const top )
>
> then that's a complete joke. [...]
It doesn't mean writing code like that; who says it does? All three
"consts" in that declaration are nearly meaningless. If they're
declared as "const" in the function *definition*, they make the
parameter objects (visible only inside the function) read-only --
which might be useful, but it shouldn't be made visible to callers.
You could write:
int getnumber(int *number, int min, int top);
int getnumber(int *const number, int const min, int const top) {
/* ... code that cannot modify number, min, or top */
}
But most C programmers don't bother.
[snip]
If I were designing a new language with no need for backward
compatibility, "const" (i.e., read-only) would be the default,
and you'd need to add a keyword to specify that an object may
be modified. It just wasn't possible to do that for C.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-24 20:39 +0000 |
| Message-ID | <8wFmw.201245$Cy6.152264@fx23.am4> |
| In reply to | #55400 |
On 24/12/2014 20:18, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> If it means writing code like this: >> >> > int getnumber( int * const number, int const min, int const top ) > It doesn't mean writing code like that; who says it does? All three > "consts" in that declaration are nearly meaningless. It was in code posted by Stefan Ram in another thread today. But I don't know it was proper code or meant as a joke. I suspect it wasn't a joke.. > If I were designing a new language with no need for backward > compatibility, "const" (i.e., read-only) would be the default, > and you'd need to add a keyword to specify that an object may > be modified. It just wasn't possible to do that for C. That would be better I think. Provided it didn't apply to obviously value parameters, such void fn(int,int,int). But it might take more than a single keyword to achieve what is needed: with pointer chains, arrays of pointers and structs containing pointers, at the minute you have to specify const-ness at every point. Presumably you'd have to specify write-ability at every point too. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-24 12:57 -0800 |
| Message-ID | <ln4msk22bv.fsf@nuthaus.mib.org> |
| In reply to | #55406 |
BartC <bc@freeuk.com> writes:
> On 24/12/2014 20:18, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> If it means writing code like this:
>>>
>>> > int getnumber( int * const number, int const min, int const top )
>
>> It doesn't mean writing code like that; who says it does? All three
>> "consts" in that declaration are nearly meaningless.
>
> It was in code posted by Stefan Ram in another thread today.
>
> But I don't know it was proper code or meant as a joke. I suspect it
> wasn't a joke..
I have no idea what Stefan Ram had in mind when he posted that, but it's
not representative of typical C code.
> > If I were designing a new language with no need for backward
> > compatibility, "const" (i.e., read-only) would be the default,
> > and you'd need to add a keyword to specify that an object may
> > be modified. It just wasn't possible to do that for C.
>
> That would be better I think. Provided it didn't apply to obviously
> value parameters, such void fn(int,int,int).
I don't know what you mean by that. Why shouldn't it apply?
The "default-read-only" semantics would mean that the parameter objects
cannot be modified in side the function. It wouldn't affect callers.
For example (using C-like syntax):
void func(int x, int y) {
printf("x = %d, y = %d\n", x, y); /* ok */
x ++; /* invalid, x is read-only */
}
int a = 10;
var int b = 20;
a ++; /* invalid */
b ++; /* ok */
func(a, b); /* ok */
> But it might take more than a single keyword to achieve what is needed:
> with pointer chains, arrays of pointers and structs containing pointers,
> at the minute you have to specify const-ness at every point. Presumably
> you'd have to specify write-ability at every point too.
Yes -- and a single keyword should be enough for that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-24 21:22 +0000 |
| Message-ID | <n8Gmw.272856$p95.29198@fx38.am4> |
| In reply to | #55408 |
On 24/12/2014 20:57, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 24/12/2014 20:18, Keith Thompson wrote:
>> > If I were designing a new language with no need for backward
>> > compatibility, "const" (i.e., read-only) would be the default,
>> > and you'd need to add a keyword to specify that an object may
>> > be modified. It just wasn't possible to do that for C.
>>
>> That would be better I think. Provided it didn't apply to obviously
>> value parameters, such void fn(int,int,int).
>
> I don't know what you mean by that. Why shouldn't it apply?
Because changes to such parameters don't affect the caller in any way;
why a function be stopped from writing to its own variables? And if so,
should the same apply to *any* variable?
Sometimes parameters need to be adjusted in value, or they might need to
be incremented as counts or pointers; why make all this harder for no
advantage?
I think even in Pascal which used Var and non-Var parameters, you could
write to the non-Var parameters. The difference is the write doesn't
affect anything in the caller.
> The "default-read-only" semantics would mean that the parameter objects
> cannot be modified in side the function. It wouldn't affect callers.
> For example (using C-like syntax):
>
> void func(int x, int y) {
> printf("x = %d, y = %d\n", x, y); /* ok */
> x ++; /* invalid, x is read-only */
But, Why? I know some languages have dispensed with variables, but I
think C still has a need of them, and without having to jump through
hoops either!
Also, any 'var' indicator in the parameter list of a function isn't any
business of the caller of the function.
>> But it might take more than a single keyword to achieve what is needed:
>> with pointer chains, arrays of pointers and structs containing pointers,
>> at the minute you have to specify const-ness at every point. Presumably
>> you'd have to specify write-ability at every point too.
>
> Yes -- and a single keyword should be enough for that.
You mean, a single keyword inserted at N different points? And which is
only possible to do when 100% of the type specification is available at
the point of declaration? That's nearly as much a mess as before.
But I do like it when you propose a new language that had no need for
backwards compatibility, you then proceed to drag in most of the baggage
of the old one!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2014-12-24 14:53 -0800 |
| Message-ID | <lnzjaczmkw.fsf@nuthaus.mib.org> |
| In reply to | #55410 |
BartC <bc@freeuk.com> writes:
> On 24/12/2014 20:57, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 24/12/2014 20:18, Keith Thompson wrote:
>
>>> > If I were designing a new language with no need for backward
>>> > compatibility, "const" (i.e., read-only) would be the default,
>>> > and you'd need to add a keyword to specify that an object may
>>> > be modified. It just wasn't possible to do that for C.
>>>
>>> That would be better I think. Provided it didn't apply to obviously
>>> value parameters, such void fn(int,int,int).
>>
>> I don't know what you mean by that. Why shouldn't it apply?
>
> Because changes to such parameters don't affect the caller in any way;
> why a function be stopped from writing to its own variables? And if so,
> should the same apply to *any* variable?
Remember that this is my own hypothetical language, in which *all*
objects (don't confuse the issue by calling them "variables") are
read-only by default. If you want to be able to modify an object after
its initialization, just add a simple keyword to its declaration.
I used "var" in my previous examples; I think I prefer "rw".
*Most* objects don't change their values once they're initialized. For
those that do, often the code can be rearranged to avoid it; being able
to mix declarations and statements helps with this.
> Sometimes parameters need to be adjusted in value, or they might need to
> be incremented as counts or pointers; why make all this harder for no
> advantage?
The advantage is consistency, and having an added keyword for the less
common case rather than, as in C, the more common case. (I have no data
to back this up; this is speculation on my part.)
> I think even in Pascal which used Var and non-Var parameters, you could
> write to the non-Var parameters. The difference is the write doesn't
> affect anything in the caller.
Yes. On the other hand, in Ada "in"-mode parameters (the default mode)
are read-only objects within the body of the function or procedure. You
can always make a modifiable copy of the parameter in the relatively
rare cases where you need that -- and you're still guaranteed to be able
to see the value that the caller passed in.
>> The "default-read-only" semantics would mean that the parameter objects
>> cannot be modified in side the function. It wouldn't affect callers.
>> For example (using C-like syntax):
>>
>> void func(int x, int y) {
>> printf("x = %d, y = %d\n", x, y); /* ok */
>> x ++; /* invalid, x is read-only */
>
> But, Why? I know some languages have dispensed with variables, but I
> think C still has a need of them, and without having to jump through
> hoops either!
Who's talking about dispensing with variables? It's a very minor hoop
to jump through. Or you can just not use my hypothetical language,
which I'm 99.9% sure I'll never get around to defining, much less
implementing.
> Also, any 'var' indicator in the parameter list of a function isn't any
> business of the caller of the function.
Agreed. I'm not sure whether I'd want to allow "var" (or "rw") on
parameter declarations. If I did allow it, I'd want to have a way of
doing so without exposing that useless information to the caller. You
can easily do that in C, by using "const" in the definition but not in
the declaration; my hypothetical language just changes the sense of the
keyword and where it goes. On the other hand, I like the idea of
keeping the declaration and the declaration part of the definition
identical (which means including parameter names in both).
I'd probably just make parameter objects read-only.
>>> But it might take more than a single keyword to achieve what is needed:
>>> with pointer chains, arrays of pointers and structs containing pointers,
>>> at the minute you have to specify const-ness at every point. Presumably
>>> you'd have to specify write-ability at every point too.
>>
>> Yes -- and a single keyword should be enough for that.
>
> You mean, a single keyword inserted at N different points? And which is
> only possible to do when 100% of the type specification is available at
> the point of declaration? That's nearly as much a mess as before.
How big do you expect N to be in the typical case? If a function takes
an argument that's a pointer to pointer to pointer to char, how many
levels do you expect that function to be able to modify?
I probably shouldn't use C's rather convoluted declaration syntax.
Making declaration follow use was a clever idea, but IMHO the amount of
confusion it's caused indicates that it was a mistake. I might have a
syntax like:
p: pointer to pointer to pointer to char;
If it's a parameter, and the function needs to be able to modify the
character data but not any of the pointers, it might be:
p: pointer to pointer to pointer to rw char;
Or if the caller needs to modify the char pointers but not the character
data:
p: pointer to pointer to rw pointer to char;
which makes the char data itself implicitly read-only. This:
p: rw pointer to rw pointer to rw pointer to rw char;
would be legal, but rarely necessary -- and in those rare cases, I think
the syntax is quite clear.
In C, the need to add "const" for read-only data makes it easier to
ignore the issue and declare:
char ***p;
And yes, it's more complicated than it should be to figure out where to
add the "const" keyword if you want to protect the char* pointers from
modification. The need for a tool like cdecl is a strong indication
that C's declaration syntax is too confusing.
> But I do like it when you propose a new language that had no need for
> backwards compatibility, you then proceed to drag in most of the baggage
> of the old one!
If you can think of a cleaner way to let programmers specify that
certain objects are read-only, with the compiler enforcing that
restriction, I'd be interested in seeing it. If you think that
specifying objects as read-only is not worthwhile, we'll just have to
disagree.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2014-12-24 23:46 +0000 |
| Message-ID | <7fImw.184892$G23.10501@fx44.am4> |
| In reply to | #55417 |
On 24/12/2014 22:53, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 24/12/2014 20:57, Keith Thompson wrote:
>> You mean, a single keyword inserted at N different points? And which is
>> only possible to do when 100% of the type specification is available at
>> the point of declaration? That's nearly as much a mess as before.
>
> How big do you expect N to be in the typical case?
Even with a simple pointer, N is two. And pointer-to-pointer is fairly
common, making N=3.
> If a function takes
> an argument that's a pointer to pointer to pointer to char, how many
> levels do you expect that function to be able to modify?
It only seems to be with C that the issue becomes so complex; anywhere
else, either the entire data structure is writable, or none of it.
Using const becomes messy, but also can't be applied everywhere: only
where parts of the type-spec are exposed in the parameter list.
And take a simple example such as passing a struct (either by value or
via a pointer), which contains pointer members. How are the latter
protected from writing? They can't be without a lot of trouble.
> p: rw pointer to rw pointer to rw pointer to rw char;
>
> would be legal, but rarely necessary -- and in those rare cases, I think
> the syntax is quite clear.
Yes this is much clearer. But I still don't like these rw attributes.
Take your own example:
> char ***p;
A 2D table of strings perhaps. Using consts allows you to individually
control whether you can write to a row, to a column, or to an character
in a string. But when are you going to need that much control? And what
does it mean when you stick a const in the middle?
> If you can think of a cleaner way to let programmers specify that
> certain objects are read-only, with the compiler enforcing that
> restriction, I'd be interested in seeing it. If you think that
> specifying objects as read-only is not worthwhile, we'll just have to
> disagree.
As you know I do sometimes create languages of my own. Usually they have
less restrictions that C, but I do enforce the difference between a
pointer, and an array. (I think C could do this as well, except the
syntax then needed for indexing makes it awkward.)
So take a function taking an int* parameter, and a call such as:
int a;
fn(&a);
Now, there is nothing in the language that will stop anyone writing:
void fn(int* p) {
p[23]=0;
}
To me that is a bigger sin than not making use of const on parameters.
(Of course I do still allow the equivalent of *(p+23)=0, but it's clear
that that is pointer arithmetic. C uses indexing all the time on T*
types so it will rarely raise eyebrows, and certainly the C compiler
will not complain.
And while I don't currently need two pointer types to match exactly,
enabling that would catch the error above when I pass a pointer to a
/single/ int, to a function that would declare a pointer to an /array/
as the parameter.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <pc+usenet@asdf.org> |
|---|---|
| Date | 2015-01-03 01:48 +0200 |
| Message-ID | <87bnmg3fs5.fsf@bazspaz.fatphil.org> |
| In reply to | #55417 |
Keith Thompson <kst-u@mib.org> writes: > *Most* objects don't change their values once they're initialized. For > those that do, often the code can be rearranged to avoid it; being able > to mix declarations and statements helps with this. I've not checked, but I'm pretty sure that's not true for most of my code any more. Before compilers learnt about SSA, it may have been true, but since then, such a coding style is basically just doing the compiler's job for it. And nowadays, I find most compilers are at least as competent at doing their job as I am. Phil -- The best part of re-inventing the wheel is that you get to pick how many sides the new one has. -- egcagrac0 on SoylentNews
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web