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 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-09-07 05:41 -0700 |
| Message-ID | <kfn8vcmm2df.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #25259 |
James Kuyper <jameskuyper@verizon.net> writes: > On 08/28/2012 09:32 AM, David Brown wrote: > ... >> Ultimately, I'd like some way to tell the compiler what data, pointers >> and/or types can alias what. > > If you put two types in a union, within the scope of that union > declaration a conforming implementation must take aliasing between those > two types into consideration any time it's dealing with pointers that > could be pointing at different members of the same union object. Obviously this isn't right, since if it were there would be no reason for the "one special guarantee" for structure access.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bop@gmb.dk> |
|---|---|
| Date | 2012-08-28 20:38 +0200 |
| Message-ID | <aa4hgqFb8pU1@mid.individual.net> |
| In reply to | #25106 |
Jens Gustedt wrote 2012-08-27 18:34: > I am not sure that I understand this one. C has the optional uintXX_t > that are guaranteed to have a fixed width no padding etc, if they > exist. Would it for your purpose just suffice to make some of these > types mandatory e.g for 8, 16, 32 and 64 bit integers? > Why would you want to make this mandatory for everyone? Why not be satisfied if your code is portable to systems having these types? Whatever we do at the language level, we still have code that will not run both on a cell phone and a supercomputer. In places where the language standards are vague, it is to ALLOW for implementations on other types of systems. For example, I write some code for IBM mainframes. It will not run at all on any systems not having IMS and DB2. It is totally non-portable whatever language features we use. Just let us do that! Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-29 00:07 +0200 |
| Message-ID | <503D413D.6080600@loria.fr> |
| In reply to | #25272 |
Am 28.08.2012 20:38, schrieb Bo Persson: > Jens Gustedt wrote 2012-08-27 18:34: > >> I am not sure that I understand this one. C has the optional uintXX_t >> that are guaranteed to have a fixed width no padding etc, if they >> exist. Would it for your purpose just suffice to make some of these >> types mandatory e.g for 8, 16, 32 and 64 bit integers? >> > > Why would you want to make this mandatory for everyone? Why not be > satisfied if your code is portable to systems having these types? No I was asking a question to somebody and not necessarily promoting that idea. The starting point of that discussion was seeking a way to be able to access a buffer in "typeless" chunks that correspond to the common object types that a particular architecture might have. Seemingly the word "mandatory" provoked some allergic reaction. Would it be more acceptable for you to have different names for such beasts (say void8_t, void16_t etc) or would you be ok to mandate uintXX_t where XX are some multiples of CHAR_BIT? Jens
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bop@gmb.dk> |
|---|---|
| Date | 2012-08-29 21:51 +0200 |
| Message-ID | <aa7a5iF4r5U1@mid.individual.net> |
| In reply to | #25321 |
Jens Gustedt skrev 2012-08-29 00:07: > Am 28.08.2012 20:38, schrieb Bo Persson: >> Jens Gustedt wrote 2012-08-27 18:34: >> >>> I am not sure that I understand this one. C has the optional uintXX_t >>> that are guaranteed to have a fixed width no padding etc, if they >>> exist. Would it for your purpose just suffice to make some of these >>> types mandatory e.g for 8, 16, 32 and 64 bit integers? >>> >> >> Why would you want to make this mandatory for everyone? Why not be >> satisfied if your code is portable to systems having these types? > > No I was asking a question to somebody and not necessarily promoting > that idea. The starting point of that discussion was seeking a way to > be able to access a buffer in "typeless" chunks that correspond to the > common object types that a particular architecture might > have. Seemingly the word "mandatory" provoked some allergic reaction. > > Would it be more acceptable for you to have different names for such > beasts (say void8_t, void16_t etc) or would you be ok to mandate > uintXX_t where XX are some multiples of CHAR_BIT? > I don't really care what they are called :-), I just wanted to point out that any changes to the languages to make them stricter and more portable, will also affect people who don't intend to make their code portable at all, because they just cannot anyway. In another post I mentioned that we use IBM mainframes. The code written on those depends heavily on the transaction manager of the z/OS (IMS), and the availability of large DB2 databases. This is mission critical for many companies. When we code in "very portable" Java (we do that to, for web services), we have to add special support hardware to comply with the JVM specification of its data types. Hardware accelerators for the Java code! When we code in other languages, it runs natively on the existing hardware. It is allowed to be big endian, and even use non-IEEE floating point! The code we have is not portable anywhere else, not even the Java code, because it is totally dependent on the surrounding infrastructure. Having some features "mandatory" for the ease of portability, does provoke an allergic reaction. Please just let us continue to write our non-portable code, and write your portable code targeting all other systems. We are not interested in low level portability, because that is not a feature we have any use for. It might add extra cost though, if it is made mandatory like in Java. :-( Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 15:24 -0400 |
| Message-ID | <503D1AF0.6070703@verizon.net> |
| In reply to | #25106 |
On 08/27/2012 12:34 PM, Jens Gustedt wrote: ... > ... C has the optional uintXX_t > that are guaranteed to have a fixed width no padding etc, if they > exist. Would it for your purpose just suffice to make some of these > types mandatory e.g for 8, 16, 32 and 64 bit integers? Implementations which fail to support those types do so almost exclusively because there is no hardware support on the target platform for a type that meet's the standard's specifications for those types. Keep in mind that the specifications are such as to rule out emulation. For instance, an emulated 32-bit type on a system with CHAR_BIT==9 could be called int_least32_t, or int_fast32_t, but it could not meet the requirements to qualify as int32_t, because it would have to occupy at least 36 bits, and designating 4 of those bits as padding is not allowed for int32_t. The sole effect of making those types mandatory would be to render all implementations targeting such platforms non-conforming. Such platforms may currently be exceedingly rare, or even non-existent - but is there any value to be gained by prohibiting implementations for such platforms from claiming standard conformance?
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 22:47 +0200 |
| Message-ID | <503D2E7C.9090202@loria.fr> |
| In reply to | #25287 |
Am 28.08.2012 21:24, schrieb James Kuyper: > On 08/27/2012 12:34 PM, Jens Gustedt wrote: > ... >> ... C has the optional uintXX_t >> that are guaranteed to have a fixed width no padding etc, if they >> exist. Would it for your purpose just suffice to make some of these >> types mandatory e.g for 8, 16, 32 and 64 bit integers? > > Implementations which fail to support those types do so almost > exclusively because there is no hardware support on the target platform > for a type that meet's the standard's specifications for those types. > Keep in mind that the specifications are such as to rule out emulation. > For instance, an emulated 32-bit type on a system with CHAR_BIT==9 could > be called int_least32_t, or int_fast32_t, but it could not meet the > requirements to qualify as int32_t, because it would have to occupy at > least 36 bits, and designating 4 of those bits as padding is not allowed > for int32_t. exactly > The sole effect of making those types mandatory would be to render all > implementations targeting such platforms non-conforming. Such platforms > may currently be exceedingly rare, or even non-existent - but is there > any value to be gained by prohibiting implementations for such platforms > from claiming standard conformance? POSIX went that path, for example, so it seems that they got away with it well. And just think of it as a question, I didn't say that I want it myself. You seem to be against, I wouldn't be sure. Also I think that CHAR_BIT==9 could imply the existence of uint9_t, wouldn't it? One could expect that it then has the types that correspond to sizeof(int)*CHAR_BIT and similar multiples, no? I was just trying what the original poster had in mind with his question (which you completely snipped). I understood it that he sought for a way to access "uninterpreted" larger chunks of objects, where the chunks correspond to the typical sizes that arithmetic types have. Jens
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 16:59 -0400 |
| Message-ID | <503D3139.4080906@verizon.net> |
| In reply to | #25295 |
On 08/28/2012 04:47 PM, Jens Gustedt wrote: ... > Also I think that CHAR_BIT==9 could imply the existence of uint9_t, > wouldn't it? One could expect that it then has the types that > correspond to sizeof(int)*CHAR_BIT and similar multiples, no? It would not be mandatory, but it would be extremely likely.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-28 17:07 -0700 |
| Message-ID | <lnvcg2y2zt.fsf@nuthaus.mib.org> |
| In reply to | #25295 |
Jens Gustedt <jens.gustedt@loria.fr> writes:
[...]
> Also I think that CHAR_BIT==9 could imply the existence of uint9_t,
> wouldn't it? One could expect that it then has the types that
> correspond to sizeof(int)*CHAR_BIT and similar multiples, no?
The standard makes {,u}int{8,16,32,64}_t mandatory if the
implementation provides types that meet the requirements. All other
such types are optional. A system with CHAR_BIT==9 would *probably*
provide uint9_t, but the C standard doesn't require it to. I suppose
the same applies to C++ as of the 2011 standard.
--
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 | lawrence.jones@siemens.com |
|---|---|
| Date | 2012-08-27 16:50 -0400 |
| Message-ID | <v53tg9-fl3.ln1@jones.homeip.net> |
| In reply to | #25041 |
Jens Gustedt <jens.gustedt@loria.fr> wrote: > > on my wish list would be > > - variably modified types (not necessarily VLA but pointers to VLA are > nice) What good are pointers to VLAs without VLAs? What would they point to??? -- Larry Jones I'm so disappointed. -- Calvin
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 00:27 +0200 |
| Message-ID | <503BF451.7030505@loria.fr> |
| In reply to | #25143 |
Am 27.08.2012 22:50, schrieb lawrence.jones@siemens.com: > Jens Gustedt <jens.gustedt@loria.fr> wrote: >> >> on my wish list would be >> >> - variably modified types (not necessarily VLA but pointers to VLA are >> nice) > > What good are pointers to VLAs without VLAs? What would they point > to??? > There is a simple idiom to deal with large matrices double (*A)[m][n] = malloc *A; You can easily handle such matrices with functions void product(size_t n, size_t m, size_t k, double (*A)[n][k], double (*B)[k][n], double (*C)[n][m]); All those *A, *B, *C carry all there sizes with them so you can access elements as (*A)[i][j] etc If you allocate all those matrices with malloc as above, no danger of stack overflow. Admittedly the (*A) notation is not the most comfortable, but works. C++'s references would be the perfect complement for that and would make that idiom really useful. Jens http://gustedt.wordpress.com/2011/01/09/dont-be-afraid-of-variably-modified-types/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-27 16:15 -0700 |
| Message-ID | <lnd32capuh.fsf@nuthaus.mib.org> |
| In reply to | #25143 |
lawrence.jones@siemens.com writes:
> Jens Gustedt <jens.gustedt@loria.fr> wrote:
>> on my wish list would be
>>
>> - variably modified types (not necessarily VLA but pointers to VLA are
>> nice)
>
> What good are pointers to VLAs without VLAs? What would they point
> to???
I suppose you could permit VLAs with allocated storage duration
but not with automatic storage duration. (They're already not
permitted to have static storage duration.) That would remove the
case where you can define a VLA, but there's no way to handle an
allocation failure. It would also remove the case where they're
most convenient.
--
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 | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 09:20 +0200 |
| Message-ID | <503C713B.2070400@loria.fr> |
| In reply to | #25151 |
Am 28.08.2012 01:15, schrieb Keith Thompson: > lawrence.jones@siemens.com writes: >> What good are pointers to VLAs without VLAs? What would they point >> to??? > > I suppose you could permit VLAs with allocated storage duration > but not with automatic storage duration. (They're already not > permitted to have static storage duration.) That would remove the > case where you can define a VLA, but there's no way to handle an > allocation failure. It would also remove the case where they're > most convenient. I just don't agree on the last phrase. Pointers to VLA are very convenient in function interfaces. Jens http://gustedt.wordpress.com/2011/01/09/dont-be-afraid-of-variably-modified-types/
[toc] | [prev] | [next] | [standalone]
| From | Adrian Ratnapala <adrian.ratnapala@gmail.com> |
|---|---|
| Date | 2012-08-26 15:05 -0700 |
| Message-ID | <63d0061e-a98d-4272-b73c-a8cac46a5421@googlegroups.com> |
| In reply to | #25038 |
> C++ does not. Making C adopt the C++ rule would break tons > of existing code (struct foo *ptr = malloc(N * sizeof *ptr)). Yes. I recently wrote a little windows utility in C, but had to translate the brains so it could be used as a C++ module. The C++ void* insanity was biggest problem. > 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. Yep. At the end o the day, this kind of incompatibility is only a minor nuisance. Changing fundamental things in either language would be much worse. Especially if the change is to C++, because nobody understands how that thing works.
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-08-27 14:01 -0400 |
| Message-ID | <1_qdncvg4vN9KKbNnZ2dnUVZ_rudnZ2d@bestweb.net> |
| In reply to | #25027 |
On 8/26/2012 1:54 PM, 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
[...]
>
> 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...
Simple. Require sizeof(int)==1. Problem solved. :-)
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-08-27 14:29 -0500 |
| Message-ID | <k1gi0a$qpi$1@news.albasani.net> |
| In reply to | #25120 |
On 8/27/2012 1:01 PM, Kenneth Brody wrote:
> On 8/26/2012 1:54 PM, 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
> [...]
>>
>> 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...
>
> Simple. Require sizeof(int)==1. Problem solved. :-)
>
wouldn't work out well or make much sense on most common architectures.
better would probably be: pick one way or the other.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-08-26 21:08 -0500 |
| Message-ID | <k1el1b$enj$1@news.albasani.net> |
| In reply to | #25009 |
On 8/26/2012 4:57 AM, 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
> 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).
>
>
IMHO:
C++ could adopt C99 or C11 as its C subset (and make "void *" support
implicit conversion to other pointer types, formally allow "#include
<stdio.h>" and friends, adopt the "((void *)0)" definition of NULL, ...);
and C could discourage use of C++ reserved words as identifiers, or
maybe even have compilers generate warnings about it ("Foo *this;" ->
"warning: 'this' is a reserved word in C++", ...).
similarly, when possible/reasonable, APIs could be defined in C-friendly
ways, such that it is not necessary to have redundant versions of an
API, so the C API is the canonical one, and the C++ version is mostly
just syntax sugar (wrapper classes and templates).
or such...
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <Casey@Carter.net> |
|---|---|
| Date | 2012-08-27 21:47 -0500 |
| Message-ID | <k1hbfo$7ae$1@dont-email.me> |
| In reply to | #25050 |
On 2012-08-26 21:08, BGB wrote: > IMHO: > C++ could adopt C99 or C11 as its C subset (and make "void *" support > implicit conversion to other pointer types, formally allow "#include > <stdio.h>" and friends, adopt the "((void *)0)" definition of NULL, ...); C++ _does_ formally allow "include <stdio.h>". <XXX.h> defines the same set of entities as <cXXX>, except that <cXXX> provides them in namespace std (and optionally the global namespace), whereas <XXX.h> provides them in the global namespace (and optionally in namespace std). See 17.6.1.2 and Appendix D.5 in C++11. Definition of NULL as ((void*)0) is contingent on the implicit conversion of void* to other pointer types. 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)); ). 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, (b) C drop the implicit conversion from void*, and (c) both languages use a new distinct type that can implicitly convert to any pointer type. 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.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-08-27 22:34 -0500 |
| Message-ID | <k1hee9$ohv$1@news.albasani.net> |
| In reply to | #25172 |
On 8/27/2012 9:47 PM, Casey Carter wrote:
> On 2012-08-26 21:08, BGB wrote:
>> IMHO:
>> C++ could adopt C99 or C11 as its C subset (and make "void *" support
>> implicit conversion to other pointer types, formally allow "#include
>> <stdio.h>" and friends, adopt the "((void *)0)" definition of NULL, ...);
>
> C++ _does_ formally allow "include <stdio.h>". <XXX.h> defines the same
> set of entities as <cXXX>, except that <cXXX> provides them in namespace
> std (and optionally the global namespace), whereas <XXX.h> provides them
> in the global namespace (and optionally in namespace std). See 17.6.1.2
> and Appendix D.5 in C++11.
>
fair enough, I had thought it was more like, "cwhatever" was the
"standard" way in C++ land, and "whatever.h" was "just something that
happens to work".
admittedly, I have not really dug much into the C++ standard (I have
looked considerably more into the C standard here).
> 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.
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).
> 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 *".
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 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, ...).
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 09:27 +0200 |
| Message-ID | <503C72FA.2090109@loria.fr> |
| In reply to | #25175 |
Am 28.08.2012 05:34, schrieb BGB:
> On 8/27/2012 9:47 PM, Casey Carter wrote:
>> 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, ...).
yes!
That said, I don't really see the point of "void*" as it is in C++
nowadays. Since you'd have to do an explicit conversion any time you
use it, in C++ it has nothing that couldn't be done with a "unsigned
char*". In the contrary, "unsigned char*" allows byte based pointer
arithmetic and to inspect the contents on a byte base.
The only reason, I think, for "void*" is interface compability to
C. Somehow it misses the whole point of it.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <casey_at_carter_dot_net@nospam.invalid> |
|---|---|
| Date | 2012-08-28 12:24 -0500 |
| Message-ID | <k1ius0$4mr$1@dont-email.me> |
| In reply to | #25198 |
On 2012-08-28 02:27, Jens Gustedt wrote: > That said, I don't really see the point of "void*" as it is in C++ > nowadays. Since you'd have to do an explicit conversion any time you > use it, in C++ it has nothing that couldn't be done with a "unsigned > char*". In the contrary, "unsigned char*" allows byte based pointer > arithmetic and to inspect the contents on a byte base. > > The only reason, I think, for "void*" is interface compability to > C. Somehow it misses the whole point of it. > > Jens > The point of a type system is to restrict what operations are valid, so void* is desirable in C++ precisely because there are _fewer_ things you can do with it than unsigned char*.
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web