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 220 — 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 David Thompson <dave.thompson2@verizon.net> - 2015-04-26 07:13 -0400
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-26 07:10 -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-04-15 09:27 -0700
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-04-15 19:51 +0100
Re: my solution for Pascal strings James Kuyper <jameskuyper@verizon.net> - 2015-04-15 17:51 -0400
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-16 16:04 -0700
Re: my solution for Pascal strings Keith Thompson <kst-u@mib.org> - 2015-04-16 17:15 -0700
Re: my solution for Pascal strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-17 01:41 +0100
Re: my solution for Pascal strings Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:20 -0700
Re: my solution for Pascal strings Richard Heathfield <rjh@cpax.org.uk> - 2015-04-17 07:28 +0100
Re: my solution for Pascal strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-17 12:11 +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 Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 13:00 -0700
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 | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-03-28 22:44 +0100 |
| Message-ID | <20150328224430.037a0987@maxa-pc> |
| In reply to | #59166 |
On Sun, 29 Mar 2015 10:35:42 +1300 Ian Collins <ian-news@hotmail.com> wrote: > Melzzzzz wrote: > > On Sun, 29 Mar 2015 10:28:09 +1300 > > Ian Collins <ian-news@hotmail.com> wrote: > >> Melzzzzz wrote: > >>> > >>> You don't have to cast from void* in C... That is why I dislike > >>> C++ as it forces cast from void* which is pointless, IMO. > >> > >> Casting from void* is not so much pointless in C++ as something you > >> hardly ever have to do. > > > > Write c++ module for nginx and see... > > The boundaries to C libraries are the obvious places where casting > may be required. But once inside the C++ code base, it shouldn't. > Well, one has to downcast from base sooner or later.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-29 10:57 +1300 |
| Message-ID | <cnomdmFoba2U4@mid.individual.net> |
| In reply to | #59168 |
Melzzzzz wrote: > On Sun, 29 Mar 2015 10:35:42 +1300 > Ian Collins <ian-news@hotmail.com> wrote: > >> Melzzzzz wrote: >>> On Sun, 29 Mar 2015 10:28:09 +1300 >>> Ian Collins <ian-news@hotmail.com> wrote: >>>> Melzzzzz wrote: >>>>> >>>>> You don't have to cast from void* in C... That is why I dislike >>>>> C++ as it forces cast from void* which is pointless, IMO. >>>> >>>> Casting from void* is not so much pointless in C++ as something you >>>> hardly ever have to do. >>> >>> Write c++ module for nginx and see... >> >> The boundaries to C libraries are the obvious places where casting >> may be required. But once inside the C++ code base, it shouldn't. >> > > Well, one has to downcast from base sooner or later. a) A base class isn't a void* b) C++ provides an explicit type safe mechanism for casting from a pointer to base to a pointer to derived class. c) It doesn't happen that often! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| 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-04-15 09:27 -0700 |
| Message-ID | <kfnd2352w70.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #59268 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> 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.
(Disclaimer: I think I understand the question being discussed
here but the upthread messages are no longer in my newsreader,
so my apologies if the comments below are not on subject.)
Consider the following program, where 'XXXXXX' names a standard
system header, and 'YYYYYY' names a type defined in that header
(ie, a particular standard header, and a particular type in
that header). The #include line is the first line of the
file (which makes line 19 be the 'return' statement in bar()).
#include <XXXXXX>
typedef YYYYYY T;
int
foo( const T *t, int x ){
return x;
}
int
bas( int x ){
T t = { 0 };
return foo( (const T*) &t, x );
}
int
bar( int x ){
T t = { 0 };
return foo( &t, x );
}
int
main(){
return bas( 0 ) + bar( 0 );
}
Compiling with 'gcc -ansi -pedantic' gives (as does -std=c99
instead of -ansi):
example.c: In function `bar':
example.c:19: warning: passing arg 1 of `foo' from incompatible pointer type
In light of the above, do you have anything to add to your last
paragraph (ie, the one with "No need whatsoever to cast" in it)?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-15 19:51 +0100 |
| Message-ID | <mgmbug$niu$1@dont-email.me> |
| In reply to | #60089 |
On 15/04/15 17:27, Tim Rentsch wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> 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.
>
> (Disclaimer: I think I understand the question being discussed
> here but the upthread messages are no longer in my newsreader,
> so my apologies if the comments below are not on subject.)
>
> Consider the following program, where 'XXXXXX' names a standard
> system header, and 'YYYYYY' names a type defined in that header
> (ie, a particular standard header, and a particular type in
> that header). The #include line is the first line of the
> file (which makes line 19 be the 'return' statement in bar()).
>
> #include <XXXXXX>
>
> typedef YYYYYY T;
>
> int
> foo( const T *t, int x ){
> return x;
> }
>
> int
> bas( int x ){
> T t = { 0 };
> return foo( (const T*) &t, x );
> }
>
> int
> bar( int x ){
> T t = { 0 };
> return foo( &t, x );
> }
>
> int
> main(){
> return bas( 0 ) + bar( 0 );
> }
>
> Compiling with 'gcc -ansi -pedantic' gives (as does -std=c99
> instead of -ansi):
>
> example.c: In function `bar':
> example.c:19: warning: passing arg 1 of `foo' from incompatible pointer type
>
> In light of the above, do you have anything to add to your last
> paragraph (ie, the one with "No need whatsoever to cast" in it)?
Sure. It comes in two parts - a "programming philosophy" response and a
"technical objection" response.
The technical objection is that your sample code cannot be compiled
without your revealing YYYYYY (or, alternatively, a lot of spadework
that I'm not interested enough to do), so I'll suspend offering an
opinion until I know what YYYYYY is.
Philosophically, changing simple code into more complicated code with
the objective of requiring a cast is not my idea of an improvement. If
it were for the purpose of illustration, that would be understandable,
but this is clearly not for the purpose of illustration, as it doesn't
actually illustrate anything that compiles.
I suppose you wouldn't have posted it if you didn't have a candidate
YYYYYY for which your claim is true (in what appears to be a lulu of a
corner case), but /in general/ the claim is certainly not true. For
example, we can do this:
#include <string.h>
void f(char *s, char *t)
{
strcpy(s, t);
}
without having to cast t to const char *.
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-15 17:51 -0400 |
| Message-ID | <552EDD74.2040806@verizon.net> |
| In reply to | #60098 |
On 04/15/2015 02:51 PM, Richard Heathfield wrote:
> On 15/04/15 17:27, Tim Rentsch wrote:
...
>> #include <XXXXXX>
>>
>> typedef YYYYYY T;
>>
>> int
>> foo( const T *t, int x ){
>> return x;
>> }
>>
>> int
>> bas( int x ){
>> T t = { 0 };
>> return foo( (const T*) &t, x );
>> }
>>
>> int
>> bar( int x ){
>> T t = { 0 };
>> return foo( &t, x );
>> }
>>
>> int
>> main(){
>> return bas( 0 ) + bar( 0 );
>> }
>>
>> Compiling with 'gcc -ansi -pedantic' gives (as does -std=c99
>> instead of -ansi):
>>
>> example.c: In function `bar':
>> example.c:19: warning: passing arg 1 of `foo' from incompatible pointer type
I copied the above program exactly, except that I replaced the first
line with
#include XXXXXX
and then tried all of the following, without being able to reproduce
your results:
gcc -ansi -pedantic -DXXXXXX="<fenv.h>" -DYYYYYY=fenv_t example.c
gcc -ansi -pedantic -DXXXXXX="<inttypes.h>" -DYYYYYY=imaxdiv_t example.c
gcc -ansi -pedantic -DXXXXXX="<locale.h>" -DYYYYYY="struct lconv" example.c
gcc -ansi -pedantic -DXXXXXX="<signal.h>" -DYYYYYY=sig_atomic_t example.c
gcc -ansi -pedantic -DXXXXXX="<stdio.h>" -DYYYYYY=size_t example.c
gcc -ansi -pedantic -DXXXXXX="<stdlib.h>" -DYYYYYY=wchar_t example.c
gcc -ansi -pedantic -DXXXXXX="<time.h>" -DYYYYYY="struct tm" example.c
gcc -ansi -pedantic -DXXXXXX="<wchar.h>" -DYYYYYY="wint_t" example.c
gcc -ansi -pedantic -DXXXXXX="<wctype.h>" -DYYYYYY="wctype_t" example.c
Only the following two cases failed, and that's because, in both cases
(on this particular implementation), the specified type was an array type:
gcc -ansi -pedantic -DXXXXXX="<setjmp.h>" -DYYYYYY="jmp_buf" example.c
gcc -ansi -pedantic -DXXXXXX="<stdarg.h>" -DYYYYYY=va_list example.c
If XXXXXX.h contains something like
typedef int YYYYYY[1];
Then the declaration
T t= {0};
Declares an object of array type, so &t has the type int(*)[1], while
the declaration in foo() of
const T *t
gives t the type const int (*)[1]. The 'const' qualifies neither t, nor
*t, but rather **t.
6.5.2.2p2 says "Each argument shall have a type such that its value may
be assigned to an object with the unqualified version of the type of its
corresponding parameter." Therefore, a const int parameter can match an
int argument. The rules for simple assignment require that if the left
operand (corresponding to the parameter) has a pointer type, "both
operands are pointers to qualified or unqualified versions of compatible
types, and the type pointed to by the left has all the qualifiers of the
type pointed to by the right;" (6.5.16.1p1). Therefore, a const int*
parameter can match an int* argument. However, in this case, the 'const'
applies neither to t, nor to *t, but only to **t. As a result, it
renders the pointed-at types incompatible (6.7.6.1p2), therefore
violating the constraint imposed by 6.5.16.1p1.
This is a prime example of why it can be a bad idea to typedef an array
type. Seemingly obvious code can have unexpected implications.
...
> The technical objection is that your sample code cannot be compiled
> without your revealing YYYYYY (or, alternatively, a lot of spadework
> that I'm not interested enough to do), so I'll suspend offering an
> opinion until I know what YYYYYY is.
A little bit of testing turned up two cases, fairly quickly. Once I saw
them fail, it was fairly straightforward to see why there was a problem,
though it took me a while to track down the correct argument showing
that this was the case.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-16 16:04 -0700 |
| Message-ID | <kfna8y7znco.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60098 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 15/04/15 17:27, Tim Rentsch wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>
>>> 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.
>>
>> (Disclaimer: I think I understand the question being discussed
>> here but the upthread messages are no longer in my newsreader,
>> so my apologies if the comments below are not on subject.)
>>
>> Consider the following program, where 'XXXXXX' names a standard
>> system header, and 'YYYYYY' names a type defined in that header
>> (ie, a particular standard header, and a particular type in
>> that header). The #include line is the first line of the
>> file (which makes line 19 be the 'return' statement in bar()).
>>
>> #include <XXXXXX>
>>
>> typedef YYYYYY T;
>>
>> int
>> foo( const T *t, int x ){
>> return x;
>> }
>>
>> int
>> bas( int x ){
>> T t = { 0 };
>> return foo( (const T*) &t, x );
>> }
>>
>> int
>> bar( int x ){
>> T t = { 0 };
>> return foo( &t, x );
>> }
>>
>> int
>> main(){
>> return bas( 0 ) + bar( 0 );
>> }
>>
>> Compiling with 'gcc -ansi -pedantic' gives (as does -std=c99
>> instead of -ansi):
>>
>> example.c: In function `bar':
>> example.c:19: warning: passing arg 1 of `foo' from incompatible pointer type
>>
>> In light of the above, do you have anything to add to your last
>> paragraph (ie, the one with "No need whatsoever to cast" in it)?
>
> Sure. It comes in two parts - a "programming philosophy" response and
> a "technical objection" response.
>
> The technical objection is that your sample code cannot be compiled
> without your revealing YYYYYY (or, alternatively, a lot of spadework
> that I'm not interested enough to do), so I'll suspend offering an
> opinion until I know what YYYYYY is.
>
> Philosophically, changing simple code into more complicated code with
> the objective of requiring a cast is not my idea of an improvement. If
> it were for the purpose of illustration, that would be understandable,
> but this is clearly not for the purpose of illustration, as it doesn't
> actually illustrate anything that compiles.
>
> I suppose you wouldn't have posted it if you didn't have a candidate
> YYYYYY for which your claim is true (in what appears to be a lulu of a
> corner case), but /in general/ the claim is certainly not true. For
> example, we can do this:
>
> #include <string.h>
>
> void f(char *s, char *t)
> {
> strcpy(s, t);
> }
>
> without having to cast t to const char *.
Let me put it more directly. The idea that passing a (T *)
argument to a function that specifies a (const T *) parameter is
always okay is wrong; there are cases where a cast is needed.
Such cases are ordinary, regular C. Using a header isn't
necessary to show the existence of such cases - the point of
using one is just to show that the situation can arise in quite
normal situations.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-16 17:15 -0700 |
| Message-ID | <87lhhrr4om.fsf@kst-u.example.com> |
| In reply to | #60184 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> Let me put it more directly. The idea that passing a (T *)
> argument to a function that specifies a (const T *) parameter is
> always okay is wrong; there are cases where a cast is needed.
> Such cases are ordinary, regular C. Using a header isn't
> necessary to show the existence of such cases - the point of
> using one is just to show that the situation can arise in quite
> normal situations.
And what are those cases?
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-17 01:41 +0100 |
| Message-ID | <87fv7zegd5.fsf@bsb.me.uk> |
| In reply to | #60187 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > [...] >> Let me put it more directly. The idea that passing a (T *) >> argument to a function that specifies a (const T *) parameter is >> always okay is wrong; there are cases where a cast is needed. >> Such cases are ordinary, regular C. Using a header isn't >> necessary to show the existence of such cases - the point of >> using one is just to show that the situation can arise in quite >> normal situations. > > And what are those cases? When T is an array type, the const qualifies the element type not the array itself (6.7.3 p9). No idea if this is what Tim means (or if this is the only case) but it's one case. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-22 10:20 -0700 |
| Message-ID | <kfnzj60t6z8.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60187 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > [...] >> Let me put it more directly. The idea that passing a (T *) >> argument to a function that specifies a (const T *) parameter is >> always okay is wrong; there are cases where a cast is needed. >> Such cases are ordinary, regular C. Using a header isn't >> necessary to show the existence of such cases - the point of >> using one is just to show that the situation can arise in quite >> normal situations. > > And what are those cases? I deliberately didn't say because I didn't want to get dragged into a downstream debate about whether they are "relevant". The point is that they exist in normal (as opposed to obfuscated) C, and that's all that's important to what I was saying; I have no desire to get pulled into a style argument.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-17 07:28 +0100 |
| Message-ID | <mgq93n$d3$1@dont-email.me> |
| In reply to | #60184 |
On 17/04/15 00:04, Tim Rentsch wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
>>
>> I suppose you wouldn't have posted it if you didn't have a candidate
>> YYYYYY for which your claim is true (in what appears to be a lulu of a
>> corner case), but /in general/ the claim is certainly not true. For
>> example, we can do this:
>>
>> #include <string.h>
>>
>> void f(char *s, char *t)
>> {
>> strcpy(s, t);
>> }
>>
>> without having to cast t to const char *.
>
> Let me put it more directly. The idea that passing a (T *)
> argument to a function that specifies a (const T *) parameter is
> always okay is wrong; there are cases where a cast is needed.
> Such cases are ordinary, regular C. Using a header isn't
> necessary to show the existence of such cases - the point of
> using one is just to show that the situation can arise in quite
> normal situations.
Let me put it more directly still. You have not yet illustrated a case
where a cast is needed. The only example you have given did not compile
because it used a nonstandard header and a nonstandard type.
I'm sure you /do/ have an example. I'd like to see it, so that I can
decide for myself whether it constitutes a "normal situation".
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-04-17 12:11 +0100 |
| Message-ID | <871tjjdn6w.fsf@bsb.me.uk> |
| In reply to | #60197 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 17/04/15 00:04, Tim Rentsch wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>
> <snip>
>
>>>
>>> I suppose you wouldn't have posted it if you didn't have a candidate
>>> YYYYYY for which your claim is true (in what appears to be a lulu of a
>>> corner case), but /in general/ the claim is certainly not true. For
>>> example, we can do this:
>>>
>>> #include <string.h>
>>>
>>> void f(char *s, char *t)
>>> {
>>> strcpy(s, t);
>>> }
>>>
>>> without having to cast t to const char *.
>>
>> Let me put it more directly. The idea that passing a (T *)
>> argument to a function that specifies a (const T *) parameter is
>> always okay is wrong; there are cases where a cast is needed.
>> Such cases are ordinary, regular C. Using a header isn't
>> necessary to show the existence of such cases - the point of
>> using one is just to show that the situation can arise in quite
>> normal situations.
>
> Let me put it more directly still. You have not yet illustrated a case
> where a cast is needed. The only example you have given did not
> compile because it used a nonstandard header and a nonstandard type.
>
> I'm sure you /do/ have an example. I'd like to see it, so that I can
> decide for myself whether it constitutes a "normal situation".
This is the kind of puzzle that Tim is very fond of. Maybe he sees it
as teaching without spoon-feeding, but the best puzzles are usually the
worst teaching exercises because they are either trivial (if you "get
it") or impossible (if you miss the trick).
My guess is that he is referring to 6.7.3 p9 (p8 in C99 and similar
wording exists in C90) which says that a const qualifies the element
type when applied to an array type. The result is that when T is an
array type, you can't pass a T * to a function expecting a const T *.
If so, the XXXXXX header part was then a way to make the typedef look
more innocent. Without it, array typedefs don't look like
typdef YYYYYY T;
because they have []s (or more) after the T. But if you include
setjmp.h you can typedef jmp_buf T to get an array type without it being
obvious.
--
Ben.
[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]
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