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 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-31 00:18 +0200 |
| Message-ID | <503FE6B9.6000208@loria.fr> |
| In reply to | #25556 |
Am 30.08.2012 19:49, schrieb Garrett Hartshaw: > 'char *' says "this is a pointer to an object of type 'char'", > 'unsigned char *' says "this is a pointer to an object of type > 'unsigned char'", 'void *' says "this is a pointer to an object of an > unknown/any type". no, at least for C "void" is a type, too. The void type comprises an empty set of values; it is an incomplete object type that cannot be completed. so "void*" says pointer to void. This is not "nothing" or "unknown", in that sense void is not much different from "struct nix" when you never actually define "struct nix" somewhere. It behaves a bit different in terms of implicit conversions, sure, but the sematic is the same. > If you want to interpret an object as a sequence of bytes, then use > 'unsigned char *' or 'uint8_t *'. I see 'unsigned char' as meaning a > character in an encoding that is represented as an 8-bit unsigned > integer, while 'uint8_t' is an arbitrary 8-bit unsigned integer. (e.g. > I would write "unsigned char a = 'a'" and "uint8_t b = 10", but not > "unsigned char c = 10" or "uint8_t d = 'd'") > > If on the other hand you wish to have an opaque pointer to an object > of unknown type, or to an uninitialized memory region, then use 'void *'. A "void*" pointer is not "an uninitialized" memory region. It may well already be initialized. But I am really surprised about this strong need of opaque pointer in C++. If we follow the basic ideas of C++ such a usage should be very rare in C++, no? Isn't that what "abstract base classes" have been invented for? > Even if 'void *' was redefined to mean 'unsigned char *', I would > still distinguish between their uses just as I distinguish between > 'unsigned char' and 'uint8_t'. Therefore I had my question that came afterward and that you seem to have overlooked: >> Would you be more comfortable if the standard introduced a type >> alias "byte" for "unsigned char"? > >> That would completely be conceivable. For example C11 introduces > >> typedef int errno_t; > >> but by reclaiming a different semantic for "errno_t" than for >> "int". The naming of "char" (and the two others) certainly doesn't cover all its uses that these type nowadays have, and it would be good to find semantic names for the different use cases. typedef char byte_t; // for the minimal addressable storage unit typedef unsigned char bitX_t; // for an arbitrary collection of unspecific data, usually X == 8 typedef unsigned char uintX_t; // for use as small unsigned integer, usually X == 8 typedef signed char intX_t; // for use as small signed integer, usually X == 8 Jens
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-30 17:30 -0700 |
| Message-ID | <lnwr0fucle.fsf@nuthaus.mib.org> |
| In reply to | #25586 |
Jens Gustedt <jens.gustedt@loria.fr> writes:
> Am 30.08.2012 19:49, schrieb Garrett Hartshaw:
>> 'char *' says "this is a pointer to an object of type 'char'",
>> 'unsigned char *' says "this is a pointer to an object of type
>> 'unsigned char'", 'void *' says "this is a pointer to an object of an
>> unknown/any type".
>
> no, at least for C "void" is a type, too.
Yes, void is a type; specifically, it's an incomplete type that cannnot
be completed.
> The void type comprises an empty set of values; it is an incomplete
> object type that cannot be completed.
>
> so "void*" says pointer to void. This is not "nothing" or "unknown",
> in that sense void is not much different from "struct nix" when you
> never actually define "struct nix" somewhere. It behaves a bit
> different in terms of implicit conversions, sure, but the sematic is
> the same.
Not really. A `char*` pointer points to an object of type `char`. A
`void*` pointer does not point to an object of type `void`, because
there is no such thing.
Any type of pointer to object or incomplete type (i.e., any pointer
other than a function pointer) points to some object in memory (or to
nothing if it's currently a null pointer). What's special about `void*`
is that, while you can perform certain pointer operations on it, you
can't access the object it points to without first converting it to some
other pointer type.
[...]
>> If on the other hand you wish to have an opaque pointer to an object
>> of unknown type, or to an uninitialized memory region, then use 'void *'.
>
> A "void*" pointer is not "an uninitialized" memory region. It may well
> already be initialized.
I think that was a recommendation for *how* to use `void*`, not a
statement about what `void* means to the compiler.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-08-31 14:18 -0400 |
| Message-ID | <WeudnRzvb4l_Yt3NnZ2dnUVZ_qCdnZ2d@bestweb.net> |
| In reply to | #25606 |
On 8/30/2012 8:30 PM, Keith Thompson wrote:
> Jens Gustedt <jens.gustedt@loria.fr> writes:
[...]
>> so "void*" says pointer to void. This is not "nothing" or "unknown",
>> in that sense void is not much different from "struct nix" when you
>> never actually define "struct nix" somewhere. It behaves a bit
>> different in terms of implicit conversions, sure, but the sematic is
>> the same.
>
> Not really. A `char*` pointer points to an object of type `char`. A
> `void*` pointer does not point to an object of type `void`, because
> there is no such thing.
>
> Any type of pointer to object or incomplete type (i.e., any pointer
> other than a function pointer) points to some object in memory (or to
> nothing if it's currently a null pointer). What's special about `void*`
> is that, while you can perform certain pointer operations on it, you
> can't access the object it points to without first converting it to some
> other pointer type.
[...]
While technically correct that "void *" doesn't point to an object of type
"void" because there's no such thing, I think it is convenient to think of
it in those terms.
Consider, for example:
struct IncompleteType;
typedef struct IncompleteType MyVoid;
In this case, "MyVoid *" is kind of like "void *", as long as struct
IncompleteType is never "completed".
Of course, there are differences:
"void *" can be converted to/from any other data pointer type without
the need for a cast.
You are guaranteed that you can convert to "void *" and back, without
the loss of any data.
As I said, it is technically correct that "void *" cannot point to something
of type "void", because there is no such thing. (You can't have an object
of type "struct IncompleteType" in my example, either.) However, I do think
it's a convenient way to think of it, since any other "X *" would be a
pointer to something of type "X".
P.S. I see that this is crossposted to clc++. I don't know C++ well enough
to know if all of the above is true. I do understand that you can't convert
to/from "void *" in C++ without a cast.
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-08-31 19:34 +0100 |
| Message-ID | <NtKdnX7V6YwvntzNnZ2dnUVZ8jydnZ2d@giganews.com> |
| In reply to | #25658 |
On 31/08/2012 19:18, Kenneth Brody wrote: > On 8/30/2012 8:30 PM, Keith Thompson wrote: >> Jens Gustedt <jens.gustedt@loria.fr> writes: > [...] >>> so "void*" says pointer to void. This is not "nothing" or "unknown", >>> in that sense void is not much different from "struct nix" when you >>> never actually define "struct nix" somewhere. It behaves a bit >>> different in terms of implicit conversions, sure, but the sematic is >>> the same. >> >> Not really. A `char*` pointer points to an object of type `char`. A >> `void*` pointer does not point to an object of type `void`, because >> there is no such thing. >> >> Any type of pointer to object or incomplete type (i.e., any pointer >> other than a function pointer) points to some object in memory (or to >> nothing if it's currently a null pointer). What's special about `void*` >> is that, while you can perform certain pointer operations on it, you >> can't access the object it points to without first converting it to some >> other pointer type. > [...] > > While technically correct that "void *" doesn't point to an object of > type "void" because there's no such thing, I think it is convenient to > think of it in those terms. > > Consider, for example: > > struct IncompleteType; > typedef struct IncompleteType MyVoid; > > In this case, "MyVoid *" is kind of like "void *", as long as struct > IncompleteType is never "completed". > > Of course, there are differences: > > "void *" can be converted to/from any other data pointer type without > the need for a cast. > > You are guaranteed that you can convert to "void *" and back, without > the loss of any data. > > As I said, it is technically correct that "void *" cannot point to > something of type "void", because there is no such thing. (You can't > have an object of type "struct IncompleteType" in my example, either.) > However, I do think it's a convenient way to think of it, since any > other "X *" would be a pointer to something of type "X". > > P.S. I see that this is crossposted to clc++. I don't know C++ well > enough to know if all of the above is true. I do understand that you > can't convert to/from "void *" in C++ without a cast. In C++ you can convert to void* without a cast. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-31 17:24 -0700 |
| Message-ID | <lnhariio8n.fsf@nuthaus.mib.org> |
| In reply to | #25658 |
Kenneth Brody <kenbrody@spamcop.net> writes:
> On 8/30/2012 8:30 PM, Keith Thompson wrote:
>> Jens Gustedt <jens.gustedt@loria.fr> writes:
> [...]
>>> so "void*" says pointer to void. This is not "nothing" or "unknown",
>>> in that sense void is not much different from "struct nix" when you
>>> never actually define "struct nix" somewhere. It behaves a bit
>>> different in terms of implicit conversions, sure, but the sematic is
>>> the same.
>>
>> Not really. A `char*` pointer points to an object of type `char`. A
>> `void*` pointer does not point to an object of type `void`, because
>> there is no such thing.
>>
>> Any type of pointer to object or incomplete type (i.e., any pointer
>> other than a function pointer) points to some object in memory (or to
>> nothing if it's currently a null pointer). What's special about `void*`
>> is that, while you can perform certain pointer operations on it, you
>> can't access the object it points to without first converting it to some
>> other pointer type.
> [...]
>
> While technically correct that "void *" doesn't point to an object of
> type "void" because there's no such thing, I think it is convenient to
> think of it in those terms.
I disagree. That is, I agree that it's technically correct (the
best kind of correct!), but I think it's correct in every other
sense as well. I don't think pretending that there's such a thing
as an object of type void, that a void* pointer points to, is useful.
> Consider, for example:
>
> struct IncompleteType;
> typedef struct IncompleteType MyVoid;
>
> In this case, "MyVoid *" is kind of like "void *", as long as struct
> IncompleteType is never "completed".
And that's a *huge* difference. If you have a pointer to struct,
even if the struct type hasn't yet been completed, it tells you
that it actually points to an object of that type. Presumably code
that has visibility to the full definition of struct IncompleteType
will be able to dereference the pointer and access the pointed-to
object. And that's the whole point of declaring something as struct
IncompleteType*.
On the other hand, if you deliberately never complete the type
struct IncompleteType, then there can be no objects of type struct
IncompleteType, and you'll never able to dereference a pointer to
struct IncompleteType without first converting it to some other
pointer type. If void* didn't exist, that might be a reasonable
thing to do -- but it does.
[...]
> As I said, it is technically correct that "void *" cannot point to
> something of type "void", because there is no such thing. (You can't
> have an object of type "struct IncompleteType" in my example, either.)
> However, I do think it's a convenient way to think of it, since any
> other "X *" would be a pointer to something of type "X".
Yes, any *other* type X* points to something of type X. void*
is an exception to that rule, which is why it exists.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Nobody <nobody@nowhere.com> |
|---|---|
| Date | 2012-09-02 01:10 +0100 |
| Message-ID | <pan.2012.09.02.00.10.30.170000@nowhere.com> |
| In reply to | #25681 |
On Fri, 31 Aug 2012 17:24:40 -0700, Keith Thompson wrote: >> Consider, for example: >> >> struct IncompleteType; >> typedef struct IncompleteType MyVoid; >> >> In this case, "MyVoid *" is kind of like "void *", as long as struct >> IncompleteType is never "completed". > > And that's a *huge* difference. If you have a pointer to struct, > even if the struct type hasn't yet been completed, it tells you > that it actually points to an object of that type. Presumably code > that has visibility to the full definition of struct IncompleteType > will be able to dereference the pointer and access the pointed-to > object. And that's the whole point of declaring something as struct > IncompleteType*. Also: alignment. An implementation can impose a minimum alignment for structures (even incomplete structures). The representation of MyVoid* only has to allow for such alignment, meaning that (unlike void*) it may not be possible to reliably convert a char* to a MyVoid* then back to a char* (on a word-aligned architecture, a MyVoid* only needs enough bits for the word address, whearas a void* must have enough bits for the offset within a word if char is smaller than a word).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-09-07 05:57 -0700 |
| Message-ID | <kfn4nnam1ml.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #25681 |
Keith Thompson <kst-u@mib.org> writes: > Kenneth Brody <kenbrody@spamcop.net> writes: >> On 8/30/2012 8:30 PM, Keith Thompson wrote: >>> Jens Gustedt <jens.gustedt@loria.fr> writes: >> [...] >>>> so "void*" says pointer to void. This is not "nothing" or "unknown", >>>> in that sense void is not much different from "struct nix" when you >>>> never actually define "struct nix" somewhere. It behaves a bit >>>> different in terms of implicit conversions, sure, but the sematic is >>>> the same. >>> >>> Not really. A `char*` pointer points to an object of type `char`. A >>> `void*` pointer does not point to an object of type `void`, because >>> there is no such thing. >>> >>> Any type of pointer to object or incomplete type (i.e., any pointer >>> other than a function pointer) points to some object in memory (or to >>> nothing if it's currently a null pointer). What's special about `void*` >>> is that, while you can perform certain pointer operations on it, you >>> can't access the object it points to without first converting it to some >>> other pointer type. >> [...] >> >> While technically correct that "void *" doesn't point to an object of >> type "void" because there's no such thing, I think it is convenient to >> think of it in those terms. > > I disagree. That is, I agree that it's technically correct (the > best kind of correct!), but I think it's correct in every other > sense as well. [snip elaboration] I would say exactly the opposite - a pointer of type 'void *' points at something of type void. In fact all valid addresses (arguably even those pointing past the end of arrays) refer to legimate void objects. Just because you can't /do/ anything with those void objects, as such, doesn't make them any less legimate. To give a more concrete argument, the rules for derived types, in particular pointer types, says "A pointer type describes an object whose value provides a reference to an entity of the referenced type." There is no special mention or exception made for pointers to void.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-09-07 14:17 -0700 |
| Message-ID | <lnvcfpsfb7.fsf@nuthaus.mib.org> |
| In reply to | #26042 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Kenneth Brody <kenbrody@spamcop.net> writes:
[...]
>>> While technically correct that "void *" doesn't point to an object of
>>> type "void" because there's no such thing, I think it is convenient to
>>> think of it in those terms.
>>
>> I disagree. That is, I agree that it's technically correct (the
>> best kind of correct!), but I think it's correct in every other
>> sense as well. [snip elaboration]
>
> I would say exactly the opposite - a pointer of type 'void *'
> points at something of type void. In fact all valid addresses
> (arguably even those pointing past the end of arrays) refer
> to legimate void objects. Just because you can't /do/ anything
> with those void objects, as such, doesn't make them any less
> legimate.
So you believe that there's such a thing as a "void object"?
An "object" is by definition a "region of data storage in the
execution environment, the contents of which can represent values".
For a void object, what is the size of this region, and what values
can its contents represent?
> To give a more concrete argument, the rules for derived types,
> in particular pointer types, says "A pointer type describes an
> object whose value provides a reference to an entity of the
> referenced type." There is no special mention or exception
> made for pointers to void.
Or for pointers to other incomplete types, or for null pointers.
I suggest that this is an oversight. I'll also note that it uses
the word "entity", not "object". Neither void pointers nor function
pointers refer to objects.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-09-07 19:37 -0700 |
| Message-ID | <kfnwr05dytu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #26087 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Kenneth Brody <kenbrody@spamcop.net> writes: > [...] >>>> While technically correct that "void *" doesn't point to an object of >>>> type "void" because there's no such thing, I think it is convenient to >>>> think of it in those terms. >>> >>> I disagree. That is, I agree that it's technically correct (the >>> best kind of correct!), but I think it's correct in every other >>> sense as well. [snip elaboration] >> >> I would say exactly the opposite - a pointer of type 'void *' >> points at something of type void. In fact all valid addresses >> (arguably even those pointing past the end of arrays) refer >> to legimate void objects. Just because you can't /do/ anything >> with those void objects, as such, doesn't make them any less >> legimate. > > So you believe that there's such a thing as a "void object"? Sure. void is an object type -- an incomplete object type, but still an object type. What's wrong with having there be void objects? > An "object" is by definition a "region of data storage in the > execution environment, the contents of which can represent values". > For a void object, what is the size of this region, and what values > can its contents represent? Same answers as for 'struct foo' when that is an incoomplete type, namely, we don't know and we don't know. One thing we _do_ know that is very useful is where the object starts. >> To give a more concrete argument, the rules for derived types, >> in particular pointer types, says "A pointer type describes an >> object whose value provides a reference to an entity of the >> referenced type." There is no special mention or exception >> made for pointers to void. > > Or for pointers to other incomplete types, or for null pointers. Pointers to incomplete object types still refer to objects. The null pointer case is a red herring, just like a pointer to one-past-an-array - the pointer still provides a reference to something of the referenced type, even if in some cases we can't actually get a "thing" by dereferencing. We can't get a "thing" by dereferencing a pointer to an incomplete object type either, but there still can be an object there of that type even if we don't know what it is. > I suggest that this is an oversight. I'll also note that it uses > the word "entity", not "object". Neither void pointers nor function > pointers refer to objects. The word "entity" is used only because functions and objects are different. A pointer-to-function refers to a function; a pointer to an object type refers to an object, whether it is of complete object type or incomplete object type. The world is just a lot simpler if we assume that there are void objects along with all the other kinds of objects. I'm sure a consistent model can be constructed where a pointer-to-void points to "nothing", but why would we do that when it will just complicate things? For example, converting a pointer to a pointer-to-character type gives a pointer to the first byte of the object. If a (void*) pointer points to "nothing", converting it to a (char*) will end up being undefined behavior. Those kinds of problems seem like a big headache for no tangible value.
[toc] | [prev] | [next] | [standalone]
| From | Garrett Hartshaw <ghartshaw@gmail.com> |
|---|---|
| Date | 2012-08-30 22:07 -0400 |
| Message-ID | <k1p6em$q1f$1@dont-email.me> |
| In reply to | #25586 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2012 06:18 PM, Jens Gustedt wrote: > Am 30.08.2012 19:49, schrieb Garrett Hartshaw: >> 'char *' says "this is a pointer to an object of type 'char'", >> 'unsigned char *' says "this is a pointer to an object of type >> 'unsigned char'", 'void *' says "this is a pointer to an object >> of an unknown/any type". > > no, at least for C "void" is a type, too. > > The void type comprises an empty set of values; it is an > incomplete object type that cannot be completed. > > so "void*" says pointer to void. This is not "nothing" or > "unknown", in that sense void is not much different from "struct > nix" when you never actually define "struct nix" somewhere. It > behaves a bit different in terms of implicit conversions, sure, but > the sematic is the same. > >> If you want to interpret an object as a sequence of bytes, then >> use 'unsigned char *' or 'uint8_t *'. I see 'unsigned char' as >> meaning a character in an encoding that is represented as an >> 8-bit unsigned integer, while 'uint8_t' is an arbitrary 8-bit >> unsigned integer. (e.g. I would write "unsigned char a = 'a'" and >> "uint8_t b = 10", but not "unsigned char c = 10" or "uint8_t d = >> 'd'") >> >> If on the other hand you wish to have an opaque pointer to an >> object of unknown type, or to an uninitialized memory region, >> then use 'void *'. > > A "void*" pointer is not "an uninitialized" memory region. It may > well already be initialized. As Keith said, that was meant to be how it should be used, rather than exactly what it means to the compiler. > > But I am really surprised about this strong need of opaque pointer > in C++. If we follow the basic ideas of C++ such a usage should be > very rare in C++, no? Isn't that what "abstract base classes" have > been invented for? > >> Even if 'void *' was redefined to mean 'unsigned char *', I >> would still distinguish between their uses just as I distinguish >> between 'unsigned char' and 'uint8_t'. > > Therefore I had my question that came afterward and that you seem > to have overlooked: > >>> Would you be more comfortable if the standard introduced a >>> type alias "byte" for "unsigned char"? >> >>> That would completely be conceivable. For example C11 >>> introduces >> >>> typedef int errno_t; >> >>> but by reclaiming a different semantic for "errno_t" than for >>> "int". > > The naming of "char" (and the two others) certainly doesn't cover > all its uses that these type nowadays have, and it would be good to > find semantic names for the different use cases. > > typedef char byte_t; // for the minimal addressable > storage unit typedef unsigned char bitX_t; // for an arbitrary > collection of unspecific data, usually X == 8 typedef unsigned char > uintX_t; // for use as small unsigned integer, usually X == 8 > typedef signed char intX_t; // for use as small signed > integer, usually X == 8 > > Jens > One of the major uses of typedef is to allow this kind of disambiguation between types that are represented identically. While I don't often have need to work low-level directly on bytes, if I did I would not hesitate to create a byte_t typedef, and if it was already included in the standard, so much the better (although I would probably typedef it as 'unsigned char' to avoid the implementation-defined signed-ness of plain 'char'). However, even if 'byte_t' were added to the standard, I would still want to distinguish between 'byte_t *' (used as a pointer to a byte) and 'void *' (used as an opaque pointer or a pointer to uninitialized memory) *even if they both meant the same thing to the compiler*. Granted it would better for 'memcpy' and friends to use 'byte_t *' rather than 'void *', as their underlying functionality is specified in terms of moving/copying bytes. 'void *' would still be required *in C* as the return value of 'malloc' (unitialized memory) and for use as a userData parameter in callbacks (opaque pointer to an object of unspecified type). There is little use for 'void *' in pure C++ code, but it would still be required in the language to interface with C code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQQBxQAAoJEP8JewLaHvzSQJ0H+gNUnCggPWCdrovjjEDnANY0 mL2/5I+R+Ckn7sMYDWmdc6jhxQPcfoKX7aHT9C2DV1MWRfigMb4z0rsKqcc+WjUY FJXEjLtlv9H+IHHuypXWNqVAPm7HgpXq74L/yhv2H2IlJqra6DW58ULdWRm6DUSN xHijMzGpuNIw7LE3zzilinJfvP26+pxXZDuFmWXs2pCAPXgikZS1AG9PQWnVWXLz DXDZ7nejxIc8FIesNfxO3NLzzMVZ69ZhyfB4M6UwCD2TdeRdrAYay5f3sEHKtIvG N2RXXXV+J36ZX4w0i6dQuuCuAHzBaPwBcvtW79nIzgAv5pqlCDA4kuMl8WF1Y4s= =SUbB -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-31 14:53 +0200 |
| Message-ID | <5040B3E1.9010105@loria.fr> |
| In reply to | #25611 |
Am 31.08.2012 04:07, schrieb Garrett Hartshaw: > Granted it would better for 'memcpy' and friends to use 'byte_t *' > rather than 'void *', as their underlying functionality is specified > in terms of moving/copying bytes. 'void *' would still be required *in > C* as the return value of 'malloc' (unitialized memory) and for use as > a userData parameter in callbacks (opaque pointer to an object of > unspecified type). Perhaps this got a bit lost in the discussion, but all of that started by trying to find replacements for "void*" in C++. "void*" is a concept that works suitably well in C. It is just a nuisance in C++. > There is little use for 'void *' in pure C++ code, > but it would still be required in the language to interface with C code. Sure that was my starting point. I even think that in C++ all conversion from "void*" to another type should and could be avoided. Basically I would say code that uses "void*" (manipulating pointers to void, or obfuscating types) are "C in disguise". I haven't heard of a good C++ use case, yet, that couldn't be packed into an 'extern "C"' interface and where the implementation then couldn't be done in proper C. A bit in the same spirit as some specific functions for OS or compilers are implemented in assembler. Jens
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2012-09-05 19:41 -0700 |
| Message-ID | <b6bee8af-fb13-4787-8894-88a4c89e287e@googlegroups.com> |
| In reply to | #25640 |
On Friday, August 31, 2012 3:53:54 PM UTC+3, Jens Gustedt wrote: > Perhaps this got a bit lost in the discussion, but all of that started > by trying to find replacements for "void*" in C++. Why? > "void*" is a concept that works suitably well in C. It is just a > nuisance in C++. Not at all. Every raw pointer converts implicitly to void*. If you need "a pointer" regardless of type at what it points then "void*" is the thing to use. It is safer than some "unsigned char*". You can not by some typo to do arithmetics or to dereference void*. > > There is little use for 'void *' in pure C++ code, Download the flagship template libraries collection called "boost". I bet you find hundreds of explicit usages of "void*" there if not thousands. > > but it would still be required in the language to interface with C code. > > Sure that was my starting point. That is also one reason why it may be is needed, but far not the main one. > > > > I even think that in C++ all conversion from "void*" to another type > should and could be avoided. Basically I would say code that uses > "void*" (manipulating pointers to void, or obfuscating types) are "C > in disguise". You can cast void* back into T* what it was with dynamic_cast<>() in C++. dynamic_cast<>() does check runtime that the cast is correct. It is very safe. reinterpret_cast<>() of "unsigned char*" into T* is "C in disguise". > I haven't heard of a good C++ use case, yet, that couldn't be packed > into an 'extern "C"' interface and where the implementation then > couldn't be done in proper C. A bit in the same spirit as some > specific functions for OS or compilers are implemented in assembler. I repeat. Just take boost. It is all good, well tested C++, mostly header-only libraries. Open source. Free to eyeball and to use. Lot of things from it went straight or with minor mods into C++2011. Then come back and tell us how you reimplement that thing in C or assembler.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-09-05 23:44 -0400 |
| Message-ID | <k29676$dqo$1@dont-email.me> |
| In reply to | #25979 |
On 09/05/2012 10:41 PM, � wrote: > On Friday, August 31, 2012 3:53:54 PM UTC+3, Jens Gustedt wrote: ... >> "void*" is a concept that works suitably well in C. It is just a >> nuisance in C++. > > Not at all. Every raw pointer converts implicitly to void*. If you > need "a pointer" regardless of type at what it points then "void*" > is the thing to use. It is safer than some "unsigned char*". You > can not by some typo to do arithmetics or to dereference void*. In C++, if you need "a pointer regardless of type", you can template on T and use T*, for increased type safety on top of the same amount of flexibility that void* gives you. As an additional bonus, you can do (meaningful!) arithmetic on T* and even dereference it, which you can't do with void*. ... > You can cast void* back into T* what it was with dynamic_cast<>() in > C++. dynamic_cast<>() does check runtime that the cast is correct. > It is very safe. Yes, it is safe, but dynamic_cast<T>(v) has a number of limitations: "T shall be a pointer or reference to a complete class type, or “pointer to cv void.”"(5.2.7p1), so it cannot be used to convert to, for instance, double* or an opaque class type. Also, "If T is a pointer type, v shall be an rvalue of a pointer to complete class type ... If T is an lvalue reference type, v shall be an lvalue of a complete class type ... If T is an rvalue reference type, v shall be an expression having a complete class type ..." (5.2.7p2). Notice that v cannot have type void*, because void is neither complete, nor a class type. >> I haven't heard of a good C++ use case, yet, that couldn't be packed >> into an 'extern "C"' interface and where the implementation then >> couldn't be done in proper C. A bit in the same spirit as some >> specific functions for OS or compilers are implemented in assembler. > > I repeat. Just take boost. It is all good, well tested C++, mostly > header-only libraries. Open source. Free to eyeball and to use. Lot > of things from it went straight or with minor mods into C++2011. > Then come back and tell us how you reimplement that thing in > C or assembler. He's not suggesting that the entire thing be implemented in C, only that any place in the code which has a good reason for using void* could be split into two parts: a part in C++ that makes no use of void*, and a part that could be implemented entirely in C. His words also imply that there might also be place where void* is used without there being a "good C++ use case", in which case the code can probably be replaced, not by C code, but by C++ code using T*, where T is a template type parameter. I don't know enough about boost internals to guess whether that would be true, but it at least seems plausible to me. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2012-09-05 23:08 -0700 |
| Message-ID | <c359eeff-2743-47b2-bdc9-f14839b2bf0e@googlegroups.com> |
| In reply to | #25983 |
On Thursday, September 6, 2012 6:44:40 AM UTC+3, James Kuyper wrote: > On 09/05/2012 10:41 PM, � wrote: > > On Friday, August 31, 2012 3:53:54 PM UTC+3, Jens Gustedt wrote: > ... > >> "void*" is a concept that works suitably well in C. It is just a > >> nuisance in C++. > > > > Every raw pointer converts implicitly to void*. If you > > need "a pointer" regardless of type at what it points then "void*" > > is the thing to use. It is safer than some "unsigned char*". You > > can not by some typo to do arithmetics or to dereference void*. > > In C++, if you need "a pointer regardless of type", you can template on > T and use T*, for increased type safety on top of the same amount of > flexibility that void* gives you. As an additional bonus, you can do > (meaningful!) arithmetic on T* and even dereference it, which you can't > do with void*. In C++ a flexibility that is not needed is considered a bad thing. The void* is anonymous. So when a part of software has not business to know the nature or to dereference it then making it available is wrong. As similar example think of std::array<>. All it does compared to usual array is that it removes implicit conversion to pointer and wraps pointers into iterators. As result the code of usage compiles into exactly same binary. Still it is lot safer because dereferencing or doing arithmetics with it does not compile. > > You can cast void* back into T* what it was with dynamic_cast<>() in > > C++. dynamic_cast<>() does check runtime that the cast is correct. > > It is very safe. > > Yes, it is safe, but dynamic_cast<T>(v) has a number of limitations: "T > shall be a pointer or reference to a complete class type, or “pointer to > cv void.”"(5.2.7p1), so it cannot be used to convert to, for instance, > double* or an opaque class type. dynamic_cast<T>(v) has some runtime cost. So if you use pointers to fundamental types in C++ then you likely are anyway seeking ways to lower the cost that complete classes might have. > Also, "If T is a pointer type, v shall be an rvalue of a pointer to > complete class type ... If T is an lvalue reference type, v shall be an > lvalue of a complete class type ... If T is an rvalue reference type, v > shall be an expression having a complete class type ..." (5.2.7p2). > Notice that v cannot have type void*, because void is neither complete, > nor a class type. To void* one should cast implicitly. Explicit cast looks not good like casting away constness and other such things. > >> I haven't heard of a good C++ use case, yet, that couldn't be packed > >> into an 'extern "C"' interface and where the implementation then > >> couldn't be done in proper C. A bit in the same spirit as some > >> specific functions for OS or compilers are implemented in assembler. > > > > I repeat. Just take boost. It is all good, well tested C++, mostly > > header-only libraries. Open source. Free to eyeball and to use. Lot > > of things from it went straight or with minor mods into C++2011. > > Then come back and tell us how you reimplement that thing in > > C or assembler. > > He's not suggesting that the entire thing be implemented in C, only that > any place in the code which has a good reason for using void* could be > split into two parts: a part in C++ that makes no use of void*, and a > part that could be implemented entirely in C. The C++ itself can wrap and hide void* usage lot better than in cooperation with C. > His words also imply that > there might also be place where void* is used without there being a > "good C++ use case", in which case the code can probably be replaced, > not by C code, but by C++ code using T*, where T is a template type > parameter. There certainly are lot of bad C++ code where void* or preprocessor macros should be replaced with templates. void* is a tool like any other. You can use it in harmful way. That is not the case with boost. > I don't know enough about boost internals to guess whether that would be > true, but it at least seems plausible to me. Boost is mostly header-only, the void* is mostly used privately. With C it would drop being header only or the void* usage would become public.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-09-06 07:07 -0400 |
| Message-ID | <k2a06a$aam$1@dont-email.me> |
| In reply to | #25989 |
On 09/06/2012 02:08 AM, � wrote: > On Thursday, September 6, 2012 6:44:40 AM UTC+3, James Kuyper wrote: >> On 09/05/2012 10:41 PM, � wrote: >>> On Friday, August 31, 2012 3:53:54 PM UTC+3, Jens Gustedt wrote: ... [Re: C++ restrictions on dynamic_cast<T>(v)] >> Also, "If T is a pointer type, v shall be an rvalue of a pointer to >> complete class type ... If T is an lvalue reference type, v shall be an >> lvalue of a complete class type ... If T is an rvalue reference type, v >> shall be an expression having a complete class type ..." (5.2.7p2). >> Notice that v cannot have type void*, because void is neither complete, >> nor a class type. > > To void* one should cast implicitly. ... In that paragraph, I'm talking about conversion from void*, not conversion to void*. Implicit conversion from void* to a pointer to an object type is allowed by C, but not by C++. > ... Explicit cast looks not good > like casting away constness and other such things. dynamic_cast<T>(v) shall not be used to cast away constness (5.2.7p1). -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2012-09-06 09:40 -0700 |
| Message-ID | <5326b7c7-c154-4a56-90ac-28aa1663e381@googlegroups.com> |
| In reply to | #25995 |
On Thursday, September 6, 2012 2:07:55 PM UTC+3, James Kuyper wrote: > On 09/06/2012 02:08 AM, � wrote: > > On Thursday, September 6, 2012 6:44:40 AM UTC+3, James Kuyper wrote: > >> Notice that v cannot have type void*, because void is neither complete, > >> nor a class type. > > > > To void* one should cast implicitly. ... > > In that paragraph, I'm talking about conversion from void*, not > conversion to void*. Implicit conversion from void* to a pointer to an > object type is allowed by C, but not by C++. Ok, my bad. You are correct. A proper C++ compiler just does not let me. If it lets to dynamic cast from void* then it is some sort of extension again.
[toc] | [prev] | [next] | [standalone]
| From | Dombo <dombo@disposable.invalid> |
|---|---|
| Date | 2012-09-02 23:16 +0200 |
| Message-ID | <k20i79$1j7$1@dont-email.me> |
| In reply to | #25586 |
Op 31-Aug-12 0:18, Jens Gustedt schreef: > Am 30.08.2012 19:49, schrieb Garrett Hartshaw: >> If on the other hand you wish to have an opaque pointer to an object >> of unknown type, or to an uninitialized memory region, then use 'void *'. > > A "void*" pointer is not "an uninitialized" memory region. It may well > already be initialized. > > But I am really surprised about this strong need of opaque pointer in > C++. If we follow the basic ideas of C++ such a usage should be very > rare in C++, no? Isn't that what "abstract base classes" have been > invented for? I've been programming C++ for almost 20 years now, I don't remember having ever having a need to use void* other than to interface with C code (typically when registering a callback on a C API, where context information can be passed back to the callback function via a void*).
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2012-09-05 20:27 -0700 |
| Message-ID | <e2935bc0-735d-432a-adf4-bf34dbda5d0f@googlegroups.com> |
| In reply to | #25766 |
On Monday, September 3, 2012 12:14:18 AM UTC+3, Dombo wrote: > Op 31-Aug-12 0:18, Jens Gustedt schreef: > > Am 30.08.2012 19:49, schrieb Garrett Hartshaw: > > >> If on the other hand you wish to have an opaque pointer to an object > >> of unknown type, or to an uninitialized memory region, then use 'void *'. > > > > A "void*" pointer is not "an uninitialized" memory region. It may well > > already be initialized. > > > > But I am really surprised about this strong need of opaque pointer in > > C++. If we follow the basic ideas of C++ such a usage should be very > > rare in C++, no? Isn't that what "abstract base classes" have been > > invented for? void* is the pointer to most abstract base class in C++. The base class that is common to all classes and fundamental types. > I've been programming C++ for almost 20 years now, I don't remember > having ever having a need to use void* other than to interface with C > code (typically when registering a callback on a C API, where context > information can be passed back to the callback function via a void*). There are very different levels of usage of C++. When I use some C++ framework like for example QT and only need the things that the framework already provides then I will have next to no need for void*. The typical uses in communication, serialization, containers, encryption, compression, threads and signals are all provided by the framework and the internal void* usage is hidden with templates or code generators. When something so abstract and mundane is missing and I need to implement it for generic case then the need for void* is there, nothing to replace it with.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-30 13:57 -0400 |
| Message-ID | <503FA997.7030703@verizon.net> |
| In reply to | #25530 |
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. 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. 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*).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-08-30 12:25 -0700 |
| Message-ID | <40b147d8-094c-48f9-87bd-308352775ebd@googlegroups.com> |
| In reply to | #25557 |
בתאריך יום חמישי, 30 באוגוסט 2012 18:57:44 UTC+1, מאת James Kuyper: > On 08/30/2012 08:54 AM, David Brown wrote: > > 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*). > The problem is that often void * are to objects, which you need to copy. For instance if you're writing a qsort() style sorting routine, or a general-purose compressor, you'll need to cast to unsigned char * to actually access the bits.
[toc] | [prev] | [next] | [standalone]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web