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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-26 18:19 +0000 |
| Message-ID | <mf1ii9$9os$1@dont-email.me> |
| In reply to | #59026 |
On 26/03/2015 15:39, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: > [...] >> I don't like 'const' as used in C, where it doesn't really define a >> constant, but suggests that a variable is read-only. > > Yes, that's exactly what const means. Would you like it better if it > were spelled "readonly"? Yes. Although I would still never use it and it would probably increase the clutter because it's longer. With 'const' ideally meaning what a lot of people already mistakenly think it means (ie. what it signifies in Pascal). > > [...] > >> As far as I'm concerned, 'const' is just extra clutter. And some >> people like to stick it in nearly everywhere. > > In my experience, people don't use it enough. I see code that defines > and initializes an object and then never changes it, If it had been > defined with "const", I would *know* that it still has its initial > value (without looking for code that modifies it). No, there are sometimes so many consts littering the code that you /can't/ easily see what's what! >> And that leads to type conflicts. So if you pass a pointer to that >> const int to a function that takes 'int*', then you'll get a type >> warning. You'd have to change the parameter type to 'const int*'. This >> is the start of the 'const poisoning' that Malcolm is on about. > > If the function doesn't modify the object the pointer points to, the > parameter probably should have been defined as "const int*" in the first > place. Exactly. And if that parameter is then an argument to another function belonging to a library, then /that/ now needs 'const'. I think this is what is meant by const poisoning: you have a huge application and a set of libraries that have worked quite happily now, until someone innocently writes: const int n=5; and you need to pass &n. Now you have to revise the entire code base to remove all the warnings. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-26 11:33 -0700 |
| Message-ID | <87fv8robgi.fsf@kst-u.example.com> |
| In reply to | #59036 |
Bartc <bc@freeuk.com> writes:
> On 26/03/2015 15:39, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>> [...]
>>> I don't like 'const' as used in C, where it doesn't really define a
>>> constant, but suggests that a variable is read-only.
>>
>> Yes, that's exactly what const means. Would you like it better if it
>> were spelled "readonly"?
>
> Yes.
>
> Although I would still never use it and it would probably increase the
> clutter because it's longer.
Which means you have no way to enforce that something must not be
modified, and you risk bugs where a function modifies something that you
expected to be unchanging.
Ok, what about "ro"? Or, as I suggested, nothing, with a keyword like
"var" to indicate that an object *can* be modified?
> With 'const' ideally meaning what a lot of people already mistakenly
> think it means (ie. what it signifies in Pascal).
Having a keyword that means that something is evaluated at compile time
might be useful. I think that's what C++'s "constexpr" does. But that
and read-only are two different concepts -- both useful IMHO.
>> [...]
>>
>>> As far as I'm concerned, 'const' is just extra clutter. And some
>>> people like to stick it in nearly everywhere.
>>
>> In my experience, people don't use it enough. I see code that defines
>> and initializes an object and then never changes it, If it had been
>> defined with "const", I would *know* that it still has its initial
>> value (without looking for code that modifies it).
>
> No, there are sometimes so many consts littering the code
> that you /can't/ easily see what's what!
I haven't found that to be the case.
>>> And that leads to type conflicts. So if you pass a pointer to that
>>> const int to a function that takes 'int*', then you'll get a type
>>> warning. You'd have to change the parameter type to 'const int*'. This
>>> is the start of the 'const poisoning' that Malcolm is on about.
>>
>> If the function doesn't modify the object the pointer points to, the
>> parameter probably should have been defined as "const int*" in the first
>> place.
>
> Exactly. And if that parameter is then an argument to another function
> belonging to a library, then /that/ now needs 'const'. I think this is
> what is meant by const poisoning: you have a huge application and a
> set of libraries that have worked quite happily now, until someone
> innocently writes:
>
> const int n=5;
>
> and you need to pass &n. Now you have to revise the entire code base
> to remove all the warnings.
Yes, taking existing code that doesn't use "const" and modifying it to
use "const" consistently can be messy. Writing code that uses "const"
properly in the first place can avoid that mess.
If you've defined
const int n=5;
then you don't want n to change, ever. Why would you want to pass its
address to a function that doesn't promise not to modify it?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-26 12:08 -0700 |
| Message-ID | <e36c47a4-17b6-42b3-99dd-8e8a70409ab8@googlegroups.com> |
| In reply to | #59037 |
On Thursday, March 26, 2015 at 6:33:40 PM UTC, Keith Thompson wrote: > > If you've defined > > const int n=5; > > then you don't want n to change, ever. Why would you want to pass its > address to a function that doesn't promise not to modify it? > If a function expects a list of integers, maybe representing pre-calculated string lengths, and you want to operate on just one string, you'd pass list_function(&str, &n, 1); of course list_function can take a const int *. But the const qualifier is mainly clutter. As for the str parameter, const qualifying a char ** can produce quite hard-to read code. /* return index of first filepath with no extension */ int list_function(char **str, int *len, int N); /* return index of first filepath with no extension */ int list_function( const char * const *str, const int *len, int N );
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-26 12:24 -0700 |
| Message-ID | <a80633d6-4a2d-4aff-919b-397dcb2f13df@googlegroups.com> |
| In reply to | #59038 |
W dniu czwartek, 26 marca 2015 20:08:46 UTC+1 użytkownik Malcolm McLean napisał: > On Thursday, March 26, 2015 at 6:33:40 PM UTC, Keith Thompson wrote: > > > > If you've defined > > > > const int n=5; > > > > then you don't want n to change, ever. Why would you want to pass its > > address to a function that doesn't promise not to modify it? > > > If a function expects a list of integers, maybe representing pre-calculated > string lengths, and you want to operate on just one string, you'd pass > list_function(&str, &n, 1); > > of course list_function can take a const int *. But the const qualifier > is mainly clutter. As for the str parameter, const qualifying a > char ** can produce quite hard-to read code. > > /* return index of first filepath with no extension */ > int list_function(char **str, int *len, int N); > > /* return index of first filepath with no extension */ > int list_function( const char * const *str, const int *len, int N ); const is boring
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-26 23:46 -0500 |
| Message-ID | <mf2n13$7ib$3@dont-email.me> |
| In reply to | #59040 |
fir wrote: > W dniu czwartek, 26 marca 2015 20:08:46 UTC+1 użytkownik Malcolm McLean napisał: >> On Thursday, March 26, 2015 at 6:33:40 PM UTC, Keith Thompson wrote: >>> >>> If you've defined >>> >>> const int n=5; >>> >>> then you don't want n to change, ever. Why would you want to pass its >>> address to a function that doesn't promise not to modify it? >>> >> If a function expects a list of integers, maybe representing pre-calculated >> string lengths, and you want to operate on just one string, you'd pass >> list_function(&str, &n, 1); >> >> of course list_function can take a const int *. But the const qualifier >> is mainly clutter. As for the str parameter, const qualifying a >> char ** can produce quite hard-to read code. >> >> /* return index of first filepath with no extension */ >> int list_function(char **str, int *len, int N); >> >> /* return index of first filepath with no extension */ >> int list_function( const char * const *str, const int *len, int N ); > > const is boring > Boring is good. Boring is *the point*. Boring keeps the phone from ringing. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-26 23:44 -0500 |
| Message-ID | <mf2mtc$7ib$2@dont-email.me> |
| In reply to | #59036 |
Bartc wrote: > On 26/03/2015 15:39, Keith Thompson wrote: <snip> > > const int n=5; > > and you need to pass &n. Now you have to revise the entire code base to > remove all the warnings. > So don't do that. const is a hint that you wish it not to change; if it changes, then it's not const. Roy: Doctor, doctor it hurts when I do that! Archie: So don't do that. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2015-03-27 04:53 +0000 |
| Message-ID | <20150326214626.222@kylheku.com> |
| In reply to | #59036 |
On 2015-03-26, Bartc <bc@freeuk.com> wrote: > of libraries that have worked quite happily now, until someone > innocently writes: > > const int n=5; > > and you need to pass &n. Now you have to revise the entire code base to > remove all the warnings. Or just: int n_mutable = n; func(&n_mutable); If func doesn't actually mutate the object, and no such mutation is considered in its future, then it is not "const correct". If func mutates the object, then you simply cannot use it on n. If you want n to be a constant, and to have the adjusted value, then the fix is this: int n_orig = 5; const int n = (func(&n_orig), n_orig); The ripple effects caused by introducing a const are because someone wants to use the const tool (write const correct code), but the surrounding code base isn't const correct. Nobody "innocently" writes const int n = 5. That programmer is quite probably a stickler for const correctness.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-26 23:42 -0500 |
| Message-ID | <mf2mpb$7ib$1@dont-email.me> |
| In reply to | #59013 |
Bartc wrote:
> On 26/03/2015 06:33, fir wrote:
>> W dniu czwartek, 26 marca 2015 02:42:09 UTC+1 użytkownik Les Cargill
>> napisał:
>
>>> const float angle = 90.0;
>>> const float EPSI = (FLT_EPSILON * 1000.0);
>>> const float TAN_UNDEF = FLT_MAX;
>>> {
>>> const float sinA = sin(angle);
>>> const float cosA = cos(angle);
>>> const float tanA = (abs(cos)>EPSI) ? (sin/cos) : TAN_UNDEF;
>>> ...
>>> }
>>>
>>> That's just the one "use case".
>>>
>>> "const char * const p = ...." gets some use, too.
>>> If there's a "const" violation down the page, I at
>>> least have to think about things before removing
>>> one or both of the "const"s .
>>>
>>> I try to make as much stuff immutable as possible.
>>>
>> from this example abowe doesnt seem to be terrific usable too
>> i understand this is
>
> I don't like 'const' as used in C, where it doesn't really define a
> constant, but suggests that a variable is read-only.
>
So what is wrong with that?
>> ADVANTAGES
>> 1) many consts of the same value could be stored in the same bytes
>> (though seem to be really rare probably)
>
> With a proper named constant (as you might get in C with '#define N 5'
> or 'enum {n=5}'), this would be irrelevant, because the value doesn't
> need to be stored anywhere; it will be immediate data.
>
Then you run into header file manipulation - which is fine.
> But there is one advantage of a C-style const, is that you can take its
> address (to pass to a function for example).
>
I think you can also have extern references to it.
>> 2) is compile 'guard' against incidental revrite (seem to be also
>> extreamlly rare
>> case - tending to be factual zero probably)
>> DISADVANTAGES
>> 1) longer code
>
> As far as I'm concerned, 'const' is just extra clutter. And some people
> like to stick it in nearly everywhere.
>
> And that leads to type conflicts.
Casting is a normal part of 'C programming.
> 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. In that
case, a const int isn't appropriate - but a constant list of values
might be, in which it's already both const pointer and const things-
being-pointed-to.
> You'd have to change the parameter type to 'const int*'. This is the
> start of the 'const poisoning' that Malcolm is on about.
>
True enough - you have to be mindful. It is annoying in some of the
standard library code.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-27 07:04 +0000 |
| Message-ID | <mf2vbn$tqt$1@dont-email.me> |
| In reply to | #59054 |
On 27/03/15 04:42, Les Cargill wrote: <snip> > Casting is a normal part of 'C programming. I hope not. Casting is a sign that something exceptional is happening. It should be very rare indeed. <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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-03-27 10:43 +0000 |
| Message-ID | <mf3c67$b0v$1@dont-email.me> |
| In reply to | #59068 |
On 27/03/2015 07:04, Richard Heathfield wrote: > On 27/03/15 04:42, Les Cargill wrote: > > <snip> > >> Casting is a normal part of 'C programming. > > I hope not. Casting is a sign that something exceptional is happening. > It should be very rare indeed. Or something unexceptional, such as compiling a program that's been working perfectly well, with a much fussier compiler. Then you might need to use casts to make it shut up. Typical casts might be '(char*)"ABC"' so that it can be passed to a function taking 'unsigned char*'. Or (char*)"ABC" so that it can be passed to something taking taking 'char*'! (Although this is one needed by C++.) In other words, when you're fighting a particularly pedantic compiler. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-27 10:50 +0000 |
| Message-ID | <mf3ckt$cl4$1@dont-email.me> |
| In reply to | #59082 |
On 27/03/15 10:43, Bartc wrote: > On 27/03/2015 07:04, Richard Heathfield wrote: >> On 27/03/15 04:42, Les Cargill wrote: >> >> <snip> >> >>> Casting is a normal part of 'C programming. >> >> I hope not. Casting is a sign that something exceptional is happening. >> It should be very rare indeed. > > Or something unexceptional, such as compiling a program that's been > working perfectly well, with a much fussier compiler. Then you might > need to use casts to make it shut up. If you need to shut the compiler up, you're probably doing something wrong. > > Typical casts might be '(char*)"ABC"' so that it can be passed to a > function taking 'unsigned char*'. If the function takes unsigned char *, your casting a string literal to char * really isn't going to help. In any case, if it takes unsigned char * rather than char *, there's just possibly a good reason for that, and casting (presumably to unsigned char *, as I expect you meant) isn't a great idea if what is really needed is an unsigned char *, not a string literal masquerading as an unsigned char *. > Or (char*)"ABC" so that it can be passed to something taking taking > 'char*'! I can see no point whatsoever to that cast. > (Although this is one needed by C++.) Irrelevant - this is comp.lang.c, not comp.lang.c++. > > In other words, when you're fighting a particularly pedantic compiler. > You'd be better off working with it than fighting against it. Casting isn't *always* wrong, but it nearly always is, and both of the above are perfect examples of wrong-headed casting. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-27 08:23 -0700 |
| Message-ID | <87r3samplq.fsf@kst-u.example.com> |
| In reply to | #59084 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 27/03/15 10:43, Bartc wrote:
[...]
>> Or (char*)"ABC" so that it can be passed to something taking taking
>> 'char*'!
>
> I can see no point whatsoever to that cast.
>
>> (Although this is one needed by C++.)
>
> Irrelevant - this is comp.lang.c, not comp.lang.c++.
It's peripherally relevant.
In C++, string literals are const, so func("ABC") passes an argument of
type `const char*`. If `func` takes an argument of type `char*`, that
call would be invalid.
And for good reason: If `func` doesn't promise not to change the data
that its parameter points to, passing a string literal to it is
dangerous. If `func` *isn't` going to change the data, the parameter
should be defined as `const char*` (and then you can safely pass a
string literal to it with no complaint from the compiler).
Unfortunately, C string literals are not const -- but in actual C code
the argument is likely to be a pointer object rather than a string
literal. So, for example:
void func(char*);
const char *arg = "ABC";
func(arg); /* error */
You could omit the "const" on the declaration of arg (it's not
required), but that would leave you open to risk of attempts to modify
the string not being caught by the compiler.
Bottom line: It's better to use `const` correctly than to work around
the problems that show up when you use it inconsistently.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-27 12:54 -0700 |
| Message-ID | <92806db0-231d-48fc-b050-01ecd8b95948@googlegroups.com> |
| In reply to | #59084 |
On Friday, March 27, 2015 at 10:51:07 AM UTC, Richard Heathfield wrote: > > You'd be better off working with it than fighting against it. Casting > isn't *always* wrong, but it nearly always is, and both of the above are > perfect examples of wrong-headed casting. > The idea of types is that they form a protective layer between the code and the bits. The snag is that the protective layer can't solve all formatting problems. So it's a natural thing for programmers and language designers to add another protective layer, then another. The result is Russian doll programming. In order to understand the program at the binary level you have to go through layer after layer of wrapping until eventually you come to the bits. And two protective layers aren't twice as good as one protective layer, if essentially you've got an abstraction, you're not operating on raw bits any more, and you've made the jump.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-03-28 16:20 -0500 |
| Message-ID | <mf75l1$jjv$1@dont-email.me> |
| In reply to | #59068 |
Richard Heathfield wrote: > On 27/03/15 04:42, Les Cargill wrote: > > <snip> > >> Casting is a normal part of 'C programming. > > I hope not. Casting is a sign that something exceptional is happening. > It should be very rare indeed. > > <snip> > > It's better to not have to, but I'd stop short of flagging it as bad practice. It depends on the context. Say I have a symbol table object that contains a void * for the thing being symbolized. I'd rather do that - and cast - than have a pointer for each type supported. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-03-28 22:23 +0100 |
| Message-ID | <20150328222333.5d909f3b@maxa-pc> |
| In reply to | #59160 |
On Sat, 28 Mar 2015 16:20:22 -0500 Les Cargill <lcargill99@comcast.com> wrote: > Richard Heathfield wrote: > > On 27/03/15 04:42, Les Cargill wrote: > > > > <snip> > > > >> Casting is a normal part of 'C programming. > > > > I hope not. Casting is a sign that something exceptional is > > happening. It should be very rare indeed. > > > > <snip> > > > > > > It's better to not have to, but I'd stop short of flagging > it as bad practice. It depends on the context. > > Say I have a symbol table object that contains a void * for > the thing being symbolized. I'd rather do that - and cast - > than have a pointer for each type supported. > 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.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-29 10:28 +1300 |
| Message-ID | <cnoknaFoba2U2@mid.individual.net> |
| In reply to | #59161 |
Melzzzzz wrote: > On Sat, 28 Mar 2015 16:20:22 -0500 > Les Cargill <lcargill99@comcast.com> wrote: > >> Richard Heathfield wrote: >>> On 27/03/15 04:42, Les Cargill wrote: >>> >>> <snip> >>> >>>> Casting is a normal part of 'C programming. >>> >>> I hope not. Casting is a sign that something exceptional is >>> happening. It should be very rare indeed. >>> >>> <snip> >>> >>> >> >> It's better to not have to, but I'd stop short of flagging >> it as bad practice. It depends on the context. >> >> Say I have a symbol table object that contains a void * for >> the thing being symbolized. I'd rather do that - and cast - >> than have a pointer for each type supported. >> > > 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. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-03-28 22:29 +0100 |
| Message-ID | <20150328222934.513da127@maxa-pc> |
| In reply to | #59163 |
On Sun, 29 Mar 2015 10:28:09 +1300 Ian Collins <ian-news@hotmail.com> wrote: > Melzzzzz wrote: > > On Sat, 28 Mar 2015 16:20:22 -0500 > > Les Cargill <lcargill99@comcast.com> wrote: > > > >> Richard Heathfield wrote: > >>> On 27/03/15 04:42, Les Cargill wrote: > >>> > >>> <snip> > >>> > >>>> Casting is a normal part of 'C programming. > >>> > >>> I hope not. Casting is a sign that something exceptional is > >>> happening. It should be very rare indeed. > >>> > >>> <snip> > >>> > >>> > >> > >> It's better to not have to, but I'd stop short of flagging > >> it as bad practice. It depends on the context. > >> > >> Say I have a symbol table object that contains a void * for > >> the thing being symbolized. I'd rather do that - and cast - > >> than have a pointer for each type supported. > >> > > > > 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...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-29 10:35 +1300 |
| Message-ID | <cnol5fFoba2U3@mid.individual.net> |
| In reply to | #59164 |
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. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| 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]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web