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 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-10-24 01:59 -0700 |
| Message-ID | <42b34cc2-54a1-42c7-9df2-83a79e96fd01@hj4g2000vbb.googlegroups.com> |
| In reply to | #12004 |
On Oct 24, 12:14 am, James Kuyper <jameskuy...@verizon.net> wrote: > > > In one day they aren't using much of STL, name spaces (except adding a > > using namespace std:) or other advance features. > > A statement that "I've learned C++" would not be justified by that level > of understanding.. > There weren't any templates or namespaces, and exception handling was widely non-implemented. Basically you were using C++ once you had an object hierarchy, and for that you just needed "class" and "public, protected, private) together with the base membership syntax. That was fundamentally it. The operator overloaded IO stream library made programs look very different to C, but was ultimately a distraction. inline, slash slash comments, operator and references were just minor tweaks. The difficult one was "virtual".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-10-24 06:25 -0400 |
| Message-ID | <j83eel$al4$1@dont-email.me> |
| In reply to | #12018 |
On 10/24/2011 04:59 AM, Malcolm McLean wrote: > On Oct 24, 12:14�am, James Kuyper <jameskuy...@verizon.net> wrote: [restoring clipped attribution:] >> On 10/23/2011 02:34 PM, Richard Damon wrote: ... >>> In one day they aren't using much of STL, name spaces (except adding a >>> using namespace std:) or other advance features. >> >> A statement that "I've learned C++" would not be justified by that level >> of understanding.. >> > There weren't any templates or namespaces, and exception handling was > widely non-implemented. > > Basically you were using C++ once you had an object hierarchy, and for > that you just needed "class" and "public, protected, private) together > with the base membership syntax. That was fundamentally it. The > operator overloaded IO stream library made programs look very > different to C, but was ultimately a distraction. inline, slash slash > comments, operator and references were just minor tweaks. The > difficult one was "virtual". So Charles Richmond's acorn analogy is entirely apt. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2011-10-24 14:43 +0000 |
| Message-ID | <slrnjaauci.1bk.grahn+nntp@frailea.sa.invalid> |
| In reply to | #12018 |
On Mon, 2011-10-24, Malcolm McLean wrote: > On Oct 24, 12:14 am, James Kuyper <jameskuy...@verizon.net> wrote: >> >> > In one day they aren't using much of STL, name spaces (except adding a >> > using namespace std:) or other advance features. >> >> A statement that "I've learned C++" would not be justified by that level >> of understanding.. >> > There weren't any templates or namespaces, and exception handling was > widely non-implemented. > > Basically you were using C++ once you had an object hierarchy, The kind of perverted C++ I hate the most is C code squeezed into an unnatural inheritance hierarchy. I wasn't around in the early days, but I get the impression that virtual inheritance was the C++ feature stuck in the minds of many C programmers switching. I find run-time polymorphism one of the less useful features of C++. I design a lot of classes, but there are very few "is-a" relationships between them. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-10-24 09:01 -0700 |
| Message-ID | <70cc03d0-c611-4445-905a-bdb8ca8de27b@m5g2000prg.googlegroups.com> |
| In reply to | #12033 |
On Oct 24, 4:43 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote: > > The kind of perverted C++ I hate the most is C code squeezed into an > unnatural inheritance hierarchy. I wasn't around in the early days, > but I get the impression that virtual inheritance was the C++ feature > stuck in the minds of many C programmers switching. > > I find run-time polymorphism one of the less useful features of C++. I > design a lot of classes, but there are very few "is-a" relationships > between them. > That was partly why I stopped using C++. Unless you're defining an object hierarchy, you're not doing object- oriented design. Instead you're encapuslating structures. MYFILE *myfopen(); void myfclose(MYFILE *stream); int myfput(MYFILE *fp, int ch); etc is a perfectly legitimate idiom, but you don't gain much by going to C++ and making MYFILE a class. I've seen a few very well designed object-oriented programs, notably 3D Studio Max, but they're very much the exception. An object-oriented design is difficult to get right. C++ also makes it harder than it should be to define base classes designed for other programmers to inherit from. Largely it's a documentation issue. -- Visit my website http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | André Gillibert <MetaEntropy.removeThis@gmail.com> |
|---|---|
| Date | 2011-10-24 18:23 +0200 |
| Message-ID | <20111024182355.7e4e8607@corefixtop.gillibert.homelinux.net> |
| In reply to | #12039 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > I've seen a few very well designed object-oriented programs, notably > 3D Studio Max, but they're very much the exception. An object-oriented > design is difficult to get right. C++ also makes it harder than it > should be to define base classes designed for other programmers to > inherit from. Largely it's a documentation issue. > > And, of course, the fact the most basic and standard C++ library, iostreams, is poorly documented and has a weird design (e.g. two seek methods), doesn't help C++ programmers to get a sane mind. Even the Qt library abuses inheritance. For example, QProcess (which represents a child process) is derived from QIOProcess (which represents a I/O stream like a file descriptor on UNIX), with a setReadChannel method to select if the QIOProcess reads from the stderr or stdout of the child process. -- André Gillibert
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-10-25 08:02 +1300 |
| Message-ID | <9glr1mFk5cU11@mid.individual.net> |
| In reply to | #12039 |
On 10/25/11 05:01 AM, Malcolm McLean wrote: > On Oct 24, 4:43 pm, Jorgen Grahn<grahn+n...@snipabacken.se> wrote: >> >> The kind of perverted C++ I hate the most is C code squeezed into an >> unnatural inheritance hierarchy. I wasn't around in the early days, >> but I get the impression that virtual inheritance was the C++ feature >> stuck in the minds of many C programmers switching. >> >> I find run-time polymorphism one of the less useful features of C++. I >> design a lot of classes, but there are very few "is-a" relationships >> between them. >> > That was partly why I stopped using C++. > > Unless you're defining an object hierarchy, you're not doing object- > oriented design. Instead you're encapuslating structures. That's a rather strange reason for not using a language, considering C++ isn't just an OO language. > MYFILE *myfopen(); > void myfclose(MYFILE *stream); > int myfput(MYFILE *fp, int ch); > > etc is a perfectly legitimate idiom, but you don't gain much by going > to C++ and making MYFILE a class. As soon as the resource (be it a file, or memory or whatever) needs some form of management, then it certainly dose make sense. I'd happily just stick to C + smart pointers if I had to. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-10-25 00:44 -0700 |
| Message-ID | <66f4454e-d2e9-4b0b-b6f6-474b3de928e8@k35g2000yqh.googlegroups.com> |
| In reply to | #12039 |
On Oct 24, 5:01 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > On Oct 24, 4:43 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote: > > > The kind of perverted C++ I hate the most is C code squeezed into an > > unnatural inheritance hierarchy. I wasn't around in the early days, > > but I get the impression that virtual inheritance was the C++ feature > > stuck in the minds of many C programmers switching. > > > I find run-time polymorphism one of the less useful features of C++. I > > design a lot of classes, but there are very few "is-a" relationships > > between them. > > That was partly why I stopped using C++. > > Unless you're defining an object hierarchy, you're not doing object- > oriented design. Instead you're encapuslating structures. I seem to find myself naturally finding IS_A relations. The Open Closed Principle, as usually implemented, relies on polymorphism. Do I work in wierd domains or am I in a thought strait jacket? Graphical Editor- every widget is derived froma base class Mobile Radio- each "end user" type is derived from a common base class and an end user can be anything from a handset to a despatcher to a complete telephony network > MYFILE *myfopen(); > void myfclose(MYFILE *stream); > int myfput(MYFILE *fp, int ch); > > etc is a perfectly legitimate idiom, but you don't gain much by going > to C++ and making MYFILE a class. until you want MYFILE to be a string or a comms link a database or... > I've seen a few very well designed object-oriented programs, notably > 3D Studio Max, but they're very much the exception. An object-oriented > design is difficult to get right. C++ also makes it harder than it > should be to define base classes designed for other programmers to > inherit from. Largely it's a documentation issue. maybe true
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2011-10-25 21:24 +0000 |
| Message-ID | <slrnjaea8e.1bk.grahn+nntp@frailea.sa.invalid> |
| In reply to | #12039 |
On Mon, 2011-10-24, Malcolm McLean wrote: > On Oct 24, 4:43 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote: >> >> The kind of perverted C++ I hate the most is C code squeezed into an >> unnatural inheritance hierarchy. I wasn't around in the early days, >> but I get the impression that virtual inheritance was the C++ feature >> stuck in the minds of many C programmers switching. >> >> I find run-time polymorphism one of the less useful features of C++. I >> design a lot of classes, but there are very few "is-a" relationships >> between them. >> > That was partly why I stopped using C++. > > Unless you're defining an object hierarchy, you're not doing object- > oriented design. Instead you're encapuslating structures. I take it you think encapsulating structures is inferior to defining object hierarchies? I don't. Encapsulating structures means building new types, documenting them, deciding what operations they should support and which ones should be explicitly forbidden, defining invariants and so on. > MYFILE *myfopen(); > void myfclose(MYFILE *stream); > int myfput(MYFILE *fp, int ch); > > etc is a perfectly legitimate idiom, but you don't gain much by going > to C++ and making MYFILE a class. That's not C++. The C++ version would not use pointers, or have superfluous "myf" prefixes on the function names (C++ supports overloading). /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-10-26 00:58 -0700 |
| Message-ID | <cb6a955c-36f4-41b3-9f0e-176bfcff2c04@f11g2000vbm.googlegroups.com> |
| In reply to | #12100 |
On Oct 25, 11:24 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote: > > I take it you think encapsulating structures is inferior to defining > object hierarchies? I don't. Encapsulating structures means building > new types, documenting them, deciding what operations they should > support and which ones should be explicitly forbidden, defining > invariants and so on. > It's not really object-oriented design. And C++ doesn't buy you much. You can encapsulate objects in C, and it's a design paradigm I use heavily. You're doing object-oriented design when your objects have relationships to each other, in C++ class hierarchies, in other languages interfaces. -- BMP, GIF, JPEG file formats, all described in Basic Algorithms http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-10-26 23:21 +1300 |
| Message-ID | <9gq596FhlkU1@mid.individual.net> |
| In reply to | #12111 |
On 10/26/11 08:58 PM, Malcolm McLean wrote: > On Oct 25, 11:24 pm, Jorgen Grahn<grahn+n...@snipabacken.se> wrote: >> >> I take it you think encapsulating structures is inferior to defining >> object hierarchies? I don't. Encapsulating structures means building >> new types, documenting them, deciding what operations they should >> support and which ones should be explicitly forbidden, defining >> invariants and so on. >> > It's not really object-oriented design. And C++ doesn't buy you much. > You can encapsulate objects in C, and it's a design paradigm I use > heavily. Why are you so hung up on object-oriented design? C++ isn't just an OO language (a read of the standard library will show you that). -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2011-10-29 06:56 +0000 |
| Subject | OOP and C++ and C (was Re: Dennis Ritchie -- An Appreciation) |
| Message-ID | <slrnjan8si.1bk.grahn+nntp@frailea.sa.invalid> |
| In reply to | #12111 |
On Wed, 2011-10-26, Malcolm McLean wrote: > On Oct 25, 11:24 pm, Jorgen Grahn <grahn+n...@snipabacken.se> wrote: >> >> I take it you think encapsulating structures is inferior to defining >> object hierarchies? I don't. Encapsulating structures means building >> new types, documenting them, deciding what operations they should >> support and which ones should be explicitly forbidden, defining >> invariants and so on. >> > It's not really object-oriented design. (reordered) > 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. > 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. > You can encapsulate objects in C, and it's a design paradigm I use > heavily. So do I, and it's definitely workable -- but not having RAII, operator overloading, function overloading, templates and container types really hurts. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Markus Wichmann <nullplan@gmx.net> |
|---|---|
| Date | 2011-10-29 21:18 +0200 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <k50un8-un1.ln1@voyager.wichi.de.vu> |
| In reply to | #12222 |
On 29.10.2011 08:56, Jorgen Grahn wrote:
> So do I, and it's definitely workable -- but not having RAII, 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
- 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
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"
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).
Templates are yet another pothole to the learning programmer: Every
instanciation creates an entirely new and unrelated set of routines and
class variables. I mean, if I have:
class A { static int count; };
then there's only one A::count in the whole program. If I have
template <class T> class A {static int count; };
suddenly there's no bound to the number of A::counts in the program,
because there is _no_ A::count, but instead A<int>::count,
A<long>::count, etc.
> /Jorgen
>
Ciao,
Markus
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-30 10:43 -0700 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <b2e2ca6f-4a0a-4b1b-a519-da66df1e54ee@d33g2000prb.googlegroups.com> |
| In reply to | #12261 |
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. 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.
>
> - 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)++;
>
> 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 might of course be tempted to say something like, "But I shouldn't
have to go looking at the type to know what that line is doing." This
is of course a good argument but it is a good argument for variable
names that are more informative than 'x' and 'y'. Variable names need
to have some semantic meaning that explains what the variable is used
for. When that is done well you generally know what can be done with
the variable, which is more important than what type it is (which is
something I can let the compiler worry about).
> 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.
If that's the only example that you've seen though then you're
obviously not looking at a lot of C++.
> Templates are yet another pothole to the learning programmer: Every
> instanciation creates an entirely new and unrelated set of routines and
> class variables.
As well it should. A list of widgets is not the same as a list of
blobbets. If they were then you'd instantiate the same template to
hold them both and your argument is moot.
C programmers tend to bring up this bloat "issue" a lot. It's not an
issue. In C++ you write a template to create new types. Templates
are like the preprocessor on steroids and fulfill many, but not all,
of the tasks originally reserved for macros. While I can write a
template for a container that works with any type in C++, in C I'm
stuck having to use void* or macros. The former might be a good
solution that doesn't introduce bloat, but it does require a lot of
care and may also introduce an unnecessary level of obscurity; it's
also no different from instantiating std::list<void*>. The other
option, macros, can get you a lot of the same thing, but they're MUCH
harder to use and are inherently unsafe.
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.
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. 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.
I mean, if I have:
>
> class A { static int count; };
>
> then there's only one A::count in the whole program. If I have
>
> template <class T> class A {static int count; };
>
> suddenly there's no bound to the number of A::counts in the program,
> because there is _no_ A::count, but instead A<int>::count,
> A<long>::count, etc.
As well it should. If you mean to count the amount of times a
particular class is instantiated then you SHOULD have a different
count for each class. Templates are not classes. They are
*templates* for creating classes...and other things. If you want to
count the amount of times any class built with that template are
instantiated then you need to account for that with a different
structure. Perhaps something like so:
struct count_these { static int count; };
template < typename T > struct A { static count_these our_count; };
This also more accurately reflects the fact that you are counting many
different things in the same bucket.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-10-31 02:26 -0700 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <a54cafb3-f5ec-4254-81cb-3adf75b409be@o19g2000vbk.googlegroups.com> |
| In reply to | #12301 |
On Oct 30, 5:43 pm, nroberts <roberts.n...@gmail.com> 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...
in C++ RAII it's considerd better style not to do too many things in
the destructor. So you'd have a class to hold the file handle and a
class for each resource that needed special handling. Then your super
class doesn't need any explicit code in the destructor.
> 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. 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.
this is why I rarely overload operators (except for << >> for i/o
streams). its pretty well best to confine operator over loading to
arithmatic types.
> > - 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)++;
>
> > 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 <expletive> in whatever language you choose to
> be programming in.
I'm with you up to here.
> You might of course be tempted to say something like, "But I shouldn't
> have to go looking at the type to know what that line is doing."
sounds pretty crazy to me
> This is of course a good argument
no it isn't
> but it is a good argument for variable
noooooo! This way lies the Hungarian Lunacy. If your functions are
small and localised then the variable will be defined close by and we
can see what type it is.
void refrog (MyType x, MyType y)
{
x = y++;
}
> Variable names need
> to have some semantic meaning that explains what the variable is used
> for.
no. really really no.
> When that is done well you generally know what can be done with
> the variable, which is more important than what type it is (which is
> something I can let the compiler worry about).
a well chosen type tells you the semantics of the type
> > 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).
operator<< does soemthing like this with io streams.
operator()() allows you define classes that behave like functions
operator=() sometimes has to be defined
operator==() is often nice
conversion operators can be useful if used carefully
> Which is a pretty excellent example of great use of templates.
>
> If that's the only example that you've seen though then you're
> obviously not looking at a lot of C++.
give some examples then. Arthmatic types need them but what else?
string concatentaion. And?
> > Templates are yet another pothole to the learning programmer: Every
> > instanciation creates an entirely new and unrelated set of routines and
> > class variables.
so does copy-pasteing which is the poor mans template
> As well it should. A list of widgets is not the same as a list of
> blobbets. If they were then you'd instantiate the same template to
> hold them both and your argument is moot.
>
> C programmers tend to bring up this bloat "issue" a lot. It's not an
> issue. In C++ you write a template to create new types. Templates
> are like the preprocessor on steroids
they make your balls shrink?
> and fulfill many, but not all,
> of the tasks originally reserved for macros.
gah. For the /misuses/ of macros
<snip good stuff>
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-10-31 08:43 -0700 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <a4925f62-aa0f-4c24-975e-f00731afeb97@ek5g2000vbb.googlegroups.com> |
| In reply to | #12327 |
On Oct 31, 2:26 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Oct 30, 5:43 pm, nroberts <roberts.n...@gmail.com> wrote:
> > but it is a good argument for variable
>
> noooooo! This way lies the Hungarian Lunacy. If your functions are
> small and localised then the variable will be defined close by and we
> can see what type it is.
Nobody said anything about Hungarian notation. That's a straw man.
>
> void refrog (MyType x, MyType y)
> {
> x = y++;
>
> }
OK, well I'm looking at that function and I have no idea what you are
intending with it. I really doubt that knowing the definitions of
MyType would help me either.
>
> > When that is done well you generally know what can be done with
> > the variable, which is more important than what type it is (which is
> > something I can let the compiler worry about).
>
> a well chosen type tells you the semantics of the type
int q;
Tell me, what is the intended use of q?
void (*f)(int,int,double);
Tell me, what does f do?
You should be able to tell me since the types tell you enough, right?
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-01 03:11 -0700 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <63adb0b9-9de6-4ff9-820f-a36459162596@bq8g2000vbb.googlegroups.com> |
| In reply to | #12357 |
On Oct 31, 3:43 pm, nroberts <roberts.n...@gmail.com> wrote:
> On Oct 31, 2:26 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> > On Oct 30, 5:43 pm, nroberts <roberts.n...@gmail.com> wrote:
> > > but it is a good argument for variable
>
> > noooooo! This way lies the Hungarian Lunacy. If your functions are
> > small and localised then the variable will be defined close by and we
> > can see what type it is.
>
> Nobody said anything about Hungarian notation. That's a straw man.
ok, a bit quick on the Hungarian. Type information in variable names
is IMO, a bad idea.
> > void refrog (MyType x, MyType y)
> > {
> > x = y++;
>
> > }
>
> OK, well I'm looking at that function and I have no idea what you are
> intending with it. I really doubt that knowing the definitions of
> MyType would help me either.
Yes, but in general MyType would have a meaningful name.
Bearing adjustBearing (Bearing& b, Angle& adjustment)
{
return b + adjustment++;
}
ok, one of them has some semantics embedded in the name. But I think
arithmatic types are bad examples of what I'm talking about.
> > > When that is done well you generally know what can be done with
> > > the variable, which is more important than what type it is (which is
> > > something I can let the compiler worry about).
>
> > a well chosen type tells you the semantics of the type
>
> int q;
>
> Tell me, what is the intended use of q?
it's an integer. If you meant to limit it some way you should have
chosen a more semantically meaningful type. Though addmittedly Ada is
better at that than C++ or C.
> void (*f)(int,int,double);
pick a better name than f? Though I agree it would be hard in this
case.
> Tell me, what does f do?
sin(double);
> You should be able to tell me since the types tell you enough, right?
With things like names or counts or sizes you probably needed sematic
information the type. With higher level (domain level) types it
becomes less necessary.
Success send (Stream&, const Message&);
void basestation_reset (Basestation&);
[toc] | [prev] | [next] | [standalone]
| From | nroberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-11-01 08:17 -0700 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <c05ea3a4-4152-4c28-b67c-152a4ddfc9eb@eh5g2000vbb.googlegroups.com> |
| In reply to | #12434 |
On Nov 1, 3:11 am, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > On Oct 31, 3:43 pm, nroberts <roberts.n...@gmail.com> wrote: > > > > When that is done well you generally know what can be done with > > > > the variable, which is more important than what type it is (which is > > > > something I can let the compiler worry about). > > > > a well chosen type tells you the semantics of the type > > void (*f)(int,int,double); > > pick a better name than f? Exactly my point. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-02 06:16 -0700 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <dd5c4458-e978-4163-879b-9f6b30167761@h5g2000vbf.googlegroups.com> |
| In reply to | #12448 |
On Nov 1, 3:17 pm, nroberts <roberts.n...@gmail.com> wrote: > On Nov 1, 3:11 am, Nick Keighley <nick_keighley_nos...@hotmail.com> > wrote: > > > On Oct 31, 3:43 pm, nroberts <roberts.n...@gmail.com> wrote: > > > > > When that is done well you generally know what can be done with > > > > > the variable, which is more important than what type it is (which is > > > > > something I can let the compiler worry about). > > > > > a well chosen type tells you the semantics of the type > > > void (*f)(int,int,double); > > > pick a better name than f? > > Exactly my point. Thanks. you made it poorly then
[toc] | [prev] | [next] | [standalone]
| From | jgk@panix.com (Joe keane) |
|---|---|
| Date | 2011-11-28 00:23 +0000 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <jauk9d$fb$1@reader1.panix.com> |
| In reply to | #12327 |
In article <a54cafb3-f5ec-4254-81cb-3adf75b409be@o19g2000vbk.googlegroups.com>, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote: >string concatenation? I started with BASIC so, yeah, but if the C answer is 'call 'strcat'' i think that is the end of the story.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-11-27 23:57 -0800 |
| Subject | Re: OOP and C++ and C |
| Message-ID | <ded5ec83-3602-480e-906a-f3f71101c32a@t16g2000vba.googlegroups.com> |
| In reply to | #13987 |
On Nov 28, 2:23 am, j...@panix.com (Joe keane) wrote: > In article <a54cafb3-f5ec-4254-81cb-3adf75b40...@o19g2000vbk.googlegroups.com>, > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > > >string concatenation? > > I started with BASIC so, yeah, but if the C answer is 'call 'strcat'' > i think that is the end of the story. > strcat() isn't a very good function, because it's often hard to make sure that the buffer is big enough to hold two runtime-entered strings. It's easy to write char *cat(const char *str1, const char *str2) to return an allocated string. The function is not included in the standard library because it was decided not to allow string functions to depend on malloc(). -- Basic Algorithms: now an iBook http://www.malcolmmclean.site11.com/www
[toc] | [prev] | [next] | [standalone]
Page 3 of 15 — ← Prev page 1 2 [3] 4 5 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web