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 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 21:02 +0200 |
| Message-ID | <503D15B1.2050501@loria.fr> |
| In reply to | #25264 |
Am 28.08.2012 19:24, schrieb Casey Carter:
> 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,
sure
> so void* is desirable in C++ precisely because there are _fewer_
> things you can do with it than unsigned char*.
my question would be more, why would you need it at all? Where does
the idea of having a pointer that has no type information occur in
C++? In C++ all objects have a type from their creation ("new" always
generates a typed object) and all other stuff is regulated through the
different forms of cast, inheritence and all that. If you want to do
it really badly, you'd do a reintrepret_cast anyhow, no need to go
through "void*", no? I think C++ itself doesn't need "void*" much and
the use of it is rightly frowned upon in C++. (Well there are some
very restricted corner cases such as overloading "operator new" or
things like that.)
You need "void*" when you use "malloc" or other stuff for
compatibility with C. So why the hell have it function differently in
C++? This is just an inconvenience / annoyance.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bop@gmb.dk> |
|---|---|
| Date | 2012-08-28 21:15 +0200 |
| Message-ID | <aa4jnaFro9U1@mid.individual.net> |
| In reply to | #25279 |
Jens Gustedt wrote 2012-08-28 21:02: > > You need "void*" when you use "malloc" or other stuff for > compatibility with C. So why the hell have it function differently in > C++? This is just an inconvenience / annoyance. > No, it was done on purpose. If you write MyClass* x = malloc(sizeof(MyClass)); you are in real trouble, because you forgot to call the constructor of MyClass. You really don't want to have that conversion by default. In C this is less of a problem, because there is no constructor anyway. Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 23:00 +0200 |
| Message-ID | <503D3160.5080103@loria.fr> |
| In reply to | #25283 |
Am 28.08.2012 21:15, schrieb Bo Persson: > Jens Gustedt wrote 2012-08-28 21:02: > >> >> You need "void*" when you use "malloc" or other stuff for >> compatibility with C. So why the hell have it function differently in >> C++? This is just an inconvenience / annoyance. >> > > No, it was done on purpose. > > If you write > > MyClass* x = malloc(sizeof(MyClass)); > > you are in real trouble, because you forgot to call the constructor of > MyClass. You really don't want to have that conversion by default. exactly that was my point. But the problem is not that "malloc" has a return type of "void*" the problem is the use of "malloc" itself. Don't shoot the messenger. In C++, somebody using "malloc" is on his own. Casting to the target pointer type is even more of a problem, because it is just hiding the fact that you didn't call a constructor. You got to be very sure of what you are doing, anyhow. Requesting that you should cast the "void*" is counterproductive. A "strict C++" mode that barks at you for any use of "malloc", *that* would be appropriate. I'd still like to hear of a plausible use case for "void*" in C++ that is not related to C compability or to the overloading of "operator new". Jens
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2012-08-28 23:12 +0200 |
| Message-ID | <k1jc78$t2m$2@news.albasani.net> |
| In reply to | #25299 |
On Tue, 28 Aug 2012 23:00:16 +0200 Jens Gustedt <jens.gustedt@loria.fr> wrote: > > I'd still like to hear of a plausible use case for "void*" in C++ that > is not related to C compability or to the overloading of "operator > new". > Well, when implementing template container for pointers, it is great optimization to use just single class specialized for pointers to void, and cast to appropriate pointer type in specialized classes, while using single implementation. It greatly reduces code size.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 17:30 -0400 |
| Message-ID | <503D3873.9040302@verizon.net> |
| In reply to | #25302 |
On 08/28/2012 05:12 PM, Melzzzzz wrote: > On Tue, 28 Aug 2012 23:00:16 +0200 > Jens Gustedt <jens.gustedt@loria.fr> wrote: > >> >> I'd still like to hear of a plausible use case for "void*" in C++ that >> is not related to C compability or to the overloading of "operator >> new". >> > Well, when implementing template container for pointers, it is great > optimization to use just single class specialized for pointers to void, > and cast to appropriate pointer type in specialized classes, > while using single implementation. > It greatly reduces code size. Given that C++ doesn't allow implicit conversions from void*, char* can be just about as good as void* for that kind of purpose.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2012-08-28 23:38 +0200 |
| Message-ID | <k1jdon$t2m$4@news.albasani.net> |
| In reply to | #25309 |
On Tue, 28 Aug 2012 17:30:27 -0400 James Kuyper <jameskuyper@verizon.net> wrote: > On 08/28/2012 05:12 PM, Melzzzzz wrote: > > On Tue, 28 Aug 2012 23:00:16 +0200 > > Jens Gustedt <jens.gustedt@loria.fr> wrote: > > > >> > >> I'd still like to hear of a plausible use case for "void*" in C++ > >> that is not related to C compability or to the overloading of > >> "operator new". > >> > > Well, when implementing template container for pointers, it is great > > optimization to use just single class specialized for pointers to > > void, and cast to appropriate pointer type in specialized classes, > > while using single implementation. > > It greatly reduces code size. > > Given that C++ doesn't allow implicit conversions from void*, char* > can be just about as good as void* for that kind of purpose. > True... Only thing useful is that one don't have to cast when converting to void*, so it's halfway there ;)
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <casey_at_carter_dot_net@nospam.invalid> |
|---|---|
| Date | 2012-08-29 10:09 -0500 |
| Message-ID | <k1lbat$d8b$1@dont-email.me> |
| In reply to | #25309 |
On 2012-08-28 16:30, James Kuyper wrote: > On 08/28/2012 05:12 PM, Melzzzzz wrote: >> On Tue, 28 Aug 2012 23:00:16 +0200 >> Jens Gustedt <jens.gustedt@loria.fr> wrote: >> >>> >>> I'd still like to hear of a plausible use case for "void*" in C++ that >>> is not related to C compability or to the overloading of "operator >>> new". >>> >> Well, when implementing template container for pointers, it is great >> optimization to use just single class specialized for pointers to void, >> and cast to appropriate pointer type in specialized classes, >> while using single implementation. >> It greatly reduces code size. > > Given that C++ doesn't allow implicit conversions from void*, char* can > be just about as good as void* for that kind of purpose. > The standard requires that casting from any object pointer type to void* and back preserves the original pointer value (5.2.9/13). That guarantee is not present for any other pointer type.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-29 18:01 +0200 |
| Message-ID | <503E3CDD.4020802@loria.fr> |
| In reply to | #25393 |
Am 29.08.2012 17:09, schrieb Casey Carter: > On 2012-08-28 16:30, James Kuyper wrote: >> On 08/28/2012 05:12 PM, Melzzzzz wrote: >>> On Tue, 28 Aug 2012 23:00:16 +0200 >>> Jens Gustedt <jens.gustedt@loria.fr> wrote: >>> >>>> >>>> I'd still like to hear of a plausible use case for "void*" in C++ that >>>> is not related to C compability or to the overloading of "operator >>>> new". >>>> >>> Well, when implementing template container for pointers, it is great >>> optimization to use just single class specialized for pointers to void, >>> and cast to appropriate pointer type in specialized classes, >>> while using single implementation. >>> It greatly reduces code size. >> >> Given that C++ doesn't allow implicit conversions from void*, char* can >> be just about as good as void* for that kind of purpose. >> > > The standard requires that casting from any object pointer type to void* > and back preserves the original pointer value (5.2.9/13). right. > That guarantee is not present for any other pointer type. That is wrong. It also says (this is from C11 but I suppose that C++11 should have something similar): A pointer to void shall have the same representation and alignment requirements as a pointer to a character type. It also says A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer. So at least in C there is no problem in converting back and forth to "unsigned char*". (Alignment is not a problem, since "char" types have the weakest alignment requirements.) So the same guarantee as you mention above for "void*" also holds for all character pointer types. +++++ In any case, the use cases for "void*" in C++ haven't convinced me much, yet. I still think that usage of "void*" is peripheral to C++ and mostly there to ensure interface compatibility with C. Veritable C++ code that uses "void*" to implement say the common core of a template library is not very clear with itself. For me such things look more that the implementation of such a core would better be done with the right tool. In the same way as it is sometimes appropriate to use some inline assembler from C, it should be more common praxis to use just pure C for the implementation of some type agnostic core functionality. Jens
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-29 12:03 -0400 |
| Message-ID | <503E3D48.7000907@verizon.net> |
| In reply to | #25393 |
On 08/29/2012 11:09 AM, Casey Carter wrote: > On 2012-08-28 16:30, James Kuyper wrote: ... >> Given that C++ doesn't allow implicit conversions from void*, char* can >> be just about as good as void* for that kind of purpose. >> > > The standard requires that casting from any object pointer type to void* > and back preserves the original pointer value (5.2.9/13). That guarantee > is not present for any other pointer type. Section 6.3.2.3p7 of the C standard says: "When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object." It says nothing about the reverse conversion, however. In general, such a requirement would be inconsistent with the C++ object model, but I'm surprised at being unable to find a corresponding guarantee in the C++ standard for some restricted category of types, such as "trivially copyable" or "standard layout" types.
[toc] | [prev] | [next] | [standalone]
| From | Dombo <dombo@disposable.invalid> |
|---|---|
| Date | 2012-09-02 22:58 +0200 |
| Message-ID | <k20h5i$qhb$1@dont-email.me> |
| In reply to | #25302 |
Op 28-Aug-12 23:12, Melzzzzz schreef: > On Tue, 28 Aug 2012 23:00:16 +0200 > Jens Gustedt <jens.gustedt@loria.fr> wrote: > >> >> I'd still like to hear of a plausible use case for "void*" in C++ that >> is not related to C compability or to the overloading of "operator >> new". >> > Well, when implementing template container for pointers, it is great > optimization to use just single class specialized for pointers to void, > and cast to appropriate pointer type in specialized classes, > while using single implementation. > It greatly reduces code size. It *may* greatly reduce code size, if the compiler doesn't do this optimization (sharing implementation of pointer templates) already for you.
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <casey_at_carter_dot_net@nospam.invalid> |
|---|---|
| Date | 2012-08-28 16:25 -0500 |
| Message-ID | <k1jd0q$32a$1@dont-email.me> |
| In reply to | #25299 |
On 2012-08-28 16:00, Jens Gustedt wrote: > Am 28.08.2012 21:15, schrieb Bo Persson: >> Jens Gustedt wrote 2012-08-28 21:02: >> >>> >>> You need "void*" when you use "malloc" or other stuff for >>> compatibility with C. So why the hell have it function differently in >>> C++? This is just an inconvenience / annoyance. >>> >> >> No, it was done on purpose. >> >> If you write >> >> MyClass* x = malloc(sizeof(MyClass)); >> >> you are in real trouble, because you forgot to call the constructor of >> MyClass. You really don't want to have that conversion by default. > > exactly that was my point. But the problem is not that "malloc" has a > return type of "void*" the problem is the use of "malloc" > itself. Don't shoot the messenger. > > In C++, somebody using "malloc" is on his own. Casting to the target > pointer type is even more of a problem, because it is just hiding the > fact that you didn't call a constructor. You got to be very sure of > what you are doing, anyhow. > > Requesting that you should cast the "void*" is counterproductive. A > "strict C++" mode that barks at you for any use of "malloc", *that* > would be appropriate. malloc is not the only function - standard or otherwise - that returns a void*. Are you suggesting that C++ should forbid malloc, or that C++ should forbid void*, or that C++ should have some other type whose only purpose is to represent void* returns from C functions?
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 23:58 +0200 |
| Message-ID | <503D3EFF.5020706@loria.fr> |
| In reply to | #25305 |
Am 28.08.2012 23:25, schrieb Casey Carter:
> On 2012-08-28 16:00, Jens Gustedt wrote:
>> Requesting that you should cast the "void*" is counterproductive. A
>> "strict C++" mode that barks at you for any use of "malloc", *that*
>> would be appropriate.
>
> malloc is not the only function - standard or otherwise - that returns a
> void*.
In the C11 standard I found:
void *aligned_alloc(size_t alignment, size_t size);
void *calloc(size_t nmemb, size_t size);
void *malloc(size_t size);
void *realloc(void *ptr, size_t size);
void *memcpy(void * restrict s1, const void * restrict s2, size_t n);
void *memmove(void *s1, const void *s2, size_t n);
void *memchr(const void *s, int c, size_t n);
void *memset(void *s, int c, size_t n);
void *bsearch(const void *key, const void *base,
size_t nmemb, size_t size,
int (*compar)(const void *, const void *));
void *bsearch_s(const void *key, const void *base,
rsize_t nmemb, rsize_t size,
int (*compar)(const void *k, const void *y, void *context),
void *context);
void *tss_get(tss_t key);
Maybe I overlooked something, possible, but these are not really a
lot, and nothing which would be considered good style to be used in
C++, I think.
> Are you suggesting that C++ should forbid malloc, or that C++
> should forbid void*, or that C++ should have some other type whose only
> purpose is to represent void* returns from C functions?
That it'd leave "void*" alone and uses it as it was originally defined
in C. It just makes no sense. Somebody that uses C memory functions is
beyond the red line anyhow. Requiring a cast here is just useless, and
is not adding to compability, but the contrary.
Use "unsigned char*" instead, when you feel the need of an untyped
pointer inside C++, which should be rare in C++, anyhow.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-08-28 23:03 +0100 |
| Message-ID | <mMSdnTZvUeek3aDNnZ2dnUVZ8hadnZ2d@giganews.com> |
| In reply to | #25317 |
On 28/08/2012 22:58, Jens Gustedt wrote: > Am 28.08.2012 23:25, schrieb Casey Carter: >> Are you suggesting that C++ should forbid malloc, or that C++ >> should forbid void*, or that C++ should have some other type whose only >> purpose is to represent void* returns from C functions? > > That it'd leave "void*" alone and uses it as it was originally defined > in C. It just makes no sense. Somebody that uses C memory functions is > beyond the red line anyhow. Requiring a cast here is just useless, and > is not adding to compability, but the contrary. > > Use "unsigned char*" instead, when you feel the need of an untyped > pointer inside C++, which should be rare in C++, anyhow. What utter nonsense mate. Use void* not unsigned char* for untyped pointers in C++. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-29 08:02 +0200 |
| Message-ID | <503DB06C.6070404@loria.fr> |
| In reply to | #25319 |
Am 29.08.2012 00:03, schrieb Leigh Johnston: > On 28/08/2012 22:58, Jens Gustedt wrote: >> Am 28.08.2012 23:25, schrieb Casey Carter: >>> Are you suggesting that C++ should forbid malloc, or that C++ >>> should forbid void*, or that C++ should have some other type whose only >>> purpose is to represent void* returns from C functions? >> >> That it'd leave "void*" alone and uses it as it was originally defined >> in C. It just makes no sense. Somebody that uses C memory functions is >> beyond the red line anyhow. Requiring a cast here is just useless, and >> is not adding to compability, but the contrary. >> >> Use "unsigned char*" instead, when you feel the need of an untyped >> pointer inside C++, which should be rare in C++, anyhow. > > What utter nonsense mate. That could well be possible. Did you read the previous discussion? Otherwise your statement doesn't qualify for much more intelligence than mine. I just would prefered to have a reason that goes beyond something like "we tradionally use void* like this". I still didn't get a consistent reply why "void*" is needed in C++ (but for compability with C and for "operator new"). It still seems that such discussions aren't possible and that at least some people just react with ideology. > Use void* not unsigned char* for untyped pointers in C++. What higher entity revealed you that commandment? Jens
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <casey_at_carter_dot_net@nospam.invalid> |
|---|---|
| Date | 2012-08-29 10:12 -0500 |
| Message-ID | <k1lbhn$d8b$2@dont-email.me> |
| In reply to | #25353 |
On 2012-08-29 01:02, Jens Gustedt wrote: >> Use void* not unsigned char* for untyped pointers in C++. > > What higher entity revealed you that commandment? > > Jens > ISO 14882-2011 5.2.9/13 (static_cast) says: ...A value of type pointer to object converted to "pointer to cv void" and back, possibly with a different cv-qualification, shall have its original value.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-29 20:36 +0200 |
| Message-ID | <503E6134.5050000@loria.fr> |
| In reply to | #25395 |
Am 29.08.2012 17:12, schrieb Casey Carter: > On 2012-08-29 01:02, Jens Gustedt wrote: >>> Use void* not unsigned char* for untyped pointers in C++. >> >> What higher entity revealed you that comamandment? >> >> Jens >> > > ISO 14882-2011 5.2.9/13 (static_cast) says: > > ...A value of type pointer to object converted to "pointer to cv void" > and back, possibly with a different cv-qualification, shall have its > original value. C has a similar phrase. But that only states that you may use "void*". It doesn't state that you can't use any other. Or you read here something like "thou shalt only use void* for low level implementations" ? In C at least, any object pointer can be cast back and forth to any other object pointer and there is only UB if there are alignment problems. "unsigned char*" always has the least possible alignment so you can basically use it for that (or any of the two other character types). And traditionally in early C (and C++ also, I suppose) it had been "char*". Jens
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-08-29 12:08 -0500 |
| Message-ID | <k1lig4$b99$1@news.albasani.net> |
| In reply to | #25353 |
On 8/29/2012 1:02 AM, Jens Gustedt wrote:
> Am 29.08.2012 00:03, schrieb Leigh Johnston:
>> On 28/08/2012 22:58, Jens Gustedt wrote:
>>> Am 28.08.2012 23:25, schrieb Casey Carter:
>>>> Are you suggesting that C++ should forbid malloc, or that C++
>>>> should forbid void*, or that C++ should have some other type whose only
>>>> purpose is to represent void* returns from C functions?
>>>
>>> That it'd leave "void*" alone and uses it as it was originally defined
>>> in C. It just makes no sense. Somebody that uses C memory functions is
>>> beyond the red line anyhow. Requiring a cast here is just useless, and
>>> is not adding to compability, but the contrary.
>>>
>>> Use "unsigned char*" instead, when you feel the need of an untyped
>>> pointer inside C++, which should be rare in C++, anyhow.
>>
>> What utter nonsense mate.
>
> That could well be possible. Did you read the previous discussion?
> Otherwise your statement doesn't qualify for much more intelligence
> than mine.
>
> I just would prefered to have a reason that goes beyond something like
> "we tradionally use void* like this". I still didn't get a consistent
> reply why "void*" is needed in C++ (but for compability with C and for
> "operator new").
>
compatibility with C would be the main thing here.
if the languages were merged, presumably everyone on both sides would
want their code to still work, preferably unmodified.
if it were a case where most existing C code broke, people wouldn't be
happy, and would just stay with C.
if it were a case where C++ were broke, then C++ people wouldn't be
happy, and would just stick with C++.
like, say, what if we renamed all of C++'s keywords, and made them
special defines where you had to include headers to enable them:
#include <stdclass.h>
#include <stdtemplate.h>
...
class Foo:IBar { ... };
otherwise it was just _Class and _Template and _Namespace and similar?...
a person could just be like "well, it is a trivial change, but go add
these here includes to every source-file and header which uses C++
related extensions".
as well as possibly needing a keyword for overloaded functions:
overload int foo(int x) { ... }
overload int foo(double x) { ... }
...
to be like "hey, this one might need name mangling!"
and, maybe classes are defined to have a strict mapping to structs
similar to that of COM objects, ...
it would likely be a no-go for C++ developers as well.
even if it were something as minor as adding:
#include <stdcplusplus.h>
to just a few files...
so, a compromise would likely be needed on many points.
> It still seems that such discussions aren't possible and that at least
> some people just react with ideology.
>
hopefully, I think at least I am more thinking in terms of being
pragmatic, even if, yes, such a merge is unlikely.
IMO, it is more the place of a language to provide a set of mechanisms,
not enforce any particular mindset or ideology.
>> Use void* not unsigned char* for untyped pointers in C++.
>
> What higher entity revealed you that commandment?
>
ironically, I do remember seeing C++ code in the past using "char *" for
many things which C people would normally use "void *" for.
"void *" makes a few stronger guarantees, which may be something at least.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-29 13:49 -0400 |
| Message-ID | <503E563A.60403@verizon.net> |
| In reply to | #25403 |
On 08/29/2012 01:08 PM, BGB wrote: ... > ironically, I do remember seeing C++ code in the past using "char *" for > many things which C people would normally use "void *" for. > > "void *" makes a few stronger guarantees, which may be something at least. In C, there's trade-off: [[un]signed]char* can be dereferenced and supports pointer arithmetic, while void* allows implicit conversion to and from other types. That makes void* the appropriate type for pointers to objects of unspecified types, and unsigned char* the appropriate type for treating an object as if it were an uninterpreted array of bytes. C++ templates replace the need to treat objects of unspecified types with the ability to treat objects of arbitrary type. Removing the implicit conversion from void* to T* removes some (but not quite all) of the remaining value of supporting void*.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-08-29 19:16 +0100 |
| Message-ID | <MIOdnarQbN_kwaPNnZ2dnUVZ8r6dnZ2d@giganews.com> |
| In reply to | #25407 |
On 29/08/2012 18:49, James Kuyper wrote: > On 08/29/2012 01:08 PM, BGB wrote: > ... >> ironically, I do remember seeing C++ code in the past using "char *" for >> many things which C people would normally use "void *" for. >> >> "void *" makes a few stronger guarantees, which may be something at least. > > In C, there's trade-off: [[un]signed]char* can be dereferenced and > supports pointer arithmetic, while void* allows implicit conversion to > and from other types. That makes void* the appropriate type for pointers > to objects of unspecified types, and unsigned char* the appropriate type > for treating an object as if it were an uninterpreted array of bytes. > > C++ templates replace the need to treat objects of unspecified types > with the ability to treat objects of arbitrary type. Removing the > implicit conversion from void* to T* removes some (but not quite all) of > the remaining value of supporting void*. char* is .. wait for it .. a pointer to char; void* is .. wait for it .. a pointer to anything; this has not changed from C to C++. The lack of implicit conversion *from* void* does not change the utility of void*. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-29 14:34 -0400 |
| Message-ID | <503E60D0.7040702@verizon.net> |
| In reply to | #25409 |
On 08/29/2012 02:16 PM, Leigh Johnston wrote: ... > ... The lack of > implicit conversion *from* void* does not change the utility of void*. In C, implicit conversion to and from void* is the only feature that void* has that justifies using it instead unsigned char*. In C++, half of those implicit conversions are missing, and no compensating advantage has been added to void*. How could it NOT change the utility?
[toc] | [prev] | [next] | [standalone]
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web