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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-25 23:33 -0700 |
| Message-ID | <e7ba96ae-9d01-47c1-8df0-ced45600b579@googlegroups.com> |
| In reply to | #58997 |
W dniu czwartek, 26 marca 2015 02:42:09 UTC+1 użytkownik Les Cargill napisał:
> fir wrote:
> > W dniu wtorek, 24 marca 2015 17:16:15 UTC+1 użytkownik Tim Rentsch napisał:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>
> >>> On Wednesday, December 24, 2014 11:19:19 AM UTC, Bart wrote:
> >>>>
> >>>> 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.
> >>>
> >>> [discussing some of the implications of using const]
> >>>
> >>> So Denis Ritchie opposed the introduction of const. [snip]
> >>
> >> You're wrong about that. During the ANSI standardization process,
> >> Dennis Ritchie objected to one particular aspect of rules related to
> >> 'const' types. But the implication in question was simply an
> >> inadvertent error (as he himself remarked, "In discussion with
> >> various X3J11 members, I learned that this section is now regarded
> >> as an inadvertant error, and no one thinks that it will last in its
> >> current form"), and indeed the passage in question did not make it
> >> into the Standard.
> >
> > const.. i never used it (except very rare spare const ints like "const int n = 5", nothing more)
> > what is really use of it? i dont seem to see it as something too much usable..
> >
>
> const float angle = 90.0;
> const float EPSI = (FLT_EPSILON * 1000.0);
> const float TAN_UNDEF = FLT_MAX;
> {
> const float sinA = sin(angle);
> const float cosA = cos(angle);
> const float tanA = (abs(cos)>EPSI) ? (sin/cos) : TAN_UNDEF;
> ...
> }
>
> That's just the one "use case".
>
> "const char * const p = ...." gets some use, too.
> If there's a "const" violation down the page, I at
> least have to think about things before removing
> one or both of the "const"s .
>
> I try to make as much stuff immutable as possible.
>
from this example abowe doesnt seem to be terrific usable too
i understand this is
ADVANTAGES
1) many consts of the same value could be stored in the same bytes (though seem to be really rare probably)
2) is compile 'guard' against incidental revrite (seem to be also extreamlly rare
case - tending to be factual zero probably)
DISADVANTAGES
1) longer code
besides im not sure if code that uses consts
is more or less readable, * [[theoretically a way of distinguishing that some data bassed by pointer are notchangeble is good - but this is
at all bad in c , i would change it at all but if so i would prefer explicitely denoting those that are modificable not those that are not etc]]
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) [?]
* trouble seem that if using const one would need track in code each variabkle if is const or not and that is a big amount of work clowing down coding and not sure if worth it
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-26 03:02 -0700 |
| Message-ID | <06830a79-a412-4962-9a9d-82d67ef92011@googlegroups.com> |
| In reply to | #59002 |
On Thursday, March 26, 2015 at 6:34:08 AM UTC, fir wrote: > > from this example abowe doesnt seem to be terrific usable too > i understand this is > ADVANTAGES > 1) many consts of the same value could be stored in the same bytes (though seem to > be really rare probably) > Only relevant on small embedded systems, where you'd usually want to merge by hand anyway. > > 2) is compile 'guard' against incidental revrite (seem to be also extreamlly rare > case - tending to be factual zero probably) > 3) It documents whether a pointer parameter is input or output. 4) There's a school of thought that parameters shouldn't be modified in functions. const can enforce that. 5) helps the compiler resolve alining issues. > DISADVANTAGES > 1) longer code > 2) const poisoning - it propagates to everything it touches. 3) internals of an opaque structure are no business of caller. const breaks that paradigm. 4) Not really a disadvantage, but it guards against an error that isn't very likely, and will usually be caught early on. It's easy for the compiler to catch, which is the motive.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-26 23:34 -0500 |
| Message-ID | <mf2mbc$66m$2@dont-email.me> |
| In reply to | #59011 |
Malcolm McLean wrote: > On Thursday, March 26, 2015 at 6:34:08 AM UTC, fir wrote: >> >> from this example abowe doesnt seem to be terrific usable too >> i understand this is >> ADVANTAGES >> 1) many consts of the same value could be stored in the same bytes (though seem to >> be really rare probably) >> > Only relevant on small embedded systems, where you'd usually want to merge by > hand anyway. >> >> 2) is compile 'guard' against incidental revrite (seem to be also extreamlly rare >> case - tending to be factual zero probably) >> > 3) It documents whether a pointer parameter is input or output. > 4) There's a school of thought that parameters shouldn't be modified in functions. > const can enforce that. > 5) helps the compiler resolve alining issues. >> DISADVANTAGES >> 1) longer code >> > 2) const poisoning - it propagates to everything it touches. True that. I find this less onerous than most. It is a bit annoying in furniture located in libraries people have to use. > 3) internals of an opaque structure are no business of caller. const breaks that > paradigm. Declaring a parameter const is a contract not to change a parameter. So it's an interface ... thing, not about the internals. > 4) Not really a disadvantage, but it guards against an error that isn't very likely, > and will usually be caught early on. It's easy for the compiler to catch, which > is the motive. > Right. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-27 12:38 -0700 |
| Message-ID | <63fe1d33-5bdf-44bc-9d96-1a00712270e2@googlegroups.com> |
| In reply to | #59053 |
On Friday, March 27, 2015 at 4:30:36 AM UTC, Les Cargill wrote:
> Malcolm McLean wrote:
> >
> > 3) internals of an opaque structure are no business of caller. const breaks that
> > paradigm.
>
>
> Declaring a parameter const is a contract not to change a parameter. So
> it's an interface ... thing, not about the internals.
>
Say we've got this.
typedef struct
{
PORT *intefacetoio;
long currentposition;
} FILE;
long ftell(FILE *fp)
{
return file->currentposition;
}
In const-world, that should be
long ftell(const FILE *fp)
{
return file->currentposition;
}
because ftell is a read operation.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-28 12:02 +1300 |
| Message-ID | <cnm5t0F1tlmU3@mid.individual.net> |
| In reply to | #59100 |
Malcolm McLean wrote:
> On Friday, March 27, 2015 at 4:30:36 AM UTC, Les Cargill wrote:
>> Malcolm McLean wrote:
>>>
>>> 3) internals of an opaque structure are no business of caller. const breaks that
>>> paradigm.
No, it does not. The internals may not matter to the caller, but the
sate does.
>> Declaring a parameter const is a contract not to change a parameter. So
>> it's an interface ... thing, not about the internals.
>>
> Say we've got this.
>
> typedef struct
> {
> PORT *intefacetoio;
> long currentposition;
> } FILE;
>
> long ftell(FILE *fp)
> {
> return file->currentposition;
> }
>
> In const-world, that should be
>
> long ftell(const FILE *fp)
> {
> return file->currentposition;
>
> }
>
> because ftell is a read operation.
It may well be. If the implementer of ftell knows (and his
specification states that) the function will not modify the object, then
the parameter can and probably should be const.
By guaranteeing to the user that the object sate will not change, the
user knows any state information obtained before the call will still be
valid after the call and won't have to be reread. This simplifies the
user's code and improves performance by not having to reload a value.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-27 16:39 -0700 |
| Message-ID | <87bnjem2nd.fsf@kst-u.example.com> |
| In reply to | #59100 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, March 27, 2015 at 4:30:36 AM UTC, Les Cargill wrote:
>> Malcolm McLean wrote:
>> >
>> > 3) internals of an opaque structure are no business of
>> > caller. const breaks that paradigm.
>>
>>
>> Declaring a parameter const is a contract not to change a parameter. So
>> it's an interface ... thing, not about the internals.
>>
> Say we've got this.
>
> typedef struct
> {
> PORT *intefacetoio;
> long currentposition;
> } FILE;
>
> long ftell(FILE *fp)
> {
> return file->currentposition;
> }
>
> In const-world, that should be
>
> long ftell(const FILE *fp)
> {
> return file->currentposition;
>
> }
>
> because ftell is a read operation.
Maybe. Since the definition of type FILE is unspecified, we don't
know that ftell() doesn't modify the FILE object (perhaps operations
could be logged in memory). But since FILE is an opaque type, it
probably doesn't matter a whole lot whether the parameter is const
or not. No portable C code can do anything with the contents of
a FILE object anyway.
If the parameter were const, an implementation that wants to update
something could just include a pointer to non-const data as a member
of its FILE type.
If a future standard changed the definition to
long ftell(const FILE *fp);
I don't think it would break any existing portable code.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-27 17:18 -0700 |
| Message-ID | <edefb5d1-e150-4108-8ba1-a1e5c8891483@googlegroups.com> |
| In reply to | #59108 |
On Friday, March 27, 2015 at 11:39:32 PM UTC, Keith Thompson wrote: > > Maybe. Since the definition of type FILE is unspecified, we don't > know that ftell() doesn't modify the FILE object (perhaps operations > could be logged in memory). But since FILE is an opaque type, it > probably doesn't matter a whole lot whether the parameter is const > or not. No portable C code can do anything with the contents of > a FILE object anyway. > > If the parameter were const, an implementation that wants to update > something could just include a pointer to non-const data as a member > of its FILE type. > > If a future standard changed the definition to > > long ftell(const FILE *fp); > > I don't think it would break any existing portable code. > It could break some existing ftell() implementations, however.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-28 13:34 +1300 |
| Message-ID | <cnmb91F1tlmU5@mid.individual.net> |
| In reply to | #59110 |
Malcolm McLean wrote: > On Friday, March 27, 2015 at 11:39:32 PM UTC, Keith Thompson wrote: >> >> Maybe. Since the definition of type FILE is unspecified, we don't >> know that ftell() doesn't modify the FILE object (perhaps operations >> could be logged in memory). But since FILE is an opaque type, it >> probably doesn't matter a whole lot whether the parameter is const >> or not. No portable C code can do anything with the contents of >> a FILE object anyway. >> >> If the parameter were const, an implementation that wants to update >> something could just include a pointer to non-const data as a member >> of its FILE type. >> >> If a future standard changed the definition to >> >> long ftell(const FILE *fp); >> >> I don't think it would break any existing portable code. >> > It could break some existing ftell() implementations, however. Progress doesn't always come for free. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-03-27 22:09 -0400 |
| Message-ID | <B3oRw.97938$tF6.87755@fx11.iad> |
| In reply to | #59110 |
On 3/27/15 8:18 PM, Malcolm McLean wrote: > On Friday, March 27, 2015 at 11:39:32 PM UTC, Keith Thompson wrote: >> >> Maybe. Since the definition of type FILE is unspecified, we don't >> know that ftell() doesn't modify the FILE object (perhaps operations >> could be logged in memory). But since FILE is an opaque type, it >> probably doesn't matter a whole lot whether the parameter is const >> or not. No portable C code can do anything with the contents of >> a FILE object anyway. >> >> If the parameter were const, an implementation that wants to update >> something could just include a pointer to non-const data as a member >> of its FILE type. >> >> If a future standard changed the definition to >> >> long ftell(const FILE *fp); >> >> I don't think it would break any existing portable code. >> > It could break some existing ftell() implementations, however. > As long as none of the FILE objects are actually declared const, ftell is allowed to cast away the const and alter the FILE object.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-28 05:41 -0700 |
| Message-ID | <3f031d7f-329b-4d9a-aeae-743b8bf65ea0@googlegroups.com> |
| In reply to | #59114 |
On Saturday, March 28, 2015 at 2:09:48 AM UTC, Richard Damon wrote: > On 3/27/15 8:18 PM, Malcolm McLean wrote: > > > >> I don't think it would break any existing portable code. > >> > > It could break some existing ftell() implementations, however. > > > > As long as none of the FILE objects are actually declared const, ftell > is allowed to cast away the const and alter the FILE object. > C is wonderful like that. C++ allows a member to be declared "mutable". But the next logical step is to introduce an "immutable" keyword to make mutable members read-only.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-03-29 15:24 +0000 |
| Message-ID | <55181906.21437296@news.xs4all.nl> |
| In reply to | #59124 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Saturday, March 28, 2015 at 2:09:48 AM UTC, Richard Damon wrote: > > As long as none of the FILE objects are actually declared const, ftell > > is allowed to cast away the const and alter the FILE object. > > > C is wonderful like that. > > C++ allows a member to be declared "mutable". But the next logical step > is to introduce an "immutable" keyword to make mutable members > read-only. And then, of course, to introduce a <mutable_cast> to cast away (or to add!) immutability... Richard
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-26 10:37 +0000 |
| Message-ID | <mf0nf9$l39$1@dont-email.me> |
| In reply to | #59002 |
On 26/03/2015 06:33, fir wrote:
> W dniu czwartek, 26 marca 2015 02:42:09 UTC+1 użytkownik Les Cargill napisał:
>> const float angle = 90.0;
>> const float EPSI = (FLT_EPSILON * 1000.0);
>> const float TAN_UNDEF = FLT_MAX;
>> {
>> const float sinA = sin(angle);
>> const float cosA = cos(angle);
>> const float tanA = (abs(cos)>EPSI) ? (sin/cos) : TAN_UNDEF;
>> ...
>> }
>>
>> That's just the one "use case".
>>
>> "const char * const p = ...." gets some use, too.
>> If there's a "const" violation down the page, I at
>> least have to think about things before removing
>> one or both of the "const"s .
>>
>> I try to make as much stuff immutable as possible.
>>
> from this example abowe doesnt seem to be terrific usable too
> i understand this is
I don't like 'const' as used in C, where it doesn't really define a
constant, but suggests that a variable is read-only.
> ADVANTAGES
> 1) many consts of the same value could be stored in the same bytes (though seem to be really rare probably)
With a proper named constant (as you might get in C with '#define N 5'
or 'enum {n=5}'), this would be irrelevant, because the value doesn't
need to be stored anywhere; it will be immediate data.
But there is one advantage of a C-style const, is that you can take its
address (to pass to a function for example).
> 2) is compile 'guard' against incidental revrite (seem to be also extreamlly rare
> case - tending to be factual zero probably)
> DISADVANTAGES
> 1) longer code
As far as I'm concerned, 'const' is just extra clutter. And some people
like to stick it in nearly everywhere.
And that leads to type conflicts. So if you pass a pointer to that const
int to a function that takes 'int*', then you'll get a type warning.
You'd have to change the parameter type to 'const int*'. This is the
start of the 'const poisoning' that Malcolm is on about.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-26 05:56 -0700 |
| Message-ID | <540a9e02-2615-4184-be27-582533ff61f1@googlegroups.com> |
| In reply to | #59013 |
W dniu czwartek, 26 marca 2015 11:37:25 UTC+1 użytkownik Bart napisał:
> On 26/03/2015 06:33, fir wrote:
> > W dniu czwartek, 26 marca 2015 02:42:09 UTC+1 użytkownik Les Cargill napisał:
>
> >> const float angle = 90.0;
> >> const float EPSI = (FLT_EPSILON * 1000.0);
> >> const float TAN_UNDEF = FLT_MAX;
> >> {
> >> const float sinA = sin(angle);
> >> const float cosA = cos(angle);
> >> const float tanA = (abs(cos)>EPSI) ? (sin/cos) : TAN_UNDEF;
> >> ...
> >> }
> >>
> >> That's just the one "use case".
> >>
> >> "const char * const p = ...." gets some use, too.
> >> If there's a "const" violation down the page, I at
> >> least have to think about things before removing
> >> one or both of the "const"s .
> >>
> >> I try to make as much stuff immutable as possible.
> >>
> > from this example abowe doesnt seem to be terrific usable too
> > i understand this is
>
> I don't like 'const' as used in C, where it doesn't really define a
> constant, but suggests that a variable is read-only.
>
partially i agree (for some reeasons i got on my mind but recently forgot (really, i only remember i was thinking on it)
on the other side is quite opposite
(I was writing ago months ago) : const
really does not "belong to whole instance
" it is more like identifier of some reference to variable, not whole variable
jou could have X that has 10 writable references, and 11 const references -
so this is right, (though probably just from the same reasons the const poisoning is bad
and wrong - i dont exactly remember those poisoning, could maybe someone give clear snippet example ... ??
poisoning is here??? ->
///////////
void foo(int value);
const int x = 10;
foo(x);
///////////
or poisoning is here??? ->
///////////
void foo(const int value);
int x = 10;
foo(x);
////////
also such 'defferred const' (when you calculate it in runtime then assign and later it is ok) also seem ok to me
im not sure as to total onst (oldschool ones)
they are probably ok, but probably should not be used in agrs as the function (requiring the
passed value to be also total const) - this probably would be this poisoning and this seem very bad
so imo probably this is like
- const of reference - ok
- deferred consts - ok
- total const - only in oldschol way (root locations)
- poisoning - bad, (need be removed/repaired)
- const usability - right now it presents to me as somewhat doubtfull, limited is okay,
[for sure if you got a global and initialised
table of const not meant to be changed here const should be used]
(if changed that in c args are for read only
[as i proposed in c2 improvements, there is no
pasing struct by value thet are passed by ref
and read only, value may be by keyvord val
and for write only by some keyword or disallowed at all)
x, y = fu(x,y,z); //wana also write to x and y structures pass it on left side
on ABI level it is passing adresses, x,y,z
exist on upper scope onlt fu only referencing it
]
no const is needed here, aliasing problems vanished etc, [clear syntax no explicit pointers and explicit consts]
so args const not needed, (at least seems so)
maniacal denoting locals as consts? not sure,
often probably such value yelds to two values one ist (here implicit) const used to initialisation, other is ram value that could be reused in calculattions, i dot know, it would need to see
> > ADVANTAGES
> > 1) many consts of the same value could be stored in the same bytes (though seem to be really rare probably)
>
> With a proper named constant (as you might get in C with '#define N 5'
> or 'enum {n=5}'), this would be irrelevant, because the value doesn't
> need to be stored anywhere; it will be immediate data.
>
> But there is one advantage of a C-style const, is that you can take its
> address (to pass to a function for example).
>
> > 2) is compile 'guard' against incidental revrite (seem to be also extreamlly rare
> > case - tending to be factual zero probably)
> > DISADVANTAGES
> > 1) longer code
>
> As far as I'm concerned, 'const' is just extra clutter. And some people
> like to stick it in nearly everywhere.
>
i also tend to think so (partially)
> And that leads to type conflicts. So if you pass a pointer to that const
> int to a function that takes 'int*', then you'll get a type warning.
> You'd have to change the parameter type to 'const int*'. This is the
> start of the 'const poisoning' that Malcolm is on about.
>
> --
> Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-26 06:23 -0700 |
| Message-ID | <d3cf3e97-33ed-43ca-bb30-6435146a06ac@googlegroups.com> |
| In reply to | #59016 |
W dniu czwartek, 26 marca 2015 13:57:04 UTC+1 użytkownik fir napisał: > and wrong - i dont exactly remember those poisoning, could maybe someone give clear snippet example ... ?? > > poisoning is here??? -> > > /////////// > void foo(int value); > > const int x = 10; > foo(x); > > /////////// > > or poisoning is here??? -> > /////////// > void foo(const int value); > > int x = 10; > foo(x); > //////// as to those above snippets i dont know how it is now in c but imo those two abowe should work with no complain rethink yet what with structures: pass a const structure to function that takes non const one: should work imo though if fu() modifies the structure it would be a violation - so compiler should maybe not react on situations where just const structure is passed to non const consumer function (as it may work or no depending on what fu(doees) but detect if fu() is writing type - if so compiler error pass a non const structure to function that takes const - no problem should be no reaction - so in general imo no poisoning should be implied on args, passing const to non-const consumer could rise an compilation error if fu(0 is really writing [as many people in librarier maybe not dentoe is function is really writing it my rise some problems, it seem such lib function should denote in abi if they are really writing or not - otherwise it may yeild to 'reverse poisoning' lib that enforces arg to be non const with no real need ]
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-03-26 10:07 -0700 |
| Message-ID | <9c88d495-8606-4b8f-b24c-4d6b8d63372f@googlegroups.com> |
| In reply to | #59017 |
Fir wrote: << as to those above snippets i dont know how it is now in c but imo those two abowe should work with no complain rethink yet what with structures: pass a const structure to function that takes non const one: should work imo though if fu() modifies the structure it would be a violation - so compiler should maybe not react on situations where just const structure is passed to non const consumer function (as it may work or no depending on what fu(doees) but detect if fu() is writing type - if so compiler error pass a non const structure to function that takes const - no problem should be no reaction - so in general imo no poisoning should be implied on args, passing const to non-const consumer could rise an compilation error if fu(0 is really writing [as many people in librarier maybe not dentoe is function is really writing it my rise some problems, it seem such lib function should denote in abi if they are really writing or not - otherwise it may yeild to 'reverse poisoning' lib that enforces arg to be non const with no real need ] >> const type a=987; Has only one meaning if what is declared const is the memory in the range [&a..&a+sizeof(type)] And all with usual const arg of function: Exapmle int F( type* const v); That not change what its arg point Than in code F(a); That would say F use what 'a' points but not change 'a' If int g( type* v); Change what v point to Than in code g(a); Would change what 'a' point to but that memory is const => segfault But I prefer a language without const etc... I not see the utility of that..
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2015-03-26 10:16 -0700 |
| Message-ID | <31f14cd3-fdaa-4aba-bb21-db57d0e452df@googlegroups.com> |
| In reply to | #59032 |
I make some errors... Possible no one understand my English... Anyway... [possible I think wrong in all languages I think too...] const type a=987; Has only one meaning if what is declared const is the memory in the range [&a..&a+sizeof(type)] And all with usual const arg of functions: Exapmle int F( type* const v); That not change what its arg point Than in code F(&a); That would say F use what 'a' points to but not change 'a' If int g( type* v); Change what v points to Than in code g(&a); Would change what 'a' point to but that memory is const => segfault But I prefer a language without const etc... I not see the utility of that..
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-26 06:30 -0700 |
| Message-ID | <ee6e769c-eb67-45c8-b260-7f2d0c443238@googlegroups.com> |
| In reply to | #59016 |
W dniu czwartek, 26 marca 2015 13:57:04 UTC+1 użytkownik fir napisał: > > on the other side is quite opposite > (I was writing ago months ago) : const > really does not "belong to whole instance > " it is more like identifier of some reference to variable, not whole variable > one could consider part-time const and part-space consts this 'deferred' one is part-time one (form now till end, ot till other time - sych part const could be usable part-space would be const int x except foo(); // ;-0 read for all acceses except for one place in code that culd modify it (this shows that const is bad name as it should be read/readonly if one means space, probably can stay 'const' if one means time, (not sure need more exploration))
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-26 08:39 -0700 |
| Message-ID | <87sicrojir.fsf@kst-u.example.com> |
| In reply to | #59013 |
Bartc <bc@freeuk.com> writes:
[...]
> I don't like 'const' as used in C, where it doesn't really define a
> constant, but suggests that a variable is read-only.
Yes, that's exactly what const means. Would you like it better if it
were spelled "readonly"?
[...]
> As far as I'm concerned, 'const' is just extra clutter. And some
> people like to stick it in nearly everywhere.
In my experience, people don't use it enough. I see code that defines
and initializes an object and then never changes it, If it had been
defined with "const", I would *know* that it still has its initial
value (without looking for code that modifies it).
> And that leads to type conflicts. So if you pass a pointer to that
> const int to a function that takes 'int*', then you'll get a type
> warning. You'd have to change the parameter type to 'const int*'. This
> is the start of the 'const poisoning' that Malcolm is on about.
If the function doesn't modify the object the pointer points to, the
parameter probably should have been defined as "const int*" in the first
place.
As I've said before, I personally would prefer "const" to be the
default, with a keyword that has to be added if you want to be able to
modify an object. Of course I'm not suggesting any such change 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-26 09:26 -0700 |
| Message-ID | <b8d2f63b-4c04-4cc1-8fd5-06628c191459@googlegroups.com> |
| In reply to | #59026 |
On Thursday, March 26, 2015 at 3:39:46 PM UTC, Keith Thompson wrote:
>
> If the function doesn't modify the object the pointer points to, the
> parameter probably should have been defined as "const int*" in the first
> place.
>
My binary image library has quite a few functions of the form
/* image must be 1 for set pixels, 0 for unset pixels
RESULTS *analyseimage(unsigned char *image, int width, int height)
{
/* set a contiguous region to 2 */
floodfill(image, width, height, x, y, 2);
/* process it somehow, e.g. count the pixels */
...
result = countof2s();
/* set it back to 1 */
floodfill(image, width, height, x, y, 2);
return result;
}
The image isn't modified, but the spare bits are used to avoid potentially failing allocation
functions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-26 10:53 -0700 |
| Message-ID | <87k2y3odai.fsf@kst-u.example.com> |
| In reply to | #59030 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, March 26, 2015 at 3:39:46 PM UTC, Keith Thompson wrote:
>> If the function doesn't modify the object the pointer points to, the
>> parameter probably should have been defined as "const int*" in the first
>> place.
>>
> My binary image library has quite a few functions of the form
>
> /* image must be 1 for set pixels, 0 for unset pixels
> RESULTS *analyseimage(unsigned char *image, int width, int height)
> {
> /* set a contiguous region to 2 */
> floodfill(image, width, height, x, y, 2);
>
> /* process it somehow, e.g. count the pixels */
> ...
> result = countof2s();
>
> /* set it back to 1 */
> floodfill(image, width, height, x, y, 2);
>
> return result;
> }
>
> The image isn't modified, but the spare bits are used to avoid
> potentially failing allocation functions.
Which is why I wrote "probably". This function *is* modifying the image
temporarily -- which means it could blow up if the image is defined as a
static const array and the compiler decides to store in in memory marked
as read-only. Declaring `image` as `const unsigned char *image` would
prevent such calls, but it would also prevent the function from doing
its temporary modification.
const lets you tell the compiler that an object is read-only. It
doesn't let you tell the compiler that you want to modify an object
temporarily, and you promise to put it back the way you found it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web