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 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
| From | Willem <willem@toad.stack.nl> |
|---|---|
| Date | 2011-12-01 13:38 +0000 |
| Subject | Re: Sapir-Whorf Hypothesis and programming |
| Message-ID | <slrnjdf0qn.1bm1.willem@toad.stack.nl> |
| In reply to | #14142 |
JohnF wrote:
) Doesn't Church's thesis and Turing completeness
) kind of take the steam out of any "linguistic relativity"
) idea applied to programming languages? At best, there's
) maybe some "stylistic relativity", depending on how you
) prefer designing/writing code. But regarding what's
) computable, and what computable functions a given language
) can express, that's pretty much a done deal. No???
No.
What Turing is saying, in a sense, is that you can always emulate the
features of language A in language B, and therefore you can compute the
same things. However, you have to be familiar with language A to be able
to emulate its features in language B.
The upside to this is: if you learn a very different language, such as lisp
or haskell or prolog, or even ruby, you can then go back to C and implement
the new features that make programming so much easier, but which you never
knew existed before you learned those languages.
Claiming that it is only "stylistic relativity" is like claiming that the
invention of the train really wasn't that important, because people could
get where they wanted already simply by walking.
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 | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2011-12-01 13:47 -0800 |
| Subject | Re: Sapir-Whorf Hypothesis and programming |
| Message-ID | <15932308.74.1322776063863.JavaMail.geo-discussion-forums@pret21> |
| In reply to | #14156 |
On Thursday, December 1, 2011 9:38:31 PM UTC+8, Willem wrote: > JohnF wrote: > ) Doesn't Church's thesis and Turing completeness > ) kind of take the steam out of any "linguistic relativity" > ) idea applied to programming languages? At best, there's > ) maybe some "stylistic relativity", depending on how you > ) prefer designing/writing code. But regarding what's > ) computable, and what computable functions a given language > ) can express, that's pretty much a done deal. No??? > I agree with you. But Turing died to young, I'll pay my regrets to the mass not to understand his works in time. H was living like another famous artiest who cut his own ear.
[toc] | [prev] | [next] | [standalone]
| From | JohnF <john@please.see.sig.for.email.com> |
|---|---|
| Date | 2011-12-02 08:10 +0000 |
| Subject | Re: Sapir-Whorf Hypothesis and programming |
| Message-ID | <jba14t$5nd$1@reader1.panix.com> |
| In reply to | #14156 |
Willem <willem@toad.stack.nl> wrote: > JohnF wrote: > ) Doesn't Church's thesis and Turing completeness > ) kind of take the steam out of any "linguistic relativity" > ) idea applied to programming languages? At best, there's > ) maybe some "stylistic relativity", depending on how you > ) prefer designing/writing code. But regarding what's > ) computable, and what computable functions a given language > ) can express, that's pretty much a done deal. No??? > > No. > > What Turing is saying, in a sense, is that you can always emulate the > features of language A in language B, and therefore you can compute the > same things. However, you have to be familiar with language A to be able > to emulate its features in language B. > > The upside to this is: if you learn a very different language, such as lisp > or haskell or prolog, or even ruby, you can then go back to C and implement > the new features that make programming so much easier, but which you never > knew existed before you learned those languages. > > Claiming that it is only "stylistic relativity" is like claiming that the > invention of the train really wasn't that important, because people could > get where they wanted already simply by walking. > SaSW, Willem Sure, as a practical issue, some particular application may be way, way better programmed in one language than in another. But "practical" wasn't the issue. Even a walking person can >>think<< how much better a train (or any faster-moving travel) might be. As far as programming is concerned, in my own case I programmed in Fortran (and a few assemblers) for my first 10 years, but then >>immediately<< recognized the superiority of C (for almost all purposes) as soon as I read the first few chapters of K&R. Again, it's not a "practical" question. It's whether or not your mind becomes so conditioned by using one programming language, more-or-less exclusively, that your semantic/algorithmic thinking becomes constrained to that language's syntax. That's what Sapir-Whorf would say interpreted in a programming context. And I'd say "no", at least not in my case. Although, of course, there's quite a learning curve to become fluent in any language, natural or artificial. -- John Forkosh ( mailto: j@f.com where j=john and f=forkosh )
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-12-02 17:48 +0000 |
| Subject | Re: Sapir-Whorf Hypothesis and programming |
| Message-ID | <20111202093806.731@kylheku.com> |
| In reply to | #14142 |
On 2011-12-01, JohnF <john@please.see.sig.for.email.com> wrote: > Nick Keighley <nick_keighley_nospam@hotmail.com> wrote: >> >> read up on "blub" or the The Sapir-Whorf Hypothesis > > Very interesting. I've been aware of Sapir-Whorf for > a long time regarding linguistics, but hadn't been > aware of its interpretation with respect to programming > languages. Googling blub and sapir-whorf, and then reading > http://en.wikipedia.org/wiki/Linguistic_relativity > brings the following question to mind: > Doesn't Church's thesis and Turing completeness > kind of take the steam out of any "linguistic relativity" > idea applied to programming languages? At best, there's > maybe some "stylistic relativity", depending on how you Turing equivalence requires that each machine doing solving the same task in different ways has unlimited memory. One task needing four terabytes of RAM to complete (and then eight if the input is slightly extended!) while antoher needs a few kilobytes does not feel like a stylistic difference. > prefer designing/writing code. But regarding what's > computable, and what computable functions a given language > can express, that's pretty much a done deal. No??? Computing something isn't the same as expressing it. Expressing means that if you're familiar with the language, you can immediately recognize for instance, "hey, this program is obviously computing Fibonacci numbers using recursion". One way in which expressivity lost is the lack of abstraction. The more distracting, irrelevant details the program has to be concerned with, which have to be done for /any/ task in similar ways, the less it expresses the particular task. I.e. the less abstract it is. Those irrelevant things that are mixed into the solution make every program look like every other program, no matter what it computes. E.g. if you take any sample of 500 machine language instructions out of your computer's memory, it looks the same as any other 500. All it expresses is "I am an amorphous block of machine language".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-11-30 18:35 -0500 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <4ED6BDAA.5010607@verizon.net> |
| In reply to | #14100 |
On 11/30/2011 05:09 PM, Quentin Pope wrote: > On Wed, 30 Nov 2011 22:59:39 +0100, jacob navia wrote: ... >> That is because you did not know that Fortran has operator oerloading, >> C#, even Java. I have added operatr overloading to the lcc-win compiler >> and it is very useful. See the other message about this in this thread. > > Sorry, but it is NOT useful. In those other languages, it is a curse. It > leads to many bugs, and plenty of confusing code where it is difficult to > tell what a simple-looking line of code is actually doing without digging > through piles of other code to track down the relevant overloading. Any feature of any language can be misused. I you have to look "through piles of other code to track down the relevant overloading", in order to know what the overload is doing, then it should not have been overloaded - it's just that simple. The expression a + b gives the result of adding a to b; if the meaning of that phrase is not crystal clear for the relevant type(s), WITHOUT having to read the code or documentation for the operator overload, then operator+() should never have been overloaded for that(those) type(s). This design rule is frequently violated; that's not exactly an uncommon feature of good design rules. Vectors, arrays, complex numbers, quaternions, tensors in general are all examples of types for which the meaning of operator+() is crystal clear to anyone who knows enough about those types to justify writing code that uses them. operator*() is a trickier matter for most of those types, because they have at least two different plausible meanings for a*b. That's an argument for things like .outer_product() and .inner_product(), etc. > Overloading is not the C way. It is not standard C and not portable. Of course, that goes without saying.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-12-01 02:53 -0800 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <e2c62a36-0383-4d66-b258-d5ddeef4cf86@v5g2000yqn.googlegroups.com> |
| In reply to | #14112 |
On Dec 1, 1:35 am, James Kuyper <jameskuy...@verizon.net> wrote: > > The expression a + b gives the result of adding a to b; if the meaning > of that phrase is not crystal clear for the relevant type(s), WITHOUT > having to read the code or documentation for the operator overload, then > operator+() should never have been overloaded for that(those) type(s). > mytype x = 1, mytype y; x = sqrt(-x); y = 0 * x; What should y be? You can't always be crystal clear.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-12-01 07:07 -0500 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <jb7ql5$9ku$1@dont-email.me> |
| In reply to | #14146 |
On 12/01/2011 05:53 AM, Malcolm McLean wrote: > On Dec 1, 1:35�am, James Kuyper <jameskuy...@verizon.net> wrote: >> >> The expression a + b gives the result of adding a to b; if the meaning >> of that phrase is not crystal clear for the relevant type(s), WITHOUT >> having to read the code or documentation for the operator overload, then >> operator+() should never have been overloaded for that(those) type(s). >> > mytype x = 1, > mytype y; > > x = sqrt(-x); > y = 0 * x; > > What should y be? You can't always be crystal clear. If the overloaded operator (or function) can't be crystal clear, don't overload it. That's my point. Offhand, I can't think of any type for which it would be reasonable to overload all of the operators used above, and sqrt(), unless the value of 'y' came out as (mytype)0 in the end - but I wouldn't be surprised if you could come up with a reasonable counter-example (it's trivial, of course, to come up with an unreasonable counter-example). Your example is NOT clear solely because the name 'mytype' conveys no special meaning. Good design is not just about the interface of a type, but also involves the name of the type. The only thing that particular type name conveys is information about the ownership of the type. If the name of the type doesn't convey the information the user needs to know in order to understand what the above code means, then it wasn't properly named, or the user doesn't know enough about the meaning of the type to justify using it. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2011-12-04 00:35 +0000 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <slrnjdlg2l.q8l.grahn+nntp@frailea.sa.invalid> |
| In reply to | #14098 |
On Wed, 2011-11-30, jacob navia wrote: > Le 30/11/11 22:42, Jorgen Grahn a écrit : >> On Tue, 2011-11-29, Joe keane wrote: >> ... >>> I think operator overloading is a gain of about zero. >>> >>> I've never written in C and been like 'darn it, if i only had operator >>> overloading!'. >> >> Operator overloading ties in with many of the other C++ features -- I >> don't think it would be very useful as an isolated feature. ... > That is because you did not know that Fortran has operator > oerloading, C#, even Java. I don't care about those languages. But I could have sworn that Java didn't have it, and my googling just shows me people rationalizing the fact ... > I have added operatr overloading > to the lcc-win compiler and it is very useful. As an isolated feature? I'd much rather have function overloading. I might consider operator overloading mildly useful in a future C standard -- if it contained function overloading and references as well. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2011-12-03 18:28 -0800 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <4imld7leqonhrtsq34n193irj88chjq40c@4ax.com> |
| In reply to | #14283 |
On 4 Dec 2011 00:35:35 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >On Wed, 2011-11-30, jacob navia wrote: >> Le 30/11/11 22:42, Jorgen Grahn a écrit : >>> On Tue, 2011-11-29, Joe keane wrote: >>> ... >>>> I think operator overloading is a gain of about zero. >>>> >>>> I've never written in C and been like 'darn it, if i only had operator >>>> overloading!'. >>> >>> Operator overloading ties in with many of the other C++ features -- I >>> don't think it would be very useful as an isolated feature. >... >> That is because you did not know that Fortran has operator >> oerloading, C#, even Java. > >I don't care about those languages. But I could have sworn that Java >didn't have it, and my googling just shows me people rationalizing the >fact ... > >> I have added operatr overloading >> to the lcc-win compiler and it is very useful. > >As an isolated feature? I'd much rather have function overloading. I >might consider operator overloading mildly useful in a future C >standard -- if it contained function overloading and references as >well. > If you guys keep adding these kinds of features to C, eventually you will have C++. It's always nice to know where you're headed.
[toc] | [prev] | [next] | [standalone]
| From | ImpalerCore <jadill33@gmail.com> |
|---|---|
| Date | 2011-11-30 14:10 -0800 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <509a8c2e-3e0b-4b0c-a370-0cc517f4972f@u5g2000vbd.googlegroups.com> |
| In reply to | #14096 |
On Nov 30, 4:42 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> On Tue, 2011-11-29, Joe keane wrote:
>
> ...
>
> > I think operator overloading is a gain of about zero.
>
> > I've never written in C and been like 'darn it, if i only had operator
> > overloading!'.
>
> Operator overloading ties in with many of the other C++ features -- I
> don't think it would be very useful as an isolated feature.
It depends on how you view the difference between something like
c_day_duration c_date_subtract( struct c_greg_date date1,
struct c_greg_date date2 );
vs
c_day_duration operator-( struct c_greg_date date1,
struct c_greg_date date2 );
I would be lying if I didn't desire this kind of overloading at some
verbose points in my code, at least for struct types where
mathematical operations made some sense. But I can certainly get by
without it. The point is that I don't think one would need a class
abstraction to make use of it.
Best regards,
John D.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-12-01 00:15 +0100 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <jb6df2$uk4$1@speranza.aioe.org> |
| In reply to | #14101 |
Le 30/11/11 23:10, ImpalerCore a écrit : > On Nov 30, 4:42 pm, Jorgen Grahn<grahn+n...@snipabacken.se> wrote: >> On Tue, 2011-11-29, Joe keane wrote: >> >> ... >> >>> I think operator overloading is a gain of about zero. >> >>> I've never written in C and been like 'darn it, if i only had operator >>> overloading!'. >> >> Operator overloading ties in with many of the other C++ features -- I >> don't think it would be very useful as an isolated feature. > > It depends on how you view the difference between something like > > c_day_duration c_date_subtract( struct c_greg_date date1, > struct c_greg_date date2 ); > > vs > > c_day_duration operator-( struct c_greg_date date1, > struct c_greg_date date2 ); > > I would be lying if I didn't desire this kind of overloading at some > verbose points in my code, at least for struct types where > mathematical operations made some sense. But I can certainly get by > without it. The point is that I don't think one would need a class > abstraction to make use of it. You don't. lcc-win has operator overloading without any classes or other "goodies". For instance z = (a+b-1)/(b*(b-a)); or z = div(subtract(sum(a,b),1),mult(b,subtract(b,a)))) Which you prefer? This is so OBVIOUS that the people arguing against it look completely ridiculous.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-12-01 12:21 +1300 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <9jns4cF4d0U39@mid.individual.net> |
| In reply to | #14107 |
On 12/ 1/11 12:15 PM, jacob navia wrote: > Le 30/11/11 23:10, ImpalerCore a écrit : >> On Nov 30, 4:42 pm, Jorgen Grahn<grahn+n...@snipabacken.se> wrote: >>> On Tue, 2011-11-29, Joe keane wrote: >>> >>> ... >>> >>>> I think operator overloading is a gain of about zero. >>> >>>> I've never written in C and been like 'darn it, if i only had operator >>>> overloading!'. >>> >>> Operator overloading ties in with many of the other C++ features -- I >>> don't think it would be very useful as an isolated feature. >> >> It depends on how you view the difference between something like >> >> c_day_duration c_date_subtract( struct c_greg_date date1, >> struct c_greg_date date2 ); >> >> vs >> >> c_day_duration operator-( struct c_greg_date date1, >> struct c_greg_date date2 ); >> >> I would be lying if I didn't desire this kind of overloading at some >> verbose points in my code, at least for struct types where >> mathematical operations made some sense. But I can certainly get by >> without it. The point is that I don't think one would need a class >> abstraction to make use of it. > > You don't. lcc-win has operator overloading without any classes or other > "goodies". > > For instance > > z = (a+b-1)/(b*(b-a)); Do you use pass by value, or do you pass by reference under the hood? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-12-01 00:29 +0100 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <jb6e8k$lg$1@speranza.aioe.org> |
| In reply to | #14109 |
Le 01/12/11 00:21, Ian Collins a écrit : > > Do you use pass by value, or do you pass by reference under the hood? > Of course by reference... qfloats are 120 bytes long... For a function of 2 arguments you would have to push 240 bytes each time... impossible.
[toc] | [prev] | [next] | [standalone]
| From | "Joel C. Salomon" <joelcsalomon@gmail.com> |
|---|---|
| Date | 2011-12-01 15:50 -0500 |
| Subject | Operator overloading extensions (Was re: OOP and C++ and C) |
| Message-ID | <jb8p9q$fqs$1@news.albasani.net> |
| In reply to | #14111 |
On 11/30/2011 06:29 PM, in reference to lcc's operator overloading extension, jacob navia wrote: > Le 01/12/11 00:21, Ian Collins a écrit : >> Do you use pass by value, or do you pass by reference under the hood? > > Of course by reference... qfloats are 120 bytes long... > For a function of 2 arguments you would have to push 240 bytes > each time... impossible. When I first read about lcc's operator overloading, these two aspects struck me as not in the "spirit of C": function names with operator symbols inside them and the invention of reference parameters. [As an aside, to Jacob: How much complexity is added to the grammar to accommodate things like "operator+"? Is this as intrusive as it seems on first blush?] That said, operator overloading is a handy idea. Before he left Bell Labs, Ken Thompson added operator overloading to the Plan 9 C compiler. I believe this extension is still available in the 8c/6c C compilers distributed with Google Go. It's... different than Jacob's C++-inspired idea. See Jim McKie's quoting Ken's documentation at <http://9fans.net/archive/2001/05/482>. I think operator overloading is a nice feature (in either form); YMMV as to which (if any) is a better fit to C. --Joel
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-12-01 07:38 +0100 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <4ed72001$0$1385$4fafbaef@reader1.news.tin.it> |
| In reply to | #14107 |
"jacob navia" <jacob@spamsink.net> ha scritto nel messaggio
news:jb6df2$uk4$1@speranza.aioe.org...
> Le 30/11/11 23:10, ImpalerCore a écrit :
>> On Nov 30, 4:42 pm, Jorgen Grahn<grahn+n...@snipabacken.se> wrote:
>>> On Tue, 2011-11-29, Joe keane wrote:
>>>
>>> ...
>>>
>>>> I think operator overloading is a gain of about zero.
>>>
>>>> I've never written in C and been like 'darn it, if i only had operator
>>>> overloading!'.
>>>
>>> Operator overloading ties in with many of the other C++ features -- I
>>> don't think it would be very useful as an isolated feature.
>>
>> It depends on how you view the difference between something like
>>
>> c_day_duration c_date_subtract( struct c_greg_date date1,
>> struct c_greg_date date2 );
>>
>> vs
>>
>> c_day_duration operator-( struct c_greg_date date1,
>> struct c_greg_date date2 );
>>
>> I would be lying if I didn't desire this kind of overloading at some
>> verbose points in my code, at least for struct types where
>> mathematical operations made some sense. But I can certainly get by
>> without it. The point is that I don't think one would need a class
>> abstraction to make use of it.
>
> You don't. lcc-win has operator overloading without any classes or other
> "goodies".
>
> For instance
>
> z = (a+b-1)/(b*(b-a));
>
> or
>
> z = div(subtract(sum(a,b),1),mult(b,subtract(b,a))))
> Which you prefer?
it is not question of which i prefer but
what give the correct result
and minimize symbols for obtain that
#.x ==jmp to .x
jz .y==jmp to .y if zero flag ==1
jc .y==jmp to .y if carry flag ==1
#.1
; comment: z = (a+b-1)/(b*(b-a));
.e: P("Error operation\n")|stc|#.z
.1: r=a |c=b
a+=b|jc .e|jz .e|--a ; a=(a+b-1)
c-=r|jc .e|b*=c |jc .e|jz .e ; b=b*(b-r)
a/=b
clc
.z:
in C or in C++ you can not obtain correct results
portably even for unsigned 32 bit
numbers not like HLLs
> This is so OBVIOUS that the people arguing against it look
> completely ridiculous.
>
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-12-01 20:26 +1300 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <9joohhF4d0U41@mid.individual.net> |
| In reply to | #14132 |
On 12/ 1/11 07:38 PM, io_x wrote:
> "jacob navia"<jacob@spamsink.net> wrote:
>>
>> You don't. lcc-win has operator overloading without any classes or other
>> "goodies".
>>
>> For instance
>>
>> z = (a+b-1)/(b*(b-a));
>>
>> or
>>
>> z = div(subtract(sum(a,b),1),mult(b,subtract(b,a))))
>
>> Which you prefer?
>
> it is not question of which i prefer but
> what give the correct result
> and minimize symbols for obtain that
>
> #.x ==jmp to .x
> jz .y==jmp to .y if zero flag ==1
> jc .y==jmp to .y if carry flag ==1
>
> #.1
> ; comment: z = (a+b-1)/(b*(b-a));
> .e: P("Error operation\n")|stc|#.z
> .1: r=a |c=b
> a+=b|jc .e|jz .e|--a ; a=(a+b-1)
> c-=r|jc .e|b*=c |jc .e|jz .e ; b=b*(b-r)
> a/=b
> clc
> .z:
>
> in C or in C++ you can not obtain correct results
> portably even for unsigned 32 bit
> numbers not like HLLs
Even for you, that is truly bizarre.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-11-30 18:37 -0500 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <4ED6BE1C.2080106@verizon.net> |
| In reply to | #14055 |
On 11/29/2011 06:36 PM, Joe keane wrote: > In article <0b7ed530-acf2-4d5f-b9d9-fe7d26e71e45@i6g2000vbe.googlegroups.com>, > Nick Keighley <nick_keighley_nospam@hotmail.com> wrote: >> you could safely concatentate strings in C++ without using an >> overloaded oeprator. > > kind of my point ... >> What exactly is your point? > > I think operator overloading is a gain of about zero. > > I've never written in C and been like 'darn it, if i only had operator > overloading!'. I have (except for the minced oath - and I didn't use a real oath, either). ... > The opereator overloading is a candy bar. C's scalar types represent characters, numbers, or pointers. It also has derived types that are arrays, and functions. Operator overloads can make a class type look like one of those kinds of types, and they can be a very useful, reasonable thing to define, if the class represents an extension to the idea of characters, numbers, pointers, arrays or functions. When used for any other purpose, they tend to obfuscate code, rather than clarify it. Any member function whose meaning doesn't fit the usual meaning of a given operator should not be implemented as an overloaded of that operator. The use of >> and << for I/O, and the use of + for string concatenation, both clearly violate this design principle, and I cannot defend them. However, but by now such usage is a well-established convention, and unlikely to be changed.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-12-01 02:05 -0800 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <c1cdd794-a4d5-4112-acaa-a56456ba8449@y12g2000vba.googlegroups.com> |
| In reply to | #14113 |
On Nov 30, 11:37 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 11/29/2011 06:36 PM, Joe keane wrote: > > > In article <0b7ed530-acf2-4d5f-b9d9-fe7d26e71...@i6g2000vbe.googlegroups.com>, > > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > >> you could safely concatentate strings in C++ without using an > >> overloaded oeprator. > > > kind of my point > ... > >> What exactly is your point? > > > I think operator overloading is a gain of about zero. > > > I've never written in C and been like 'darn it, if i only had operator > > overloading!'. > > I have (except for the minced oath - and I didn't use a real oath, either). > > ... > > > The opereator overloading is a candy bar. > > C's scalar types represent characters, numbers, or pointers. It also has > derived types that are arrays, and functions. Operator overloads can > make a class type look like one of those kinds of types, and they can be > a very useful, reasonable thing to define, if the class represents an > extension to the idea of characters, numbers, pointers, arrays or > functions. operator overloading in C++ can also be used for conversion operators as well. > When used for any other purpose, they tend to obfuscate code, > rather than clarify it. Any member function whose meaning doesn't fit > the usual meaning of a given operator should not be implemented as an > overloaded of that operator. > > The use of >> and << for I/O, and the use of + for string concatenation, > both clearly violate this design principle, and I cannot defend them. > However, but by now such usage is a well-established convention, and > unlikely to be changed.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-12-01 07:09 -0500 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <jb7qqf$9ku$2@dont-email.me> |
| In reply to | #14141 |
On 12/01/2011 05:05 AM, Nick Keighley wrote: > On Nov 30, 11:37�pm, James Kuyper <jameskuy...@verizon.net> wrote: ... >> C's scalar types represent characters, numbers, or pointers. It also has >> derived types that are arrays, and functions. Operator overloads can >> make a class type look like one of those kinds of types, and they can be >> a very useful, reasonable thing to define, if the class represents an >> extension to the idea of characters, numbers, pointers, arrays or >> functions. > > operator overloading in C++ can also be used for conversion operators > as well. Yes, and that's something that's essential for implementation of smart pointer types, for instance. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Markus Wichmann <nullplan@gmx.net> |
|---|---|
| Date | 2011-11-01 10:13 +0100 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <frp4o8-ki2.ln1@voyager.wichi.de.vu> |
| In reply to | #12301 |
On 30.10.2011 18:43, nroberts wrote:
> On Oct 29, 12:18 pm, Markus Wichmann <nullp...@gmx.net> wrote:
>> On 29.10.2011 08:56, Jorgen Grahn wrote:
>>
>>> So do I, and it's definitely workable -- but not having RAII,
>
> Not having scope tied destructors hurts. There are a whole lot of
> methods for simplifying code through tying to scope that can't be done
> without them. The gcc compiler has an extension though that allows
> this in C. Of course it is quite obviously possible to go without
> these things in C, especially since you're probably not using
> exceptions (setjmp/longjmp is available but pretty rarely used), it
> just makes things easier and more straight forward in some people's
> opinions.
>
> Some people like being able to create a variable that is guaranteed to
> have a function called on it so you can fill that function with
> important things like closing file handles, releasing resources,
> etc... That way you don't have to remember to do so for every error
> condition and in the right order, and only those parts you've
> initiated, etc... Other people find the hiding of these details in an
> interface like that makes code harder to understand and prefer the
> verbosity of having to clean up properly for different conditions
> within the block that deals with those conditions. Neither
> perspective is wrong.
>
>>> operator
>>> overloading, function overloading, templates and container types
>>> really hurts.
>>
>> Oh, please. At least to of the above tend to make code unreadable. I
>> mean, if you see the following line, for instance:
>>
>> x = y++;
>>
>> and the compiler doesn't warn on this line on highest level, then in C
>> we have a pretty limited set of possibilities, namely:
>>
>> - x and y can both be arithmetic types
>> - x and y can both be pointers to the same type
>> - x can be a void* and y can be a typed pointer
>> - x or y can be preprocessor macros, though in this case that would
>> really be bad... oh wait, there's at least one instance of it in my
>> system library:
>>
>> #define errno (*__errno_location())
>>
>> C++ adds:
>> - x or y can be class instances, in which case:
>> - there might be a typeof y::operator++() which is then called
>> - there might be an operator++(typeof y) defined somewhere else
>> - there might be typeof x::operator=(typeof y&)
>> - there might be operator=(typeof x&, typeof y&)
>> - typeof x might have an implicit constructor taking a typeof y
>> - typeof x might have an implicit constructor taking whatever
>> typeof y::operator++() or operator++(typeof y) return
>> - I don't know exactly about this one, but operator++(typeof y) might
>> even return a class instance that has an operator(typeof x)(), IIRC
>
> All of these features are important and have their uses. They can all
> be used badly. Poor design is poor design in C, C++, or any other
> language.
True, but in C++ you have more possibilities for bad design.
> Consider this function:
>
> void function_that_outputs_blob(blob* b);
>
> If that function does something other than outputting a blob, whatever
> that means, then people reading code that use it are not going to know
> what that code does. This is exactly the same for using standard
> function names like operator++ to mean something other than the
> standard use or having conversion operators for types to which
> conversion makes no sense.
>
That is right, but at the very least, people reading the code are able
to detect a call to a function, unlike the line I posted.
>>
>> - even if they aren't class instances, we have:
>> - x might be a reference to typeof y
>> - y might be a reference to something
>> - x might even reference y, which means that this line invokes
>> undefined behaviour
>> - or y might reference x, which yields the same
>
> These later cases can all occur in C if the line is changed to:
>
> *x += (*y)++;
>
That's true too, but then you actually know that x and y must be
pointers, which isn't obvious from the C++ line.
>>
>> As you can see, C++ blows this line all the way from "something will be
>> incremented and something else will store the old value" to "no friggin
>> idea what this line does! Might be anything. And I wouldn't even know
>> where to start looking"
>
> Only if you're an idiot. I'm sorry, but it's simply true. If you
> can't look at declarations of your x and y variables to see what type
> they are then you are quite fucked in whatever language you choose to
> be programming in.
>
You actually did notice that I also included "operator++(typeof y)" in
the list of stuff that might be defined somewhere? Well, yeah, that's
exactly what I meant. It could be defined _fucking_anywhere_. Needn't be
anywhere near the declaration or definition of typeof y.
>> As of yet I only saw one useful application of operator overloading and
>> references, and that was a typesafe printf() implementation (which
>> basically has the compiler choose the correct functions according to the
>> argument type and those functions then check whether the conversion
>> specification on the format string was correct).
>
> Which is a pretty excellent example of great use of templates.
>
No templates were used in that implementation. It was a class that went
something like:
class TSPrintf {
std::string format;
unsigned int pos;
public:
TSPrintf(const std::string&);
TSPrintf& operator()(unsigned int);
TSPrintf& operator()(char);
TSPrintf& operator()(const char*);
TSPrintf& operator()(you_name_it);
};
The call would then go like
TSPrintf("%u errors in %u lines\n")(errors)(lines);
And if you tried funny stuff like
TSPrintf("%s errors\n")(errors);
with errors being an unsigned int variable, the compiler would call
TSPrintf::operator()(unsigned int), which would detect that it has been
called with a format specifier of "%s" and thus would throw an exception.
> If that's the only example that you've seen though then you're
> obviously not looking at a lot of C++.
>
I looked at the STL at another point and lost myself in the code
somewhere. It's a bit astonishing what kind of stuff you actually need
to do before you can shift strings into streams.
> If you want to write generic code that operates at the static type
> level then you really need templates. Macros can almost get you there
> but at a very high cost.
>
I guess this is where we actually deviate: In C my code isn't meant to
be general. There is a sane level of generalization in the standard
library (what with qsort() and bsearch()), but the code I write is meant
to solve a specific problem.
C++ however advocates a bottom-up design which often leads to more code
being written than actually used. Also, the code is more general,
because you think about needing a list, before you think about needing a
list of integers. (OK, bad example, as there's already std::list available)
> The one thing that can be said against templates is that they can be
> hard to learn. The syntax isn't exactly optimal and the requirements
> of when, where, and how to use the typename and template keywords can
> be confusing. For example:
>
> template < typename T >
> struct example
> {
> typedef typename T::some_typedef local_typedef;
>
> template < typename U > static void fun();
> };
>
> example<int>::template fun<double>();
>
> It's kind of confusing and ugly.
Yeah. And local typedefs don't always serve to really abbreviate things
as they were meant to. I once read a template that went along the lines of:
template <typename T> class X {
typedef T my_local_type;
}
I don't see why one would "abbreviate" T with "my_local_type", but hey,
that's how they roll. So you cannot figure out what a class function
actually returns even after you read the declaration.
> Bloated? Depends on how much
> depends on the templates' parameters. If none of it does, then yeah
> it's going to be unnecessarily bloated. If most of it does then no,
> it's going to be about as "bloated" as it has to be.
>
> Of course, the generic programming paradigm, which is what templates
> are pretty much about, is often foreign to someone stuck in the C
> world and unwilling to expand their knowledge. This is no different
> from any other tool though. If you don't want to learn these things,
> that's fine, but your willing ignorance isn't a good argument.
>
Well, I guess you're right about that. I still think it is good design
to actually write only the stuff you need. I once wrote a matrix class.
I only needed it to contain integers, so I wrote it like this. I don't
see why I should have written a template class. Just so that at some
later point I could reuse it? But then again, this class was half a
day's work, so there's no real point. Plus I actually only needed the
Gauss-Jordan algorithm.
CYA,
Markus
[toc] | [prev] | [next] | [standalone]
Page 5 of 15 — ← Prev page 1 … 3 4 [5] 6 7 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web