Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #11845 > unrolled thread
| Started by | scs@eskimo.com (Steve Summit) |
|---|---|
| First post | 2011-10-18 00:00 +0000 |
| Last post | 2011-10-27 00:18 -0700 |
| Articles | 20 on this page of 291 — 52 participants |
Back to article view | Back to comp.lang.c
Dennis Ritchie -- An Appreciation scs@eskimo.com (Steve Summit) - 2011-10-18 00:00 +0000
Re: Dennis Ritchie -- An Appreciation Uno <Uno@example.invalid> - 2011-10-18 05:20 -0600
Re: Dennis Ritchie -- An Appreciation jgk@panix.com (Joe keane) - 2011-11-11 23:51 +0000
Re: Dennis Ritchie -- An Appreciation Dann Corbit <dcorbit@connx.com> - 2011-10-18 14:37 -0700
Re: Dennis Ritchie -- An Appreciation Ian Collins <ian-news@hotmail.com> - 2011-10-19 10:52 +1300
Re: Dennis Ritchie -- An Appreciation "James" <no@spam.invalid> - 2011-10-18 16:47 -0700
Re: Dennis Ritchie -- An Appreciation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-19 00:02 -0700
Re: Dennis Ritchie -- An Appreciation "Bill Davy" <Bill@SynectixLtd.com> - 2011-10-19 08:57 +0100
Re: Dennis Ritchie -- An Appreciation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-19 02:13 -0700
Re: Dennis Ritchie -- An Appreciation Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-10-19 13:41 +0000
Re: Dennis Ritchie -- An Appreciation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-20 00:04 -0700
Re: Dennis Ritchie -- An Appreciation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-19 15:32 +0000
Re: Dennis Ritchie -- An Appreciation Patrick Scheible <kkt@zipcon.net> - 2011-10-19 09:57 -0700
Re: Dennis Ritchie -- An Appreciation Frederick Williams <freddywilliams@btinternet.com> - 2011-10-19 20:46 +0100
Re: Dennis Ritchie -- An Appreciation 88888 dihedral <dihedral88888@googlemail.com> - 2011-10-19 13:06 -0700
Re: Dennis Ritchie -- An Appreciation Kaz Kylheku <kaz@kylheku.com> - 2011-10-19 20:49 +0000
Re: Dennis Ritchie -- An Appreciation Roberto Waltman <usenet@rwaltman.com> - 2011-10-19 19:04 -0400
Re: Dennis Ritchie -- An Appreciation lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2011-10-20 07:43 -0700
Re: Dennis Ritchie -- An Appreciation Frederick Williams <freddywilliams@btinternet.com> - 2011-10-21 16:56 +0100
Re: Dennis Ritchie -- An Appreciation "sadsailor" <overboard@the.oceans> - 2011-10-21 16:37 -0500
Re: Dennis Ritchie -- An Appreciation Kaz Kylheku <kaz@kylheku.com> - 2011-10-21 17:17 +0000
Re: Dennis Ritchie -- An Appreciation Roberto Waltman <usenet@rwaltman.com> - 2011-10-21 13:30 -0400
Re: Dennis Ritchie -- An Appreciation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-22 07:57 -0700
Re: Dennis Ritchie -- An Appreciation bks@panix.com (Bradley K. Sherman) - 2011-10-22 15:51 +0000
Re: Dennis Ritchie -- An Appreciation Kaz Kylheku <kaz@kylheku.com> - 2011-10-22 18:19 +0000
Re: Dennis Ritchie -- An Appreciation Ian Collins <ian-news@hotmail.com> - 2011-10-23 08:00 +1300
Re: Dennis Ritchie -- An Appreciation Frederick Williams <freddywilliams@btinternet.com> - 2011-10-23 15:39 +0100
Re: Dennis Ritchie -- An Appreciation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-23 05:55 -0700
Re: Dennis Ritchie -- An Appreciation Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-23 21:30 +0100
Re: Dennis Ritchie -- An Appreciation blp@cs.stanford.edu (Ben Pfaff) - 2011-10-23 14:27 -0700
Re: Dennis Ritchie -- An Appreciation James Kuyper <jameskuyper@verizon.net> - 2011-10-23 10:28 -0400
Re: Dennis Ritchie -- An Appreciation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-23 08:36 -0700
Re: Dennis Ritchie -- An Appreciation "Charles Richmond" <netnews@aquaporin4.com> - 2011-10-23 23:21 -0500
Re: Dennis Ritchie -- An Appreciation "Charles Richmond" <netnews@aquaporin4.com> - 2011-10-23 23:21 -0500
Re: Dennis Ritchie -- An Appreciation "Charles Richmond" <netnews@aquaporin4.com> - 2011-10-23 23:23 -0500
Re: Dennis Ritchie -- An Appreciation Robert Wessel <robertwessel2@yahoo.com> - 2011-10-23 12:35 -0500
Re: Dennis Ritchie -- An Appreciation James Kuyper <jameskuyper@verizon.net> - 2011-10-23 14:01 -0400
Re: Dennis Ritchie -- An Appreciation Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-23 14:34 -0400
Re: Dennis Ritchie -- An Appreciation Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-10-23 13:49 -0600
Re: Dennis Ritchie -- An Appreciation James Kuyper <jameskuyper@verizon.net> - 2011-10-23 18:14 -0400
Re: Dennis Ritchie -- An Appreciation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-24 01:59 -0700
Re: Dennis Ritchie -- An Appreciation James Kuyper <jameskuyper@verizon.net> - 2011-10-24 06:25 -0400
Re: Dennis Ritchie -- An Appreciation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-24 14:43 +0000
Re: Dennis Ritchie -- An Appreciation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-24 09:01 -0700
Re: Dennis Ritchie -- An Appreciation André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-10-24 18:23 +0200
Re: Dennis Ritchie -- An Appreciation Ian Collins <ian-news@hotmail.com> - 2011-10-25 08:02 +1300
Re: Dennis Ritchie -- An Appreciation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-25 00:44 -0700
Re: Dennis Ritchie -- An Appreciation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-25 21:24 +0000
Re: Dennis Ritchie -- An Appreciation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-26 00:58 -0700
Re: Dennis Ritchie -- An Appreciation Ian Collins <ian-news@hotmail.com> - 2011-10-26 23:21 +1300
OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-29 06:56 +0000
Re: OOP and C++ and C Markus Wichmann <nullplan@gmx.net> - 2011-10-29 21:18 +0200
Re: OOP and C++ and C nroberts <roberts.noah@gmail.com> - 2011-10-30 10:43 -0700
Re: OOP and C++ and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-31 02:26 -0700
Re: OOP and C++ and C nroberts <roberts.noah@gmail.com> - 2011-10-31 08:43 -0700
Re: OOP and C++ and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-01 03:11 -0700
Re: OOP and C++ and C nroberts <roberts.noah@gmail.com> - 2011-11-01 08:17 -0700
Re: OOP and C++ and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-02 06:16 -0700
Re: OOP and C++ and C jgk@panix.com (Joe keane) - 2011-11-28 00:23 +0000
Re: OOP and C++ and C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-27 23:57 -0800
Re: OOP and C++ and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-28 00:20 -0800
Re: OOP and C++ and C jgk@panix.com (Joe keane) - 2011-11-29 23:36 +0000
Re: OOP and C++ and C Ian Collins <ian-news@hotmail.com> - 2011-11-30 12:42 +1300
Re: OOP and C++ and C jacob navia <jacob@spamsink.net> - 2011-11-30 10:46 +0100
Re: OOP and C++ and C jgk@panix.com (Joe keane) - 2011-12-01 23:20 +0000
Re: OOP and C++ and C Ian Collins <ian-news@hotmail.com> - 2011-12-02 12:39 +1300
Re: OOP and C++ and C Kaz Kylheku <kaz@kylheku.com> - 2011-12-02 00:42 +0000
Re: OOP and C++ and C Ian Collins <ian-news@hotmail.com> - 2011-12-02 13:45 +1300
Re: OOP and C++ and C Kaz Kylheku <kaz@kylheku.com> - 2011-12-02 00:57 +0000
Re: OOP and C++ and C jacob navia <jacob@spamsink.net> - 2011-12-02 08:49 +0100
Re: OOP and C++ and C jgk@panix.com (Joe keane) - 2011-12-02 17:45 +0000
Re: OOP and C++ and C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-30 21:42 +0000
Re: OOP and C++ and C jacob navia <jacob@spamsink.net> - 2011-11-30 22:59 +0100
Re: OOP and C++ and C Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-30 22:09 +0000
Re: OOP and C++ and C Ian Collins <ian-news@hotmail.com> - 2011-12-01 11:20 +1300
Re: OOP and C++ and C jacob navia <jacob@spamsink.net> - 2011-12-01 00:21 +0100
Re: OOP and C++ and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-01 01:22 -0800
Re: Sapir-Whorf Hypothesis and programming JohnF <john@please.see.sig.for.email.com> - 2011-12-01 10:18 +0000
Re: Sapir-Whorf Hypothesis and programming Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-01 04:57 -0800
Re: Sapir-Whorf Hypothesis and programming JohnF <john@please.see.sig.for.email.com> - 2011-12-02 08:34 +0000
Re: Sapir-Whorf Hypothesis and programming Willem <willem@toad.stack.nl> - 2011-12-01 13:38 +0000
Re: Sapir-Whorf Hypothesis and programming 88888 Dihedral <dihedral88888@googlemail.com> - 2011-12-01 13:47 -0800
Re: Sapir-Whorf Hypothesis and programming JohnF <john@please.see.sig.for.email.com> - 2011-12-02 08:10 +0000
Re: Sapir-Whorf Hypothesis and programming Kaz Kylheku <kaz@kylheku.com> - 2011-12-02 17:48 +0000
Re: OOP and C++ and C James Kuyper <jameskuyper@verizon.net> - 2011-11-30 18:35 -0500
Re: OOP and C++ and C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-12-01 02:53 -0800
Re: OOP and C++ and C James Kuyper <jameskuyper@verizon.net> - 2011-12-01 07:07 -0500
Re: OOP and C++ and C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-12-04 00:35 +0000
Re: OOP and C++ and C Geoff <geoff@invalid.invalid> - 2011-12-03 18:28 -0800
Re: OOP and C++ and C ImpalerCore <jadill33@gmail.com> - 2011-11-30 14:10 -0800
Re: OOP and C++ and C jacob navia <jacob@spamsink.net> - 2011-12-01 00:15 +0100
Re: OOP and C++ and C Ian Collins <ian-news@hotmail.com> - 2011-12-01 12:21 +1300
Re: OOP and C++ and C jacob navia <jacob@spamsink.net> - 2011-12-01 00:29 +0100
Operator overloading extensions (Was re: OOP and C++ and C) "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-12-01 15:50 -0500
Re: OOP and C++ and C "io_x" <a@b.c.invalid> - 2011-12-01 07:38 +0100
Re: OOP and C++ and C Ian Collins <ian-news@hotmail.com> - 2011-12-01 20:26 +1300
Re: OOP and C++ and C James Kuyper <jameskuyper@verizon.net> - 2011-11-30 18:37 -0500
Re: OOP and C++ and C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-12-01 02:05 -0800
Re: OOP and C++ and C James Kuyper <jameskuyper@verizon.net> - 2011-12-01 07:09 -0500
Re: OOP and C++ and C Markus Wichmann <nullplan@gmx.net> - 2011-11-01 10:13 +0100
Re: OOP and C++ and C Ian Collins <ian-news@hotmail.com> - 2011-11-01 23:02 +1300
Re: OOP and C++ and C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-01 04:04 -0700
Re: OOP and C++ and C nroberts <roberts.noah@gmail.com> - 2011-11-01 08:45 -0700
Re: OOP and C++ and C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-01 09:25 -0700
Re: OOP and C++ and C nroberts <roberts.noah@gmail.com> - 2011-11-01 09:30 -0700
Re: OOP and C++ and C James Kuyper <jameskuyper@verizon.net> - 2011-11-01 12:59 -0400
Re: OOP and C++ and C nroberts <roberts.noah@gmail.com> - 2011-11-01 10:30 -0700
Re: OOP and C++ and C James Kuyper <jameskuyper@verizon.net> - 2011-11-01 14:33 -0400
Re: OOP and C++ and C nroberts <roberts.noah@gmail.com> - 2011-11-01 13:10 -0700
Re: OOP and C++ and C James Kuyper <jameskuyper@verizon.net> - 2011-11-01 16:37 -0400
Re: OOP and C++ and C nroberts <roberts.noah@gmail.com> - 2011-11-01 13:44 -0700
Re: OOP and C++ and C James Kuyper <jameskuyper@verizon.net> - 2011-11-01 21:03 -0400
Re: OOP and C++ and C Keith Thompson <kst-u@mib.org> - 2011-11-01 16:26 -0700
Re: OOP and C++ and C Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 02:38 +0000
Re: OOP and C++ and C Uncle Steve <stevet810@gmail.com> - 2011-11-02 22:53 -0400
Re: OOP and C++ and C Ian Collins <ian-news@hotmail.com> - 2011-11-03 16:03 +1300
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-30 01:07 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ian Collins <ian-news@hotmail.com> - 2011-10-30 21:22 +1300
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-30 04:41 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-10-30 08:40 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-30 10:56 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-31 03:03 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-31 02:59 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-30 07:56 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-30 08:13 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-30 18:05 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-30 11:38 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ian Collins <ian-news@hotmail.com> - 2011-10-31 07:56 +1300
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-31 01:11 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ian Collins <ian-news@hotmail.com> - 2011-10-31 21:34 +1300
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 08:36 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ian Collins <ian-news@hotmail.com> - 2011-11-01 07:37 +1300
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-10-31 06:55 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-31 06:08 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-10-31 10:42 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-31 07:56 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-10-31 12:54 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ian Collins <ian-news@hotmail.com> - 2011-11-01 07:47 +1300
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-30 19:46 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-31 01:49 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-31 15:15 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 09:01 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-31 18:04 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 11:56 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-01 03:03 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-31 09:18 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 09:39 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-31 09:54 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 10:11 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-01 03:22 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-31 23:08 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 09:04 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-31 09:26 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 09:37 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-31 10:01 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ian Collins <ian-news@hotmail.com> - 2011-11-01 07:59 +1300
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 09:52 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) ImpalerCore <jadill33@gmail.com> - 2011-10-31 17:25 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Seebs <usenet-nospam@seebs.net> - 2011-11-01 21:44 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) ImpalerCore <jadill33@gmail.com> - 2011-11-02 07:07 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-30 08:33 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-30 18:00 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-31 03:20 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-10-31 20:07 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 13:48 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-10-31 22:18 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-01 03:59 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-31 22:52 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-01 04:27 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-01 18:56 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-01 12:59 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-11-01 16:46 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-01 14:16 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-11-01 21:35 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-02 08:22 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-02 10:14 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-02 12:09 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) jameskuyper <jameskuyper@gmail.com> - 2011-11-02 13:11 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-02 15:01 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-02 22:11 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-02 15:32 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-11-02 21:31 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-03 07:41 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Uncle Steve <stevet810@gmail.com> - 2011-11-02 19:58 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) pacman@kosh.dhis.org (Alan Curry) - 2011-11-02 21:45 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-02 14:26 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-11-02 11:07 -0400
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-03 12:51 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-03 06:36 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-03 14:34 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-03 08:41 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-04 03:30 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-04 09:03 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 09:24 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-04 09:44 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-09 00:06 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 00:03 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-09 10:57 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-10 09:13 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Keith Thompson <kst-u@mib.org> - 2011-11-10 11:05 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-10 13:23 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-10 14:47 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) "BartC" <bc@freeuk.com> - 2011-11-11 00:17 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-11 09:29 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-11 18:05 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) John Gordon <gordon@panix.com> - 2011-11-11 18:19 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-11-11 13:28 -0500
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) John Gordon <gordon@panix.com> - 2011-11-11 18:37 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) James Kuyper <jameskuyper@verizon.net> - 2011-11-11 14:13 -0500
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-11 11:17 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-11 21:49 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) John Gordon <gordon@panix.com> - 2011-11-11 22:11 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-11 14:19 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-12 02:50 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-12 01:44 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-12 17:54 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-12 11:38 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-14 02:36 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-14 16:01 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 10:40 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Seebs <usenet-nospam@seebs.net> - 2011-11-14 18:36 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 11:51 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 12:08 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Seebs <usenet-nospam@seebs.net> - 2011-11-14 20:25 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 13:11 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Seebs <usenet-nospam@seebs.net> - 2011-11-14 21:46 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 14:56 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Seebs <usenet-nospam@seebs.net> - 2011-11-14 23:01 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 15:50 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Seebs <usenet-nospam@seebs.net> - 2011-11-15 02:48 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-15 08:52 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Richard Damon <news.x.richarddamon@xoxy.net> - 2011-11-14 20:15 -0500
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Seebs <usenet-nospam@seebs.net> - 2011-11-15 02:48 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 14:17 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Seebs <usenet-nospam@seebs.net> - 2011-11-14 22:38 +0000
Re: OOP and C++ and C blp@cs.stanford.edu (Ben Pfaff) - 2011-11-14 14:45 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 15:21 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Seebs <usenet-nospam@seebs.net> - 2011-11-14 23:40 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 15:59 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Robert Wessel <robertwessel2@yahoo.com> - 2011-11-14 12:16 -0600
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Willem <willem@toad.stack.nl> - 2011-11-14 18:25 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-11 14:15 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-11 23:53 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-11 16:16 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-11 19:53 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-11 12:02 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-14 02:05 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-14 08:36 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Keith Thompson <kst-u@mib.org> - 2011-11-10 17:00 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-11 04:53 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-11 09:27 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-12 04:27 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-10 23:00 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-11-10 15:10 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-11 03:30 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-11 00:41 -0800
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) cri@tiac.net (Richard Harter) - 2011-11-12 05:14 +0000
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) David Thompson <dave.thompson2@verizon.net> - 2011-11-21 02:39 -0500
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) nroberts <roberts.noah@gmail.com> - 2011-10-30 11:00 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) "io_x" <a@b.c.invalid> - 2011-10-30 19:09 +0100
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-30 11:51 -0700
Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-30 20:36 +0000
Re: Dennis Ritchie -- An Appreciation Richard Damon <news.x.richarddamon@xoxy.net> - 2011-10-24 12:16 -0400
Re: Dennis Ritchie -- An Appreciation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-25 20:30 +0000
Re: Dennis Ritchie -- An Appreciation "Bill Cunningham" <nospam@nspam.invalid> - 2011-10-24 15:52 -0400
Re: Dennis Ritchie -- An Appreciation "Bill Cunningham" <nospam@nspam.invalid> - 2011-10-24 21:40 -0400
Re: Dennis Ritchie -- An Appreciation Fritz Wuehler <fritz@spamexpire-201110.rodent.frell.theremailer.net> - 2011-10-26 06:13 +0200
Re: Dennis Ritchie -- An Appreciation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-26 01:34 -0700
Re: Dennis Ritchie -- An Appreciation "Bill Cunningham" <nospam@nspam.invalid> - 2011-10-26 09:47 -0400
Re: Dennis Ritchie -- An Appreciation Fritz Wuehler <fritz@spamexpire-201110.rodent.frell.theremailer.net> - 2011-10-27 04:54 +0200
Re: Dennis Ritchie -- An Appreciation luser- -droog <mijoryx@yahoo.com> - 2011-10-27 11:27 -0700
Re: Dennis Ritchie -- An Appreciation AK <anoopkammaran@gmail.com> - 2011-10-20 00:01 -0700
Re: Dennis Ritchie -- An Appreciation lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2011-10-20 07:50 -0700
Re: Dennis Ritchie -- An Appreciation Walter Banks <walter@bytecraft.com> - 2011-10-20 11:07 -0400
Re: Dennis Ritchie -- An Appreciation Kaz Kylheku <kaz@kylheku.com> - 2011-10-20 16:31 +0000
Re: Dennis Ritchie -- An Appreciation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-10-20 11:13 -0700
Re: Dennis Ritchie -- An Appreciation 88888 Dihedral <dihedral88888@googlemail.com> - 2011-10-20 11:43 -0700
Re: Dennis Ritchie -- An Appreciation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-21 08:35 +0000
Re: Dennis Ritchie -- An Appreciation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-21 02:45 -0700
Re: Dennis Ritchie -- An Appreciation André Gillibert <MetaEntropy.removeThis@gmail.com> - 2011-10-24 18:41 +0200
Re: Dennis Ritchie -- An Appreciation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-25 14:06 +0000
Re: Dennis Ritchie -- An Appreciation 88888 Dihedral <dihedral88888@googlemail.com> - 2011-10-25 10:13 -0700
Re: Dennis Ritchie -- An Appreciation "Charles Richmond" <netnews@aquaporin4.com> - 2011-10-20 21:58 -0500
Re: Dennis Ritchie -- An Appreciation "Charles Richmond" <netnews@aquaporin4.com> - 2011-10-20 21:52 -0500
Re: Dennis Ritchie -- An Appreciation "io_x" <a@b.c.invalid> - 2011-10-23 10:32 +0200
Re: Dennis Ritchie -- An Appreciation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-23 05:58 -0700
Re: Dennis Ritchie -- An Appreciation lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2011-10-20 07:40 -0700
Re: Dennis Ritchie -- An Appreciation 88888 Dihedral <dihedral88888@googlemail.com> - 2011-10-25 10:19 -0700
Re: Dennis Ritchie -- An Appreciation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-26 01:53 -0700
Re: Dennis Ritchie -- An Appreciation 88888 Dihedral <dihedral88888@googlemail.com> - 2011-10-26 14:40 -0700
Re: Dennis Ritchie -- An Appreciation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-27 00:18 -0700
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-10-31 15:15 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <0.b8af719e321c345fd074.20111031151514GMT.87ehxtdwfx.fsf@bsb.me.uk> |
| In reply to | #12328 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Oct 30, 9:46 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>>
>> Some code might clarify things. You might want to sketch a situation
>> with lots of "plugs and sockets" which gets more complex hen written in
>> C++.
>>
>
> I'm not sure I've even got the syntax right, it's so long since I did
> this, but the root of the problem goes something like this
>
> template <class Iterator, class numeric>
> <numeric> standard_deviation( Iterator begin, Iterator end)
> {
> while(begin !- end)
> {
> /* code here */
> ++begin;
> }
> /* There's something wrong with out standard deviation, so I want
> to call a tried and tested function to get the mean, which is foo ()
> */
> foo();
> /* The problem is that, even though under the bonnet I've just been
> passed a double *, the only way of calling foo() is to construct a
> temporary vector */
> }
>
> temple <class numeric>
> <numeric> foo( std:vector<numeric> &list )
> {
> }
>
> In C, you can have the problem that we might have floats or doubles or
> long doubles. The whole point of the template idea is that you only
> have to write the routines once. But you need iron tight discipline to
> achieve this.
No, I meant some C code which gets more complex in C++. That was your
claim -- that some kinds of code get more complex in C++. This snippet
demonstrates that you can't hack a call to a function with one type from
a template that uses another. That's true, but not what you were
talking about. For one thing, it's very hard to write this sort of the
generic code in C, so it's unfair to complain that it's "unhackable" and
"complex" in C++. The C for a type-generic loop would be horrendous.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-31 09:01 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <800b5a1f-9bbe-4aa2-8b8f-aeba19a7b568@h5g2000yqk.googlegroups.com> |
| In reply to | #12352 |
On Oct 31, 8:15 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> No, I meant some C code which gets more complex in C++. That was your
> claim -- that some kinds of code get more complex in C++. This snippet
> demonstrates that you can't hack a call to a function with one type from
> a template that uses another. That's true, but not what you were
> talking about. For one thing, it's very hard to write this sort of the
> generic code in C, so it's unfair to complain that it's "unhackable" and
> "complex" in C++. The C for a type-generic loop would be horrendous.
Let's compare them. The basic for_each implementation in C++:
template < typename ForwardIterator, typename Fun >
void for_each(ForwardIterator start, ForwardIterator end, Fun fun)
{
for (; start != end; ++start) fun(*start);
}
Use:
void print_int(int i) { std::cout << i; }
std::vector<int> vect;
...
std::for_each(vect.begin(), vect.end(), print_int);
Or now:
std::for_each(vect.begin(), vect.end(), [](int i) { std::cout <<
i; });
I, personally, don't find that very complicated.
Now the C version. I'm sure a C expert can do better than me, but
here's my untested attempt:
void for_each(char const* start, size_t size, size_t count, void(*fun)
(char*))
{
while (count--)
{
fun(start);
start += size;
}
}
Use:
void print_int(char const* ptr) { printf("%d", *((int const*)ptr)); }
int array[COUNT];
...
for_each((char const*)array, sizeof(int), COUNT, print_int);
I don't find that particularly difficult to get, but as a C++
developer I am annoyed by all the casting (especially upon review
before posting when I noticed I forgot the const on the int cast).
There's also room for user error if the wrong size is passed in, which
the compiler does for you with the C++ version. Neither of these is
insurmountable though.
Of course, generally you don't write your functions to work on char*
when they don't, so you'd probably be creating a wrapper for
print_int. In that way it would be reminiscent of having to create
functor objects for binding more than 2 parameters. The new C++
solves this issue, but most here probably are not familiar with bind
and lambdas.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-10-31 18:04 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <0.ee5e7d84f347ee1e9392.20111031180450GMT.87vcr5ca0t.fsf@bsb.me.uk> |
| In reply to | #12360 |
nroberts <roberts.noah@gmail.com> writes:
> On Oct 31, 8:15 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>> No, I meant some C code which gets more complex in C++. That was your
>> claim -- that some kinds of code get more complex in C++. This snippet
>> demonstrates that you can't hack a call to a function with one type from
>> a template that uses another. That's true, but not what you were
>> talking about. For one thing, it's very hard to write this sort of the
>> generic code in C, so it's unfair to complain that it's "unhackable" and
>> "complex" in C++. The C for a type-generic loop would be horrendous.
>
> Let's compare them. The basic for_each implementation in C++:
>
> template < typename ForwardIterator, typename Fun >
> void for_each(ForwardIterator start, ForwardIterator end, Fun fun)
> {
> for (; start != end; ++start) fun(*start);
> }
>
> Use:
>
> void print_int(int i) { std::cout << i; }
>
> std::vector<int> vect;
> ...
> std::for_each(vect.begin(), vect.end(), print_int);
>
> Or now:
>
> std::for_each(vect.begin(), vect.end(), [](int i) { std::cout <<
> i; });
>
> I, personally, don't find that very complicated.
No, nor do I, but I am not sure that this helps. Presumably you, like
me do not agree that it is common for thing to get more complex in C++.
The *language* is more complex, but the code if often simpler.
> Now the C version. I'm sure a C expert can do better than me, but
> here's my untested attempt:
The main difference is that a C expert would avoid most of the casts by
using void * and initialisation.
>
> void for_each(char const* start, size_t size, size_t count, void(*fun)
> (char*))
In the general case you can't make start point to const data (and your
C++ version doesn't use const).
> {
> while (count--)
> {
> fun(start);
> start += size;
> }
> }
>
> Use:
>
> void print_int(char const* ptr) { printf("%d", *((int const*)ptr)); }
>
> int array[COUNT];
> ...
> for_each((char const*)array, sizeof(int), COUNT, print_int);
sizeof array[0] is better.
> I don't find that particularly difficult to get, but as a C++
> developer I am annoyed by all the casting (especially upon review
> before posting when I noticed I forgot the const on the int cast).
> There's also room for user error if the wrong size is passed in, which
> the compiler does for you with the C++ version. Neither of these is
> insurmountable though.
It's worse. There's no type checking at all! Also what the function
can do quickly becomes so limiting that it's not worth bothering.
Either that or you end up with file-scope variables to pass data to the
function. In almost every case, if you write a C call-back, provide for
a general data pointer too:
typedef void callback(void *item, void *general_data);
void for_each(void *start, size_t size, size_t count, callback *cb);
We'll have to wait for someone on the "other" side of the debate to
illustrate the kind of code they have in mind.
> Of course, generally you don't write your functions to work on char*
> when they don't, so you'd probably be creating a wrapper for
> print_int. In that way it would be reminiscent of having to create
> functor objects for binding more than 2 parameters. The new C++
> solves this issue, but most here probably are not familiar with bind
> and lambdas.
If you try to match the type safety of the C++, you'll probably end up
with a macro system.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-31 11:56 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <0b74da0d-1aa9-4e63-a4cc-9f17e1589922@c1g2000vbw.googlegroups.com> |
| In reply to | #12386 |
On Oct 31, 11:04 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: > nroberts <roberts.n...@gmail.com> writes: > > void for_each(char const* start, size_t size, size_t count, void(*fun) > > (char*)) > > In the general case you can't make start point to const data (and your > C++ version doesn't use const). The C++ version can be const or non-const. It doesn't specify and lets the type resolution establish and check const correctness based on the template parameters. This is actually one thing that really, really bothers me in C. In order to have a for_each that works on const or non-const data you either need to write it twice or use non-const. The usual approach in C seems to be to use non-const even when it's not necessary. This means of course that you've got a bunch of interfaces that claim to use non-const when they really don't change anything. For example, it is quite common to see: void fun(char*); char * str = "hello"; fun(str); If we are to only make those assumptions that the function's declaration can establish then this use is illegal and dangerous. But in C you can't actually be sure about this and it is not uncommon to see such use. Just the other day in fact I pointed out to someone unit testing C code that it was crashing because the function actually DID modify the parameters and he was passing it static strings probably stored in r/o memory. Of course, then you get these same programmers coming into C++ who are not in the habit of writing const-correct code, don't understand it, and find it annoying because it's always complaining. So instead of figuring it out they write interfaces that lack const correctness as they did in C and you get the same big f'n mess or worse.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-11-01 03:03 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <0.eb25cb5261c4575c2be2.20111101030310GMT.87pqhcczo1.fsf@bsb.me.uk> |
| In reply to | #12395 |
nroberts <roberts.noah@gmail.com> writes: > On Oct 31, 11:04 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: >> nroberts <roberts.n...@gmail.com> writes: > >> > void for_each(char const* start, size_t size, size_t count, void(*fun) >> > (char*)) >> >> In the general case you can't make start point to const data (and your >> C++ version doesn't use const). > > The C++ version can be const or non-const. It doesn't specify and > lets the type resolution establish and check const correctness based > on the template parameters. I did not say that very well. I meant that nothing in the C++ forces the iterators to be const ones so, this should have been reflected in the C code if it is going to put up as a comparison. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-10-31 09:18 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <227cb8e8-1152-4474-b941-c28919e3f3a4@es7g2000vbb.googlegroups.com> |
| In reply to | #12352 |
On Oct 31, 5:15 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: > Malcolm McLean <malcolm.mcle...@btinternet.com> writes: > > No, I meant some C code which gets more complex in C++. That was your > claim -- that some kinds of code get more complex in C++. This snippet > demonstrates that you can't hack a call to a function with one type from > a template that uses another. That's true, but not what you were > talking about. For one thing, it's very hard to write this sort of the > generic code in C, so it's unfair to complain that it's "unhackable" and > "complex" in C++. The C for a type-generic loop would be horrendous. > The point is, you're unlikely to make this particular mistake in C. You'll write double stdev(double *x, int N) double mean(double *x, int N) So if one person writes mean and the other stdev, the code will likely plug together perfectly nicely. Even in C, it is possible to mess things up. You can say typedef float real; real stdev(real *x, int N) Thinking you're doing everyone a big favour by allowing your code to toggle between double and float. You're not. All you're doing is polluting the namespace and adding complexity. Anther problem is that, frequently, you want to get the mean and deviation of fields of structures. So double stdev(void *array, int offset, size_t size, int N) Would be a more generic function. However this is probably a bad idea because it's making the call hard to understand, and forcing the implementer of "mean" to do messy casts and pointer arithmetic. As always, the toy example is a bad one. mean() is so frequently required, and so trivial to calculate, that there's an argument for a generic stepping function. Generally, you don't have this sort of problem. Functions written in C can be made reusable with a minimum of effort, and can be embedded in other programs with a minimum of fuss. That's much less true of functions that use elaborate container systems. They tend to be difficult to integrate. -- C programming resources http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-31 09:39 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <9503f3fb-b8f1-4a83-b14d-ff895f53867d@hv4g2000vbb.googlegroups.com> |
| In reply to | #12366 |
On Oct 31, 9:18 am, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > Generally, you don't have this sort of problem. Functions written in C > can be made reusable with a minimum of effort, and can be embedded in > other programs with a minimum of fuss. That's much less true of > functions that use elaborate container systems. They tend to be > difficult to integrate. Why, because you said so?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-10-31 09:54 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <b54586a2-a121-40a7-bd75-a605e4296774@s30g2000yqd.googlegroups.com> |
| In reply to | #12368 |
On Oct 31, 6:39 pm, nroberts <roberts.n...@gmail.com> wrote:
> On Oct 31, 9:18 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>
> > Generally, you don't have this sort of problem. Functions written in C
> > can be made reusable with a minimum of effort, and can be embedded in
> > other programs with a minimum of fuss. That's much less true of
> > functions that use elaborate container systems. They tend to be
> > difficult to integrate.
>
> Why, because you said so?
>
No, because the containers used by caller and the containers used by
callee have to be compatible. The more elaborate your container
system, the less likely that is to be achieved, and the more that can
go wrong. The worst situation is where you have semi-compatiblity.
Consider this, for example
template <class numeric, class iterator>
double mean(iterator start, iterator end)
{
numeric tot(0);
int N = 0;
iterator it;
for(it=start, it != end, ++it)
{
tot += *it;
N++;
}
return (double)(tot/ (double) N);
}
There's a problem with this, which will become apparent when you call
the function with a small data type. However when you test it with
short sequences, which you can calculate by hand, it will probably
appear OK. It's a semi-compatible generic function.
--
Basic Algorithms: a second book of C
http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-31 10:11 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <35030a29-f7c5-4365-97e1-4e82bc1a5812@es7g2000vbb.googlegroups.com> |
| In reply to | #12374 |
On Oct 31, 9:54 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Oct 31, 6:39 pm, nroberts <roberts.n...@gmail.com> wrote:> On Oct 31, 9:18 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > wrote:
>
> > > Generally, you don't have this sort of problem. Functions written in C
> > > can be made reusable with a minimum of effort, and can be embedded in
> > > other programs with a minimum of fuss. That's much less true of
> > > functions that use elaborate container systems. They tend to be
> > > difficult to integrate.
>
> > Why, because you said so?
>
> No, because the containers used by caller and the containers used by
> callee have to be compatible. The more elaborate your container
> system, the less likely that is to be achieved, and the more that can
> go wrong. The worst situation is where you have semi-compatiblity.
> Consider this, for example
>
> template <class numeric, class iterator>
> double mean(iterator start, iterator end)
> {
> numeric tot(0);
> int N = 0;
> iterator it;
>
> for(it=start, it != end, ++it)
> {
> tot += *it;
> N++;
> }
> return (double)(tot/ (double) N);
>
> }
>
> There's a problem with this, which will become apparent when you call
> the function with a small data type. However when you test it with
> short sequences, which you can calculate by hand, it will probably
> appear OK. It's a semi-compatible generic function.
There are a LOT of problems with the above code. It was written by
someone that doesn't know C++.
However, why don't you point out the problem you are talking about so
that we can all be in on the secret. What is the problem you see
there that represents a flaw in the use or design of C++?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-11-01 03:22 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <0.dfcffada15f153fbbf81.20111101032237GMT.87k47kcyrm.fsf@bsb.me.uk> |
| In reply to | #12366 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Oct 31, 5:15 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: >> Malcolm McLean <malcolm.mcle...@btinternet.com> writes: >> >> No, I meant some C code which gets more complex in C++. That was your >> claim -- that some kinds of code get more complex in C++. This snippet >> demonstrates that you can't hack a call to a function with one type from >> a template that uses another. That's true, but not what you were >> talking about. For one thing, it's very hard to write this sort of the >> generic code in C, so it's unfair to complain that it's "unhackable" and >> "complex" in C++. The C for a type-generic loop would be horrendous. >> > The point is, you're unlikely to make this particular mistake in C. That seems to be quite a different point to the one I was commenting on. <snip> > Generally, you don't have this sort of problem. Functions written in C > can be made reusable with a minimum of effort, and can be embedded in > other programs with a minimum of fuss. That's much less true of > functions that use elaborate container systems. They tend to be > difficult to integrate. And if this third point had been the one you'd originally made I would not have disagreed. Low-level functions written in lower-level languages are almost always easier to integrate in other systems. This has provided a new role for C in some areas -- as the natural language for easily integrated, portable, libraries. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-10-31 23:08 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <451eaa78-7d56-4690-a836-1424bba29336@c1g2000vbw.googlegroups.com> |
| In reply to | #12426 |
On Nov 1, 5:22 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
> > On Oct 31, 5:15 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> >> No, I meant some C code which gets more complex in C++. That was your
> >> claim -- that some kinds of code get more complex in C++. This snippet
> >> demonstrates that you can't hack a call to a function with one type from
> >> a template that uses another. That's true, but not what you were
> >> talking about. For one thing, it's very hard to write this sort of the
> >> generic code in C, so it's unfair to complain that it's "unhackable" and
> >> "complex" in C++. The C for a type-generic loop would be horrendous.
>
> > The point is, you're unlikely to make this particular mistake in C.
>
> That seems to be quite a different point to the one I was commenting on.
>
Not really.
Probably most C programmers, at some time, have played with
struct string
{
int len;
char *str;
};
However they soon realise that all they're achieving is making it hard
to integrate string functions. You can make a mess in C if you want,
but you have to go out of your way to code it. So most people don't
bother. They drop the struct string nonsense and just pass about char
*s, which is the standard way. (You can argue whether the standard
plugs and sockets are well designed or not, that's a slightly
different matter).
In C++, it's much easier to do the equivalent. All you need to do is
to use std::string and char *s in the same program, and you've soon
got a mess.
Now of course, by itself, just having two string types which can be
interconverted easily enough is not going to bring down the program.
It's the accumulation of problems like that which eventually makes
code unmaintainable.
--
Read Basic Algorithms, now available as an ibook
http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-31 09:04 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <d34cb8ec-dacf-49d9-99c7-0f208c376378@a17g2000yqj.googlegroups.com> |
| In reply to | #12328 |
On Oct 31, 1:49 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Oct 30, 9:46 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> > Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> > Some code might clarify things. You might want to sketch a situation
> > with lots of "plugs and sockets" which gets more complex hen written in
> > C++.
>
> I'm not sure I've even got the syntax right, it's so long since I did
> this, but the root of the problem goes something like this
>
> template <class Iterator, class numeric>
> <numeric> standard_deviation( Iterator begin, Iterator end)
> {
> while(begin !- end)
> {
> /* code here */
> ++begin;
> }
> /* There's something wrong with out standard deviation, so I want
> to call a tried and tested function to get the mean, which is foo ()
> */
> foo();
> /* The problem is that, even though under the bonnet I've just been
> passed a double *, the only way of calling foo() is to construct a
> temporary vector */
>
> }
>
> temple <class numeric>
> <numeric> foo( std:vector<numeric> &list )
> {
>
> }
>
> In C, you can have the problem that we might have floats or doubles or
> long doubles. The whole point of the template idea is that you only
> have to write the routines once. But you need iron tight discipline to
> achieve this.
So, let me see if I understand you correctly...you find C++ more
complicated because you're not allowed to call functions that expect
one type with a different one and that if you need to you have to do
some conversions?
I think I can live with that. I wonder, what would happen if I
created a function expecting to be passed a handle to a managed buffer
structure and tried to pass it a double*...
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-10-31 09:26 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <e4231598-6983-4e42-ac69-45113204bcc9@ek5g2000vbb.googlegroups.com> |
| In reply to | #12362 |
On Oct 31, 6:04 pm, nroberts <roberts.n...@gmail.com> wrote:
> On Oct 31, 1:49 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> wrote:
>
>
>
>
>
>
>
>
>
> > On Oct 30, 9:46 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> > > Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> > > Some code might clarify things. You might want to sketch a situation
> > > with lots of "plugs and sockets" which gets more complex hen written in
> > > C++.
>
> > I'm not sure I've even got the syntax right, it's so long since I did
> > this, but the root of the problem goes something like this
>
> > template <class Iterator, class numeric>
> > <numeric> standard_deviation( Iterator begin, Iterator end)
> > {
> > while(begin !- end)
> > {
> > /* code here */
> > ++begin;
> > }
> > /* There's something wrong with out standard deviation, so I want
> > to call a tried and tested function to get the mean, which is foo ()
> > */
> > foo();
> > /* The problem is that, even though under the bonnet I've just been
> > passed a double *, the only way of calling foo() is to construct a
> > temporary vector */
>
> > }
>
> > temple <class numeric>
> > <numeric> foo( std:vector<numeric> &list )
> > {
>
> > }
>
> > In C, you can have the problem that we might have floats or doubles or
> > long doubles. The whole point of the template idea is that you only
> > have to write the routines once. But you need iron tight discipline to
> > achieve this.
>
> So, let me see if I understand you correctly...you find C++ more
> complicated because you're not allowed to call functions that expect
> one type with a different one and that if you need to you have to do
> some conversions?
>
> I think I can live with that. I wonder, what would happen if I
> created a function expecting to be passed a handle to a managed buffer
> structure and tried to pass it a double*...
>
The point is, if you write C, you won't write a function that demands
a managed buffer, unless the function really strictly needs it. In C++
you often will, which forces everyone to use your managed buffer
system. The C++ method is tolerable if everyone uses the stl
conventions, which is that a list is passed in as an iterator to the
start of the list and an iterator to one past the end. But the fact is
that everyone doesn't use the stl conventions. Partly it's a failure
of education, partly it's that they are hard to explain and it's
difficult to make programmers see the benefits, partly it's
historical, stl was bolted on to C++ at a late date, so people grew up
using C-style arrays instead of vectors. Whatever the reason, the
system isn't used as it should be.
--
C programming resources
http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-31 09:37 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <1d55beb5-8376-49a7-8f73-f5cdf531ff9a@x2g2000vbd.googlegroups.com> |
| In reply to | #12365 |
On Oct 31, 9:26 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Oct 31, 6:04 pm, nroberts <roberts.n...@gmail.com> wrote:
>
>
>
>
>
>
>
> > On Oct 31, 1:49 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
> > wrote:
>
> > > On Oct 30, 9:46 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> > > > Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> > > > Some code might clarify things. You might want to sketch a situation
> > > > with lots of "plugs and sockets" which gets more complex hen written in
> > > > C++.
>
> > > I'm not sure I've even got the syntax right, it's so long since I did
> > > this, but the root of the problem goes something like this
>
> > > template <class Iterator, class numeric>
> > > <numeric> standard_deviation( Iterator begin, Iterator end)
> > > {
> > > while(begin !- end)
> > > {
> > > /* code here */
> > > ++begin;
> > > }
> > > /* There's something wrong with out standard deviation, so I want
> > > to call a tried and tested function to get the mean, which is foo ()
> > > */
> > > foo();
> > > /* The problem is that, even though under the bonnet I've just been
> > > passed a double *, the only way of calling foo() is to construct a
> > > temporary vector */
>
> > > }
>
> > > temple <class numeric>
> > > <numeric> foo( std:vector<numeric> &list )
> > > {
>
> > > }
>
> > > In C, you can have the problem that we might have floats or doubles or
> > > long doubles. The whole point of the template idea is that you only
> > > have to write the routines once. But you need iron tight discipline to
> > > achieve this.
>
> > So, let me see if I understand you correctly...you find C++ more
> > complicated because you're not allowed to call functions that expect
> > one type with a different one and that if you need to you have to do
> > some conversions?
>
> > I think I can live with that. I wonder, what would happen if I
> > created a function expecting to be passed a handle to a managed buffer
> > structure and tried to pass it a double*...
>
> The point is, if you write C, you won't write a function that demands
> a managed buffer, unless the function really strictly needs it.
Well, if that's your point then you have a very odd way of stating it.
Of course, the point is quite debatable since it's actually impossible
to write a function that uses a static buffer in C. You are always
going to have to pass in a size and pointer.
In C++
> you often will, which forces everyone to use your managed buffer
> system.
Gotta debate the first. The second is a reasonable point though, if
you write a function that expects a vector you are indeed forced to
use one in order to call it. I don't think this is different from any
other statically typed language though.
The C++ method is tolerable if everyone uses the stl
> conventions, which is that a list is passed in as an iterator to the
> start of the list and an iterator to one past the end. But the fact is
> that everyone doesn't use the stl conventions. Partly it's a failure
> of education, partly it's that they are hard to explain and it's
> difficult to make programmers see the benefits, partly it's
> historical, stl was bolted on to C++ at a late date, so people grew up
> using C-style arrays instead of vectors. Whatever the reason, the
> system isn't used as it should be.
It seems to me that you're too long out of the C++ loop to make good
judgments about what is common.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-10-31 10:01 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <65cdba0d-c567-4140-ae7c-77633170400b@o14g2000yqh.googlegroups.com> |
| In reply to | #12370 |
On Oct 31, 6:37 pm, nroberts <roberts.n...@gmail.com> wrote: > On Oct 31, 9:26 am, Malcolm McLean <malcolm.mcle...@btinternet.com> > > > The point is, if you write C, you won't write a function that demands > > a managed buffer, unless the function really strictly needs it. > > Well, if that's your point then you have a very odd way of stating it. > Most functions operate on lists. C provides one easy way to set up a list, which is as an array. The consequence is that, in C programs, lists are usually arrays, unless there's a pressing performance need for another structure. The result is that, _in practice_ functions tend to be inter-operable. The interfaces are kept clean and simple. You can even, very frequently, call a C function from another language. -- Visit my website http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-11-01 07:59 +1300 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <9h89g6FeluU3@mid.individual.net> |
| In reply to | #12375 |
On 11/ 1/11 06:01 AM, Malcolm McLean wrote: > On Oct 31, 6:37 pm, nroberts<roberts.n...@gmail.com> wrote: >> On Oct 31, 9:26 am, Malcolm McLean<malcolm.mcle...@btinternet.com> >> >>> The point is, if you write C, you won't write a function that demands >>> a managed buffer, unless the function really strictly needs it. >> >> Well, if that's your point then you have a very odd way of stating it. >> > Most functions operate on lists. C provides one easy way to set up a > list, which is as an array. The consequence is that, in C programs, > lists are usually arrays, unless there's a pressing performance need > for another structure. The result is that, _in practice_ functions > tend to be inter-operable. The interfaces are kept clean and simple. Which is why C++ algorithms use iterators, they are interoperable and the interfaces are kept clean, simple and consistent. You can use them with any container, including arrays! > You can even, very frequently, call a C function from another > language. That's because C is the common denominator on most platforms. > -- Your sig is missing the trailing space by the way. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-31 09:52 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <ff3b35dc-25e8-4959-a41f-02f89c5417b6@n18g2000vbv.googlegroups.com> |
| In reply to | #12365 |
On Oct 31, 9:26 am, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > The C++ method is tolerable if everyone uses the stl > conventions, which is that a list is passed in as an iterator to the > start of the list and an iterator to one past the end. But the fact is > that everyone doesn't use the stl conventions. Partly it's a failure > of education, partly it's that they are hard to explain and it's > difficult to make programmers see the benefits, partly it's > historical, stl was bolted on to C++ at a late date, so people grew up > using C-style arrays instead of vectors. Whatever the reason, the > system isn't used as it should be. Maybe putting this argument of yours in an alternate perspective would show you how vaporous it is. My general experience with C is that C developers don't know the first thing about cohesion, modularizing, etc... They're all proud hackers that peck at things until they work, without any regard to maintenance and reuse. They base statically sized arrays on assumptions that are far from guaranteed and do nothing to assert those preconditions. They scatter global variables throughout their systems and write functions that read and write to many unrelated, global concepts at once so that it is impossible to separate the concepts into distinct modules or put them under unit test without instantiating the entire system. They write and use functions like 'gets' that assume things that are quite literally impossible to check, allowing all manner of security exploits and crash conditions; this method of thinking among C developers is so bad they even do this in their standard library. They use convoluted methods of error handling like singular, global variables that can be written to anywhere along the call stack so that it's impossible to tell which function caused the error or if the code you're getting is even the right one...and then they use such systems in multi-threaded architectures such that the error you get might not even BE in the call stack anywhere. All that and much, much, much more. In my experience, C developers lack all discipline and design skills...and don't even see the problem with that. Basic principles of engineering are lost on them. I must therefore conclude that C is a bad, complex language. How stupid am I? Now it must be said, in non-sarcasm mode, that though the above is indeed a true reflection of C coders I have met...I realize that it's not the majority since the vast majority are people I've not met. Further it's not C specific as this is the general trend I see in all software development cultures. In my experience, good developers are rare no matter what language they speak. Most the good ones know how to write good code in more than one.
[toc] | [prev] | [next] | [standalone]
| From | ImpalerCore <jadill33@gmail.com> |
|---|---|
| Date | 2011-10-31 17:25 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <6494fe37-6721-4d7c-9c82-6ab18987047a@v5g2000vbh.googlegroups.com> |
| In reply to | #12303 |
On Oct 30, 2:38 pm, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Oct 30, 8:05 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:> Malcolm McLean <malcolm.mcle...@btinternet.com> writes:
>
> > How does C solve this problem of having a great may data types and badly
> > written (i.e. overly specific) function interfaces?
>
> It doesn't really solve the problem. One of the most dangerous
> features of C is the ability to typedef a basic type to something
> like, say DWORD. Then you find yourself rewriting perfectly good code,
> just because someone decided to put DWORDs where they really meant
> "int", and the code no longer runs under the particular operating
> system where DWORDs are used.
Do you have the same problem with int32_t? The only difference is
that one is *standardized* and the other 'DWORD' is not. The
underlying concept is the same; you want a double-word on
architectures that support 16-bit integers and those that support 32-
bit integers.
The benefit of typedefs is that it allows a module writer to define
types with stricter semantics. In this case, 'DWORD' has stricter
semantics because it is required to be 32-bits; an 'int' type does
not.
One can also use typedefs to define a common name to a type with
specific semantics. The example I commonly use is using an typedef of
'int' to define a type to represent a month.
typedef int greg_month;
Even though 'int' is the base type, the added semantics placed on
'greg_month' is that it is only allowed to store values from 1 to 12,
and perhaps -1 to represent an error state. Writing a function API
using these typedefs increases developer comprehension.
void create_report( struct my_report* report,
struct my_data* data,
greg_month start,
greg_month end );
One could certainly use 'int' in the start and end months, but
'greg_month' is a better visualization of its constraints than 'int'.
One sees 'greg_month' and knows that its implied range is from 1 to
12; the same cannot be said for using 'int'. Unfortunately C does not
provide automatic enforcement of those semantics, and the module
writer must take pains to code constraints to ensure that the values
passed into 'start' and 'end' match the desired semantics for the type
'greg_month'.
What one gains in developer comprehension becomes a flaw at the
integration stage. If one wants to use different libraries by
different people with different representations of the same thing, it
quickly becomes difficult to reconcile these differences. It is a
fundamental flaw of typedefs, as the plethora of boolean type styles
before standardization in C99 demonstrates.
Even so, I still believe the use of typedef to be a net positive even
though integration is a serious problem.
> But it alleviates it, because it's easy to write a function that
> operates on lists (a list is an ordered collection, usually of like
> items) as taking an array and a count. It's hard to do anything
> fancier, like wrapping the list into a structure with a "length"
> member, creating a linked list, or semi-hardcoding the length of the
> array with a preprocessor define. So the plugs might not fit the
> sockets, but at least all the sockets are set up in a similar way.
>
> Once you start allowing containers, that simplicity goes.
I consider simplicity and power at two ends of a spectrum. If one
must start from scratch, there is a lot to be said to start with
simplicity. But as the limitations of simplicity become apparent,
people will desire constructs with more power. And if power comes in
the form in a library that is standardized (STL), it is reasonable to
believe that one can use that standard to justify using a complex
library, just as one should prefer to use a C standard function.
That power comes with a cost, which is increased sophistication and
comprehension required for all developers using the library. I find
that this effect results in the increased stratification in the
expertise of C++ over C developers. Are you in the strata that can
properly use the STL, or template meta-programming, or designing class
hierarchies, or exception handling, and the list of features keep
growing.
I view C and C++ not as superior or inferior to one another, but as
points on this spectrum with their own advantages and disadvantages.
simplicity<----------------------->power
C++ is stretching their position to the right, while C tends to enjoy
its position where its at.
Best regards,
John D.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-11-01 21:44 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <slrnjb0r95.ng2.usenet-nospam@guild.seebs.net> |
| In reply to | #12419 |
On 2011-11-01, ImpalerCore <jadill33@gmail.com> wrote: > Do you have the same problem with int32_t? The only difference is > that one is *standardized* and the other 'DWORD' is not. No, there's a much bigger difference: One of them says what it actually means, the other says something that is almost exactly the opposite of what it means. > The > underlying concept is the same; you want a double-word on > architectures that support 16-bit integers and those that support 32- > bit integers. No, the underlying concept is "you want a 32-bit integer". DWORD is, on many modern machines, a *half-word*. But int32_t is always 32 bits. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | ImpalerCore <jadill33@gmail.com> |
|---|---|
| Date | 2011-11-02 07:07 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <5fa6c773-1c7d-44d4-bc1d-6f7b2a9c941e@h5g2000yqk.googlegroups.com> |
| In reply to | #12490 |
On Nov 1, 5:44 pm, Seebs <usenet-nos...@seebs.net> wrote: > On 2011-11-01, ImpalerCore <jadil...@gmail.com> wrote: > > > Do you have the same problem with int32_t? The only difference is > > that one is *standardized* and the other 'DWORD' is not. > > No, there's a much bigger difference: > > One of them says what it actually means, the other says something that > is almost exactly the opposite of what it means. > > > The > > underlying concept is the same; you want a double-word on > > architectures that support 16-bit integers and those that support 32- > > bit integers. > > No, the underlying concept is "you want a 32-bit integer". DWORD is, on > many modern machines, a *half-word*. But int32_t is always 32 bits. Interesting. I suppose my conception of "word" has been more defined by its use in the documentation of the hardware protocols I work with rather than a property of the processor. But I agree with you, DWORD is too ambiguous of a name to represent a fixed-width integer because of WORD's ambiguity. Best regards, John D.
[toc] | [prev] | [next] | [standalone]
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web