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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-28 15:09 -0700 |
| Message-ID | <00d72c55-1533-458c-b587-6e7e48e083bf@googlegroups.com> |
| In reply to | #59163 |
On Saturday, March 28, 2015 at 9:28:19 PM UTC, Ian Collins wrote: > Melzzzzz wrote: > > Casting from void* is not so much pointless in C++ as something you > hardly ever have to do. > Yes, Baby X is written in C, and practically every widget has at least one callback, which passes back a void *. In C++, or most languages, you'd either provide a function called "button pressed" to an interface, which the button would call when pressed, or the button would be templated with a function object / lambda type function. I prefer the C method. Linking by name is a bit restrictive, and difficult to document. Lambdas are better in that respect, but the syntax is weird (in C++). In particular it's annoying to have parentheses enclosing a function body. The convention is to use them for very limited, local delimiting. Also, with C it's no problem to have the void * a null, if you just want to do everything via global state.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-28 21:46 +0000 |
| Message-ID | <mf77ed$os7$2@dont-email.me> |
| In reply to | #59160 |
On 28/03/15 21:20, Les Cargill wrote: <snip> > Say I have a symbol table object that contains a void * for > the thing being symbolized. I'd rather do that Fine. > - and cast - Why? You don't need to. -- 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-29 09:54 -0500 |
| Message-ID | <mf93dt$osc$1@dont-email.me> |
| In reply to | #59169 |
Richard Heathfield wrote: > On 28/03/15 21:20, Les Cargill wrote: > > <snip> > >> Say I have a symbol table object that contains a void * for >> the thing being symbolized. I'd rather do that > > Fine. > > >> - and cast - > > Why? You don't need to. > You do when you want to serialize it or do math with it: float z = *(float *)symbolTable[k].objectPointer; char *s = (char *)symbolTable[j].objectPointer; -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-29 15:54 +0100 |
| Message-ID | <mf93ln$ot1$1@dont-email.me> |
| In reply to | #59206 |
On 29/03/15 15:54, Les Cargill wrote: > Richard Heathfield wrote: >> On 28/03/15 21:20, Les Cargill wrote: >> >> <snip> >> >>> Say I have a symbol table object that contains a void * for >>> the thing being symbolized. I'd rather do that >> >> Fine. >> >> >>> - and cast - >> >> Why? You don't need to. > > You do when you want to serialize it or do math with it: > > float z = *(float *)symbolTable[k].objectPointer; > char *s = (char *)symbolTable[j].objectPointer; <shrug> I'd use float *pz = symbolTable[k].objectPointer and then deref pz when I had to. This would also allow me to update the object in due course, should that be necessary, without having to grab its address again. Is it possible to adopt a programming style that requires frequent casts? Yes, of course. Is it necessary to adopt such a style? No, of course not. -- 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-29 19:04 -0500 |
| Message-ID | <mfa3ju$o0q$4@dont-email.me> |
| In reply to | #59207 |
Richard Heathfield wrote: > On 29/03/15 15:54, Les Cargill wrote: >> Richard Heathfield wrote: >>> On 28/03/15 21:20, Les Cargill wrote: >>> >>> <snip> >>> >>>> Say I have a symbol table object that contains a void * for >>>> the thing being symbolized. I'd rather do that >>> >>> Fine. >>> >>> >>>> - and cast - >>> >>> Why? You don't need to. >> >> You do when you want to serialize it or do math with it: >> >> float z = *(float *)symbolTable[k].objectPointer; >> char *s = (char *)symbolTable[j].objectPointer; > > > <shrug> I'd use float *pz = symbolTable[k].objectPointer and then deref > pz when I had to. This would also allow me to update the object in due > course, should that be necessary, without having to grab its address again. > > Is it possible to adopt a programming style that requires frequent > casts? Yes, of course. Is it necessary to adopt such a style? No, of > course not. > That's the problem - it *CAN BE* necessary. I don't add unecessary casts just to be doing it, but perhaps you've not seen some of the code bases I have... I still maintain the judicious use of "const" is to the good. Of course you don't have to use it at all. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-30 08:00 +0100 |
| Message-ID | <mfas93$rhb$2@dont-email.me> |
| In reply to | #59241 |
On 30/03/15 01:04, Les Cargill wrote: > Richard Heathfield wrote: <snip> >> >> Is it possible to adopt a programming style that requires frequent >> casts? Yes, of course. Is it necessary to adopt such a style? No, of >> course not. > > That's the problem - it *CAN BE* necessary. Yes, in much the same way that it can be necessary to clean out sugar from your petrol tank. I never have to do this, however, because I don't allow sugar to get into the petrol tank in the first place. Programming with only a very few casts (and not the ones you might expect) is not only possible but easy. > I don't add unecessary casts > just to be doing it, but perhaps you've not seen some of the code bases > I have... If you're using a cast to add a const qualifier to an argument before passing it to a function, I would suggest that you may well be adding unnecessary casts just to be doing it. > I still maintain the judicious use of "const" is to the good. Of course > you don't have to use it at all. Oh, I'm with you there. It's your casting that I have issues with. -- 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 07:58 -0500 |
| Message-ID | <mfbh01$l32$1@dont-email.me> |
| In reply to | #59249 |
Richard Heathfield wrote: > On 30/03/15 01:04, Les Cargill wrote: >> Richard Heathfield wrote: > > <snip> >>> >>> Is it possible to adopt a programming style that requires frequent >>> casts? Yes, of course. Is it necessary to adopt such a style? No, of >>> course not. >> >> That's the problem - it *CAN BE* necessary. > > Yes, in much the same way that it can be necessary to clean out sugar > from your petrol tank. I never have to do this, however, because I don't > allow sugar to get into the petrol tank in the first place. > > Programming with only a very few casts (and not the ones you might > expect) is not only possible but easy. > I would not disagree. Indeed, it is possible to do without it altogether. > > I don't add unecessary casts >> just to be doing it, but perhaps you've not seen some of the code bases >> I have... > > If you're using a cast to add a const qualifier to an argument before > passing it to a function, I would suggest that you may well be adding > unnecessary casts just to be doing it. > That well may be - but there's a ... documentary aspect of having const parameters that may be to the good. Casting in that case says "for the lifetime of this call, this thing is const". This means you're using the compiler to check for the proper mutability state of a variable. >> I still maintain the judicious use of "const" is to the good. Of course >> you don't have to use it at all. > > Oh, I'm with you there. It's your casting that I have issues with. > Don't assume it's *my* casting in most cases :) We don't all get a clean whiteboard every project. My principal use of const is to have local variables with very short lifetime to reduce the strength of expressions. That's purely done out of pity for future maintainers. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-30 14:29 +0100 |
| Message-ID | <mfbj2u$v49$1@dont-email.me> |
| In reply to | #59267 |
On 30/03/15 13:58, Les Cargill wrote: > Richard Heathfield wrote: >> >> Programming with only a very few casts (and not the ones you might >> expect) is not only possible but easy. > > I would not disagree. Indeed, it is possible to do without it altogether. Perhaps. >> > I don't add unecessary casts >>> just to be doing it, but perhaps you've not seen some of the code bases >>> I have... >> >> If you're using a cast to add a const qualifier to an argument before >> passing it to a function, I would suggest that you may well be adding >> unnecessary casts just to be doing it. >> > > That well may be - but there's a ... documentary aspect of having > const parameters that may be to the good. > > Casting in that case says "for the lifetime of this call, this > thing is const". This means you're using the compiler to check for > the proper mutability state of a variable. No, it's just a waste of time. If the parameter type is const, that's all we need to know. No need whatsoever to cast, and no benefit accrues if we do. <snip> -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-30 07:35 -0700 |
| Message-ID | <kfnd23q5zae.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #59206 |
Les Cargill <lcargill99@comcast.com> writes:
> Richard Heathfield wrote:
>> On 28/03/15 21:20, Les Cargill wrote:
>>
>> <snip>
>>
>>> Say I have a symbol table object that contains a void * for
>>> the thing being symbolized. I'd rather do that
>>
>> Fine.
>>
>>
>>> - and cast -
>>
>> Why? You don't need to.
>
> You do when you want to serialize it or do math with it:
>
> float z = *(float *)symbolTable[k].objectPointer;
> char *s = (char *)symbolTable[j].objectPointer;
Note that you can do these (in C99 or later) without
using casts:
float z = *(float *){ symbolTable[k].objectPointer };
char *s = (char *){ symbolTable[j].objectPointer };
or for the second one, just
char *s = symbolTable[j].objectPointer;
given that the 'objectPointer' member is of type (void *).
IMO this form is preferable to casting, since only "safe"
conversions are allowed (ie, without some sort of warning
or error), which is decidedly not so with casting.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-27 16:14 +0000 |
| Message-ID | <mf3vj3$o7r$1@dont-email.me> |
| In reply to | #59054 |
On 27/03/2015 04:42, Les Cargill wrote: > Bartc wrote: >> 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. >> > > So what is wrong with that? I use 'const' in other languages to mean Pascal-style const. So personally C's use of it conflicts with that. But I've seen enough posts here about it over the years that it seems quite a few other people have the same misunderstanding. > Then you run into header file manipulation - which is fine. > I think you can also have extern references to it. If C had proper named constants (what is usually achieved by roundabout means, and incompletely, using enum and #define), then some of those problems wouldn't occur: * You don't need to make them global and use extern; just define them in the header as they use no storage; each module that uses them will convert them to immediate data. * Since they use no storage, there is no need to minimise storage by sharing space of consts with identical values. (Not quite true with floating point constants on certain hardware, but that is an implementation detail.) * Named const values can be used in compile-time expressions with no restriction * A C const value can be changed by casting a pointer to it; with a true named constant that is impossible, as it's not an lvalue * They can have a type associated with them unlike #define * They have normal scope rules unlike #define * They can be used for float and long long int constants unlike enum Etc. But in one or two megathreads in the past, people here have expressed no desire to have such a simple and obvious feature in the language, preferring the /possible/ adoption of the 'constexpr' feature from C++, perhaps sometime later this century. 'constexpr' is an version of C's 'const' which has even more issues than const. >> So if you pass a pointer to that const >> int to a function that takes 'int*', then you'll get a type warning. > > Right, because one interpretation of having an int * parameter is that > you wish to change it. Indeed, it's nearly the only interpretation > unless you're treating the pointer as an array or vector. But most people don't bother. If they want a pointer to an int, or a pointer to a sequence of ints, they will just use int*. And if they did bother, they then find that would have to use 'const' in 90% of declarations. In other words, they'd have to introduce clutter (and wasting large amounts of time silencing compiler warning, while generating more bugs and wasting extra time by making it harder to 'see' declarations at a glance). And the scheme doesn't really work: if you have a struct containing an int* field, and pass a const pointer to such a const struct, then nothing will stop a function from writing into the int* target if you don't want it to. Unless the field is permanently declared const int*, which will then lead to considerable difficulties everywhere else (and the struct definition might not be yours anyway). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-27 12:15 -0700 |
| Message-ID | <87fv8qmev6.fsf@kst-u.example.com> |
| In reply to | #59090 |
Bartc <bc@freeuk.com> writes:
> On 27/03/2015 04:42, Les Cargill wrote:
>> Bartc wrote:
>>> 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.
>>
>> So what is wrong with that?
>
> I use 'const' in other languages to mean Pascal-style const. So
> personally C's use of it conflicts with that. But I've seen enough
> posts here about it over the years that it seems quite a few other
> people have the same misunderstanding.
But now you *know* that "const" in C means read-only. I understand that
that can be confusing -- but why is it still a problem *for you*?
>> Then you run into header file manipulation - which is fine.
>> I think you can also have extern references to it.
>
> If C had proper named constants (what is usually achieved by
> roundabout means, and incompletely, using enum and #define), then some
> of those problems wouldn't occur:
But named constants are an entirely different language feature than C's
"const" (read-only). Sure, it would be nice if C had that other feature
(beyond what enum and #define already provide), but that's not what
we're talking about.
"const" lets you assert, in a manner that will be enforced by the
compiler, that an object will not be modified via a particular name.
[...]
> Etc. But in one or two megathreads in the past, people here have
> expressed no desire to have such a simple and obvious feature in the
> language, preferring the /possible/ adoption of the 'constexpr'
> feature from C++, perhaps sometime later this century. 'constexpr' is
> an version of C's 'const' which has even more issues than const.
I'm not familiar with constexpr. Perhaps I'll look into it.
>>> So if you pass a pointer to that const
>>> int to a function that takes 'int*', then you'll get a type warning.
>>
>> Right, because one interpretation of having an int * parameter is that
>> you wish to change it. Indeed, it's nearly the only interpretation
>> unless you're treating the pointer as an array or vector.
>
> But most people don't bother. If they want a pointer to an int, or a
> pointer to a sequence of ints, they will just use int*. And if they
> did bother, they then find that would have to use 'const' in 90% of
> declarations.
Most people *should* bother.
Yes, you may end up using "const" in 90% of your declarations. And in
the process, you may find and fix bugs in your code where you're
modifying things you didn't intend to.
The transition from B's untyped objects, with no distinction between
pointers and integers, to C's relatively stronger typing must have been
difficult too. I wouldn't want to go back.
> In other words, they'd have to introduce clutter (and wasting large
> amounts of time silencing compiler warning, while generating more bugs
> and wasting extra time by making it harder to 'see' declarations at a
> glance).
If you're changing code to silence compiler warnings, you're doing it
wrong. Change the code *to make it correct*. If you do that right, the
compiler warnings will go away as a side effect of having correct (in
this case, const-correct) code.
> And the scheme doesn't really work: if you have a struct containing an
> int* field, and pass a const pointer to such a const struct, then
> nothing will stop a function from writing into the int* target if you
> don't want it to. Unless the field is permanently declared const int*,
> which will then lead to considerable difficulties everywhere else (and
> the struct definition might not be yours anyway).
If you define a structure with an int* field, defining the structure
itself as const prevents you from modifying the int*, but not the int
object that it points to. The const applies only to the struct object
and its members, not to data that a member points to. If you want to
say that the pointed-to object is read-only, define a pointer to const:
struct s {
int *const ptr;
};
const struct s obj = { .ptr = some_address };
Now obj, obj.ptr, and *(obj.ptr) are all read-only.
If the struct definition is incorrect and you're not able to change it,
then you've got problems that the language definition can't solve for
you.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-28 08:30 +1300 |
| Message-ID | <cnlpfjF1tloU1@mid.individual.net> |
| In reply to | #59098 |
Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > >> Etc. But in one or two megathreads in the past, people here have >> expressed no desire to have such a simple and obvious feature in the >> language, preferring the /possible/ adoption of the 'constexpr' >> feature from C++, perhaps sometime later this century. 'constexpr' is >> an version of C's 'const' which has even more issues than const. > > I'm not familiar with constexpr. Perhaps I'll look into it. You should. Amongst other goodies it avoids that largely pointless impediment to the evolution of C "breaking existing code". -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-28 14:56 -0700 |
| Message-ID | <kfn7fu07pm9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #59099 |
Ian Collins <ian-news@hotmail.com> writes: > Keith Thompson wrote: >> Bartc <bc@freeuk.com> writes: >> >>> Etc. But in one or two megathreads in the past, people here >>> have expressed no desire to have such a simple and obvious >>> feature in the language, preferring the /possible/ adoption of >>> the 'constexpr' feature from C++, perhaps sometime later this >>> century. 'constexpr' is an version of C's 'const' which has >>> even more issues than const. >> >> I'm not familiar with constexpr. Perhaps I'll look into it. > > You should. Amongst other goodies it avoids that largely > pointless impediment to the evolution of C "breaking existing > code". Can you elaborate on that last statement? I'm familiar with constexpr, but I don't see what you're getting at with either part of the last sentence.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-29 11:10 +1300 |
| Message-ID | <cnon75Foba2U6@mid.individual.net> |
| In reply to | #59171 |
Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> Keith Thompson wrote: >>> Bartc <bc@freeuk.com> writes: >>> >>>> Etc. But in one or two megathreads in the past, people here >>>> have expressed no desire to have such a simple and obvious >>>> feature in the language, preferring the /possible/ adoption of >>>> the 'constexpr' feature from C++, perhaps sometime later this >>>> century. 'constexpr' is an version of C's 'const' which has >>>> even more issues than const. >>> >>> I'm not familiar with constexpr. Perhaps I'll look into it. >> >> You should. Amongst other goodies it avoids that largely >> pointless impediment to the evolution of C "breaking existing >> code". > > Can you elaborate on that last statement? I'm familiar with > constexpr, but I don't see what you're getting at with either > part of the last sentence. Too many useful additions to C are rejected because they might break fragile legacy code. C++ has evolved more rapidly than C in part because the committee recognises that there is a cost/benefit tradeoff to be made with new features. Making string literal const and cost really cost were early examples of this. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-28 20:04 -0700 |
| Message-ID | <87y4mgld12.fsf@kst-u.example.com> |
| In reply to | #59176 |
Ian Collins <ian-news@hotmail.com> writes:
> Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>> Keith Thompson wrote:
>>>> Bartc <bc@freeuk.com> writes:
>>>>> Etc. But in one or two megathreads in the past, people here
>>>>> have expressed no desire to have such a simple and obvious
>>>>> feature in the language, preferring the /possible/ adoption of
>>>>> the 'constexpr' feature from C++, perhaps sometime later this
>>>>> century. 'constexpr' is an version of C's 'const' which has
>>>>> even more issues than const.
>>>>
>>>> I'm not familiar with constexpr. Perhaps I'll look into it.
>>>
>>> You should. Amongst other goodies it avoids that largely
>>> pointless impediment to the evolution of C "breaking existing
>>> code".
>>
>> Can you elaborate on that last statement? I'm familiar with
>> constexpr, but I don't see what you're getting at with either
>> part of the last sentence.
>
> Too many useful additions to C are rejected because they might break
> fragile legacy code. C++ has evolved more rapidly than C in part
> because the committee recognises that there is a cost/benefit tradeoff
> to be made with new features. Making string literal const and cost
> really cost were early examples of this.
I presume you mean "const really const". But as I understand it C++
didn't do that. "const" still means read-only. C++ just added a
special case whereby the name of a const-qualified object is treated
as a constant expression if its initializer is a constant expression
(something I'd like to see in C). So this:
const int this_is_a_constant = 42;
switch (expr) {
case this_is_a_constant: // ...
}
is valid in C++ but not in C, but this:
const int this_is_not_a_constant = rand();
is still valid in both C and 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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-29 17:14 +1300 |
| Message-ID | <cnpcgaFoba2U9@mid.individual.net> |
| In reply to | #59187 |
Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> Tim Rentsch wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>> Keith Thompson wrote:
>>>>> Bartc <bc@freeuk.com> writes:
>>>>>> Etc. But in one or two megathreads in the past, people here
>>>>>> have expressed no desire to have such a simple and obvious
>>>>>> feature in the language, preferring the /possible/ adoption of
>>>>>> the 'constexpr' feature from C++, perhaps sometime later this
>>>>>> century. 'constexpr' is an version of C's 'const' which has
>>>>>> even more issues than const.
>>>>>
>>>>> I'm not familiar with constexpr. Perhaps I'll look into it.
>>>>
>>>> You should. Amongst other goodies it avoids that largely
>>>> pointless impediment to the evolution of C "breaking existing
>>>> code".
>>>
>>> Can you elaborate on that last statement? I'm familiar with
>>> constexpr, but I don't see what you're getting at with either
>>> part of the last sentence.
>>
>> Too many useful additions to C are rejected because they might break
>> fragile legacy code. C++ has evolved more rapidly than C in part
>> because the committee recognises that there is a cost/benefit tradeoff
>> to be made with new features. Making string literal const and cost
>> really cost were early examples of this.
>
> I presume you mean "const really const". But as I understand it C++
> didn't do that. "const" still means read-only. C++ just added a
> special case whereby the name of a const-qualified object is treated
> as a constant expression if its initializer is a constant expression
> (something I'd like to see in C). So this:
>
> const int this_is_a_constant = 42;
> switch (expr) {
> case this_is_a_constant: // ...
> }
>
> is valid in C++ but not in C, but this:
>
> const int this_is_not_a_constant = rand();
>
> is still valid in both C and C++.
Yes. It makes a real improvement to the language and the only thing it
could possibly break is code that is already broken. The same applies
to making string literals const char[].
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-03-30 13:03 -0700 |
| Message-ID | <kfnmw2u45j9.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #59176 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> Keith Thompson wrote: >>>> Bartc <bc@freeuk.com> writes: >>>> >>>>> Etc. But in one or two megathreads in the past, people here >>>>> have expressed no desire to have such a simple and obvious >>>>> feature in the language, preferring the /possible/ adoption of >>>>> the 'constexpr' feature from C++, perhaps sometime later this >>>>> century. 'constexpr' is an version of C's 'const' which has >>>>> even more issues than const. >>>> >>>> I'm not familiar with constexpr. Perhaps I'll look into it. >>> >>> You should. Amongst other goodies it avoids that largely >>> pointless impediment to the evolution of C "breaking existing >>> code". >> >> Can you elaborate on that last statement? I'm familiar with >> constexpr, but I don't see what you're getting at with either >> part of the last sentence. > > Too many useful additions to C are rejected because they might > break fragile legacy code. C++ has evolved more rapidly than C in > part because the committee recognises that there is a cost/benefit > tradeoff to be made with new features. Making string literal > const and cost really cost were early examples of this. I see. You chose to focus on a minor or incidental aspect of constexpr so you could take an editorial swipe at C (and a misguided one IMO, but lets ignore that). I had hoped you were saying something more substantial.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-31 16:40 +1300 |
| Message-ID | <cnuj9kFm7ngU3@mid.individual.net> |
| In reply to | #59305 |
Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> Tim Rentsch wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> Keith Thompson wrote: >>>>> Bartc <bc@freeuk.com> writes: >>>>> >>>>>> Etc. But in one or two megathreads in the past, people here >>>>>> have expressed no desire to have such a simple and obvious >>>>>> feature in the language, preferring the /possible/ adoption of >>>>>> the 'constexpr' feature from C++, perhaps sometime later this >>>>>> century. 'constexpr' is an version of C's 'const' which has >>>>>> even more issues than const. >>>>> >>>>> I'm not familiar with constexpr. Perhaps I'll look into it. >>>> >>>> You should. Amongst other goodies it avoids that largely >>>> pointless impediment to the evolution of C "breaking existing >>>> code". >>> >>> Can you elaborate on that last statement? I'm familiar with >>> constexpr, but I don't see what you're getting at with either >>> part of the last sentence. >> >> Too many useful additions to C are rejected because they might >> break fragile legacy code. C++ has evolved more rapidly than C in >> part because the committee recognises that there is a cost/benefit >> tradeoff to be made with new features. Making string literal >> const and cost really cost were early examples of this. > > I see. You chose to focus on a minor or incidental aspect > of constexpr so you could take an editorial swipe at C (and > a misguided one IMO, but lets ignore that). I had hoped you > were saying something more substantial. Yet again you choose misinterpret what I wrote. Adding constexpr would be a safe addition because it doesn't change the rules related to const. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-26 23:31 -0500 |
| Message-ID | <mf2m58$66m$1@dont-email.me> |
| In reply to | #59002 |
fir wrote:
> 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(cosA)>EPSI) ? (sinA/cosA) : 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)'
This doesn't happen, at least not much.
> 2) is compile 'guard' against incidental revrite (seem to be also extreamlly rare
Yes.
> case - tending to be factual zero probably)
More than that, it signals the *intent* that it's not to be changed. You
have to go through a small ritual to make it changeable again.
I think of it as "throwing the write protect tab."
> DISADVANTAGES
> 1) longer code
>
> besides im not sure if code that uses consts
> is more or less readable,
I am gambling on simple expressions being easier to read, to avoid any
issues of operator precedence and over all, it being cleaner. Its much
harder to misread, which I take as "more readable".
It's rather like the saying "in order to be understood, speak more slowly".
You're correct it makes the code longer. But if the computation for
each "step" is all on a single text window, that has advantages.
> * [[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) [?]
>
Yes. You would need to cast the thing to a "const" type before calling fu.
> * 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
>
No, the compiler will flag an error if you erroneously
assign to something that is not an lvalue.
I've just experimented lately with making *everything* const initially,
then using the compiler to find when const should be removed. You'd be
surprised how little need to be changed.
Is it a practical engineering gain? I am not sure.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-26 23:42 -0700 |
| Message-ID | <87y4mjlz53.fsf@kst-u.example.com> |
| In reply to | #59052 |
Les Cargill <lcargill99@comcast.com> writes:
> fir wrote:
[...]
>> * 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
>
> No, the compiler will flag an error if you erroneously
> assign to something that is not an lvalue.
The name of a const-qualified object is still an lvalue; it's just not a
modifiable lvalue.
--
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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web