Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #25009 > unrolled thread
| Started by | "Ansel" <tinker454@trytospammenowloser.com> |
|---|---|
| First post | 2012-08-26 03:57 -0600 |
| Last post | 2012-09-07 06:18 -0700 |
| Articles | 20 on this page of 226 — 44 participants |
Back to article view | Back to comp.lang.c
C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 03:57 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-26 12:28 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-26 13:56 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 21:34 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 01:44 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) jacob navia <jacob@spamsink.net> - 2012-08-26 12:32 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 05:11 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 14:16 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Varun Tewari <tewari.varun@gmail.com> - 2012-08-26 09:38 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-08-27 06:29 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Barry Schwarz <schwarzb@dqel.com> - 2012-08-26 10:03 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Kenneth Brody <kenbrody@spamcop.net> - 2012-08-27 14:00 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) jacob navia <jacob@spamsink.net> - 2012-08-26 19:54 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-26 23:00 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-26 14:19 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-26 23:38 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 23:50 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-27 09:43 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 18:24 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 10:21 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 10:57 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 09:42 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 15:59 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 21:26 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 23:41 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-27 10:40 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 18:34 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 12:40 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 14:06 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 15:32 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 16:04 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 17:57 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 18:45 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) scott@slp53.sl.home (Scott Lurndal) - 2012-08-28 18:08 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 20:44 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 14:50 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 22:36 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 16:56 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 23:28 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 18:18 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-08-28 15:56 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 19:09 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 19:01 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 09:25 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 12:39 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 09:41 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 10:19 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 10:44 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 12:24 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:13 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 08:07 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 14:49 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Adrian Ratnapala <raka@scooter.fritz.box> - 2012-08-30 04:44 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <Casey_at_Carter_dot_net@dontspam.me.invalid> - 2012-08-30 00:20 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-30 09:01 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-29 16:19 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:17 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-07 14:22 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) lawrence.jones@siemens.com - 2012-09-10 17:21 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:03 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 05:41 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Bo Persson <bop@gmb.dk> - 2012-08-28 20:38 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 00:07 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Bo Persson <bop@gmb.dk> - 2012-08-29 21:51 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 15:24 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 22:47 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 16:59 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-28 17:07 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) lawrence.jones@siemens.com - 2012-08-27 16:50 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 00:27 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-27 16:15 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:20 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-26 15:05 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Kenneth Brody <kenbrody@spamcop.net> - 2012-08-27 14:01 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-27 14:29 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-26 21:08 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <Casey@Carter.net> - 2012-08-27 21:47 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-27 22:34 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:27 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-28 12:24 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 21:02 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Bo Persson <bop@gmb.dk> - 2012-08-28 21:15 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 23:00 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Melzzzzz <mel@zzzzz.com> - 2012-08-28 23:12 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-28 17:30 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Melzzzzz <mel@zzzzz.com> - 2012-08-28 23:38 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-29 10:09 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 18:01 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 12:03 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Dombo <dombo@disposable.invalid> - 2012-09-02 22:58 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-28 16:25 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 23:58 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-28 23:03 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 08:02 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-29 10:12 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 20:36 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-29 12:08 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 13:49 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 19:16 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 14:34 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 19:41 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 15:01 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-29 14:05 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-29 15:18 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-29 17:53 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-30 09:47 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 10:17 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-31 05:59 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) scott@slp53.sl.home (Scott Lurndal) - 2012-08-31 14:29 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-01 06:45 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-30 08:05 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-30 14:54 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 18:13 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-30 18:39 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Garrett Hartshaw <ghartshaw@gmail.com> - 2012-08-30 13:49 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-30 14:07 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-31 11:13 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-31 13:41 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-09-03 10:28 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-31 10:55 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-31 00:18 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-30 17:30 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Kenneth Brody <kenbrody@spamcop.net> - 2012-08-31 14:18 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-31 19:34 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-31 17:24 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nobody <nobody@nowhere.com> - 2012-09-02 01:10 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 05:57 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-07 14:17 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 19:37 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Garrett Hartshaw <ghartshaw@gmail.com> - 2012-08-30 22:07 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-31 14:53 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-09-05 19:41 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-05 23:44 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-09-05 23:08 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-06 07:07 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-09-06 09:40 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Dombo <dombo@disposable.invalid> - 2012-09-02 23:16 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Öö Tiib <ootiib@hot.ee> - 2012-09-05 20:27 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-30 13:57 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-30 12:25 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) David Brown <david@westcontrol.removethisbit.com> - 2012-08-31 11:27 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-31 11:58 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) "io_x" <a@b.c.invalid> - 2012-09-01 19:09 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 20:49 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 20:09 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 22:33 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 21:43 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 23:23 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-29 17:21 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 09:06 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) scott@slp53.sl.home (Scott Lurndal) - 2012-08-30 13:53 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 18:51 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Les Cargill <lcargill99@comcast.com> - 2012-08-31 21:15 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-08-29 23:21 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Luca Risolia <luca.risolia@studio.unibo.it> - 2012-08-30 02:38 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 09:11 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-30 08:46 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <Casey_at_Carter_dot_net@dontspam.me.invalid> - 2012-08-30 08:39 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 21:06 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Casey Carter <casey_at_carter_dot_net@nospam.invalid> - 2012-08-28 12:18 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-28 13:00 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) Ike Naar <ike@iceland.freeshell.org> - 2012-08-28 22:47 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-28 19:32 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Bo Persson <bop@gmb.dk> - 2012-08-28 20:58 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) BGB <cr88192@hotmail.com> - 2012-08-28 16:55 -0500
Re: C as a Subset of C++ (or C++ as a superset of C) lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-26 19:49 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 21:41 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-08-26 21:01 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 01:56 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Ceriousmall <divadsmall@gmail.com> - 2012-08-27 04:37 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-08-27 08:50 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-01 10:35 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-01 12:47 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:08 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) lawrence.jones@siemens.com - 2012-09-11 11:14 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-11 15:14 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-12 01:01 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-12 04:40 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-12 06:31 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-12 10:16 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-12 07:27 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-12 07:58 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-13 04:24 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-12 16:21 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-12 10:21 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-12 18:59 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-12 14:01 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-12 20:36 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-12 16:57 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-13 11:36 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-13 12:03 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-13 13:30 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-13 21:32 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-13 15:13 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) James Kuyper <jameskuyper@verizon.net> - 2012-09-13 07:33 -0400
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-14 03:35 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-14 12:21 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:35 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:31 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:33 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-13 14:16 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-12 14:18 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-13 05:15 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-14 03:37 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "BartC" <bc@freeuk.com> - 2012-09-14 13:58 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-14 08:18 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-14 08:33 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:37 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:36 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) "Jan G" <gbn2012@world.net> - 2012-09-30 03:38 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 14:49 -0800
Re: C as a Subset of C++ (or C++ as a superset of C) Ian Collins <ian-news@hotmail.com> - 2012-12-18 12:11 +1300
Re: C as a Subset of C++ (or C++ as a superset of C) "io_x" <a@b.c.invalid> - 2012-09-13 12:04 +0200
Re: C as a Subset of C++ (or C++ as a superset of C) Keith Thompson <kst-u@mib.org> - 2012-09-12 11:42 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-13 13:00 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:07 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-05 14:57 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) John Bode <jfbode1029@gmail.com> - 2012-09-05 15:29 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Kaz Kylheku <kaz@kylheku.com> - 2012-09-01 22:45 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) Leigh Johnston <leigh@i42.co.uk> - 2012-09-02 01:07 +0100
Re: C as a Subset of C++ (or C++ as a superset of C) "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:35 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) Kaz Kylheku <kaz@kylheku.com> - 2012-09-02 21:35 +0000
Re: C as a Subset of C++ (or C++ as a superset of C) "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:30 -0600
Re: C as a Subset of C++ (or C++ as a superset of C) mike3 <mike4ty4@yahoo.com> - 2012-09-12 15:40 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-13 05:18 -0700
Re: C as a Subset of C++ (or C++ as a superset of C) Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:18 -0700
Page 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-08-28 13:00 -0500 |
| Message-ID | <k1j15a$e8i$1@news.albasani.net> |
| In reply to | #25263 |
On 8/28/2012 12:18 PM, Casey Carter wrote:
> On 2012-08-27 22:34, BGB wrote:
>>> Definition of NULL as ((void*)0) is contingent on the implicit
>>> conversion of void* to other pointer types.
>>>
>>
>> well, yes, but I listed that they could add this as well.
>> probably most C++ code wouldn't notice the change.
>
> I should have been more clear about my point here: I was trying to say
> that the only reason this definition of NULL is unacceptable to C++ is
> because of the lack of the implicit conversion from void*. Given that
> conversion, there would be no other barrier in C++ to using ((void*)0)
> for NULL.
>
yep, which is probably why they could do it...
it does at least make more sense than defining it as 0 (which would give
a warning in C).
possible could be changing it internally to _Nullptr or similar, which
could be defined as "functionally equivalent to ((void *)0)".
>> possibly, the change could be limited to 'extern "C"' code or similar
>> (and/or could be ignored in cases of templates or overloading, or at
>> least be a lower priority than any other matches).
>
> I think the rules for overload resolution and template type deduction
> are complicated enough without introducing a feature that behaves
> differently depending on whether or not it interacts with those systems.
>
> There's no such thing as 'extern "C" code': extern "foo" is a *linkage
> specification* whose sole purpose is to tell the implementation to
> engage the ABI machinery appropriate for language "foo".
>
they *could* make it work this way, but OTOH, maybe it isn't such a
great idea to add context-sensitivity in this case.
otherwise, C's "void *" semantics would then apply everywhere.
>>> That implicit conversion from void* to any pointer type is a dangerous
>>> hole in the type system. I admit I'm not much of a C programmer anymore:
>>> the only valid reason I can think of to have this conversion is so that
>>> malloc calls don't require you to specify the type _three_ times (e.g.,
>>> int* p = (int*)malloc(sizeof(*p)); ).
>>>
>>
>> there are plenty of uses besides malloc, so malloc is just one of many
>> cases (mmap, memcpy, VirtualAlloc, ...).
>>
>> or, a biggie:
>> for any user-defined code which accepts or returns "void *".
>
> Returns, not accepts. The implicit conversion _from_ void* is dangerous,
> implicit conversion _to_ void* is perfectly safe type erasure.
>
but, changing this behavior would break existing code.
consider you have something like:
Foo *obj;
obj=gcalloc(sizeof(Foo)); //allocated via a GC API
which would need to be changed everywhere to:
obj=(Foo *)gcalloc(sizeof(Foo)); //allocated via a GC API
this kind of thing isn't really a good option.
introducing another pointer type similarly has the problem of requiring
changing existing code to make it work (altering use of "void *" return
types), which is similarly not a good option.
>>
>> for example, to do similar tasks in C++ often requires a larger number
>> of casts.
>>
>>
>>> If I really wanted to pitch the committees for stronger ties between C
>>> and C++, I'd probably suggest that (a) C pick up nullptr (and nullptr_t)
>>> to serve as generic null pointer constant,
>>
>> could work...
>>
>>
>>> (b) C drop the implicit
>>> conversion from void*,
>>
>> this would break large amounts of C code.
>
> I'll handwave here and claim that's what compiler options are for. Valid
> C90 code will always be valid C90 code, I see no reason why a future C20
> compiler couldn't be instructed to compile code as C90. Old code will
> always be old code, but does that mean that we have to keep on writing
> old code forever?
>
actually, I was thinking if C99 or C11 were the subset, not C90.
in both cases, "void *" works as it did before.
> It's already the case that C11 made some C99 features optional: there
> may be conforming C11 compilers that refuse to compile some conforming
> C99 programs. The kind of change I suggest is quantitatively but not
> qualitatively different.
>
it would break the majority of existing code, rather than just "some
code which uses a few features which never gained widespread adoption
anyways" (or "something which has largely fallen into disuse"), this is
a bit more severe, as it would break "nearly all existing C programs"...
>> I don't think people on either side would want changes which cause their
>> existing programs to break and have to be rewritten.
>>
>>> and (c) both languages use a new distinct type
>>> that can implicitly convert to any pointer type.
>>
>> we call this 'void *', where this is nearly the only thing that can
>> really be done with this type anyways ("void" variables are otherwise
>> pretty much useless, ...).
>
> I am differentiating between the implicit conversion _from_ any pointer
> type and the implicit conversion _to_ any pointer type; I posit that
> those two features have unique design intentions and should therefore be
> represented by distinct types. C conflates the two ideas in void*, C++
> doesn't have the conversion _to_ any pointer type at all, except for
> nullptr. (Given how simple it is to make a user-defined type in C++ that
> implicitly converts to any pointer type, it's notable that I've never
> seen anyone feel the need to do so.)
>
> void* has 2 uses in C:
> 1. it's the "sink" type to which all other pointer types can be
> implicitly converted.
> 2. it's the "source" type that implicitly converts to all other pointer
> types.
>
> and 2 uses in C++:
> 1. "sink" type just as in C.
> 2. type-erased pointer that designates _some_kind_ of object about which
> nothing is known except its location in memory.
>
> The secondary usage is diametrically opposite between C and C++: one
> disallows using a void* for any purpose without a cast, the other allows
> you to pass a void* where you would any pointer type without a cast. In
> C, I can pass the same void* to fclose, free, strcat, and
> hundreds/thousands of other functions without a compiler diagnostic.
> Using void* you've effectively opted out of a large part of the type
> system.
>
> C programmers also often use void* as either a type-erased or generic
> pointer but do so purely based on convention and discipline: you will
> get no help from the compiler. If an intern jumps into your code the
> next day and passes your type-erased pointer to fputs, the compiler will
> accept it happily.
>
actually, C code typically handles the type-erased case by defining new
types based on incomplete structs or similar, as in:
typedef struct _opaqueptr_s opaqueptr_t;
so, this isn't really an issue in practice.
>> > Holes in the type
>>> system are very useful at the fringes of C/C++ programs, I think that
>>> having distinct "source" (X -> any*) and "sink" (any* -> X) pointer
>>> types preserves the utility of C-style void* while minimizing the
>>> danger.
>>
>> yes, but the least impact route would be to just pick up C's "void *"
>> semantics for this, since C++ code isn't likely to notice, and existing
>> C code can keep working unmodified.
>
> While it's true that making the language more permissive doesn't impact
> the correctness of existing programs, that doesn't necessarily make it
> always a good idea. I seriously doubt that the C++ community would ever
> accept implicit conversion from void* into the language; the case I'm
> attempting to make here is that C shouldn't have that feature either and
> likely would not if it was designed afresh today.
>
> Given that preserving the semantics of old code has a higher priority to
> the C community than almost any other concern, I think it's unlikely
> that we will ever have a C++ that is truly a superset of C. If anything
> I think it's more likely that C++ would introduce even more breaking
> changes to become _less_ compatible with C.
well, one could always argue that, on the other side, it may be that C
is already good and that it is C++ which needs changing to be more
compatible with C, but either way.
usually, the route of least impact is the most preferable, and simply
adding "void*" is what leads to this.
the other possible option is, granted, the introduction of an explicit
"C mode" into the compiler, which could possibly look like 'extern "C"'
but would infact change the semantics, or maybe, the introduction of new
syntax for this case, say:
_C { ... }
which would both enable C style linkage, as well as switching over to C
style semantics as well.
maybe it could also be used to declare functions with C-style semantics
(but retaining C++ linkage), as-in:
void myfunc(void) _C
{
Foo *obj;
obj=malloc(sizeof(Foo));
...
}
then C compilers would simply ignore the _C modifier (that or it is
handled similarly to how 'extern "C"' is generally handled in headers,
IOW, via preprocessor magic).
maybe it could be called something like:
C_MODE
and would be defined something like:
#ifndef C_MODE
#ifdef __cplusplus
#define C_MODE _C
#else
#define C_MODE
#endif
#endif
or, something along these lines...
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2012-08-28 22:47 +0000 |
| Message-ID | <slrn3vfsk3qija.3fm.ike@iceland.freeshell.org> |
| In reply to | #25263 |
On 2012-08-28, Casey Carter <casey_at_carter_dot_net@nospam.invalid> wrote: > There's no such thing as 'extern "C" code': extern "foo" is a *linkage > specification* whose sole purpose is to tell the implementation to > engage the ABI machinery appropriate for language "foo". For one thing, 'extern "C"' may turn off C++ name mangling.
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2012-08-28 19:32 -0700 |
| Message-ID | <909f5149-c19f-4468-8af5-61fd250caf1d@googlegroups.com> |
| In reply to | #25263 |
Casey Carter於 2012年8月29日星期三UTC+8上午1時18分35秒寫道：
> On 2012-08-27 22:34, BGB wrote:
>
> >> Definition of NULL as ((void*)0) is contingent on the implicit
>
> >> conversion of void* to other pointer types.
>
> >>
>
> >
>
> > well, yes, but I listed that they could add this as well.
>
> > probably most C++ code wouldn't notice the change.
>
>
>
> I should have been more clear about my point here: I was trying to say
>
> that the only reason this definition of NULL is unacceptable to C++ is
>
> because of the lack of the implicit conversion from void*. Given that
>
> conversion, there would be no other barrier in C++ to using ((void*)0)
>
> for NULL.
>
>
>
> > possibly, the change could be limited to 'extern "C"' code or similar
>
> > (and/or could be ignored in cases of templates or overloading, or at
>
> > least be a lower priority than any other matches).
>
>
>
> I think the rules for overload resolution and template type deduction
>
> are complicated enough without introducing a feature that behaves
>
> differently depending on whether or not it interacts with those systems.
>
>
>
> There's no such thing as 'extern "C" code': extern "foo" is a *linkage
>
> specification* whose sole purpose is to tell the implementation to
>
> engage the ABI machinery appropriate for language "foo".
>
>
>
> >> That implicit conversion from void* to any pointer type is a dangerous
>
> >> hole in the type system. I admit I'm not much of a C programmer anymore:
>
> >> the only valid reason I can think of to have this conversion is so that
>
> >> malloc calls don't require you to specify the type _three_ times (e.g.,
>
> >> int* p = (int*)malloc(sizeof(*p)); ).
>
> >>
>
> >
>
> > there are plenty of uses besides malloc, so malloc is just one of many
>
> > cases (mmap, memcpy, VirtualAlloc, ...).
>
> >
>
> > or, a biggie:
>
> > for any user-defined code which accepts or returns "void *".
>
>
>
> Returns, not accepts. The implicit conversion _from_ void* is dangerous,
>
> implicit conversion _to_ void* is perfectly safe type erasure.
>
>
>
> >
>
> > for example, to do similar tasks in C++ often requires a larger number
>
> > of casts.
>
> >
>
> >
>
> >> If I really wanted to pitch the committees for stronger ties between C
>
> >> and C++, I'd probably suggest that (a) C pick up nullptr (and nullptr_t)
>
> >> to serve as generic null pointer constant,
>
> >
>
> > could work...
>
> >
>
> >
>
> >> (b) C drop the implicit
>
> >> conversion from void*,
>
> >
>
> > this would break large amounts of C code.
>
>
>
> I'll handwave here and claim that's what compiler options are for. Valid
>
> C90 code will always be valid C90 code, I see no reason why a future C20
>
> compiler couldn't be instructed to compile code as C90. Old code will
>
> always be old code, but does that mean that we have to keep on writing
>
> old code forever?
>
>
>
> It's already the case that C11 made some C99 features optional: there
>
> may be conforming C11 compilers that refuse to compile some conforming
>
> C99 programs. The kind of change I suggest is quantitatively but not
>
> qualitatively different.
>
>
>
> > I don't think people on either side would want changes which cause their
>
> > existing programs to break and have to be rewritten.
>
> >
>
> >> and (c) both languages use a new distinct type
>
> >> that can implicitly convert to any pointer type.
>
> >
>
> > we call this 'void *', where this is nearly the only thing that can
>
> > really be done with this type anyways ("void" variables are otherwise
>
> > pretty much useless, ...).
>
>
>
> I am differentiating between the implicit conversion _from_ any pointer
>
> type and the implicit conversion _to_ any pointer type; I posit that
>
> those two features have unique design intentions and should therefore be
>
> represented by distinct types. C conflates the two ideas in void*, C++
>
> doesn't have the conversion _to_ any pointer type at all, except for
>
> nullptr. (Given how simple it is to make a user-defined type in C++ that
>
> implicitly converts to any pointer type, it's notable that I've never
>
> seen anyone feel the need to do so.)
>
>
>
> void* has 2 uses in C:
>
> 1. it's the "sink" type to which all other pointer types can be
>
> implicitly converted.
>
> 2. it's the "source" type that implicitly converts to all other pointer
>
> types.
>
>
>
> and 2 uses in C++:
>
> 1. "sink" type just as in C.
>
> 2. type-erased pointer that designates _some_kind_ of object about which
>
> nothing is known except its location in memory.
>
>
>
> The secondary usage is diametrically opposite between C and C++: one
>
> disallows using a void* for any purpose without a cast, the other allows
>
> you to pass a void* where you would any pointer type without a cast. In
>
> C, I can pass the same void* to fclose, free, strcat, and
>
> hundreds/thousands of other functions without a compiler diagnostic.
>
> Using void* you've effectively opted out of a large part of the type system.
>
>
>
> C programmers also often use void* as either a type-erased or generic
>
> pointer but do so purely based on convention and discipline: you will
>
> get no help from the compiler. If an intern jumps into your code the
>
> next day and passes your type-erased pointer to fputs, the compiler will
>
> accept it happily.
>
>
>
> > > Holes in the type
>
> >> system are very useful at the fringes of C/C++ programs, I think that
>
> >> having distinct "source" (X -> any*) and "sink" (any* -> X) pointer
>
> >> types preserves the utility of C-style void* while minimizing the danger.
>
> >
>
> > yes, but the least impact route would be to just pick up C's "void *"
>
> > semantics for this, since C++ code isn't likely to notice, and existing
>
> > C code can keep working unmodified.
>
>
>
> While it's true that making the language more permissive doesn't impact
>
> the correctness of existing programs, that doesn't necessarily make it
>
> always a good idea. I seriously doubt that the C++ community would ever
>
> accept implicit conversion from void* into the language; the case I'm
>
> attempting to make here is that C shouldn't have that feature either and
>
> likely would not if it was designed afresh today.
>
>
>
> Given that preserving the semantics of old code has a higher priority to
>
> the C community than almost any other concern, I think it's unlikely
>
> that we will ever have a C++ that is truly a superset of C. If anything
>
> I think it's more likely that C++ would introduce even more breaking
>
> changes to become _less_ compatible with C.
Please check objective C. Programmers will pick the right tool
at the right time for their tasks to earn money in the industry.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bop@gmb.dk> |
|---|---|
| Date | 2012-08-28 20:58 +0200 |
| Message-ID | <aa4inaFk3pU1@mid.individual.net> |
| In reply to | #25175 |
BGB wrote 2012-08-28 05:34: > On 8/27/2012 9:47 PM, Casey Carter wrote: > >> That implicit conversion from void* to any pointer type is a dangerous >> hole in the type system. I admit I'm not much of a C programmer anymore: >> the only valid reason I can think of to have this conversion is so that >> malloc calls don't require you to specify the type _three_ times (e.g., >> int* p = (int*)malloc(sizeof(*p)); ). >> > > there are plenty of uses besides malloc, so malloc is just one of many > cases (mmap, memcpy, VirtualAlloc, ...). But you don't use memcpy for C++ type, you use std::copy which is typed. And you don't do malloc either, you use the containers from the C++ standard library. Or use the occasional new X, which doesn't need a cast either. > > or, a biggie: > for any user-defined code which accepts or returns "void *". No, these can be templates and accept or return T*, for any type T. > > for example, to do similar tasks in C++ often requires a larger number > of casts. If you do it the C++ way, it actually uses fewer casts. :-) A big problem with trying to finds the common ground between C and C++ is that lots of good C++ code isn't using many C features at all. And well written C code tend to be very non-idiomatic C++ code. Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-08-28 16:55 -0500 |
| Message-ID | <k1jeu7$a6b$1@news.albasani.net> |
| In reply to | #25277 |
On 8/28/2012 1:58 PM, Bo Persson wrote: > BGB wrote 2012-08-28 05:34: >> On 8/27/2012 9:47 PM, Casey Carter wrote: >> >>> That implicit conversion from void* to any pointer type is a dangerous >>> hole in the type system. I admit I'm not much of a C programmer anymore: >>> the only valid reason I can think of to have this conversion is so that >>> malloc calls don't require you to specify the type _three_ times (e.g., >>> int* p = (int*)malloc(sizeof(*p)); ). >>> >> >> there are plenty of uses besides malloc, so malloc is just one of many >> cases (mmap, memcpy, VirtualAlloc, ...). > > But you don't use memcpy for C++ type, you use std::copy which is typed. > And you don't do malloc either, you use the containers from the C++ > standard library. Or use the occasional new X, which doesn't need a cast > either. > yes, but the topic here would be C code running in a C++ compiler, in such a scenario where plain C in a C++ compiler worked the same as in a C compiler. expecting the code to be rewritten into C++ in the process is a no-go. >> >> or, a biggie: >> for any user-defined code which accepts or returns "void *". > > No, these can be templates and accept or return T*, for any type T. > not in C code. >> >> for example, to do similar tasks in C++ often requires a larger number >> of casts. > > If you do it the C++ way, it actually uses fewer casts. :-) > > > A big problem with trying to finds the common ground between C and C++ > is that lots of good C++ code isn't using many C features at all. And > well written C code tend to be very non-idiomatic C++ code. > but, more importantly though: existing C code has to still work, if the languages were to be merged. idiomatic or not, things still working is the main thing. yes, it is possible to just write in the "least-common-denominator" of C and C++ (I have done this a few times), but this is not the issue here.
[toc] | [prev] | [next] | [standalone]
| From | lovecreatesbeauty <lovecreatesbeauty@gmail.com> |
|---|---|
| Date | 2012-08-26 19:49 -0700 |
| Message-ID | <a14eec48-2b92-4be8-9e7b-d8c2f629492e@googlegroups.com> |
| In reply to | #25009 |
On Sunday, August 26, 2012 9:57:30 AM UTC, Ansel wrote: > Isn't it a lame use of human time and effort to maintain completely separate > > C and C++ standards? As in the words of Betty White about Facebook: "It > C isn't subset of C++. C++ isn't superset of C. They are different. C++ is a new language. Now I somewhat agree with a similar opinion thrown long time ago: C++ has no relationship with C except its name stolen from C
[toc] | [prev] | [next] | [standalone]
| From | "Ansel" <tinker454@trytospammenowloser.com> |
|---|---|
| Date | 2012-08-26 21:41 -0600 |
| Message-ID | <k1eq7k$ouu$1@speranza.aioe.org> |
| In reply to | #25051 |
lovecreatesbeauty wrote: > On Sunday, August 26, 2012 9:57:30 AM UTC, Ansel wrote: >> Isn't it a lame use of human time and effort to maintain completely >> separate >> >> C and C++ standards? As in the words of Betty White about Facebook: >> "It >> > > C isn't subset of C++. > C++ isn't superset of C. The thought behind the OP was, though, "*could* it be so, and to good effect?". > They are different. > C++ is a new language. > > Now I somewhat agree with a similar opinion thrown long time ago: > > C++ has no relationship with C except its name stolen from C
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-26 21:01 -0700 |
| Message-ID | <lnlih1c7aa.fsf@nuthaus.mib.org> |
| In reply to | #25051 |
lovecreatesbeauty <lovecreatesbeauty@gmail.com> writes:
> On Sunday, August 26, 2012 9:57:30 AM UTC, Ansel wrote:
>> Isn't it a lame use of human time and effort to maintain completely
>> separate
>>
>> C and C++ standards? As in the words of Betty White about Facebook:
>> "It
>
> C isn't subset of C++.
> C++ isn't superset of C.
> They are different.
> C++ is a new language.
True (but I'd say "newer" rather than "new").
> Now I somewhat agree with a similar opinion thrown long time ago:
>
> C++ has no relationship with C except its name stolen from C
I completely disagree with that. C++ is clearly derived from C.
It's *nearly* a superset of C. Almost the entire standard C library
is included in C by reference. The C and C++ committees coordinate
with each other to avoid unnecessary incompatibilities.
It's not difficult (though sometimes a bit tricky) to write
substantial programs that are valid C and valid C++ with the same
semantics. Try that with two languages that have "no relationship"
(say, C and Fortran).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-08-27 01:56 -0700 |
| Message-ID | <90b006cb-a517-4324-9758-639fa80f192f@e29g2000vbm.googlegroups.com> |
| In reply to | #25051 |
On Aug 27, 3:49 am, lovecreatesbeauty <lovecreatesbea...@gmail.com> wrote: > On Sunday, August 26, 2012 9:57:30 AM UTC, Ansel wrote: > > Isn't it a lame use of human time and effort to maintain completely separate > > > C and C++ standards? As in the words of Betty White about Facebook: "It > > C isn't subset of C++. > C++ isn't superset of C. > They are different. > C++ is a new language. > > Now I somewhat agree with a similar opinion thrown long time ago: > > C++ has no relationship with C except its name stolen from C which is plainly nonsense
[toc] | [prev] | [next] | [standalone]
| From | Ceriousmall <divadsmall@gmail.com> |
|---|---|
| Date | 2012-08-27 04:37 -0700 |
| Message-ID | <9b1c5091-da65-4b8a-b32c-4d004bf2cf64@qa3g2000pbc.googlegroups.com> |
| In reply to | #25051 |
lovecreatesbeauty wrote: > On Sunday, August 26, 2012 9:57:30 AM UTC, Ansel wrote: > > Isn't it a lame use of human time and effort to maintain completely separate > > > > C and C++ standards? As in the words of Betty White about Facebook: "It > > > > C isn't subset of C++. > C++ isn't superset of C. > They are different. > C++ is a new language. > > Now I somewhat agree with a similar opinion thrown long time ago: > > C++ has no relationship with C except its name stolen from C Pure rubbish here, out of what was C with classes born....?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-27 08:50 -0400 |
| Message-ID | <k1fqfj$m74$1@dont-email.me> |
| In reply to | #25051 |
On 08/26/2012 10:49 PM, lovecreatesbeauty wrote: ... > Now I somewhat agree with a similar opinion thrown long time ago: > > C++ has no relationship with C except its name stolen from C Nonsense. Almost every feature of C90 is a feature of C++98, and many of the features added to C99 have since become part of later versions of C++. C++ has a large number of additional features, and modifies the meaning of some constructs that are permitted by both languages, but it's not difficult to write code that avoids all of the incompatibilities. It is very difficult to write strictly conforming C that cannot be converted into C code that compiles without change of meaning as C++ code. In fact, many people who claim that they have C++ experience have in fact only used C++ to compile code that would (with at most minor modifications) compile with exactly the same meaning as C code. This can actually be a problem if you're trying to hire someone to work on code that makes extensive use of the features C++ has that C doesn't. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2012-09-01 10:35 -0700 |
| Message-ID | <f1df229a-567b-465e-a079-2327d42d2578@googlegroups.com> |
| In reply to | #25009 |
On Sunday, August 26, 2012 4:57:30 AM UTC-5, Ansel wrote: > Isn't it a lame use of human time and effort to maintain completely separate > C and C++ standards? Isn't is a lame use of human time and effort to have, what, eleventy million different programming languages in the first place? Why stop with C and C++? Why not roll in Java and C# and Objective-C? C and C++ are different languages with a large common subset. Why is that a problem?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-09-01 12:47 -0700 |
| Message-ID | <383dea3d-662b-444d-a1b1-28456440df28@googlegroups.com> |
| In reply to | #25704 |
בתאריך יום שבת, 1 בספטמבר 2012 18:35:09 UTC+1, מאת John Bode: > On Sunday, August 26, 2012 4:57:30 AM UTC-5, Ansel wrote: > > Isn't is a lame use of human time and effort to have, what, > eleventy million different programming languages in the first place? > > Why stop with C and C++? Why not roll in Java and C# and Objective-C? > Yes, we badly need one programming language that does everything. Twenty different ways of writing a for loop is unacceptable.
[toc] | [prev] | [next] | [standalone]
| From | "Anse" <blankone23@framebuilder.net> |
|---|---|
| Date | 2012-09-01 22:08 -0600 |
| Message-ID | <k1um21$lc4$1@speranza.aioe.org> |
| In reply to | #25708 |
Malcolm McLean wrote: > ?????? ??? ???, 1 ??????? 2012 18:35:09 UTC+1, ??? John Bode: >> On Sunday, August 26, 2012 4:57:30 AM UTC-5, Ansel wrote: >> >> Isn't is a lame use of human time and effort to have, what, >> eleventy million different programming languages in the first place? >> >> Why stop with C and C++? Why not roll in Java and C# and >> Objective-C? >> > Yes, we badly need one programming language that does everything. > Twenty different ways of writing a for loop is unacceptable. "Put your money where your mouth is!". IOW, talk is cheap. Are you asking for something, or suggesting you know what to do?
[toc] | [prev] | [next] | [standalone]
| From | lawrence.jones@siemens.com |
|---|---|
| Date | 2012-09-11 11:14 -0400 |
| Message-ID | <h314i9-dcp.ln1@jones.homeip.net> |
| In reply to | #25708 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > Yes, we badly need one programming language that does everything. What you'll get is a programming language that does everything badly. -- Larry Jones I can feel my brain beginning to atrophy already. -- Calvin
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-09-11 15:14 -0700 |
| Message-ID | <6d0abf37-8d65-4c04-bd41-c9389658aa00@googlegroups.com> |
| In reply to | #26218 |
בתאריך יום שלישי, 11 בספטמבר 2012 16:14:25 UTC+1, מאת lawrenc...@siemens.com: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > Yes, we badly need one programming language that does everything. > > > What you'll get is a programming language that does everything badly. > That's arguably OK. Better to do every badly, but at least work, everywhere, than have a finely honed, expensively developed, very interesting program, in Lisp.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-09-12 01:01 -0700 |
| Message-ID | <0474b5ad-ed0b-460e-82a6-a95b8456768a@gk4g2000vbb.googlegroups.com> |
| In reply to | #26224 |
On Sep 11, 11:14 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > בתאריך יום שלישי, 11 בספטמבר 2012 16:14:25 UTC+1, מאת lawrenc...@siemens.com:> Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > > > > Yes, we badly need one programming language that does everything. > > > What you'll get is a programming language that does everything badly. > > That's arguably OK. Better to do every badly, but at least work, everywhere, than have a finely honed, expensively developed, very interesting program, in Lisp. oh. I assumed you were proposing Lisp *as* the universal hammer. Which blub are you proposing then? PL/I was the last attempt.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-09-12 04:40 -0700 |
| Message-ID | <7073a8f9-488c-4f6a-9a32-42e8f2b161cc@googlegroups.com> |
| In reply to | #26233 |
בתאריך יום רביעי, 12 בספטמבר 2012 09:01:53 UTC+1, מאת Nick Keighley: > On Sep 11, 11:14 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> > > oh. I assumed you were proposing Lisp *as* the universal hammer. Which > blub are you proposing then? PL/I was the last attempt. > I'd say it needs essentially C syntax - loops, curly brackets, non-flow control non-arithemtical functionality implemented as functions rather than the core language. That's generally been accepted. But C itself isn't a good universal language, because of the buffer overflow and wild pointer issue. Also because of the difficulties in representing higher-level contructs, like classes, graphs, and metacode. Even structs have no way of serialising without writing special functions for each case. Also the proliferation of integer types is unacceptable.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-09-12 06:31 -0700 |
| Message-ID | <1ec4d2cd-40f5-4fdd-a471-601223666426@o19g2000vbo.googlegroups.com> |
| In reply to | #26237 |
On Sep 12, 12:40 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > בתאריך יום רביעי, 12 בספטמבר 2012 09:01:53 UTC+1, מאת Nick Keighley:> On Sep 11, 11:14 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> Malcolm Mclean said >>> Yes, we badly need one programming language that does everything. apparently for small values of "everything" > > oh. I assumed you were proposing Lisp *as* the universal hammer. Which > > blub are you proposing then? PL/I was the last attempt. > > I'd say it needs essentially C syntax - loops, curly brackets, non-flow control non-arithemtical functionality implemented as functions rather than the core language. That's generally been accepted. by whom? You seem to saying we need a single low level procedural language. I'm not sure your wish-list is consistent. lets call it Single Procedural Language (SPL) > But C itself isn't a good universal language, because of the buffer overflow and wild pointer issue. use Java? But that interposes a VM. How do you avoid buffer overflow without runtime overhead? Could we write a device driver in SPL? What about cryto, compression or embedded code? > Also because of the difficulties in representing higher-level contructs, like classes, graphs, and metacode. templates? Can even Java do all these things? > Even structs have no way of serialising without writing special functions for each case. Java? Python? Sounds potentially expensive > Also the proliferation of integer types is unacceptable. but also useful. is there a current langauage thate meets your criteria?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-09-12 10:16 -0400 |
| Message-ID | <50509930.8050808@verizon.net> |
| In reply to | #26238 |
On 09/12/2012 09:31 AM, Nick Keighley wrote: > On Sep 12, 12:40 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> > wrote: ... >>>> Yes, we badly need one programming language that does everything. ... > ... is there a current langauage thate meets your > criteria? I believe that "we badly need" implies that he knows of no such language.
[toc] | [prev] | [next] | [standalone]
Page 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web