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 1 of 12 [1] 2 3 … 12 Next page →
| From | "Ansel" <tinker454@trytospammenowloser.com> |
|---|---|
| Date | 2012-08-26 03:57 -0600 |
| Subject | C as a Subset of C++ (or C++ as a superset of C) |
| Message-ID | <k1ctl7$5uq$1@speranza.aioe.org> |
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 seems like an incredible waste of time". Why don't the two standards groups get together and agree on a common specification for the ground which both standards cover? There would still be two separate standards, but they'd both be exactly the same for the common ground. The common ground document could be referred to by both standards instead of being maintained by both groups in individual efforts resulting in different verbage in separate specifications for the same functionality. This should happen after both groups agree to completely align the C subset functionality on the next realease of standards (e.g., VLAs? No one using them? Drop 'em in the name of cooperation going forward).
[toc] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2012-08-26 12:28 +0200 |
| Message-ID | <k1ctob$mbu$1@news.albasani.net> |
| In reply to | #25009 |
On 26.08.2012 11:57, Ansel wrote: > This should happen after both > groups agree to completely align the C subset functionality on the next > realease of standards (e.g., VLAs? No one using them? Drop 'em in the name > of cooperation going forward). Ever heared of printf? Best regards, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-26 13:56 -0700 |
| Message-ID | <lnehmte5jx.fsf@nuthaus.mib.org> |
| In reply to | #25011 |
Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> On 26.08.2012 11:57, Ansel wrote:
>> This should happen after both
>> groups agree to completely align the C subset functionality on the next
>> realease of standards (e.g., VLAs? No one using them? Drop 'em in the name
>> of cooperation going forward).
>
> Ever heared of printf?
You mean the standard C++ function declared in <cstdio>?
Yes, I've heard of it; why do you ask?
--
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 | "Ansel" <tinker454@trytospammenowloser.com> |
|---|---|
| Date | 2012-08-26 21:34 -0600 |
| Message-ID | <k1epq1$o99$1@speranza.aioe.org> |
| In reply to | #25034 |
Keith Thompson wrote: > Johannes Bauer <dfnsonfsduifb@gmx.de> writes: >> On 26.08.2012 11:57, Ansel wrote: >>> This should happen after both >>> groups agree to completely align the C subset functionality on the >>> next realease of standards (e.g., VLAs? No one using them? Drop 'em >>> in the name of cooperation going forward). >> >> Ever heared of printf? > > You mean the standard C++ function declared in <cstdio>? > Yes, I've heard of it; why do you ask? (I was "afraid" of asking. I thought he was on the warpath, and I didn't get what he was after either.)
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-08-27 01:44 -0700 |
| Message-ID | <0f76a55c-71cb-44fa-97b2-9cbc252da0d2@u15g2000yql.googlegroups.com> |
| In reply to | #25011 |
On Aug 26, 11:28 am, Johannes Bauer <dfnsonfsdu...@gmx.de> wrote: > On 26.08.2012 11:57, Ansel wrote: > > > This should happen after both > > groups agree to completely align the C subset functionality on the next > > realease of standards (e.g., VLAs? No one using them? Drop 'em in the name > > of cooperation going forward). > > Ever heared of printf? yes, why? Does it use VLAs?
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2012-08-26 12:32 +0200 |
| Message-ID | <k1cu0l$63j$1@speranza.aioe.org> |
| In reply to | #25009 |
Le 26/08/12 11:57, Ansel a écrit : > 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 > seems like an incredible waste of time". Why don't the two standards groups > get together and agree on a common specification for the ground which both > standards cover? There would still be two separate standards, but they'd > both be exactly the same for the common ground. The common ground document > could be referred to by both standards instead of being maintained by both > groups in individual efforts resulting in different verbage in separate > specifications for the same functionality. This should happen after both > groups agree to completely align the C subset functionality on the next > realease of standards (e.g., VLAs? No one using them? Drop 'em in the name > of cooperation going forward). > > You said in a message posted just 3 hours ago: <quote> It's hard to be enthusiastic about boring old C though. Yeah, it may be the simplest way to deliver a library of simple functions, but so what? Why bother worrying about the lonely C standard when C++ is almost a superset of it and you're using a C++ compiler anyway? <end quote> Take you own advice dude and stop trolling
[toc] | [prev] | [next] | [standalone]
| From | "Ansel" <tinker454@trytospammenowloser.com> |
|---|---|
| Date | 2012-08-26 05:11 -0600 |
| Message-ID | <k1d079$btc$1@speranza.aioe.org> |
| In reply to | #25012 |
jacob navia wrote: > Le 26/08/12 11:57, Ansel a écrit : >> 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 seems like an incredible waste of time". Why don't the >> two standards groups get together and agree on a common >> specification for the ground which both standards cover? There would >> still be two separate standards, but they'd both be exactly the same >> for the common ground. The common ground document could be referred >> to by both standards instead of being maintained by both groups in >> individual efforts resulting in different verbage in separate >> specifications for the same functionality. This should happen after >> both groups agree to completely align the C subset functionality on >> the next realease of standards (e.g., VLAs? No one using them? Drop >> 'em in the name of cooperation going forward). > > You said in a message posted just 3 hours ago: > > <quote> > It's hard to be enthusiastic about boring old C though. Yeah, it may > be the simplest way to deliver a library of simple functions, but so > what? > Why bother worrying about the lonely C standard when C++ is almost a > superset of it and you're using a C++ compiler anyway? > <end quote> > But this new topic is an adjunct to that thought (which was meant in the 3rd person). Go to bed if you are crabby.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-26 14:16 +0200 |
| Message-ID | <503A13A2.5060105@loria.fr> |
| In reply to | #25009 |
Am 26.08.2012 11:57, schrieb Ansel: > Isn't it a lame use of human time and effort to maintain completely > separate C and C++ standards? yes > The common ground document could be referred to by both standards > instead of being maintained by both groups in individual efforts > resulting in different verbage in separate specifications for the > same functionality. This should happen after both groups agree to > completely align the C subset functionality on the next realease of > standards (e.g., VLAs? No one using them? Drop 'em in the name of > cooperation going forward). I don't know all the history, but maybe one of the reasons that it didn't work so far is because some people bring their axe to the discussion instead of burying it outside? I already sense the flames from the people heating up and not recognizing that this is a thread in two different news groups. There already is a large corpus of standards that use the C standard as their base, namely POSIX. It has some general clause that everything that is described there and that is in contradiction with the C standard is unintentional. (Don't know how this will work out in future since C adopted the same thread extension as C++ which is not completely interface compatible with POSIX. They really receive a warm greeting from us all.) POSIX avoided to *use* the parts of C that don't seem of their liking, such as e.g variably modified types, that's all, and it works satisfactory, I think. C has swallowed the pill already and declared parts optional. For the variably modified types part, unfortunately it only has made VLA optional as a whole, instead of distinguishing between the possibility of instantiations of VLA and pointers to VLA (VM types) which have a much more general use. As the languages have evolved now, there are technical issues that really would need a lot of compromise such that they could work out well enough for both communities, you probably all know them, different concepts of lvalues and rvalues, different sizeof of literals, different default initializers, different concepts of compile-time constants, different concepts of union, etc etc Doing so would need people with good technical and social skills from both communities. Not the kind of self-opinionated "experts" that we often meet in discussions like this one. Jens
[toc] | [prev] | [next] | [standalone]
| From | Varun Tewari <tewari.varun@gmail.com> |
|---|---|
| Date | 2012-08-26 09:38 -0700 |
| Message-ID | <980303f1-d3d5-41be-a899-34b3bd89eb62@googlegroups.com> |
| In reply to | #25009 |
As long as libraries like POSIX etc are willing to migrate, I vouch for single standard to cover both, ++ anyway is superset of C.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Smallshaw <andrews@sdf.lonestar.org> |
|---|---|
| Date | 2012-08-27 06:29 +0000 |
| Message-ID | <slrn3vfsk3m4us.a2r.andrews@sdf.lonestar.org> |
| In reply to | #25025 |
On 2012-08-26, Varun Tewari <tewari.varun@gmail.com> wrote:
> As long as libraries like POSIX etc are willing to migrate, I vouch for single standard to cover both, ++ anyway is superset of C.
That isn't true. It IS true that code can be written that is
acceptable to either relatively easy, but a true superset it isn't:
int *number = malloc(sizeof(int));
is perfectly valid C but needs an explicit typecast in the "superset".
--
Andrew Smallshaw
andrews@sdf.lonestar.org
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2012-08-26 10:03 -0700 |
| Message-ID | <ppkk38tkth5gb6u5ga9unl07c6jsg6ri1d@4ax.com> |
| In reply to | #25009 |
On Sun, 26 Aug 2012 03:57:30 -0600, "Ansel"
<tinker454@trytospammenowloser.com> 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
>seems like an incredible waste of time". Why don't the two standards groups
>get together and agree on a common specification for the ground which both
>standards cover? There would still be two separate standards, but they'd
>both be exactly the same for the common ground. The common ground document
>could be referred to by both standards instead of being maintained by both
>groups in individual efforts resulting in different verbage in separate
>specifications for the same functionality. This should happen after both
>groups agree to completely align the C subset functionality on the next
>realease of standards (e.g., VLAs? No one using them? Drop 'em in the name
>of cooperation going forward).
What is your recommended compromise for malloc?
Should C++ give up its strict type checking and no longer require
a cast of the return value?
or
Should C now require the cast and break more than 20 years of
existing code?
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-08-27 14:00 -0400 |
| Message-ID | <1_qdncjg4vM-KKbNnZ2dnUVZ_rudnZ2d@bestweb.net> |
| In reply to | #25026 |
On 8/26/2012 1:03 PM, Barry Schwarz wrote: > On Sun, 26 Aug 2012 03:57:30 -0600, "Ansel" > <tinker454@trytospammenowloser.com> 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 [...] > What is your recommended compromise for malloc? > > Should C++ give up its strict type checking and no longer require > a cast of the return value? > > or > > Should C now require the cast and break more than 20 years of > existing code? While the former has zero effect on existing C++ code, the latter invalidates a huge amount of existing C code. Obviously, the only "right" answer is "A". Good luck on getting C++ advocates to agree to it, however. There's also "little" things such as new reserved keywords in C++. What changes to C++ would be required to allow "int new,old;"? It seems to me that just about anything you could come up with would be "change C++ to allow this valid C construct, while not invalidating current C++, so that C++ is truly a superset of C". (Just about anything else would mean invalidating existing legal C code.) It would probably take more time to resolve all of those issues than all of the "duplicate effort" currently required for two separate standards. Basically, "it ain't gonna happen". -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2012-08-26 19:54 +0200 |
| Message-ID | <503A62EC.5050909@spamsink.net> |
| In reply to | #25009 |
Le 26/08/12 11:57, Ansel a écrit :
> 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
> seems like an incredible waste of time". Why don't the two standards groups
> get together and agree on a common specification for the ground which both
> standards cover? There would still be two separate standards, but they'd
> both be exactly the same for the common ground. The common ground document
> could be referred to by both standards instead of being maintained by both
> groups in individual efforts resulting in different verbage in separate
> specifications for the same functionality. This should happen after both
> groups agree to completely align the C subset functionality on the next
> realease of standards (e.g., VLAs? No one using them? Drop 'em in the name
> of cooperation going forward).
>
>
sizeof('b') is sizeof(int) int C, 1 in C++
Which one would you compromise on?
You do not know what you are talking about dude...
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-26 23:00 +0200 |
| Message-ID | <IMadnRSuG7gZE6fNnZ2dnUVZ7vydnZ2d@lyse.net> |
| In reply to | #25027 |
On 26/08/2012 19:54, jacob navia wrote:
> Le 26/08/12 11:57, Ansel a écrit :
>> 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
>> seems like an incredible waste of time". Why don't the two standards
>> groups
>> get together and agree on a common specification for the ground which
>> both
>> standards cover? There would still be two separate standards, but they'd
>> both be exactly the same for the common ground. The common ground
>> document
>> could be referred to by both standards instead of being maintained by
>> both
>> groups in individual efforts resulting in different verbage in separate
>> specifications for the same functionality. This should happen after both
>> groups agree to completely align the C subset functionality on the next
>> realease of standards (e.g., VLAs? No one using them? Drop 'em in the
>> name
>> of cooperation going forward).
>>
>>
>
> sizeof('b') is sizeof(int) int C, 1 in C++
>
> Which one would you compromise on?
>
> You do not know what you are talking about dude...
There are a few issues where C and C++ are different - but there are
actually very few situations where well-written C99 C is not also close
to valid C++, except perhaps where the C code uses reserved words from
C++ as identifiers. Add a few extra casts around things like malloc()
and it is even closer.
Take your example here. Yes, it is true that a character literal is an
"int" in C and a "char" in C++. But can you give me an example of
useful, well-written C or C++, where the code is reasonably portable and
passes reasonable warning checks (such as "-Wall" on gcc), and for which
this difference is relevant?
Most of the features of C that are not in C++ are either old styles
(such as omitting prototypes, or "implicit int") which are best avoided,
or they are features that could be happily included in C++ (such as
"long long", designated initialisers, etc.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-26 14:19 -0700 |
| Message-ID | <ln6285e4g9.fsf@nuthaus.mib.org> |
| In reply to | #25035 |
David Brown <david@westcontrol.removethisbit.com> writes:
[...]
> Most of the features of C that are not in C++ are either old styles
> (such as omitting prototypes, or "implicit int") which are best avoided,
> or they are features that could be happily included in C++ (such as
> "long long", designated initialisers, etc.)
Implicit int was dropped by C99. Old-style (non-prototype) function
declarations have been "obsolescent" since 1989, but as of 2011 the
committee hasn't gotten around to removing them from the language;
*if* there were an effort to make C a struct subset of C++, requiring
prototypes wouldn't be a major obstacle.
C++11 added long long. It didn't add designated initializers,
compound literals, "restrict", or VLAs (the latter are optional
in C11).
But I'm not at all convinced that redefining C as a strict subset
of C++ would be worth the effort. In particular, C permits a void*
expression to be implicitly converted to another pointer type;
C++ does not. Making C adopt the C++ rule would break tons
of existing code (struct foo *ptr = malloc(N * sizeof *ptr)).
I'm less sure about the consequence of making C++ adopt the C rule,
but I suspect it would break something having to do with templates
and/or overloading.
The two committees do make some effort to avoid too many
incompatibilities -- and I'd *like* to see C++ adopt a few more
C99 and C11 features than it has so far.
--
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 | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-26 23:38 +0200 |
| Message-ID | <b-idnXlz_t8WCqfNnZ2dnUVZ7rKdnZ2d@lyse.net> |
| In reply to | #25038 |
On 26/08/2012 23:19, Keith Thompson wrote: > David Brown <david@westcontrol.removethisbit.com> writes: > [...] >> Most of the features of C that are not in C++ are either old styles >> (such as omitting prototypes, or "implicit int") which are best avoided, >> or they are features that could be happily included in C++ (such as >> "long long", designated initialisers, etc.) > > Implicit int was dropped by C99. Old-style (non-prototype) function > declarations have been "obsolescent" since 1989, but as of 2011 the > committee hasn't gotten around to removing them from the language; > *if* there were an effort to make C a struct subset of C++, requiring > prototypes wouldn't be a major obstacle. Agreed. > > C++11 added long long. It didn't add designated initializers, > compound literals, "restrict", or VLAs (the latter are optional > in C11). And is there any reason why C++ does not support these features? They are useful, and should not detract from the language. > > But I'm not at all convinced that redefining C as a strict subset > of C++ would be worth the effort. In particular, C permits a void* > expression to be implicitly converted to another pointer type; > C++ does not. Making C adopt the C++ rule would break tons > of existing code (struct foo *ptr = malloc(N * sizeof *ptr)). I suspect this is the biggest single incompatibility. But I don't see anything against letting that stand - the key point is to make the future of C and C++ compatible, not to change old standards. > I'm less sure about the consequence of making C++ adopt the C rule, > but I suspect it would break something having to do with templates > and/or overloading. I think requiring an explicit cast in C would help avoid errors in code - but obviously you want to be careful introducing a feature that would break so much existing code. Equally, you don't want to remove the feature from C++ - so this would have to stand as a difference. > > The two committees do make some effort to avoid too many > incompatibilities -- and I'd *like* to see C++ adopt a few more > C99 and C11 features than it has so far. > Me too. I'd also like to see the committees working together when they are doing the same thing. It is just silly that C11 has "_Static_assert" while C++11 has "static_assert".
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-26 23:50 +0200 |
| Message-ID | <503A9A40.20803@loria.fr> |
| In reply to | #25039 |
Am 26.08.2012 23:38, schrieb David Brown: > I'd also like to see the committees working together when they are doing > the same thing. It is just silly that C11 has "_Static_assert" while > C++11 has "static_assert". They are working successfully working together, here. C has "static_assert", too, only that it is a macro defined in a header file. All new keywords that are introduced to C are first introduced in form of identifiers that had been reserved before, such that the introduction doesn't break existing code. If you want to have "static_assert" or "bool" you'd have to include the corresponding header, and you'll see immediately where a particular incompatibility came from. Jens
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-27 09:43 +0200 |
| Message-ID | <rdednXtygdSuuKbNnZ2dnUVZ8t6dnZ2d@lyse.net> |
| In reply to | #25044 |
On 26/08/2012 23:50, Jens Gustedt wrote: > Am 26.08.2012 23:38, schrieb David Brown: >> I'd also like to see the committees working together when they are doing >> the same thing. It is just silly that C11 has "_Static_assert" while >> C++11 has "static_assert". > > They are working successfully working together, here. C has > "static_assert", too, only that it is a macro defined in a header > file. All new keywords that are introduced to C are first introduced in > form of identifiers that had been reserved before, such that the > introduction doesn't break existing code. If you want to have > "static_assert" or "bool" you'd have to include the corresponding > header, and you'll see immediately where a particular incompatibility > came from. > I understand this (and in fact knew it was the case). But that doesn't stop it being silly! The C committee should learn - as the C++ committee apparently knows - that backwards compatibility is only "important", not "critical". It is /okay/ to introduce a new "static_assert" keyword in the new version of a language, as long as people can continue to use their compilers with older standards. This is not a new idea - consider K&R style function declarations, for example. Failing that, what is to stop the C++ people following the C people here? Anyway, this is just one example that is easy to see, where the two committees added the same feature to the two languages but with differing details. The more annoying issue, as I see it, is the increasing gap of C features that are missing in C++. There are steadily more features being added to C for embedded use, such as fixed point formats. But C++ doesn't get that sort of thing, because it could all be implemented in a class. I understand the principle that you should not add something to the core library if it can be done just as well in a class - but the C++ committee doesn't seem to realise that compatibility with C is important here.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-27 18:24 +0200 |
| Message-ID | <503B9F4E.600@loria.fr> |
| In reply to | #25071 |
Am 27.08.2012 09:43, schrieb David Brown:
> On 26/08/2012 23:50, Jens Gustedt wrote:
>> Am 26.08.2012 23:38, schrieb David Brown:
>>> I'd also like to see the committees working together when they are doing
>>> the same thing. It is just silly that C11 has "_Static_assert" while
>>> C++11 has "static_assert".
>>
>> They are working successfully working together, here. C has
>> "static_assert", too, only that it is a macro defined in a header
>> file. All new keywords that are introduced to C are first introduced in
>> form of identifiers that had been reserved before, such that the
>> introduction doesn't break existing code. If you want to have
>> "static_assert" or "bool" you'd have to include the corresponding
>> header, and you'll see immediately where a particular incompatibility
>> came from.
>>
>
> I understand this (and in fact knew it was the case). But that doesn't
> stop it being silly!
>
> The C committee should learn - as the C++ committee apparently knows -
> that backwards compatibility is only "important", not "critical". It is
> /okay/ to introduce a new "static_assert" keyword in the new version of
> a language, as long as people can continue to use their compilers with
> older standards. This is not a new idea - consider K&R style function
> declarations, for example.
This is your opinion and the C committee seem to have a different
one. Calling it silly is not very constructive, in any case it is not
going to change soon, I guess.
Important fact is that for these features code will equally well
compile in both frameworks.
> Failing that, what is to stop the C++ people following the C people here?
>
> Anyway, this is just one example that is easy to see, where the two
> committees added the same feature to the two languages but with
> differing details.
>
> The more annoying issue, as I see it, is the increasing gap of C
> features that are missing in C++. There are steadily more features
> being added to C for embedded use, such as fixed point formats. But C++
> doesn't get that sort of thing, because it could all be implemented in a
> class. I understand the principle that you should not add something to
> the core library if it can be done just as well in a class - but the C++
> committee doesn't seem to realise that compatibility with C is important
> here.
I completely agree on that point, and BTW there are equal points in
the other direction from C++ to C.
Best example for something completely trivial is "{}" as a default
initializer. What the hell does C gain by imposing that there is at
least a 0 in it à la "{0}" ?
Or that C adopted declarations in "for" loops but doesn't allow
"static" declarations or "enum" declarations, and doesn't allow
declarations in "if" or "while" ?
These things look just as if somebody was voluntarily seeking to
introduce incompatibilities, instead of reducing them.
Jens
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-28 10:21 +0200 |
| Message-ID | <XtSdnfbVoLQk4qHNnZ2dnUVZ7oadnZ2d@lyse.net> |
| In reply to | #25103 |
On 27/08/2012 18:24, Jens Gustedt wrote:
> Am 27.08.2012 09:43, schrieb David Brown:
>> On 26/08/2012 23:50, Jens Gustedt wrote:
>>> Am 26.08.2012 23:38, schrieb David Brown:
>>>> I'd also like to see the committees working together when they are doing
>>>> the same thing. It is just silly that C11 has "_Static_assert" while
>>>> C++11 has "static_assert".
>>>
>>> They are working successfully working together, here. C has
>>> "static_assert", too, only that it is a macro defined in a header
>>> file. All new keywords that are introduced to C are first introduced in
>>> form of identifiers that had been reserved before, such that the
>>> introduction doesn't break existing code. If you want to have
>>> "static_assert" or "bool" you'd have to include the corresponding
>>> header, and you'll see immediately where a particular incompatibility
>>> came from.
>>>
>>
>> I understand this (and in fact knew it was the case). But that doesn't
>> stop it being silly!
>>
>> The C committee should learn - as the C++ committee apparently knows -
>> that backwards compatibility is only "important", not "critical". It is
>> /okay/ to introduce a new "static_assert" keyword in the new version of
>> a language, as long as people can continue to use their compilers with
>> older standards. This is not a new idea - consider K&R style function
>> declarations, for example.
>
> This is your opinion and the C committee seem to have a different
> one. Calling it silly is not very constructive, in any case it is not
> going to change soon, I guess.
>
Yes, I know the committees have a different opinion. And like all
committees, some of their decisions are based on good ideas, lots of
thought, and lots of experience - and others are based on opinions,
stubbornness and bad compromises. It is never possible to make everyone
happy about everything.
And while the "static_assert" example is a minor one, especially (as you
mention) there is a reasonable workaround (using a standard include
file), it does stand out as a clear example of each committee being
determined to do things /their/ way rather than working together on what
should be common ground.
> Important fact is that for these features code will equally well
> compile in both frameworks.
>
>> Failing that, what is to stop the C++ people following the C people here?
>>
>> Anyway, this is just one example that is easy to see, where the two
>> committees added the same feature to the two languages but with
>> differing details.
>>
>> The more annoying issue, as I see it, is the increasing gap of C
>> features that are missing in C++. There are steadily more features
>> being added to C for embedded use, such as fixed point formats. But C++
>> doesn't get that sort of thing, because it could all be implemented in a
>> class. I understand the principle that you should not add something to
>> the core library if it can be done just as well in a class - but the C++
>> committee doesn't seem to realise that compatibility with C is important
>> here.
>
> I completely agree on that point, and BTW there are equal points in
> the other direction from C++ to C.
>
> Best example for something completely trivial is "{}" as a default
> initializer. What the hell does C gain by imposing that there is at
> least a 0 in it à la "{0}" ?
Agreed.
>
> Or that C adopted declarations in "for" loops but doesn't allow
> "static" declarations or "enum" declarations, and doesn't allow
> declarations in "if" or "while" ?
>
I don't think I would view a declaration within an "if" as good style
myself, but I can imagine when people would want to use it - and it
would make sense for consistency.
> These things look just as if somebody was voluntarily seeking to
> introduce incompatibilities, instead of reducing them.
>
I think that was roughly the point I was trying to make.
Basically, I just want to be able to mix and match C and C++ code
freely. I want to be able to write in the same style in each language.
If I am not using C++ features, I want the code to be compilable as C
or C++, with the same functionality each time. And I want to be able to
do so without artificially restricting the features I can use in C.
It's okay if I have to #include a few standard headers, and put in a few
extern "C" wrappers.
Am I really asking too much?
(Here's another thing C should support - it should accept extern "C".)
> Jens
>
[toc] | [prev] | [next] | [standalone]
Page 1 of 12 [1] 2 3 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web