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 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-31 11:27 +0200 |
| Message-ID | <P5GdnWFfH-QqHt3NnZ2dnUVZ7vudnZ2d@lyse.net> |
| In reply to | #25557 |
On 30/08/2012 19:57, James Kuyper wrote: > On 08/30/2012 08:54 AM, David Brown wrote: >> On 30/08/2012 14:05, James Kuyper wrote: >>> On 08/30/2012 03:47 AM, David Brown wrote: >>>> On 29/08/2012 20:34, James Kuyper wrote: >>> ... >>>>> 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? >>>>> >>>> >>>> You skipped the important part of Leigh's post - "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++." >>>> >>>> If you write in your code "char* p", you are saying that "p is a pointer >>>> to a character or a list of characters". If you write "void* p", you >>>> are saying that "p points to something which could be anything". >>> >>> Yes, I skipped that, because I considered it an unimportant and silly >>> distinction. It's the functional differences between char* and void* >>> that render void* the appropriate way to store a pointer of unknown >>> type; remove those functional differences, and I wouldn't bother using >>> 'void*' rather than 'char*' just because 'void*' documents a supposedly >>> different meaning. My point being that C++ lacks some (though not yet >>> all) of the functional differences that C has between those two types. >>> >>>> These are different things. It really doesn't matter how these are >>>> implemented, and what casts can be done implicitly or explicitly - they >>>> /say/ different things. >>> >>> If they were functionally equivalent, the fact that they had different >>> names wouldn't mean that they actually say anything different, however >>> much you might want to think otherwise. >>> >> >> That is obviously incorrect. A comment is functionally equivalent to >> white space - are you suggesting that comments do not "say" anything in >> source code? > > Comments are for talking with other humans; the active part of the > language is for talking to the compiler. The active part of the language is for talking to the compiler /and/ humans. That is the reason we have typedefs, and the reason we give variables useful names rather than "i1", "i2", etc. > If the differences, for the > compiler, between 'void*' and 'char*' were reduced to a matter of how > they were spelled, I would not recommend using that spelling to convey > meaningful information to any humans who were reading the code. If you don't think "void*" and "char*" convey a different meaning to humans, then I see your point. IMHO, they /do/ convey a different meaning - so they have different usage even if they had identical functional meaning. > > This assertion is somewhat inconsistent with the fact that I have chosen > to use distinctions between other equivalent constructs to convey actual > meanings. For instance, when writing function declarations in C, I use T > *parameter_name to represent a pointer to a single object, and T > parameter_name[] when it is a pointer to the first in a series of > objects (in C++ I would use a reference for the first purpose). > > I'll not bother to try and excuse the inconsistency; I'll just say that > the pointer parameter thing feels harmless to me, whereas I feel a > strong antipathy about removing the distinctions between void* and char* > (I really dislike the gnu extension that allows pointer arithmetic on > void*). > There is nothing wrong with a bit of inconsistency here and there - you don't want your style rules to be /too/ rigid!
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-08-31 11:58 -0500 |
| Message-ID | <k1qqm2$bnb$1@news.albasani.net> |
| In reply to | #25625 |
On 8/31/2012 4:27 AM, David Brown wrote:
> On 30/08/2012 19:57, James Kuyper wrote:
>> On 08/30/2012 08:54 AM, David Brown wrote:
>>> On 30/08/2012 14:05, James Kuyper wrote:
>>>> On 08/30/2012 03:47 AM, David Brown wrote:
>>>>> On 29/08/2012 20:34, James Kuyper wrote:
>>>> ...
>>>>>> 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?
>>>>>>
>>>>>
>>>>> You skipped the important part of Leigh's post - "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++."
>>>>>
>>>>> If you write in your code "char* p", you are saying that "p is a
>>>>> pointer
>>>>> to a character or a list of characters". If you write "void* p", you
>>>>> are saying that "p points to something which could be anything".
>>>>
>>>> Yes, I skipped that, because I considered it an unimportant and silly
>>>> distinction. It's the functional differences between char* and void*
>>>> that render void* the appropriate way to store a pointer of unknown
>>>> type; remove those functional differences, and I wouldn't bother using
>>>> 'void*' rather than 'char*' just because 'void*' documents a supposedly
>>>> different meaning. My point being that C++ lacks some (though not yet
>>>> all) of the functional differences that C has between those two types.
>>>>
>>>>> These are different things. It really doesn't matter how these are
>>>>> implemented, and what casts can be done implicitly or explicitly -
>>>>> they
>>>>> /say/ different things.
>>>>
>>>> If they were functionally equivalent, the fact that they had different
>>>> names wouldn't mean that they actually say anything different, however
>>>> much you might want to think otherwise.
>>>>
>>>
>>> That is obviously incorrect. A comment is functionally equivalent to
>>> white space - are you suggesting that comments do not "say" anything in
>>> source code?
>>
>> Comments are for talking with other humans; the active part of the
>> language is for talking to the compiler.
>
> The active part of the language is for talking to the compiler /and/
> humans. That is the reason we have typedefs, and the reason we give
> variables useful names rather than "i1", "i2", etc.
>
(partial ironic satire):
but what if i, j, and k are already used up?
i0/i1/i2/i3, j0/j1/j2/j3, and k0/k1/k2/k3, can effectively get 4x (or
5x) as many integer-variables from the same letters...
then there may be {li/lj/lk}{0/1/2/3} for long-long variables,
{a/b/c/d}{0/1/2/3} for doubles, {f/g/h}{0/1/2/3} for floats, ...
>> If the differences, for the
>> compiler, between 'void*' and 'char*' were reduced to a matter of how
>> they were spelled, I would not recommend using that spelling to convey
>> meaningful information to any humans who were reading the code.
>
> If you don't think "void*" and "char*" convey a different meaning to
> humans, then I see your point. IMHO, they /do/ convey a different
> meaning - so they have different usage even if they had identical
> functional meaning.
>
in a lot of GCC compiled code, they are not too far off.
me remembering sometimes porting code from GCC and having to often
convert "void *" to "byte *" (typedef'ed "unsigned char") or similar to
make it work.
>>
>> This assertion is somewhat inconsistent with the fact that I have chosen
>> to use distinctions between other equivalent constructs to convey actual
>> meanings. For instance, when writing function declarations in C, I use T
>> *parameter_name to represent a pointer to a single object, and T
>> parameter_name[] when it is a pointer to the first in a series of
>> objects (in C++ I would use a reference for the first purpose).
>>
>> I'll not bother to try and excuse the inconsistency; I'll just say that
>> the pointer parameter thing feels harmless to me, whereas I feel a
>> strong antipathy about removing the distinctions between void* and char*
>> (I really dislike the gnu extension that allows pointer arithmetic on
>> void*).
>>
>
> There is nothing wrong with a bit of inconsistency here and there - you
> don't want your style rules to be /too/ rigid!
>
better IMO to be like "whatever makes the most sense at the moment".
as long as there is at least some semblance of consistency, then it is
probably good enough.
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2012-09-01 19:09 +0200 |
| Message-ID | <50423fb7$0$13280$4fafbaef@reader2.news.tin.it> |
| In reply to | #25625 |
"David Brown" <david@westcontrol.removethisbit.com> ha scritto nel messaggio news:P5GdnWFfH-QqHt3NnZ2dnUVZ7vudnZ2d@lyse.net... > The active part of the language is for talking to the compiler /and/ humans. > That is the reason we have typedefs, and the reason we give variables useful > names rather than "i1", "i2", etc. > >> If the differences, for the >> compiler, between 'void*' and 'char*' were reduced to a matter of how >> they were spelled, I would not recommend using that spelling to convey >> meaningful information to any humans who were reading the code. > > If you don't think "void*" and "char*" convey a different meaning to humans, > then I see your point. IMHO, they /do/ convey a different meaning - so they > have different usage even if they had identical functional meaning. "void*" add only complexity to the language... the same "const" keyword the people propose this type are wrong... because make complex what is already simple... all can be done using unsigned char* or better uint8_t* etc as a general pointer to data Buon Giorno
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-29 20:49 +0200 |
| Message-ID | <503E6446.4020306@loria.fr> |
| In reply to | #25409 |
Am 29.08.2012 20:16, schrieb Leigh Johnston: > char* is .. wait for it .. a pointer to char; void* is .. wait for it .. > a pointer to anything; and so what is "char" for you? or "unsigned char". For me "unsigned char" is the smallest adressable storage unit for C and C++ programs that, for convenience, also has the property of an unsigned integer type such that we may inspect all of its bits. So pointer to "unsigned char" is a pointer to the smallest uninterpreted storage unit that the language(s) provide. > this has not changed from C to C++. The lack of > implicit conversion *from* void* does not change the utility of void*. For C programmers it does make "void*" useless. So implicitly you are claiming that it utility for C++ lays in that fact that any object pointer converts to "void*" even without a cast? (Without that all the C library function would be very cumbersome to use, indeed.) Do you often see a "void*" in a veritable C++ interface, I mean in one that could not be defined with 'extern "C"' and then entirely implemented in C? (and I don't mean it to be provocative, I really want to know) Jens
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-08-29 20:09 +0100 |
| Message-ID | <orGdnX2Y48VM9aPNnZ2dnUVZ8vSdnZ2d@giganews.com> |
| In reply to | #25417 |
On 29/08/2012 19:49, Jens Gustedt wrote: > Am 29.08.2012 20:16, schrieb Leigh Johnston: >> char* is .. wait for it .. a pointer to char; void* is .. wait for it .. >> a pointer to anything; > > and so what is "char" for you? or "unsigned char". For me "unsigned > char" is the smallest adressable storage unit for C and C++ programs > that, for convenience, also has the property of an unsigned integer > type such that we may inspect all of its bits. So pointer to "unsigned > char" is a pointer to the smallest uninterpreted storage unit that the > language(s) provide. Indeed you can use a char* pointer to "inspect" the representation of other objects; an array of char can even be used to placement new an object of any type but this has little to do with void*; void* is used when you want a pointer to any type; a round-trip cast via void* is well defined. > >> this has not changed from C to C++. The lack of >> implicit conversion *from* void* does not change the utility of void*. > > For C programmers it does make "void*" useless. So malloc is useless? > > So implicitly you are claiming that it utility for C++ lays in that > fact that any object pointer converts to "void*" even without a cast? The utility is that void* can be used as a pointer to an object of any type; it is not obvious that a char* pointer is pointing to anything other than a char (even if it can). > > (Without that all the C library function would be very cumbersome to > use, indeed.) > > Do you often see a "void*" in a veritable C++ interface, I mean in one > that could not be defined with 'extern "C"' and then entirely > implemented in C? > > (and I don't mean it to be provocative, I really want to know) Use void* when you need an untyped pointer; such needs exist in both C and C++. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-29 22:33 +0200 |
| Message-ID | <503E7C84.5000402@loria.fr> |
| In reply to | #25422 |
Am 29.08.2012 21:09, schrieb Leigh Johnston: > On 29/08/2012 19:49, Jens Gustedt wrote: >> Am 29.08.2012 20:16, schrieb Leigh Johnston: >>> this has not changed from C to C++. The lack of >>> implicit conversion *from* void* does not change the utility of void*. >> >> For C programmers it does make "void*" useless. > > So malloc is useless? not in C, where implicit conversion from "void*" works without problems or where you refering to C++? using malloc? doesn't that give you objects for which the constructor isn't called :) >> Do you often see a "void*" in a veritable C++ interface, I mean in one >> that could not be defined with 'extern "C"' and then entirely >> implemented in C? >> >> (and I don't mean it to be provocative, I really want to know) > > Use void* when you need an untyped pointer; such needs exist in both C > and C++. you don't answer my question, still no example for a real use case in C++, could you be more concrete? Jens
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-08-29 21:43 +0100 |
| Message-ID | <PLmdnSb0GvJr46PNnZ2dnUVZ8ludnZ2d@giganews.com> |
| In reply to | #25443 |
On 29/08/2012 21:33, Jens Gustedt wrote: > Am 29.08.2012 21:09, schrieb Leigh Johnston: >> On 29/08/2012 19:49, Jens Gustedt wrote: >>> Am 29.08.2012 20:16, schrieb Leigh Johnston: >>>> this has not changed from C to C++. The lack of >>>> implicit conversion *from* void* does not change the utility of void*. >>> >>> For C programmers it does make "void*" useless. >> >> So malloc is useless? > > not in C, where implicit conversion from "void*" works without > problems Ergo void* is not useless in C. > > or where you refering to C++? using malloc? doesn't that give you > objects for which the constructor isn't called :) I never use malloc in a C++ program. > >>> Do you often see a "void*" in a veritable C++ interface, I mean in one >>> that could not be defined with 'extern "C"' and then entirely >>> implemented in C? >>> >>> (and I don't mean it to be provocative, I really want to know) >> >> Use void* when you need an untyped pointer; such needs exist in both C >> and C++. > > you don't answer my question, still no example for a real use case in > C++, could you be more concrete? Example: a pointer to an object associated with in an item in a GUI list box widget. In the GUI library I am currently creating the list box widget is actually a template however the item data type defaults to void* as both a convenience and a way to reduce template bloat; however lots of GUI libraries solely use void* for such things (e.g. Microsoft Win32 API). Another example: an object pointer passed to /pthread_create/. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-29 23:23 +0200 |
| Message-ID | <503E886A.6060106@loria.fr> |
| In reply to | #25445 |
Am 29.08.2012 22:43, schrieb Leigh Johnston: > On 29/08/2012 21:33, Jens Gustedt wrote: >> Am 29.08.2012 21:09, schrieb Leigh Johnston: >>> On 29/08/2012 19:49, Jens Gustedt wrote: >>>> Am 29.08.2012 20:16, schrieb Leigh Johnston: >>>>> this has not changed from C to C++. The lack of >>>>> implicit conversion *from* void* does not change the utility of void*. >>>> >>>> For C programmers it does make "void*" useless. >>> >>> So malloc is useless? >> >> not in C, where implicit conversion from "void*" works without >> problems > > Ergo void* is not useless in C. Where did you read that? I didn't say that. I am just, almost desperately seeking someone who wants to present me with a real use case in C++. It has a lot of good use cases in C. It would lose most of its use in C, if it wouldn't implicitly convert to any other pointer to object type. >> or where you refering to C++? using malloc? doesn't that give you >> objects for which the constructor isn't called :) > > I never use malloc in a C++ program. see >> you don't answer my question, still no example for a real use case in >> C++, could you be more concrete? > > Example: a pointer to an object associated with in an item in a GUI list > box widget. In the GUI library I am currently creating the list box > widget is actually a template however the item data type defaults to > void* as both a convenience and a way to reduce template bloat; however > lots of GUI libraries solely use void* for such things (e.g. Microsoft > Win32 API). Then they are no good C++. These things can be done in C++ without any loss of performance and with much more type safety by using templates, inheritance, all that machinery. So you gave me an example where "void*" encourages bad design, is that? My claim would be that *if* you want to play such "dirty tricks" create a proper interface and then program the beast itself in C. > Another example: an object pointer passed to /pthread_create/. That doesn't count, pthread_create (or better the new and shiny thrd_create) are C interfaces. They are designed as such. That is not a proper use case for C++. Jens
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <casey_at_carter_dot_net@nospam.invalid> |
|---|---|
| Date | 2012-08-29 17:21 -0500 |
| Message-ID | <k1m4le$obq$1@dont-email.me> |
| In reply to | #25451 |
On 2012-08-29 16:23, Jens Gustedt wrote: > That doesn't count, pthread_create (or better the new and shiny > thrd_create) are C interfaces. They are designed as such. That is not > a proper use case for C++. Ok, how should I pass data through pthread_create in C++ if you won't allow me to use void*? This discussion seems to be pointless when we give examples of use cases for void* in C++ and you respond with "that doesn't count." Perhaps you could better explain your criteria for what a valid use might be?
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-30 09:06 +0200 |
| Message-ID | <503F1113.3010803@loria.fr> |
| In reply to | #25457 |
Am 30.08.2012 00:21, schrieb Casey Carter: > On 2012-08-29 16:23, Jens Gustedt wrote: >> That doesn't count, pthread_create (or better the new and shiny >> thrd_create) are C interfaces. They are designed as such. That is not >> a proper use case for C++. > > Ok, how should I pass data through pthread_create in C++ if you won't > allow me to use void*? This is not what I said and what the discussion was about. The starting point was to seek proper use cases of "void*" for C++ that are not just interfacing to C. Sure that you should be able to call C functions, so you need "void*" there. Please give me *other* valid use cases. For the moment I only have been given - calling C interfaces - cases where "template bloat" (not my wording) made template solutions impractical Jens
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2012-08-30 13:53 +0000 |
| Message-ID | <lfK%r.1$y73.0@fe05.iad> |
| In reply to | #25513 |
Jens Gustedt <jens.gustedt@loria.fr> writes: >Am 30.08.2012 00:21, schrieb Casey Carter: >> On 2012-08-29 16:23, Jens Gustedt wrote: >>> That doesn't count, pthread_create (or better the new and shiny >>> thrd_create) are C interfaces. They are designed as such. That is not >>> a proper use case for C++. >> >> Ok, how should I pass data through pthread_create in C++ if you won't >> allow me to use void*? > >This is not what I said and what the discussion was about. The >starting point was to seek proper use cases of "void*" for C++ that >are not just interfacing to C. Sure that you should be able to call C >functions, so you need "void*" there. Please give me *other* valid use >cases. > >For the moment I only have been given > >- calling C interfaces >- cases where "template bloat" (not my wording) made template > solutions impractical > What about the existing massive volumes of C++ code which use void*? Particularly code that dates from the 80's when there was no STL?
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-30 18:51 +0200 |
| Message-ID | <503F99FA.4030906@loria.fr> |
| In reply to | #25539 |
Am 30.08.2012 15:53, schrieb Scott Lurndal: > Jens Gustedt <jens.gustedt@loria.fr> writes: >> Am 30.08.2012 00:21, schrieb Casey Carter: >>> On 2012-08-29 16:23, Jens Gustedt wrote: >>>> That doesn't count, pthread_create (or better the new and shiny >>>> thrd_create) are C interfaces. They are designed as such. That is not >>>> a proper use case for C++. >>> >>> Ok, how should I pass data through pthread_create in C++ if you won't >>> allow me to use void*? >> >> This is not what I said and what the discussion was about. The >> starting point was to seek proper use cases of "void*" for C++ that >> are not just interfacing to C. Sure that you should be able to call C >> functions, so you need "void*" there. Please give me *other* valid use >> cases. >> >> For the moment I only have been given >> >> - calling C interfaces >> - cases where "template bloat" (not my wording) made template >> solutions impractical >> > > What about the existing massive volumes of C++ code which use void*? Particularly > code that dates from the 80's when there was no STL? I don't completely get the sense of your question. You mean to take them as an example for uses cases? Or you want to emphasize that there would be a problem with old code? If (supposing that for a minute) C++ would align itself on the C usage of "void*" no old code would break, since this all does a cast to the target type, if I understand correctly. Then, also I would tend to say that C++ code from the 80's wouldn't compile with a modern compiler, anyhow. At least that is my narrow experience with C++. The big project I have written some years ago, still needs syntax adjustments at any major revision of g++. Possibly there would be some other possible solutions to get C and C++ closer on that point. But before thinking of solutions I first wanted to know if this corresponds to something real on the C++ side. I conclude for myself that the reality is that (besides interfacing with C) "void*" is less and less useful in C++. And that declaring variables of type "void*" and manipulating them (and the objects they represent) should be more considered the "C side" of the game. Jens
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-08-31 21:15 -0500 |
| Message-ID | <k1rqpl$il2$2@dont-email.me> |
| In reply to | #25539 |
Scott Lurndal wrote: > Jens Gustedt <jens.gustedt@loria.fr> writes: >> Am 30.08.2012 00:21, schrieb Casey Carter: >>> On 2012-08-29 16:23, Jens Gustedt wrote: >>>> That doesn't count, pthread_create (or better the new and shiny >>>> thrd_create) are C interfaces. They are designed as such. That is not >>>> a proper use case for C++. >>> >>> Ok, how should I pass data through pthread_create in C++ if you won't >>> allow me to use void*? >> >> This is not what I said and what the discussion was about. The >> starting point was to seek proper use cases of "void*" for C++ that >> are not just interfacing to C. Sure that you should be able to call C >> functions, so you need "void*" there. Please give me *other* valid use >> cases. >> >> For the moment I only have been given >> >> - calling C interfaces >> - cases where "template bloat" (not my wording) made template >> solutions impractical >> > > What about the existing massive volumes of C++ code which use void*? Particularly > code that dates from the 80's when there was no STL? > So use the old compiler. Check *everything* in to the CM system; ideally you can run a script that'll check it out, install the tools and build it all in one fell swoop. Makes for a fine test of the CM system.... -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-08-29 23:21 +0100 |
| Message-ID | <OvWdnTK96YJyCKPNnZ2dnUVZ8hWdnZ2d@giganews.com> |
| In reply to | #25451 |
On 29/08/2012 22:23, Jens Gustedt wrote: > Am 29.08.2012 22:43, schrieb Leigh Johnston: >> On 29/08/2012 21:33, Jens Gustedt wrote: >>> Am 29.08.2012 21:09, schrieb Leigh Johnston: >>>> On 29/08/2012 19:49, Jens Gustedt wrote: >>>>> Am 29.08.2012 20:16, schrieb Leigh Johnston: >>>>>> this has not changed from C to C++. The lack of >>>>>> implicit conversion *from* void* does not change the utility of void*. >>>>> >>>>> For C programmers it does make "void*" useless. >>>> >>>> So malloc is useless? >>> >>> not in C, where implicit conversion from "void*" works without >>> problems >> >> Ergo void* is not useless in C. > > Where did you read that? I didn't say that. I am just, almost > desperately seeking someone who wants to present me with a real use > case in C++. You said "For C programmers it does make "void*" useless.". malloc uses void* and malloc is used by C programmers ergo void* is not useless to C programmers. > > It has a lot of good use cases in C. It would lose most of its use in > C, if it wouldn't implicitly convert to any other pointer to object > type. Correct; perhaps this is what you meant. > >>> or where you refering to C++? using malloc? doesn't that give you >>> objects for which the constructor isn't called :) >> >> I never use malloc in a C++ program. > > see See what? I don't use malloc because new is superior and idiomatic. > >>> you don't answer my question, still no example for a real use case in >>> C++, could you be more concrete? >> >> Example: a pointer to an object associated with in an item in a GUI list >> box widget. In the GUI library I am currently creating the list box >> widget is actually a template however the item data type defaults to >> void* as both a convenience and a way to reduce template bloat; however >> lots of GUI libraries solely use void* for such things (e.g. Microsoft >> Win32 API). > > Then they are no good C++. These things can be done in C++ without any > loss of performance and with much more type safety by using templates, > inheritance, all that machinery. > > So you gave me an example where "void*" encourages bad design, is > that? > > My claim would be that *if* you want to play such "dirty tricks" > create a proper interface and then program the beast itself in C. Nonsense; you must have skipped where I used the words "template bloat"; even Stroustrup advocates this method (see TC++PL 13.5 Specialization). > >> Another example: an object pointer passed to /pthread_create/. > > That doesn't count, pthread_create (or better the new and shiny > thrd_create) are C interfaces. They are designed as such. That is not > a proper use case for C++. Of course it is a proper use case for C++; /pthread_create/ is callable from C++. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Luca Risolia <luca.risolia@studio.unibo.it> |
|---|---|
| Date | 2012-08-30 02:38 +0200 |
| Message-ID | <k1mcmd$bab$1@speranza.aioe.org> |
| In reply to | #25458 |
On 30/08/2012 00:21, Leigh Johnston wrote: > On 29/08/2012 22:23, Jens Gustedt wrote: >> So you gave me an example where "void*" encourages bad design, is >> that? >> >> My claim would be that *if* you want to play such "dirty tricks" >> create a proper interface and then program the beast itself in C. > > Nonsense; you must have skipped where I used the words "template bloat"; > even Stroustrup advocates this method (see TC++PL 13.5 Specialization). That is a valid use of void*, although some modern compilers are smart enough to avoid code bloat without that kind of help.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-30 09:11 +0200 |
| Message-ID | <503F1225.1080009@loria.fr> |
| In reply to | #25467 |
Am 30.08.2012 02:38, schrieb Luca Risolia: > On 30/08/2012 00:21, Leigh Johnston wrote: >> On 29/08/2012 22:23, Jens Gustedt wrote: >>> So you gave me an example where "void*" encourages bad design, is >>> that? >>> >>> My claim would be that *if* you want to play such "dirty tricks" >>> create a proper interface and then program the beast itself in C. >> >> Nonsense; you must have skipped where I used the words "template bloat"; >> even Stroustrup advocates this method (see TC++PL 13.5 Specialization). > > That is a valid use of void*, although some modern compilers are smart > enough to avoid code bloat without that kind of help. So ok, can I conclude that "void*" had been useful in C++ in early stages when the tools chains where not yet there where the designers of C++ wanted it to be? Sure that is a valid use case. Historically it would perhaps been better to say: "ok, these things can't be done with C++, yet, let's use C until we can get rid of it" So if I understand correctly, such a use should now be more and more rare, if not completely avoided in new code? Jens
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-30 08:46 +0200 |
| Message-ID | <503F0C32.4020305@loria.fr> |
| In reply to | #25458 |
Am 30.08.2012 00:21, schrieb Leigh Johnston: > On 29/08/2012 22:23, Jens Gustedt wrote: >> Am 29.08.2012 22:43, schrieb Leigh Johnston: >>> On 29/08/2012 21:33, Jens Gustedt wrote: >>>> Am 29.08.2012 21:09, schrieb Leigh Johnston: >>>>> On 29/08/2012 19:49, Jens Gustedt wrote: >>>>>> Am 29.08.2012 20:16, schrieb Leigh Johnston: >>>>>>> this has not changed from C to C++. The lack of >>>>>>> implicit conversion *from* void* does not change the utility of >>>>>>> void*. >>>>>> >>>>>> For C programmers it does make "void*" useless. >>>>> >>>>> So malloc is useless? >>>> >>>> not in C, where implicit conversion from "void*" works without >>>> problems >>> >>> Ergo void* is not useless in C. >> >> Where did you read that? I didn't say that. I am just, almost >> desperately seeking someone who wants to present me with a real use >> case in C++. > > You said "For C programmers it does make "void*" useless.". malloc uses > void* and malloc is used by C programmers ergo void* is not useless to C > programmers. > >> >> It has a lot of good use cases in C. It would lose most of its use in >> C, if it wouldn't implicitly convert to any other pointer to object >> type. > > Correct; perhaps this is what you meant. Yes, this is what I said. >> >>>> or where you refering to C++? using malloc? doesn't that give you >>>> objects for which the constructor isn't called :) >>> >>> I never use malloc in a C++ program. >> >> see > > See what? I don't use malloc because new is superior and idiomatic. Sure. So you don't need to operate on "void*" in C++. >> >>>> you don't answer my question, still no example for a real use case in >>>> C++, could you be more concrete? >>> >>> Example: a pointer to an object associated with in an item in a GUI list >>> box widget. In the GUI library I am currently creating the list box >>> widget is actually a template however the item data type defaults to >>> void* as both a convenience and a way to reduce template bloat; however >>> lots of GUI libraries solely use void* for such things (e.g. Microsoft >>> Win32 API). >> >> Then they are no good C++. These things can be done in C++ without any >> loss of performance and with much more type safety by using templates, >> inheritance, all that machinery. >> >> So you gave me an example where "void*" encourages bad design, is >> that? >> >> My claim would be that *if* you want to play such "dirty tricks" >> create a proper interface and then program the beast itself in C. > > Nonsense; you must have skipped where I used the words "template bloat"; > even Stroustrup advocates this method (see TC++PL 13.5 Specialization). so if you have Stroustrup's blessing, bad design is ok? >>> Another example: an object pointer passed to /pthread_create/. >> >> That doesn't count, pthread_create (or better the new and shiny >> thrd_create) are C interfaces. They are designed as such. That is not >> a proper use case for C++. > > Of course it is a proper use case for C++; /pthread_create/ is callable > from C++. You seem to have extreme difficulties or lack of willingless to read what I say. I said that "void*" is there for interface compatibility with C. So sure, you might call a C function that has a "void*" parameter. This is using "void*" as a data sink, you should (almost) never be tempted to convert it back. So again give me a proper use case in C++ that isn't just for calling a C interface. Jens
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <Casey_at_Carter_dot_net@dontspam.me.invalid> |
|---|---|
| Date | 2012-08-30 08:39 -0500 |
| Message-ID | <k1nqdm$7i4$1@dont-email.me> |
| In reply to | #25510 |
On 2012-08-30 01:46, Jens Gustedt wrote: > So again give me a proper use case in C++ that isn't just for calling > a C interface. void* is used to point at space that has been allocated but not yet initialized or destroyed but not yet freed to indicate that references to that space are semantically invalid.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 21:06 +0200 |
| Message-ID | <503D16A5.9020605@loria.fr> |
| In reply to | #25198 |
Am 28.08.2012 13:04, schrieb Malcolm McLean: > בתאריך יום שלישי, 28 באוגוסט 2012 08:27:55 UTC+1, מאת Jens Gustedt: >> Am 28.08.2012 05:34, schrieb BGB: >> >> >> 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. >> > void * just documents that "this is an unsigned char * holding arbitrary > bytes". It's a bit pointless to require a cast to and from, because you > can't use the data in any way without converting it to something else, > but that's just a minor syntactical niggle. minor syntax problem, perhaps, but can be very anoying In C, many agree that cast are to be avoided as much as possible, because they often hide problems. Just introducing casts into code for the only reason to have it compatible with C++ is a show stopper. Jens
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <casey_at_carter_dot_net@nospam.invalid> |
|---|---|
| Date | 2012-08-28 12:18 -0500 |
| Message-ID | <k1iuhb$2g6$1@dont-email.me> |
| In reply to | #25175 |
On 2012-08-27 22:34, BGB wrote:
>> Definition of NULL as ((void*)0) is contingent on the implicit
>> conversion of void* to other pointer types.
>>
>
> well, yes, but I listed that they could add this as well.
> probably most C++ code wouldn't notice the change.
I should have been more clear about my point here: I was trying to say
that the only reason this definition of NULL is unacceptable to C++ is
because of the lack of the implicit conversion from void*. Given that
conversion, there would be no other barrier in C++ to using ((void*)0)
for NULL.
> possibly, the change could be limited to 'extern "C"' code or similar
> (and/or could be ignored in cases of templates or overloading, or at
> least be a lower priority than any other matches).
I think the rules for overload resolution and template type deduction
are complicated enough without introducing a feature that behaves
differently depending on whether or not it interacts with those systems.
There's no such thing as 'extern "C" code': extern "foo" is a *linkage
specification* whose sole purpose is to tell the implementation to
engage the ABI machinery appropriate for language "foo".
>> That implicit conversion from void* to any pointer type is a dangerous
>> hole in the type system. I admit I'm not much of a C programmer anymore:
>> the only valid reason I can think of to have this conversion is so that
>> malloc calls don't require you to specify the type _three_ times (e.g.,
>> int* p = (int*)malloc(sizeof(*p)); ).
>>
>
> there are plenty of uses besides malloc, so malloc is just one of many
> cases (mmap, memcpy, VirtualAlloc, ...).
>
> or, a biggie:
> for any user-defined code which accepts or returns "void *".
Returns, not accepts. The implicit conversion _from_ void* is dangerous,
implicit conversion _to_ void* is perfectly safe type erasure.
>
> for example, to do similar tasks in C++ often requires a larger number
> of casts.
>
>
>> If I really wanted to pitch the committees for stronger ties between C
>> and C++, I'd probably suggest that (a) C pick up nullptr (and nullptr_t)
>> to serve as generic null pointer constant,
>
> could work...
>
>
>> (b) C drop the implicit
>> conversion from void*,
>
> this would break large amounts of C code.
I'll handwave here and claim that's what compiler options are for. Valid
C90 code will always be valid C90 code, I see no reason why a future C20
compiler couldn't be instructed to compile code as C90. Old code will
always be old code, but does that mean that we have to keep on writing
old code forever?
It's already the case that C11 made some C99 features optional: there
may be conforming C11 compilers that refuse to compile some conforming
C99 programs. The kind of change I suggest is quantitatively but not
qualitatively different.
> I don't think people on either side would want changes which cause their
> existing programs to break and have to be rewritten.
>
>> and (c) both languages use a new distinct type
>> that can implicitly convert to any pointer type.
>
> we call this 'void *', where this is nearly the only thing that can
> really be done with this type anyways ("void" variables are otherwise
> pretty much useless, ...).
I am differentiating between the implicit conversion _from_ any pointer
type and the implicit conversion _to_ any pointer type; I posit that
those two features have unique design intentions and should therefore be
represented by distinct types. C conflates the two ideas in void*, C++
doesn't have the conversion _to_ any pointer type at all, except for
nullptr. (Given how simple it is to make a user-defined type in C++ that
implicitly converts to any pointer type, it's notable that I've never
seen anyone feel the need to do so.)
void* has 2 uses in C:
1. it's the "sink" type to which all other pointer types can be
implicitly converted.
2. it's the "source" type that implicitly converts to all other pointer
types.
and 2 uses in C++:
1. "sink" type just as in C.
2. type-erased pointer that designates _some_kind_ of object about which
nothing is known except its location in memory.
The secondary usage is diametrically opposite between C and C++: one
disallows using a void* for any purpose without a cast, the other allows
you to pass a void* where you would any pointer type without a cast. In
C, I can pass the same void* to fclose, free, strcat, and
hundreds/thousands of other functions without a compiler diagnostic.
Using void* you've effectively opted out of a large part of the type system.
C programmers also often use void* as either a type-erased or generic
pointer but do so purely based on convention and discipline: you will
get no help from the compiler. If an intern jumps into your code the
next day and passes your type-erased pointer to fputs, the compiler will
accept it happily.
> > Holes in the type
>> system are very useful at the fringes of C/C++ programs, I think that
>> having distinct "source" (X -> any*) and "sink" (any* -> X) pointer
>> types preserves the utility of C-style void* while minimizing the danger.
>
> yes, but the least impact route would be to just pick up C's "void *"
> semantics for this, since C++ code isn't likely to notice, and existing
> C code can keep working unmodified.
While it's true that making the language more permissive doesn't impact
the correctness of existing programs, that doesn't necessarily make it
always a good idea. I seriously doubt that the C++ community would ever
accept implicit conversion from void* into the language; the case I'm
attempting to make here is that C shouldn't have that feature either and
likely would not if it was designed afresh today.
Given that preserving the semantics of old code has a higher priority to
the C community than almost any other concern, I think it's unlikely
that we will ever have a C++ that is truly a superset of C. If anything
I think it's more likely that C++ would introduce even more breaking
changes to become _less_ compatible with C.
[toc] | [prev] | [next] | [standalone]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web