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 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-08-29 19:41 +0100 |
| Message-ID | <8uednXbIOtvs_6PNnZ2dnUVZ8uCdnZ2d@giganews.com> |
| In reply to | #25412 |
On 29/08/2012 19:34, James Kuyper wrote: > On 08/29/2012 02:16 PM, Leigh Johnston wrote: > ... >> ... The lack of >> implicit conversion *from* void* does not change the utility of void*. > > In C, implicit conversion to and from void* is the only feature that > void* has that justifies using it instead unsigned char*. In C++, half > of those implicit conversions are missing, and no compensating advantage > has been added to void*. How could it NOT change the utility? Having to use an explicit cast when converting from void* in C++ is not a problem; in fact it is an advantage: you are less likely to create a bug. void* has as much utility in C++ as it has in C. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-29 15:01 -0400 |
| Message-ID | <503E6720.5040301@verizon.net> |
| In reply to | #25415 |
On 08/29/2012 02:41 PM, Leigh Johnston wrote: > On 29/08/2012 19:34, James Kuyper wrote: >> On 08/29/2012 02:16 PM, Leigh Johnston wrote: >> ... >>> ... The lack of >>> implicit conversion *from* void* does not change the utility of void*. >> >> In C, implicit conversion to and from void* is the only feature that >> void* has that justifies using it instead unsigned char*. In C++, half >> of those implicit conversions are missing, and no compensating advantage >> has been added to void*. How could it NOT change the utility? > > Having to use an explicit cast when converting from void* in C++ is not > a problem; in fact it is an advantage: you are less likely to create a > bug. void* has as much utility in C++ as it has in C. I was very explicitly talking about advantages of void* in comparison with character pointer types, and this isn't one of them. [[un]signed] char* has that exact same feature, so why bother with void*?
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <casey_at_carter_dot_net@nospam.invalid> |
|---|---|
| Date | 2012-08-29 14:05 -0500 |
| Message-ID | <k1lp6a$d4e$1@dont-email.me> |
| In reply to | #25420 |
On 2012-08-29 14:01, James Kuyper wrote: > On 08/29/2012 02:41 PM, Leigh Johnston wrote: >> On 29/08/2012 19:34, James Kuyper wrote: >>> On 08/29/2012 02:16 PM, Leigh Johnston wrote: >>> ... >>>> ... The lack of >>>> implicit conversion *from* void* does not change the utility of void*. >>> >>> In C, implicit conversion to and from void* is the only feature that >>> void* has that justifies using it instead unsigned char*. In C++, half >>> of those implicit conversions are missing, and no compensating advantage >>> has been added to void*. How could it NOT change the utility? >> >> Having to use an explicit cast when converting from void* in C++ is not >> a problem; in fact it is an advantage: you are less likely to create a >> bug. void* has as much utility in C++ as it has in C. > > I was very explicitly talking about advantages of void* in comparison > with character pointer types, and this isn't one of them. [[un]signed] > char* has that exact same feature, so why bother with void*? > In C++, I cannot pass a void* as argument to a function that expects an [[un]signed] char* without casting. If you don't see this as a feature, then I understand why you think void* in C++ has no purpose.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-29 15:18 -0400 |
| Message-ID | <503E6AEE.9060200@verizon.net> |
| In reply to | #25421 |
On 08/29/2012 03:05 PM, Casey Carter wrote: > On 2012-08-29 14:01, James Kuyper wrote: >> On 08/29/2012 02:41 PM, Leigh Johnston wrote: >>> On 29/08/2012 19:34, James Kuyper wrote: >>>> On 08/29/2012 02:16 PM, Leigh Johnston wrote: >>>> ... >>>>> ... The lack of >>>>> implicit conversion *from* void* does not change the utility of void*. >>>> >>>> In C, implicit conversion to and from void* is the only feature that >>>> void* has that justifies using it instead unsigned char*. In C++, half >>>> of those implicit conversions are missing, and no compensating advantage >>>> has been added to void*. How could it NOT change the utility? >>> >>> Having to use an explicit cast when converting from void* in C++ is not >>> a problem; in fact it is an advantage: you are less likely to create a >>> bug. void* has as much utility in C++ as it has in C. >> >> I was very explicitly talking about advantages of void* in comparison >> with character pointer types, and this isn't one of them. [[un]signed] >> char* has that exact same feature, so why bother with void*? >> > > In C++, I cannot pass a void* as argument to a function that expects an > [[un]signed] char* without casting. If you don't see this as a feature, > then I understand why you think void* in C++ has no purpose. "Why bother with void*?" was an exaggeration - I should have said that less provocatively. I was not actually arguing that void* has no value in C++, only that it has less value in C++ than it has in C, where it has two advantages relative to unsigned char*, instead of only one. Also, as I mentioned in other messages (though not quoted here), in C++ templates take care of many things for which void* would be needed in C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-29 17:53 -0700 |
| Message-ID | <lnharlw67t.fsf@nuthaus.mib.org> |
| In reply to | #25412 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 08/29/2012 02:16 PM, Leigh Johnston wrote:
> ...
>> ... The lack of
>> implicit conversion *from* void* does not change the utility of void*.
>
> In C, implicit conversion to and from void* is the only feature that
> void* has that justifies using it instead unsigned char*. In C++, half
> of those implicit conversions are missing, and no compensating advantage
> has been added to void*. How could it NOT change the utility?
Another feature of void* is that it prevents you from dereferencing
it or performing pointer arithmetic on it. (Unless you're using
gcc without one of the "-std=..." or "-ansi" options.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-30 09:47 +0200 |
| Message-ID | <F7ydndNsBNddh6LNnZ2dnUVZ8jidnZ2d@lyse.net> |
| In reply to | #25412 |
On 29/08/2012 20:34, James Kuyper wrote: > On 08/29/2012 02:16 PM, Leigh Johnston wrote: > ... >> ... The lack of >> implicit conversion *from* void* does not change the utility of void*. > > In C, implicit conversion to and from void* is the only feature that > void* has that justifies using it instead unsigned char*. In C++, half > of those implicit conversions are missing, and no compensating advantage > has been added to void*. How could it NOT change the utility? > 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". 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. Your compiler will spend milliseconds reading your code, and doesn't care about style, logic, or readability. But programmers might spend days reading it or writing it, and they might need to do so again after years have passed. This is why you write code that says what it should say. This is why you never use an "unsigned char" to store a small number, but rather use an "uint8_t" - it does exactly the same thing, but makes the purpose clear.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-30 10:17 +0200 |
| Message-ID | <503F21A1.7000209@loria.fr> |
| In reply to | #25515 |
Am 30.08.2012 09:47, schrieb David Brown: > On 29/08/2012 20:34, James Kuyper wrote: >> On 08/29/2012 02:16 PM, Leigh Johnston wrote: >> ... >>> ... The lack of >>> implicit conversion *from* void* does not change the utility of void*. >> >> In C, implicit conversion to and from void* is the only feature that >> void* has that justifies using it instead unsigned char*. In C++, half >> of those implicit conversions are missing, and no compensating advantage >> has been added to void*. How could it NOT change the utility? >> > > 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". > > 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. Your compiler will spend milliseconds reading > your code, and doesn't care about style, logic, or readability. But > programmers might spend days reading it or writing it, and they might > need to do so again after years have passed. This is why you write code > that says what it should say. This is why you never use an "unsigned > char" to store a small number, but rather use an "uint8_t" - it does > exactly the same thing, but makes the purpose clear. You probably didn't see my reply to that either, this thread got somehow out of bounds. You just should push the button a bit further where Leigh stopped. He resolved the term "void" but didn't for "char". "char" is the smallest addressable unit in C and C++ (Pascal had byte for that, no) that is almost completely stripped of a semantic interpretation. Traditionally "char*" was also that, a pointer to a region of unspecific bytes. Nowadays "unsigned char*" serves that purpose, because it has the advantage of letting you access any bit (!) and bite of the data and you'd don't have confusion with the other completely orthogonal use of "char*" for C strings. Semantically I don't see much difference with that respect between "void*" and "unsigned char*". Both are pointers to unspecific data. They have different properties, sure, one of my interest in this thread was to know about what properties people actually use. (And from the C++ side I only got partial answers, yet.) And you are completely right with your argument that small numbers that are meant as such should use "uint8_t" or similar and not "unsigned char". Generally, in C you should use the semantic predefined typedef's as much as possible to mark your intent with a particular data. Jens
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-08-31 05:59 -0700 |
| Message-ID | <882afaec-6556-4e87-ba5e-368866aa61b4@e9g2000vbv.googlegroups.com> |
| In reply to | #25516 |
On Aug 30, 9:17 am, Jens Gustedt <jens.gust...@loria.fr> wrote: > Am 30.08.2012 09:47, schrieb David Brown: > > On 29/08/2012 20:34, James Kuyper wrote: > >> On 08/29/2012 02:16 PM, Leigh Johnston wrote: <snip> > > 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". > > > 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. Your compiler will spend milliseconds reading > > your code, and doesn't care about style, logic, or readability. But > > programmers might spend days reading it or writing it, and they might > > need to do so again after years have passed. This is why you write code > > that says what it should say. This is why you never use an "unsigned > > char" to store a small number, but rather use an "uint8_t" - it does > > exactly the same thing, but makes the purpose clear. ugly though > You probably didn't see my reply to that either, this thread got > somehow out of bounds. > > You just should push the button a bit further where Leigh stopped. He > resolved the term "void" but didn't for "char". "char" is the smallest > addressable unit in C and C++ (Pascal had byte for that, no) no. Pascal did not have a byte type > that is > almost completely stripped of a semantic interpretation. > > Traditionally "char*" was also that, a pointer to a region of > unspecific bytes. Nowadays "unsigned char*" serves that purpose, > because it has the advantage of letting you access any bit (!) and > bite of the data and you'd don't have confusion with the other > completely orthogonal use of "char*" for C strings. which is why I use a byte or octet typedef > Semantically I don't see much difference with that respect between > "void*" and "unsigned char*". Both are pointers to unspecific > data. They have different properties, sure, one of my interest in this > thread was to know about what properties people actually use. (And > from the C++ side I only got partial answers, yet.) > > And you are completely right with your argument that small numbers > that are meant as such should use "uint8_t" or similar and not > "unsigned char". Generally, in C you should use the semantic > predefined typedef's as much as possible to mark your intent with a > particular data.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2012-08-31 14:29 +0000 |
| Message-ID | <OS30s.3679$vi7.204@fed03.iad> |
| In reply to | #25641 |
Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
>On Aug 30, 9:17=A0am, Jens Gustedt <jens.gust...@loria.fr> wrote:
>
>> You just should push the button a bit further where Leigh stopped. He
>> resolved the term "void" but didn't for "char". "char" is the smallest
>> addressable unit in C and C++ (Pascal had byte for that, no)
>
>no. Pascal did not have a byte type
Well, perhaps not in the "standard", but it was a common extension:
e.g. VAX Pascal:
[INHERIT('SYS$SHARE:STARLET'),
IDENT('V03-001')]
PROGRAM Users( OUTPUT );
TYPE
Unsigned_byte = [BYTE] 0..255;
Signed_word = [WORD] -32768..+32767;
Unsigned_word = [WORD] 0..65535;
jpi$item = [BYTE(12)] PACKED RECORD
Buffer_length: [POS(0)] Unsigned_word;
Item_code: [POS(16)] Unsigned_word;
Buffer_address: [POS(32),LONG,UNSAFE] UNSIGNED;
Buflen_address: [POS(64),LONG,UNSAFE] UNSIGNED;
END;
Terminfo_rec = [BYTE(80)] RECORD
Csp_id: [BYTE(04),POS(0),KEY(0)] PACKED ARRAY [1..04] OF CHAR;
Junk: [BYTE(27)] PACKED ARRAY [1..27] OF CHAR;
Short: [BYTE(09)] PACKED ARRAY [1..09] OF CHAR;
Long: [BYTE(21)] PACKED ARRAY [1..21] OF CHAR;
Csp_long: [BYTE(07)] PACKED ARRAY [1..07] OF CHAR;
Filler: [BYTE(12)] PACKED ARRAY [1..12] OF CHAR;
END;
Csp_stat_rec = [LONG] PACKED RECORD
Ss_status: [POS(00)] Unsigned_word;
Port: [POS(16)] Unsigned_byte;
Machine: [POS(24)] Unsigned_byte;
END;
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-09-01 06:45 -0700 |
| Message-ID | <8d30aabe-1858-44cb-8cc8-cecc8511ede1@13g2000vbf.googlegroups.com> |
| In reply to | #25645 |
On Aug 31, 3:29 pm, sc...@slp53.sl.home (Scott Lurndal) wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
> >On Aug 30, 9:17=A0am, Jens Gustedt <jens.gust...@loria.fr> wrote:
>
> >> You just should push the button a bit further where Leigh stopped. He
> >> resolved the term "void" but didn't for "char". "char" is the smallest
> >> addressable unit in C and C++ (Pascal had byte for that, no)
>
> >no. Pascal did not have a byte type
>
> Well, perhaps not in the "standard", but it was a common extension:
>
> e.g. VAX Pascal:
>
> [INHERIT('SYS$SHARE:STARLET'),
> IDENT('V03-001')]
>
> PROGRAM Users( OUTPUT );
>
> TYPE
> Unsigned_byte = [BYTE] 0..255;
> Signed_word = [WORD] -32768..+32767;
> Unsigned_word = [WORD] 0..65535;
>
> jpi$item = [BYTE(12)] PACKED RECORD
> Buffer_length: [POS(0)] Unsigned_word;
> Item_code: [POS(16)] Unsigned_word;
> Buffer_address: [POS(32),LONG,UNSAFE] UNSIGNED;
> Buflen_address: [POS(64),LONG,UNSAFE] UNSIGNED;
> END;
>
> Terminfo_rec = [BYTE(80)] RECORD
> Csp_id: [BYTE(04),POS(0),KEY(0)] PACKED ARRAY [1..04] OF CHAR;
> Junk: [BYTE(27)] PACKED ARRAY [1..27] OF CHAR;
> Short: [BYTE(09)] PACKED ARRAY [1..09] OF CHAR;
> Long: [BYTE(21)] PACKED ARRAY [1..21] OF CHAR;
> Csp_long: [BYTE(07)] PACKED ARRAY [1..07] OF CHAR;
> Filler: [BYTE(12)] PACKED ARRAY [1..12] OF CHAR;
> END;
>
> Csp_stat_rec = [LONG] PACKED RECORD
> Ss_status: [POS(00)] Unsigned_word;
> Port: [POS(16)] Unsigned_byte;
> Machine: [POS(24)] Unsigned_byte;
> END;
good grief. *Thats* Pascal! Looks more like CORAL-66
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-30 08:05 -0400 |
| Message-ID | <k1nktt$744$1@dont-email.me> |
| In reply to | #25515 |
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. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-30 14:54 +0200 |
| Message-ID | <R5ednQu53dU__6LNnZ2dnUVZ8iWdnZ2d@lyse.net> |
| In reply to | #25526 |
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? A "char *" says "this is a pointer to a character", while a "void *" says "this is a pointer to an unknown type". These convey different meanings to the reader. Clearly there is a certain amount of style - and therefore differing personal opinions - in these matters. But you cannot deny the fact that different names for the same thing convey different meanings beyond their function.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-30 18:13 +0200 |
| Message-ID | <503F9144.2060001@loria.fr> |
| In reply to | #25530 |
Am 30.08.2012 14:54, schrieb David Brown: > A "char *" says "this is a pointer to a character", while a "void *" > says "this is a pointer to an unknown type". These convey different > meanings to the reader. No a "char*" doesn't say pointer to character, that is you who is putting the sematics here. It says "pointer to char" and nothing else. (and "unsigned char*" does even less so define a pointer to an "unsigned character", whatever that would be.) > Clearly there is a certain amount of style - and therefore differing > personal opinions - in these matters. But you cannot deny the fact that > different names for the same thing convey different meanings beyond > their function. 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". Jens
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2012-08-30 18:39 +0100 |
| Message-ID | <bfWdnbgtmYvMOKLNnZ2dnUVZ8uednZ2d@giganews.com> |
| In reply to | #25545 |
On 30/08/2012 17:13, Jens Gustedt wrote: > Am 30.08.2012 14:54, schrieb David Brown: >> A "char *" says "this is a pointer to a character", while a "void *" >> says "this is a pointer to an unknown type". These convey different >> meanings to the reader. > > No a "char*" doesn't say pointer to character, that is you who is > putting the sematics here. It says "pointer to char" and nothing > else. (and "unsigned char*" does even less so define a pointer to an > "unsigned character", whatever that would be.) > >> Clearly there is a certain amount of style - and therefore differing >> personal opinions - in these matters. But you cannot deny the fact that >> different names for the same thing convey different meanings beyond >> their function. > > Would you be more comfortable if the standard introduced a type alias > "byte" for "unsigned char"? You are forgetting that in C++ we also have class types so we want pointers to "objects" not just pointers to "bytes". Using void* to indicate that it is a pointer to anything (including any class type) is perfectly reasonable C++ IMO. void* is alive and well in C++ Land even if it is used less than in C Land. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Garrett Hartshaw <ghartshaw@gmail.com> |
|---|---|
| Date | 2012-08-30 13:49 -0400 |
| Message-ID | <k1o98p$9qf$1@dont-email.me> |
| In reply to | #25545 |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/30/2012 12:13 PM, Jens Gustedt wrote: > Am 30.08.2012 14:54, schrieb David Brown: >> A "char *" says "this is a pointer to a character", while a "void >> *" says "this is a pointer to an unknown type". These convey >> different meanings to the reader. > > No a "char*" doesn't say pointer to character, that is you who is > putting the sematics here. It says "pointer to char" and nothing > else. (and "unsigned char*" does even less so define a pointer to > an "unsigned character", whatever that would be.) > '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". 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 *'. 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'. >> Clearly there is a certain amount of style - and therefore >> differing personal opinions - in these matters. But you cannot >> deny the fact that different names for the same thing convey >> different meanings beyond their function. > > 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". > > Jens > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQP6eRAAoJEP8JewLaHvzSOKkIAKpJG+LK1H1IcKMNdIrbzrgt +GZskz9DpN5YUUCdAWWI1XbNwm0qJnmmzWvXEBm8ajDnyzwoBnBo89ss0KrbXC9+ J5TfAP21aXFCdPcbGpCVD8LvwKvrj6mu0s5vTkqh+BNfPBfOVKGkvvCL5EpsE8tw f0mEoZf6vkaHez9A5GFW4j2RJh5wkJXy9s8fnPiY7pUqXGoIGF0JyUDo9Y1IQq5b //yCE9qiLEnDbjthwyexkdqOIHv9VTj0TqkATeKp2wZIL3h6d6KGBozNrJmbmeJN pxSYSBz9+pTOxP7ELLp2uWQcC9ED7JeCOdYwu0x/0Cyg2T0qdpPS9EQQYn4x4kQ= =8ONX -----END PGP SIGNATURE-----
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-30 14:07 -0700 |
| Message-ID | <lnehmoulzu.fsf@nuthaus.mib.org> |
| In reply to | #25556 |
Garrett Hartshaw <ghartshaw@gmail.com> writes:
[...]
> 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'")
[...]
Strictly speaking, `unsigned char *` and `uint8_t *` are not
interchangeable. `unsigned char` is one byte by definition.
`uint8_t` is 8 bits by definition -- and if CHAR_BIT > 8, then
`uint8_t` will not exist.
C's treatment of characters is a bit of a mess IMHO, partly due to
changes in character semantics since C was first defined. When we
could assume 7-bit ASCII (or 8-bit EBCDIC with plain char being
unsigned), C's model worked. With the introduction of ASCII-based
8-bit character representations, with plain char remaining signed
on many systems, things started getting confusing.
Conflating the concepts of a single character and a single
fundamental storage unit into the types `char`, `signed char`, and
`unsigned char`, all required to be the same size, no longer makes
as much sense now as it did then.
If I were designing a C-like language from scratch today, I'd
separate the concepts of characters and fundamental storage units.
I'd probably also separate the concept of very short integers
from both. So `char`, `byte`, and `int8` might be three distinct
and incompatible types.
Making such a change to C now would break so much code that the
resulting language could not reasonably be called "C"; it ain't
gonna happen.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-31 11:13 +0200 |
| Message-ID | <_dWdnZRkJK_wHd3NnZ2dnUVZ8k2dnZ2d@lyse.net> |
| In reply to | #25575 |
On 30/08/2012 23:07, Keith Thompson wrote: > Garrett Hartshaw <ghartshaw@gmail.com> writes: > [...] >> 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'") > [...] > > Strictly speaking, `unsigned char *` and `uint8_t *` are not > interchangeable. `unsigned char` is one byte by definition. > `uint8_t` is 8 bits by definition -- and if CHAR_BIT > 8, then > `uint8_t` will not exist. > > C's treatment of characters is a bit of a mess IMHO, partly due to > changes in character semantics since C was first defined. When we > could assume 7-bit ASCII (or 8-bit EBCDIC with plain char being > unsigned), C's model worked. With the introduction of ASCII-based > 8-bit character representations, with plain char remaining signed > on many systems, things started getting confusing. > > Conflating the concepts of a single character and a single > fundamental storage unit into the types `char`, `signed char`, and > `unsigned char`, all required to be the same size, no longer makes > as much sense now as it did then. > > If I were designing a C-like language from scratch today, I'd > separate the concepts of characters and fundamental storage units. > I'd probably also separate the concept of very short integers > from both. So `char`, `byte`, and `int8` might be three distinct > and incompatible types. > > Making such a change to C now would break so much code that the > resulting language could not reasonably be called "C"; it ain't > gonna happen. > This is pretty much exactly what Python did with Python 3. Previously, strings and characters were also used as raw data - now they are separate types. But I agree that it is not going to happen in C. I would be happy with a "byte" being officially defined as the type for memory units, however. Maybe "data8_t" would be more appropriate - then we could have "data16_t", etc., as well.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-31 13:41 -0700 |
| Message-ID | <lnbohqu745.fsf@nuthaus.mib.org> |
| In reply to | #25624 |
David Brown <david@westcontrol.removethisbit.com> writes:
> On 30/08/2012 23:07, Keith Thompson wrote:
[...]
>> If I were designing a C-like language from scratch today, I'd
>> separate the concepts of characters and fundamental storage units.
>> I'd probably also separate the concept of very short integers
>> from both. So `char`, `byte`, and `int8` might be three distinct
>> and incompatible types.
>>
>> Making such a change to C now would break so much code that the
>> resulting language could not reasonably be called "C"; it ain't
>> gonna happen.
>
> This is pretty much exactly what Python did with Python 3. Previously,
> strings and characters were also used as raw data - now they are
> separate types. But I agree that it is not going to happen in C.
>
> I would be happy with a "byte" being officially defined as the type for
> memory units, however. Maybe "data8_t" would be more appropriate - then
> we could have "data16_t", etc., as well.
The name "data8_t" works only if a byte is 8 bits, something that's
not guaranteed by the language.
If you want to require CHAR_BIT to be exactly 8, there's an argument
to be made for that, though it would exclude some systems (mostly
DSPs (digital signal processors), I think) from having conforming
C implementations.
Otherwise, the size in bits of the fundamental memory unit *has*
to be implementation-defined.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-09-03 10:28 +0200 |
| Message-ID | <H6WdndSKw73-99nNnZ2dnUVZ8uudnZ2d@lyse.net> |
| In reply to | #25670 |
On 31/08/2012 22:41, Keith Thompson wrote: > David Brown <david@westcontrol.removethisbit.com> writes: >> On 30/08/2012 23:07, Keith Thompson wrote: > [...] >>> If I were designing a C-like language from scratch today, I'd >>> separate the concepts of characters and fundamental storage units. >>> I'd probably also separate the concept of very short integers >>> from both. So `char`, `byte`, and `int8` might be three distinct >>> and incompatible types. >>> >>> Making such a change to C now would break so much code that the >>> resulting language could not reasonably be called "C"; it ain't >>> gonna happen. >> >> This is pretty much exactly what Python did with Python 3. Previously, >> strings and characters were also used as raw data - now they are >> separate types. But I agree that it is not going to happen in C. >> >> I would be happy with a "byte" being officially defined as the type for >> memory units, however. Maybe "data8_t" would be more appropriate - then >> we could have "data16_t", etc., as well. > > The name "data8_t" works only if a byte is 8 bits, something that's > not guaranteed by the language. > > If you want to require CHAR_BIT to be exactly 8, there's an argument > to be made for that, though it would exclude some systems (mostly > DSPs (digital signal processors), I think) from having conforming > C implementations. That's correct. If we exclude a few dinosaur machines (and I hope we can!), almost all current targets have 8-bit "bytes". The exceptions that I know of are, as you say, DSP architectures with either 16-bit or even 32-bit minimum access sizes. It would also be quite simple to use 9-bit (or multiples thereof) in soft processors in FPGAs, since memory banks there are normally 9-bit wide. I would suggest having these "data?_t" types work in the same way as int?_t types today - they are implemented if and only if the target supports them. On a DSP you might then have a data16_t but no data8_t. Of course, that means that if you write your code using data8_t, it will not be portable to a DSP. But this is a *good* thing, not a problem. When moving the code to the DSP, the compiler will complain, and you have to change the code to use data16_t (or even data32_t). This is much better than the current situation, where the "portable" code will use "unsigned char", it will compile fine on the DSP, and it will almost certainly fail to work as expected. > > Otherwise, the size in bits of the fundamental memory unit *has* > to be implementation-defined. >
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2012-08-31 10:55 -0500 |
| Message-ID | <k1qmvg$30m$1@news.albasani.net> |
| In reply to | #25575 |
On 8/30/2012 4:07 PM, Keith Thompson wrote: > Garrett Hartshaw <ghartshaw@gmail.com> writes: > [...] >> 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'") > [...] > > Strictly speaking, `unsigned char *` and `uint8_t *` are not > interchangeable. `unsigned char` is one byte by definition. > `uint8_t` is 8 bits by definition -- and if CHAR_BIT > 8, then > `uint8_t` will not exist. > > C's treatment of characters is a bit of a mess IMHO, partly due to > changes in character semantics since C was first defined. When we > could assume 7-bit ASCII (or 8-bit EBCDIC with plain char being > unsigned), C's model worked. With the introduction of ASCII-based > 8-bit character representations, with plain char remaining signed > on many systems, things started getting confusing. > > Conflating the concepts of a single character and a single > fundamental storage unit into the types `char`, `signed char`, and > `unsigned char`, all required to be the same size, no longer makes > as much sense now as it did then. > > If I were designing a C-like language from scratch today, I'd > separate the concepts of characters and fundamental storage units. > I'd probably also separate the concept of very short integers > from both. So `char`, `byte`, and `int8` might be three distinct > and incompatible types. > my own language (BGBScript) more or less does this. char is 16-bits (more-or-less, 1), byte is 8-bits unsigned, and sbyte is 8-bits signed. 'int8' is also a type but is essentially an alias to sbyte. 'char8' also exists as an 8-bit character (also a distinct type, and is mostly intended for ASCII). 1: char is often interpreted as a single UTF-16 codepoint for storage reasons, but may often be 24-bit internally, and strings may often be stored using UTF-8 to save space (and still tend to be null-terminated, note that this can emulate the external behavior of a length-bound UTF-16 string, but on-average uses around 1/2 as much memory). > Making such a change to C now would break so much code that the > resulting language could not reasonably be called "C"; it ain't > gonna happen. > yep. it is about like the issues of making C be based on a module-import system (rather than including headers and linking objects into binaries), and generating target neutral VM bytecode. maybe it can be done, theoretically, but it is not likely an easy task to do so without violating the standards (or at least adding some fairly ugly extensions).
[toc] | [prev] | [next] | [standalone]
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web