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 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2011-11-14 18:25 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <slrnjc2n8p.1321.willem@toad.stack.nl> |
| In reply to | #13297 |
Robert Wessel wrote:
) Lichtenstein doesn't have an army or military (they *had* an army - of
) about 80 men - but it was disbanded in the 1860s). The do have a
) police force of about 90 officers, with the usual small arms.
)
) In any event, the legion would likely suffer disproportionate
) casualties, but would overrun the Liechtensteiners as soon as they ran
) out of ammunition. I would cite the Battle of Rorke's Drift, which
) was very nearly lost by the British. In this case the force imbalance
) would be worse, even when facing a single legion.
I'm sure morale plays a large part in this, given that the Romans would
have never heard of firearms in the first place. It rather depends on
their level-headedness and to be honest, I have no idea on how this fares
with the Romans.
Also, perhaps there are civilians in Liechtenstein that have firearms
handy, for entertainment purposes? All it takes is one idiot with a
Gatling to take down a whole lot of 'em.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-11-11 14:15 -0800 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <1949a7ee-a831-416c-99a3-6fa8ae2095e5@u28g2000yqb.googlegroups.com> |
| In reply to | #13124 |
On Nov 11, 1:49 pm, c...@tiac.net (Richard Harter) wrote: > On Fri, 11 Nov 2011 11:17:21 -0800 (PST), nroberts > >I don't expect that it is unique to C, only that by saying it is IN C > >(which WAS stated, as you and I have now both quoted) that there's > >something outside of C that doesn't have it...or could be. Otherwise > >saying that it's in C is a pointless, inflammatory statement...sort of > >like saying there's a bias in American culture toward breathing air. > >Even though Americans indeed breath air, so does everyone and > >everything else living so the bias isn't exactly an American one. > > This is a fallacious argument based on a faulty analogy. Simply > observing that X has property A does not establish that there is > anything that does not have property A. It does not oblige me to show > that there could be something that does not have property A. Thank you for finally confirming my assessment that your statement was never meant to mean anything. Now that I know you're prone to posting gibberish just to stroke your ego I don't have to worry that I'm missing anything fundamental when I don't see the point.
[toc] | [prev] | [next] | [standalone]
| From | cri@tiac.net (Richard Harter) |
|---|---|
| Date | 2011-11-11 23:53 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <4ebdb403.123634286@text.giganews.com> |
| In reply to | #13135 |
On Fri, 11 Nov 2011 14:15:27 -0800 (PST), nroberts <roberts.noah@gmail.com> wrote: >On Nov 11, 1:49=A0pm, c...@tiac.net (Richard Harter) wrote: >> On Fri, 11 Nov 2011 11:17:21 -0800 (PST), nroberts >> >I don't expect that it is unique to C, only that by saying it is IN C >> >(which WAS stated, as you and I have now both quoted) that there's >> >something outside of C that doesn't have it...or could be. =A0Otherwise >> >saying that it's in C is a pointless, inflammatory statement...sort of >> >like saying there's a bias in American culture toward breathing air. >> >Even though Americans indeed breath air, so does everyone and >> >everything else living so the bias isn't exactly an American one. >> >> This is a fallacious argument based on a faulty analogy. =A0Simply >> observing that X has property A does not establish that there is >> anything that does not have property A. =A0It does not oblige me to show >> that there could be something that does not have property A. > >Thank you for finally confirming my assessment that your statement was >never meant to mean anything. Now that I know you're prone to posting >gibberish just to stroke your ego I don't have to worry that I'm >missing anything fundamental when I don't see the point. Well said, but you shouldn't leave it at that. By all means, ignore everything I post from now - you have established to your satisfaction that nothing I write is worth reading. In fact, if you have killfiles, put me in one immediately. You may be concerned that you might hurt my feelings by plonking me. Don't be. Do the right thing and put me in a killfile. You will all the better for it ... and so will I.
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-11-11 16:16 -0800 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <a1dc4e75-b15d-4c5c-bf17-cd6f362b40cf@o14g2000yqh.googlegroups.com> |
| In reply to | #13151 |
On Nov 11, 3:53 pm, c...@tiac.net (Richard Harter) wrote: > On Fri, 11 Nov 2011 14:15:27 -0800 (PST), nroberts > <roberts.n...@gmail.com> wrote: > >On Nov 11, 1:49=A0pm, c...@tiac.net (Richard Harter) wrote: > >> On Fri, 11 Nov 2011 11:17:21 -0800 (PST), nroberts > >> >I don't expect that it is unique to C, only that by saying it is IN C > >> >(which WAS stated, as you and I have now both quoted) that there's > >> >something outside of C that doesn't have it...or could be. =A0Otherwise > >> >saying that it's in C is a pointless, inflammatory statement...sort of > >> >like saying there's a bias in American culture toward breathing air. > >> >Even though Americans indeed breath air, so does everyone and > >> >everything else living so the bias isn't exactly an American one. > > >> This is a fallacious argument based on a faulty analogy. =A0Simply > >> observing that X has property A does not establish that there is > >> anything that does not have property A. =A0It does not oblige me to show > >> that there could be something that does not have property A. > > >Thank you for finally confirming my assessment that your statement was > >never meant to mean anything. Now that I know you're prone to posting > >gibberish just to stroke your ego I don't have to worry that I'm > >missing anything fundamental when I don't see the point. > > Well said, but you shouldn't leave it at that. By all means, ignore > everything I post from now - you have established to your satisfaction > that nothing I write is worth reading. In fact, if you have > killfiles, put me in one immediately. You may be concerned that you > might hurt my feelings by plonking me. Don't be. Do the right thing > and put me in a killfile. You will all the better for it ... and so > will I. Monkey.
[toc] | [prev] | [next] | [standalone]
| From | cri@tiac.net (Richard Harter) |
|---|---|
| Date | 2011-11-11 19:53 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <4ebd7b86.109172370@text.giganews.com> |
| In reply to | #13105 |
On Fri, 11 Nov 2011 18:37:10 +0000 (UTC), John Gordon <gordon@panix.com> wrote: >In <4EBD693F.4050705@verizon.net> James Kuyper <jameskuyper@verizon.net> writes: > >> > "As a side note, there is a subtle bias in C in favor of arrays of >> > structs rather than structs of arrays." -- Richard Harter > >> I see nothing in there about the bias being unique to C. > >I may have responded to the wrong sub-thread. > >If I'm reading my attributions correctly, nroberts said this: > > It's been said that there is a bias in C that favors arrays of structs > rather than structs of arrays. > >And then someone (Ben Bacarisse?) responded with this: > > I don't think that claim has been made. It was Ben. > >So I provided a quote of just such a claim. > >The quote does not state the bias is unique to C, but it does state that >C has the bias, which is the point I was responding to. But you quoted me and when you did you snipped what Roberts had written. This is what you wrote: BEGIN In <4ebd6341.102959177@text.giganews.com> cri@tiac.net (Richard Harter) writes: > AFAIK, nobody made such a claim, certainly not I. AFAICT, the whole > notion is an invention of yours. "As a side note, there is a subtle bias in C in favor of arrays of structs rather than structs of arrays." -- Richard Harter END and here is where you got my remark from. If you had read my entire post and hadn't snipped out what Roberts wrote you would have seen: BEGIN On Fri, 11 Nov 2011 09:29:26 -0800 (PST), nroberts <roberts.noah@gmail.com> wrote: >On Nov 10, 4:17=A0pm, "BartC" <b...@freeuk.com> wrote: >> "nroberts" <roberts.n...@gmail.com> wrote in message > >> > For the claim that there is a bias in C toward #1 over #2 there must >> > be a way in which this preference does not exist outside of C >> > somewhere. >> >> OK, so you're disputing not just the existence of a bias, but that fact t= >hat >> it must be unique to C in order to exist? > >No, I'm claiming that the bias must be unique to C in order to be >unique to C. The claim that it WAS unique to C is what I'm trying to >fathom. AFAIK, nobody made such a claim, certainly not I. AFAICT, the whole notion is an invention of yours. END Lesson: Be careful about what you snip and always make sure you have the right context.
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-11-11 12:02 -0800 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <9000745c-7a80-4f02-92ea-36a504e43eba@w3g2000vbw.googlegroups.com> |
| In reply to | #13114 |
On Nov 11, 11:53 am, c...@tiac.net (Richard Harter) wrote: > On Fri, 11 Nov 2011 18:37:10 +0000 (UTC), John Gordon > > > > > > > > > > <gor...@panix.com> wrote: > >In <4EBD693F.4050...@verizon.net> James Kuyper <jameskuy...@verizon.net> writes: > > >> > "As a side note, there is a subtle bias in C in favor of arrays of > >> > structs rather than structs of arrays." -- Richard Harter > > >> I see nothing in there about the bias being unique to C. > > >I may have responded to the wrong sub-thread. > > >If I'm reading my attributions correctly, nroberts said this: > > > It's been said that there is a bias in C that favors arrays of structs > > rather than structs of arrays. > > >And then someone (Ben Bacarisse?) responded with this: > > > I don't think that claim has been made. > > It was Ben. > > > > >So I provided a quote of just such a claim. > > >The quote does not state the bias is unique to C, but it does state that > >C has the bias, which is the point I was responding to. > > But you quoted me and when you did you snipped what Roberts had > written. This is what you wrote: > > BEGIN > In <4ebd6341.102959...@text.giganews.com> c...@tiac.net (Richard > > Harter) writes: > > AFAIK, nobody made such a claim, certainly not I. AFAICT, the whole > > notion is an invention of yours. > > "As a side note, there is a subtle bias in C in favor of arrays of > structs rather than structs of arrays." -- Richard Harter > END > > and here is where you got my remark from. If you had read my entire > post and hadn't snipped out what Roberts wrote you would have seen: > > BEGIN > On Fri, 11 Nov 2011 09:29:26 -0800 (PST), nroberts > > <roberts.n...@gmail.com> wrote: > >On Nov 10, 4:17=A0pm, "BartC" <b...@freeuk.com> wrote: > >> "nroberts" <roberts.n...@gmail.com> wrote in message > > >> > For the claim that there is a bias in C toward #1 over #2 there must > >> > be a way in which this preference does not exist outside of C > >> > somewhere. > > >> OK, so you're disputing not just the existence of a bias, but that fact t= > >hat > >> it must be unique to C in order to exist? > > >No, I'm claiming that the bias must be unique to C in order to be > >unique to C. The claim that it WAS unique to C is what I'm trying to > >fathom. > > AFAIK, nobody made such a claim, certainly not I. AFAICT, the whole > notion is an invention of yours. > END > > Lesson: Be careful about what you snip and always make sure you have > the right context. Actually, you're mixing and matching here. The bits you're quoting come from different lines of conversation. The one that Mr. Gordan was replying to was correctly stated, the one your pasting into contained my misspeaking. You're also completely ignoring the fact that I already corrected the mistake regarding "unique to C". Now you're just harping on something that was never meant in order to ignore the real issue at hand, which is getting YOU to explain what YOU said, which very much was that _C_ has this bias. If there's nothing special about C in any way regarding this bias, why is it C's?
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-14 02:05 -0800 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <bec72dcd-dded-4354-a690-c13ede728173@l24g2000yqm.googlegroups.com> |
| In reply to | #13115 |
On Nov 11, 8:02 pm, nroberts <roberts.n...@gmail.com> wrote: > On Nov 11, 11:53 am, c...@tiac.net (Richard Harter) wrote: > > > > > > > On Fri, 11 Nov 2011 18:37:10 +0000 (UTC), John Gordon > > > <gor...@panix.com> wrote: > > >In <4EBD693F.4050...@verizon.net> James Kuyper <jameskuy...@verizon.net> writes: > > > >> > "As a side note, there is a subtle bias in C in favor of arrays of > > >> > structs rather than structs of arrays." -- Richard Harter > > > >> I see nothing in there about the bias being unique to C. > > > >I may have responded to the wrong sub-thread. > > > >If I'm reading my attributions correctly, nroberts said this: > > > > It's been said that there is a bias in C that favors arrays of structs > > > rather than structs of arrays. > > > >And then someone (Ben Bacarisse?) responded with this: > > > > I don't think that claim has been made. > > > It was Ben. > > > >So I provided a quote of just such a claim. > > > >The quote does not state the bias is unique to C, but it does state that > > >C has the bias, which is the point I was responding to. > > > But you quoted me and when you did you snipped what Roberts had > > written. This is what you wrote: > > > BEGIN > > In <4ebd6341.102959...@text.giganews.com> c...@tiac.net (Richard > > > Harter) writes: > > > AFAIK, nobody made such a claim, certainly not I. AFAICT, the whole > > > notion is an invention of yours. > > > "As a side note, there is a subtle bias in C in favor of arrays of > > structs rather than structs of arrays." -- Richard Harter > > END > > > and here is where you got my remark from. If you had read my entire > > post and hadn't snipped out what Roberts wrote you would have seen: > > > BEGIN > > On Fri, 11 Nov 2011 09:29:26 -0800 (PST), nroberts > > > <roberts.n...@gmail.com> wrote: > > >On Nov 10, 4:17=A0pm, "BartC" <b...@freeuk.com> wrote: > > >> "nroberts" <roberts.n...@gmail.com> wrote in message > > > >> > For the claim that there is a bias in C toward #1 over #2 there must > > >> > be a way in which this preference does not exist outside of C > > >> > somewhere. > > > >> OK, so you're disputing not just the existence of a bias, but that fact t= > > >hat > > >> it must be unique to C in order to exist? > > > >No, I'm claiming that the bias must be unique to C in order to be > > >unique to C. The claim that it WAS unique to C is what I'm trying to > > >fathom. > > > AFAIK, nobody made such a claim, certainly not I. AFAICT, the whole > > notion is an invention of yours. > > END > > > Lesson: Be careful about what you snip and always make sure you have > > the right context. > > Actually, you're mixing and matching here. The bits you're quoting > come from different lines of conversation. The one that Mr. Gordan > was replying to was correctly stated, the one your pasting into > contained my misspeaking. > > You're also completely ignoring the fact that I already corrected the > mistake regarding "unique to C". Now you're just harping on something > that was never meant in order to ignore the real issue at hand, which > is getting YOU to explain what YOU said, which very much was that _C_ > has this bias. because we're in a C news-group? I suspect many langaues have a similar "bias". But I also epect many don't if they don't try and specify soem sort of storage layout. You claimed this "bias" was built into hardware architecture, I'm not sure you ever showed this. If there's nothing special about C in any way > regarding this bias, why is it C's?- Hide quoted text - > > - Show quoted text -
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-11-14 08:36 -0800 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <5910e4b7-ff1a-48fd-ade4-86fe4c3a0736@w1g2000vba.googlegroups.com> |
| In reply to | #13269 |
On Nov 14, 2:05 am, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > On Nov 11, 8:02 pm, nroberts <roberts.n...@gmail.com> wrote: > > You're also completely ignoring the fact that I already corrected the > > mistake regarding "unique to C". Now you're just harping on something > > that was never meant in order to ignore the real issue at hand, which > > is getting YOU to explain what YOU said, which very much was that _C_ > > has this bias. > > because we're in a C news-group? I suspect many langaues have a > similar "bias". But I also epect many don't if they don't try and > specify soem sort of storage layout. You claimed this "bias" was built > into hardware architecture, I'm not sure you ever showed this. Mana mana
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-10 17:00 -0800 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <lnwrb779sv.fsf@nuthaus.mib.org> |
| In reply to | #13064 |
nroberts <roberts.noah@gmail.com> writes:
> I'm going to try to get this argument back on track to see if there's
> anything to gleam from it or if my initial assumption, that people
> were just making crazy statements to win an argument, is in fact true.
>
> It's been said that there is a bias in C that favors arrays of structs
> rather than structs of arrays. The basis of this statement has so far
> seemed to be that there are two ways, among others, that one might
> organize a list of records:
>
> 1. As an array of records:
>
> struct record
> {
> type0 field0;
> type1 field1;
> ...
> } records[];
>
> 2. As a structure of arrays:
> struct
> {
> type0 field0[];
> type1 field1[];
> ...
> } records;
I haven't made any claims about any bias one way or the other.
But I'll mention that (2) is illegal, and (1) is valid only if it's
a declaration, not a definition.
Most arrays, I suspect, have a length that is not determinable
at compile time, and are allocated via malloc() and then accessed
via pointers. (I have no statistics on this.)
If I need N "struct record"s, I can do something like this:
struct record records = malloc(N * sizeof *records);
if (records == NULL) /* error handling */
for (int i = 0; i < N; i ++) {
/* do something with records[i] */
}
With the second approach, you'd need two allocations, one for an array
of type0 objects and another for an array of type1 objects.
Even if you have a fixed number of items (say, 100), there's not a
whole lot of practical difference between
struct record {
type0 field0;
type1 field1;
} records[100];
and
struct {
type0 field0[100];
type1 field1[100];
} records;
-- until you want to deal with individual records. For example, the
array-of-structs method makes it easier to write a function that deals
with a single record:
void func(struct record rec);
whereas the struct-containing-arrays method means that it would have to
be written as:
void func(type0 field0, type1 field1);
If your usage pattern doesn't require that kind of thing, and you
find the struct-containing-arrays method easier to deal with for
some reason, then by all means use it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-11-11 04:53 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <0.1a58db304bd70f0e7d15.20111111045341GMT.87zkg3xnsa.fsf@bsb.me.uk> |
| In reply to | #13064 |
nroberts <roberts.noah@gmail.com> writes:
> I'm going to try to get this argument back on track to see if there's
> anything to gleam from it or if my initial assumption, that people
> were just making crazy statements to win an argument, is in fact true.
>
> It's been said that there is a bias in C that favors arrays of structs
> rather than structs of arrays.
I don't think that claim has been made. I've posted another reply where
I try to clarify what I think has been said, but I re-word it below.
> The basis of this statement has so far
> seemed to be that there are two ways, among others, that one might
> organize a list of records:
>
> 1. As an array of records:
>
> struct record
> {
> type0 field0;
> type1 field1;
> ...
> } records[];
>
> 2. As a structure of arrays:
> struct
> {
> type0 field0[];
> type1 field1[];
> ...
> } records;
>
> Alternatives that have not been brought up are things like having
> individual variables for each element of each record, random placement
> in a blob, some sort of scattered matrix, quantum entanglement...etc.
> So the premise at this point would be that you are organizing data in
> a hierarchy of containers and contents, otherwise there's nothing to
> discuss.
>
> For the claim that there is a bias in C toward #1 over #2 there must
> be a way in which this preference does not exist outside of C
> somewhere. My assumption to date, which seems clear to me at least,
> is that no such environment exists or can exist given our
> understanding of logic and computability.
>
> A couple of valid attempts have been made to show that such an
> environment is possible:
>
> 1. You could invent a "language X" that has some other form of
> container that pretty much logically resembles the first case, but
> uses a functional syntax such that you could implement it internally
> with the later version (though why you would is questionable since
> this is not exposed and so can't be taken advantage of).
The advantage was intended to be efficiency (presumably of cache use).
That's why the two layouts were not explicitly exposed.
> 2. There are cases WITHIN C in which the supposed bias is inverted,
> such as when you want performance gains for functions that operate on
> the entire record set, but only on one field...and also because
> expressing a generic function that can operate on a particular,
> supplied field within a generic record (like a generic sum function
> that could sum up ages within a list of person records) is so
> complicated that you generally don't. In my opinion this is a very
> valid argument why this idea that C is causing any bias to #1 is in
> error, but I've let that slide hoping for refinement.
Yes, that's because the "bias" is not for one over the other. It's that
having picked one (for whatever reason) you are barred from using
natural accesses to the other organisation. (This is clearest with 2D
arrays.)
> I have responded to both by saying that "language X" can be written in
> C (this seems to be a debatable proposition but nobody's said why so
> far) since it's just a higher abstraction than was originally proposed
> and that sure, one might prefer the less obvious organization in some
> situations due to the performance gains you might get in the standard
> memory model, but that these are not issues specific in any way to C.
This is very far from the original debate. The original point was that
C did not have either. I went a little further and said that they go
against C view of objects, so they can't be added to C without
a major overhaul of the language.
> The newest argument seems to be that in non-standard memory models,
> which C kind of assumes in some ways, language X could take advantage
> of some yet unspecified memory addressing method that C would be
> incapable of.
I don't recall this argument at all. It's possible I've missed it, but
it sounds very odd indeed. What is a non-standard memory model? (Or,
conversely, what is a standard one?)
> I concede that this could possibly be true but I don't
> believe this does anything to the problem either. Remember that it is
> assumed at this point that you're attempting to organize data into a
> container/contained relationship, which is an issue that I believe
> would still come up with ANY KIND of abstraction one could possibly
> come up with. There is always going to be a selection of logical
> organizations one can use for their data and which one picks is an
> issue of the data and its use, but has nothing to do with syntax or
> memory model or even if objects exist in memory in any kind of
> recognizable form we currently expect, or anything that could be said
> to be a component of C specifically. So long as there exists a
> mapping between our logical view and the memory model we don't
> actually care what that is unless we're trying to exploit it, which
> again won't be language specific.
I don't follow this at all.
> I don't believe this begs the question. Without a need to organize
> data into container and contained there is no sense by which it can be
> said that C has a bias toward one method or another. We must be
> trying to organize data in some sense for there to be anything to
> discuss. If we were simply talking about random values spattered
> about in a completely decoupled manner, then C actually prefers
> independent variables..and so would any other language we could think
> of. We're not though. If we were going even further and talking
> about a system in which objects themselves are not coherent and
> mappable to logical constructs then I think the entire idea of
> computing goes kaput.
>
> It is true that we could possibly come up with some memory model that
> is not standard in which the cost of abstracting a "language X" is not
> paid because it's actually closer to the machine's memory model than
> structures and arrays possibly. I don't believe this solves the issue
> either though because we can push language X into reductio ad absurdum
> by proposing its obvious extension: field(records_blob, index_0,
> index_1, field_name). This expresses a hierarchy. Does it make more
> sense to iterate by index_0 or index_1? Under what conditions? At
> what point do we decide that instead of having index_0 through index_N
> do we actually return some sort of container as our data type? Will
> it make as much sense then to invert the relationship and if not does
> that comprise of a bias in the language?
>
> Working with simple examples has hidden the bigger, higher level issue
> to some people it seems.
I suspect (mainly because I don't know what you are saying here) that
the problem is the reverse -- that the lessons of a simple example are
being lost in ill-defined terminology.
> Another issue here is that "language X" is incomplete. We've not
> devised a declarative syntax for it. If we assume that either
> declaration we might use in C can be used in "language X" and then
> manipulated through the field syntax, is there any reason at all
> anymore to use the second version? The whole argument for even using
> the second version has been entirely dependent upon the nature of C
> and the standard memory model. Does not the very structure of the
> data make the first version more understandable for humans? If so,
> how could this be a language issue? If not, please explain.
Again, I just don't follow this. In case anyone still cares, what you
called "language X" was the proposition of adding a keyword
("transpose", I think) to flip the layout of 2D data structures. This
would permit the programmer to use the natural declaration in situations
where the transposed layout was more efficient (always assuming that
such situations exist).
Another language idea has been discussed (and it's independent of the
first one) which it the ability to "slice" a struct with array members
to get a struct, or to slice an array of structs to get an array of the
members. (One would presumably extend this to array of arrays as well.)
The transpose idea lets to use the natural declaration even when you
want the layout implied by the other. You still have only one
convenient was to access the data -- the one determined by the
declaration. The second idea lets you access the data structure in
either way.
> Even further, the field() syntax proposed in "language X" seems to
> mimic the first version more than the second. Given the freedom to
> evolve a completely new language that avoids the biases in C we've
> created something that very much resembles that which is being said is
> C's bias. The whole motivating factor for our attempt to abstract is
> not, "How can we get C to make #1 look more like #2,"
Actually, I do like that idea (the access either one as if it were the
other) but I agree that it's not the original motivation.
> but, "How can we
> get C to give us the speed advantages and generic re-usability we want
> from #2, but a logical structure that's more resembling #1 because
> that's what makes more sense to us."
Exactly!
> Unfortunately, the answer isn't
> so easy when it comes to composing generic functions because this is
> something that C is simply not good at.
and that was my original point, though I put it more strongly. Altering
the relationship between declaration and location contravenes C's view
of objects.
> The speed issue on the other
> hand can be taken care of by providing macros that turn a #2
> implementation into something resembling language X.
But the complaint was not that you can't use layout #2 when you need to,
but that some otherwise natural accesses become convoluted. I don't see
how macros can do more than paper over the cracks.
> Now, if something I've just said is wrong then please explain how. If
> your only reply is that "nobody's saying ..." or some other red
> herring then I'm not interested;
Eh? Sorry to have wasted your time. I thought it would be useful to
explain what I think people have been saying, but if you had put this
upfront I would not have replied (it's been quite a time consuming reply
up to this point).
> if you don't think anyone's saying it
> then there's no reason to argue about it...if the fact that the very
> next person contradicts you isn't clue enough. If you've legitimately
> got a reason why C specifically causes a bias toward the first
> implementation above then I'm all ears. Even if you've got a
> legitimate reason why "C like" language have this bias I'm all
> ears...what possible language doesn't?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-11-11 09:27 -0800 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <451631a3-ce5a-4287-aea4-023674bb737a@a5g2000vbb.googlegroups.com> |
| In reply to | #13079 |
On Nov 10, 8:53 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: > nroberts <roberts.n...@gmail.com> writes: > > I'm going to try to get this argument back on track to see if there's > > anything to gleam from it or if my initial assumption, that people > > were just making crazy statements to win an argument, is in fact true. > > > It's been said that there is a bias in C that favors arrays of structs > > rather than structs of arrays. > > I don't think that claim has been made. I quoted it verbatim just two posts ago.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-11-12 04:27 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <0.53d645d03e0afa918a00.20111112042733GMT.87hb2avubu.fsf@bsb.me.uk> |
| In reply to | #13099 |
nroberts <roberts.noah@gmail.com> writes: > On Nov 10, 8:53 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote: >> nroberts <roberts.n...@gmail.com> writes: >> > I'm going to try to get this argument back on track to see if there's >> > anything to gleam from it or if my initial assumption, that people >> > were just making crazy statements to win an argument, is in fact true. >> >> > It's been said that there is a bias in C that favors arrays of structs >> > rather than structs of arrays. >> >> I don't think that claim has been made. > > I quoted it verbatim just two posts ago. So you did -- I missed it. However, Richard's point is symmetric but I agree that this was not clear in the first post. The "bias" is for arrays of structs if we want to access the structs but it would show up as a bias for structs of arrays if it was common to want to process the members as arrays. He is, I am sure, perfectly well aware of the symmetry. In the message I replied to: | The issue here is that our data in effect is a two dimensional array | with one of the dimensions being the fields. In some languages | slicing is intrinsic to the language; in C it is not. Slicing 2D data is symmetric and applies to either declaration. If one organisation is preferred over the other, it is only because some accesses are more common *in practice*. I find this observation entirely un-contentious. I suspect you do not, because when I made this general point -- about C's inability to talk about objects in the "other" dimension (arrays of members when we have arrays of structs and structs when we have a struct whose members are arrays) -- you still seemed to disagree. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-11-10 23:00 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <0.ff2e80223ab991254e37.20111110230007GMT.87hb2bziq0.fsf@bsb.me.uk> |
| In reply to | #13030 |
nroberts <roberts.noah@gmail.com> writes:
> On Nov 8, 4:06 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> nroberts <roberts.n...@gmail.com> writes:
>> > On Nov 3, 8:30 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> >> nroberts <roberts.n...@gmail.com> writes:
>> >> > On Nov 3, 5:51 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> >> >> c...@tiac.net (Richard Harter) writes:
>>
>> >> >> The purpose of transposing the data structure is to get a different
>> >> >> layout in memory,
>>
>> >> > I disagree. The purpose of transposing the data structure is to get a
>> >> > different *logical view* of the data, which alters the algorithms
>> >> > you'll write to access or change that data.
>>
>> >> I meant the purpose of doing so /in this discussion/ was to get a
>> >> different layout in memory. The fact that the accesses will then be all
>> >> messed up is what Richard Harter describes as a bias in the syntax, and
>> >> I prefer to think of as something more fundamental about C's view of
>> >> objects and types.
>>
>> > Right, but not specifically C...it's fundamental to the nature of
>> > computing.
>>
>> Forgive me for cutting you off here, but the fact that you say this
>> makes it clear that I've not explained myself at all well. Until we
>> clear this up, it's just a waste of time discussing details.
>
> Perhaps you came in late and are unfamiliar with the original
> statements and just found yourself on the wrong side of a discussion.
> You weren't the one to originally claim that C syntax creates these
> biases but you ended up arguing with me so I assumed you were
> supporting it.
I think I've understood the origins of this thread. To be sure, I've
just reviewed it and I've not come up with any surprises.
>> I am saying that the organisation of data in memory, and the
>> organisation of data into logical structures are orthogonal, but many
>> languages (like C) link the two together.
>
> Because in computers, memory is one large array like structure.
> That's the fundamental abstraction that our hardware attempts to
> create.
I disagree with this, but that could lead to a whole new (and off topic)
discussion. Even if this is universally true, are you saying that it is
why C links logical structure to memory layout? If so I don't see the
connection. My own view is that C does this because it is a low-level
language designed to be "close to the machine".
>> In high-level languages, arrays are used to represent data sequences --
>> there need be no implication that one array element is next to its
>> successor in memory. Similarly, structures are used to group data into
>> units that can be manipulated as one.
>
> Which is why quite a while back I argued that what people claiming
> that C's syntax causes a bias like this are actually arguing for is
> abstractions. The further away you get from the fundamental
> abstraction that the hardware provides, a long array, the more
> operations have to be conducted to project the "higher" abstraction
> onto the "lower" one. This is why languages like "language X" cost
> more in terms of performance. C is an attempt to provide just enough
> abstraction to be useful across all computers, which means it is as
> close to the underlying abstraction as necessary.
There may be a cost, but it is not inevitable. In general, higher-level
languages have higher costs, but what has been called "language X" was
suggested by me because it would, in some cases, *reduce* run-time costs
(and there is no compulsion to use it's non-C features where they don't
improve performance).
It's incidental this argument, but, quite correctly, already distances
itself from the "large array" abstraction. It does so because a large
array is *not* the view of memory that all hardware provides, and
the designers of C wanted to include such hardware as possible targets.
>> C insists that such a unit be
>> contiguous in memory, but this does not follow inevitably from the
>> desire to group two coordinates into a point.
>
> Actually, C doesn't insist on this at all, it's just the simplest
> mapping.
I mean contiguous as far as C's view of memory is concerned -- that you
can choose to view any object as a char array whose elements have
consecutive addresses. I don't think it matters to either of our points
of view how these are mapped by the hardware. The programmer sees only
one view of objects -- as contiguous regions of storage. Any access
that violates this model can't be supported by C's model of objects.
This was my original point. You could add the syntax to, say, access a
column from an array of rows, but such a thing could not be an object
like any other -- you could never pass a pointer to it to a function
that operates on an ordinary C array, for example.
>> I am saying that C can't provide a higher abstraction. It
>> inevitable links the logical structure with the memory layout.
>
> This is an incorrect view of higher level languages. Since computers
> are what they are, every language inevitably links logical structure
> to memory layout. It has to. It can provide an interface that does
> not, but that interface comes at a cost and underneath you can be sure
> that it projects that interface into the hardware's abstraction in a
> very determined manner, just like C does.
Maybe we are using the same words in different ways. Let's use an
example: I want an array of cons cells for my Lisp interpreter. The
logical way to define this is
struct cell { int car, cdr } heap[1000];
If I have a function
int find(int array[], int needle);
that can search an array for a particular value, C does not permit me to
speak of the whole array of car values in the heap. First, it has no
syntax for this (maybe heap[].car?) but, more significantly its object
model would not permit it.
Given what you've written above, I suspect we agree here. Your use of
"link" is might be "there must be *some* correspondence" and mine is
"there is a restricted correspondence".
>> I am pointing out that the choice here is unnecessary. A language could
>> permit this structure to be defined in the "cohesive" way and yet be
>> laid out in the most efficient way. C forces you to chose between two
>> logically different organisations if you need two physically different
>> layouts.
>
> Because C doesn't provide higher abstractions. The abstractions you
> are looking for CAN be created in C though and the lower level
> abstractions that it provides are a nice way to describe the mapping.
> In fact, most languages that we can think of originally start by being
> written in a language like C, if they ever even go past that point and
> become self-hosting.
>
> On the other hand, what you seem to want, and I agree that it would be
> quite difficult to provide in C (or ANY language) is an abstraction
> that can, through the way you use it, interpret what the best layout
> would be. This is some sort of super-optimizer and indeed would
> require a lot of research to provide. The easiest method would
> probably be to invent a new language and provide a compiler that did
> this; you'd probably write it in C or C++. On the other hand, for
> most of the problems you'd attempt to solve with this abstraction it
> would probably be best to let the programmer decide what to turn on
> and when. This would, at least, be a lot simpler to implement and
> would solve most real-world issues. This is probably why I can't
> think of a single language that implements anything like what you seem
> to expect from C.
I don't expect it all. I posted to say why it is more than a case of
tweaking C's syntax.
Also, I think I posted that I doubt the pay-off of being able to choose
the layout would be worth the effort due to the rarity of cases where it
matters. If that is true, the effort of doing it automatically is
surely beyond the pale. Just because I make a point on one side of a
debate does not mean that I am dedicated to the cause!
I am in favour, however, of languages that provide highly expressive
constructs, and being able to refer to both columns and rows of a matrix
in equally flexible ways is a big advantage. Algol 68 did this. I am
less sure about doing the same for structs of arrays and arrays or
structs, but it seems to be a nice feature.
> Something similar that perhaps actually does provide what you'd
> expect, would be a state based template pattern that switches
> implementation based on statistics of its use to date. This would be
> both more powerful and less powerful than a new language with a really
> smart optimizer...depending on your needs. This, and anything more
> determinable, can be made in C without much difficulty.
I think we have different metrics for difficulty! For one thing, I
would factor in the cost of lost expressiveness -- having a flexible
layout (in C) would affect how the objects can be referenced, would it
not?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-11-10 15:10 -0800 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <26949187-9a81-469e-9849-b0cba8ab568b@r9g2000vbw.googlegroups.com> |
| In reply to | #13065 |
On Nov 10, 3:00 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Maybe we are using the same words in different ways. Let's use an
> example: I want an array of cons cells for my Lisp interpreter. The
> logical way to define this is
>
> struct cell { int car, cdr } heap[1000];
>
> If I have a function
>
> int find(int array[], int needle);
>
> that can search an array for a particular value, C does not permit me to
> speak of the whole array of car values in the heap. First, it has no
> syntax for this (maybe heap[].car?) but, more significantly its object
> model would not permit it.
Lets assume I agreed with all that 100% (truth is more like 80-90 but
whatever).
Could you explain to me again why this serves as a reason that C has a
bias toward constructs similar to what you have as "cell" above rather
than something like:
struct
{
int cars[1000];
int cdrs[1000];
} cells;
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-11-11 03:30 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <0.a1564bfcdb04660502ef.20111111033011GMT.8762irz67w.fsf@bsb.me.uk> |
| In reply to | #13066 |
nroberts <roberts.noah@gmail.com> writes:
> On Nov 10, 3:00 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>> Maybe we are using the same words in different ways. Let's use an
>> example: I want an array of cons cells for my Lisp interpreter. The
>> logical way to define this is
>>
>> struct cell { int car, cdr } heap[1000];
>>
>> If I have a function
>>
>> int find(int array[], int needle);
>>
>> that can search an array for a particular value, C does not permit me to
>> speak of the whole array of car values in the heap. First, it has no
>> syntax for this (maybe heap[].car?) but, more significantly its object
>> model would not permit it.
>
> Lets assume I agreed with all that 100% (truth is more like 80-90 but
> whatever).
>
> Could you explain to me again why this serves as a reason that C has a
> bias toward constructs similar to what you have as "cell" above rather
> than something like:
>
> struct
> {
> int cars[1000];
> int cdrs[1000];
> } cells;
It doesn't. The bias (and I don't like that term but it seems to have
stuck) is that if you are forced to choose the second for reasons of
efficiency, you have no simple way to recover (and process) the cells.
At least this is how I understood Richard Harter's original remark.
I prefer to think of it simply as a limitation -- and for C, quite a
reasonable one. Relaxing it would, I think, require a wholesale
re-thinking of what C considers to be an object.
Replace the struct with an array of two items and I think it becomes
clear that it's reasonable to access either version along either rows or
columns. This is probably the most significant version of "the bias" --
declare a 2D (or higher) array and you are stuck with the order you've
picked. For many algorithms, it is natural to treat rows and columns
interchangeably.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-11 00:41 -0800 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <db6b56e4-265e-4f12-940c-2293cbb7c41d@f29g2000yqa.googlegroups.com> |
| In reply to | #13030 |
On Nov 10, 5:13 pm, nroberts <roberts.n...@gmail.com> wrote:
> On Nov 8, 4:06 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> > nroberts <roberts.n...@gmail.com> writes:
> > > On Nov 3, 8:30 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> > >> nroberts <roberts.n...@gmail.com> writes:
> > >> > On Nov 3, 5:51 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> > >> >> The purpose of transposing the data structure is to get a different
> > >> >> layout in memory,
>
> > >> > I disagree. The purpose of transposing the data structure is to get a
> > >> > different *logical view* of the data, which alters the algorithms
> > >> > you'll write to access or change that data.
not how I'd use "logical"
> > >> I meant the purpose of doing so /in this discussion/ was to get a
> > >> different layout in memory. The fact that the accesses will then be all
> > >> messed up is what Richard Harter describes as a bias in the syntax, and
> > >> I prefer to think of as something more fundamental about C's view of
> > >> objects and types.
>
> > > Right, but not specifically C...it's fundamental to the nature of
> > > computing.
I don't think so. I know we've been talking array-of-structs and
structs-of-arrays. But consider arrays-of-arrays. C implements 2d
arrays (or as near as C gets to 2-d arrays) as a column array
containing row arrays. It doesn't *have* to do this Fortran, I
believe, implements it as a row array containing coumn arrays. The
most efficeint way to access a 2-d array is affected by this. The
PHYSICAL layout is different but the LOGICAL loyout isn't. Similar
things could be done with structs and arrays.
> > Forgive me for cutting you off here, but the fact that you say this
> > makes it clear that I've not explained myself at all well. Until we
> > clear this up, it's just a waste of time discussing details.
>
> Perhaps you came in late and are unfamiliar with the original
> statements and just found yourself on the wrong side of a discussion.
> You weren't the one to originally claim that C syntax creates these
> biases but you ended up arguing with me so I assumed you were
> supporting it.
he's probably agreeing with you on one thing and disagreeing with
another. I for instance don't think it's just syntax but I'm yet to be
convinced its a law of nature or something.
> > I am saying that the organisation of data in memory, and the
> > organisation of data into logical structures are orthogonal, but many
> > languages (like C) link the two together.
>
> Because in computers, memory is one large array like structure.
> That's the fundamental abstraction that our hardware attempts to
> create.
consider the 8xx86 for more bizzare memory layout
> > In high-level languages, arrays are used to represent data sequences --
> > there need be no implication that one array element is next to its
> > successor in memory. Similarly, structures are used to group data into
> > units that can be manipulated as one.
>
> Which is why quite a while back I argued that what people claiming
> that C's syntax causes a bias like this are actually arguing for is
> abstractions. The further away you get from the fundamental
> abstraction that the hardware provides, a long array, the more
> operations have to be conducted to project the "higher" abstraction
> onto the "lower" one. This is why languages like "language X" cost
> more in terms of performance.
not necessarily. I thought the point was X laid things out in memory
in a different way to C and that this may give a performance
improvement to certain algorithms
> C is an attempt to provide just enough
> abstraction to be useful across all computers, which means it is as
> close to the underlying abstraction as necessary.
the underlying "hardware abstraction"? C provides an abstraction that
matches well (but not perfectly) with much modern hardware. Its pretty
close to the hardware. I'm not sure what "as close as necessary"
means. Who decides what is necessary? C is a great success at what it
does no doubt.
> > C insists that such a unit be
> > contiguous in memory, but this does not follow inevitably from the
> > desire to group two coordinates into a point.
>
> Actually, C doesn't insist on this at all, it's just the simplest
> mapping.
C does insist on this.
struct Point {int x; iny y} pt;
&pt.a < &pt.b is well defined and true.
> > I am saying that C can't provide a higher abstraction. It
> > inevitable links the logical structure with the memory layout.
well it *could*, but it doesn't
> This is an incorrect view of higher level languages. Since computers
> are what they are, every language inevitably links logical structure
> to memory layout. It has to.
it doesn't have to be fixed and static though. logically contiguous
items could be sprayed all over physical memory.
> It can provide an interface that does
> not, but that interface comes at a cost and underneath you can be sure
> that it projects that interface into the hardware's abstraction in a
> very determined manner, just like C does.
well C does this but I don't see why an HLL must do this.
> > I am pointing out that the choice here is unnecessary. A language could
> > permit this structure to be defined in the "cohesive" way and yet be
> > laid out in the most efficient way. C forces you to chose between two
> > logically different organisations if you need two physically different
> > layouts.
>
> Because C doesn't provide higher abstractions. The abstractions you
> are looking for CAN be created in C though and the lower level
> abstractions that it provides are a nice way to describe the mapping.
> In fact, most languages that we can think of originally start by being
> written in a language like C, if they ever even go past that point and
> become self-hosting.
>
> On the other hand, what you seem to want, and I agree that it would be
> quite difficult to provide in C
I don't think anyone is askign for this. Hence "language X"
> (or ANY language) is an abstraction
> that can, through the way you use it, interpret what the best layout
> would be.
or a special type of inside-out data structure.
> This is some sort of super-optimizer and indeed would
> require a lot of research to provide. The easiest method would
> probably be to invent a new language and provide a compiler that did
> this; you'd probably write it in C or C++. On the other hand, for
> most of the problems you'd attempt to solve with this abstraction it
> would probably be best to let the programmer decide what to turn on
> and when. This would, at least, be a lot simpler to implement and
> would solve most real-world issues. This is probably why I can't
> think of a single language that implements anything like what you seem
> to expect from C.
no one "expects" this from C
> Something similar that perhaps actually does provide what you'd
> expect, would be a state based template pattern that switches
> implementation based on statistics of its use to date. This would be
> both more powerful and less powerful than a new language with a really
> smart optimizer...depending on your needs. This, and anything more
> determinable, can be made in C without much difficulty.
[toc] | [prev] | [next] | [standalone]
| From | cri@tiac.net (Richard Harter) |
|---|---|
| Date | 2011-11-12 05:14 +0000 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <4ebdf5c6.140459681@text.giganews.com> |
| In reply to | #12933 |
On Wed, 09 Nov 2011 00:06:23 +0000, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:
[snip]
><snip>
>>> I imagine that Richard would prefer C to have something like this:
>>>
>>> transposed struct cell { int car, cdr; } cell[1000];
>>>
>>> so that cell[42] is still "an object", but cell[42].car is followed by
>>> cell[43].car in memory.
>>>
>>> This would enable the programmer to express two kinds of "better" -- the
>>> way the data is logically related, and the way it is laid out in memory.
Actually Richard doesn't want any such thing. This all started with a
simple post pointing out that one might want to use the weird "struct
of arrays" for performance reasons rather than the natural "array of
structs".
[snip]
>I think I should point out that I doubt this situation occurs
>sufficiently often for it to be a concern to language designers. I am
>interested in the example from a purely theoretical point of view --
>what would a language look like that could use either layout at will?
An obvious place to look is at languages that have tables as the
primary data structure. There are a number of such languages. In
them an array is a table with one column and a struct is a table with
one row. A scalar is a table with one row and one column. (Actually
you can have multi-dimensional tables but lets keep things simple.)
The syntax could be SQL like or similar to the C syntax we know and
love. Unlike C (which is quite prudish about such things) tables can
be sliced, diced, partioned and joined. Also unlike C there are no
pointers into the interior of storage objects; on the other hand
identifiers have metadata associated with them.
At this point comp.lang.misc might be a more appropriate group.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2011-11-21 02:39 -0500 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <kcjjc71jdt6tis4gdfjv7oef08ecdq2bjj@4ax.com> |
| In reply to | #12933 |
On Wed, 09 Nov 2011 00:06:23 +0000, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: <snip> > I am saying that the organisation of data in memory, and the > organisation of data into logical structures are orthogonal, but many > languages (like C) link the two together. > > In high-level languages, arrays are used to represent data sequences -- > there need be no implication that one array element is next to its > successor in memory. Similarly, structures are used to group data into > units that can be manipulated as one. C insists that such a unit be > contiguous in memory, but this does not follow inevitably from the > desire to group two coordinates into a point. > > A weak example is Algol 68 arrays. Given a 2D array, any row or column > of it can be passed to a procedure that wants a 1D array. Algol 68 does > not afford the same flexibility to arrays of structures or structures of > arrays (and I don't know any language that does), but a language *could* > do that, and it would not be without value to do so. C can't do it > without completely overhauling its notion of an object. > Fortran >= 90 allows you to pass (usually by reference, though not mandated), or set a (fat) pointer to, any array section of the correct rank -- i.e. if you have a 4dim array and callee wants 2dim, you can slice any 2 subscripts, full or partial, but not 0 1 3 or 4 *. Similarly you can pass or point to a field across an array of structures (except it calls structures 'derived types'). (* You can also effectively overload on rank. Thus you could call both MYFUNC( A(1:10, 3, 2:7, 4) ) and MYFUNC( A(2, 3, 4, 5:8) ) but those are actually two different MYFUNC's.) F9X provides no particular features for structure of arrays. It does allow the compiler (normally) to choose storage order of fields in any structure; IMLE this is more often useful for nonarray fields. SQL (already noted elsethread) effectively hides the storage. Most if not all DBMSes allow you to dynamically modify row storage (e.g. sotring, partitioning) and column types (or at least sizes) without altering embedded or precompiled DML that references that table -- sometimes even during execution of the DML. <snip>
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-30 11:00 -0700 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <9e1376c3-3062-4e67-acb9-2cf61a0fe06c@u10g2000prl.googlegroups.com> |
| In reply to | #12288 |
On Oct 30, 7:56 am, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > On Oct 30, 8:07 am, Malcolm McLean <malcolm.mcle...@btinternet.com> > wrote: > > > > > > > > > > > On Oct 29, 8:56 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:> On Wed, 2011-10-26, Malcolm McLean wrote: > > > > > You're doing object-oriented design when your objects have > > > > relationships to each other, in C++ class hierarchies, in other > > > > languages interfaces. > > > > I accept that object-oriented programming (as Stroustrup defines it, > > > at least) includes run-time polymorphism. But let's say I do my design, > > > look for places where a "is-a" relationship is the best solution -- > > > and I don't find any. Am I suddenly not doing object-oriented design? > > > > Because that's what happens to me in practice. Less than 5% of my > > > classes do run-time polymorphism. > > > Let's say you examine your program, and find that there are no logical > > subroutines you can break out of the main loop. Are you still doing > > structured programming? > > > > > And C++ doesn't buy you much. > > > > I work in both languages and I can assure you: it *does* make a big > > > difference. Not the inheritence, but all the other features. > > > I don't find it does. > > > I find that typically my programs are structured as arrays of arrays > > of arrays, mainly of structures at the upper levels. > > what? How can your *program* be structured as "arrays of arrays...". > My programs are hierarchies of function calls. Nearly a tree but most > likely a DAG. Did you mean your data structures are strcts containing > arrays? Seems very limited. > > > Where I need more > > complex structures, quite often special links are needed for > > performance, or for the algorithm. So in both cases the use of fancy > > containers doesn't make much sense. > > the STL containers have pretty good performance. > > > I'm not saying it wouldn't help if > > there was a way of avoiding the little realloc dance when resizing a C > > array, but this small benefit doesn't justify all the complexity in > > interfacing that use of containers introduces. > > *what* compilcation. > > int a [10]; > int b [10]; > a[0] = 27; > a[1] = a[2]; > memcpy (b, a, 10); > > std::vector<int> v1(10); > std::vector<int> v2(10); > v1[0] = 27; > v1[1] = v1[2]; > memcpy (&v2[0], &v1[0], 10); Why would you do that?? You're much better off using assignment and letting the implementation decide if memcpy is even the best thing to do! You're getting no benefit by using it directly and only introduce extra complexity and confusion by using the C API here. > > I don't see the problem. > > > I know that in the C++ > > stl you can do everything with iterators, the problem is that most > > programmers aren't disciplined enough to use the system. > > but you don't have to. Why does it matter if they don't?
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-10-30 19:09 +0100 |
| Subject | Re: OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <4ead920d$0$1385$4fafbaef@reader1.news.tin.it> |
| In reply to | #12288 |
"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio news:08cbb555-c844-4b6b-9a45-8dd78be73033@y36g2000yqm.googlegroups.com... On Oct 30, 8:07 am, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > On Oct 29, 8:56 am, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:> On Wed, > 2011-10-26, Malcolm McLean wrote: > > > > You're doing object-oriented design when your objects have > > > relationships to each other, in C++ class hierarchies, in other > > > languages interfaces. <cut> > Where I need more > complex structures, quite often special links are needed for > performance, or for the algorithm. So in both cases the use of fancy > containers doesn't make much sense. the STL containers have pretty good performance. > I'm not saying it wouldn't help if > there was a way of avoiding the little realloc dance when resizing a C > array, but this small benefit doesn't justify all the complexity in > interfacing that use of containers introduces. *what* compilcation. int a [10]; int b [10]; a[0] = 27; a[1] = a[2]; memcpy (b, a, 10); #io_x #the complication is 'a' and 'b' are 10 int and you copy 10 chars #i not consider you want to copy just the first 10 chars only. #i whould write memcpy(b,a, 10*sizeof(int)); std::vector<int> v1(10); std::vector<int> v2(10); v1[0] = 27; v1[1] = v1[2]; memcpy (&v2[0], &v1[0], 10); #here as above #i whould not write memcpy with a class i don't know #what it is in; possibly #memcpy(&v2[0], &v1[0], 10*sizeof(v1[0])); #is ok but i would do it if i implement vector<> only, or #if the debugger has access to library code #too for step in what happen, and goes all [compiler traslation] ok. #i don't say i'm right in that, nor i'm a good programmer I don't see the problem. > I know that in the C++ > stl you can do everything with iterators, the problem is that most > programmers aren't disciplined enough to use the system. but you don't have to. Why does it matter if they don't?
[toc] | [prev] | [next] | [standalone]
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web