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 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2012-08-28 15:56 -0700 |
| Message-ID | <4ede52d8-fb1f-4dc3-a4a8-5fa3c91359b8@googlegroups.com> |
| In reply to | #25324 |
On Wednesday, August 29, 2012 1:18:07 AM UTC+3, James Kuyper wrote: > Specify that plain 'int' is signed in bit fields, just as it is > everywhere else. Specify the size of the allocation unit. Specify 2's > complement representation for signed integer types. Prohibit > representations that have padding bits or allow trap representations. > Mandate big-endian order (or little endian order - but don't allow both > - don't give implementations a choice) prohibiting all other orders. > Specify that bits are assigned to bit-fields in order from high-order > bits to low-order bits (or vice-versa - but pick one as allowed by the > standard, and prohibit the other). Continue to require, as C already > does, but C++ does not, that consecutive bit-fields within the same > allocation unit be allocated adjacent sets of bits. Either mandate or > prohibit bit-fields that cross allocation unit boundaries - but choose one. Why it is needed and what it helps? Two platforms do not operate on same memory. When two platforms communicate then there is either some protocol or file format involved. So it is up to the protocol or file format specification to specify the bits not up to C or C++ standards. To keep things internally in memory bit-by bit like in some protocol or file format would be terribly inefficient.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 19:09 -0400 |
| Message-ID | <503D4FC3.1060401@verizon.net> |
| In reply to | #25328 |
On 08/28/2012 06:56 PM, Öö Tiib wrote: > On Wednesday, August 29, 2012 1:18:07 AM UTC+3, James Kuyper wrote: >> Specify that plain 'int' is signed in bit fields, just as it is >> everywhere else. Specify the size of the allocation unit. Specify 2's >> complement representation for signed integer types. Prohibit >> representations that have padding bits or allow trap representations. >> Mandate big-endian order (or little endian order - but don't allow both >> - don't give implementations a choice) prohibiting all other orders. >> Specify that bits are assigned to bit-fields in order from high-order >> bits to low-order bits (or vice-versa - but pick one as allowed by the >> standard, and prohibit the other). Continue to require, as C already >> does, but C++ does not, that consecutive bit-fields within the same >> allocation unit be allocated adjacent sets of bits. Either mandate or >> prohibit bit-fields that cross allocation unit boundaries - but choose one. > > Why it is needed and what it helps? Two platforms do not operate > on same memory. When two platforms communicate then there is > either some protocol or file format involved. So it is up to the > protocol or file format specification to specify the bits not up > to C or C++ standards. With the above changes (and a few additional ones I didn't bother to specify), there could be a struct definition that uniquely corresponds to any given protocol or file format, making reading and writing such files, or parsing/writing such protocols, a lot easier. With the language as currently written, structs are useless for portable code of that kind, only bit-wise operations on arrays of unsigned char can be used (even that breaks down if CHAR_BIT != 8, but that's rather uncommon). > To keep things internally in memory bit-by bit like in some protocol > or file format would be terribly inefficient. You can always read it into a bit-packed struct, and then unpack it into a more efficient structure. The code would still be a lot simpler than what I currently have to write.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 19:01 -0400 |
| Message-ID | <503D4DE2.4030900@verizon.net> |
| In reply to | #25324 |
On 08/28/2012 06:18 PM, James Kuyper wrote: > On 08/28/2012 05:28 PM, Jens Gustedt wrote: >> Am 28.08.2012 22:56, schrieb James Kuyper: ... >>> Even in C, there's a lot more than just two possible orders... > > Sorry, that was an editing error. The previous comment was the correct > one: "C++ ... [allows] a lot more than two different possible orders" When I wrote that reply , I couldn't easily see my previous message, only the part that you had quoted. I assumed that I'd left a stupid editing error in my message. That assumption was incorrect. >> Effectively, I read this phrase >> >> The order of allocation of bit-fields within a unit (high-order to >> low-order or low-order to high-order) is implementation-defined. >> >> that an implementation would have to choose one of the orderings once >> and for all and apply this to all cases consistently. My comment was in fact perfectly correct. The key point that you missed was that the order is specified only "within a unit", not "across units". If the unit is 16 bits long, then "a" and "b" must both be in the first allocation unit, and "c", "d", and "e" must be in the second allocation unit, but "a" could occupy either the first byte or the second byte of the first unit, and "e" could occupy either the first byte or the second byte of the second unit. There's no good reason for an implementation to make inconsistent choices in the two units, but it's not required to make consistent ones, either. "ab cde" and "ba ecd" are plausible possibilities, "ab ecd" and "ba cde" are implausible but permitted possibilities, while (assuming 16-bit allocation units) "edc ba" is NOT a possibility. With 32-bit allocation units, "edcba" is a possibility.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-29 09:25 +0200 |
| Message-ID | <Kp6dnbn7FKKUWaDNnZ2dnUVZ8sCdnZ2d@lyse.net> |
| In reply to | #25261 |
On 28/08/2012 18:45, Jens Gustedt wrote:
> Am 28.08.2012 17:57, schrieb David Brown:
>>> In C this
>>>
>>> struct {
>>> unsigned a : 8;
>>> unsigned b : 8;
>>> unsigned c : 4;
>>> unsigned d : 4;
>>> unsigned e : 8;
>>> }
>>>
>>> should do what you want, provided CHAR_BITS is 8. Wouldn't that be
>>> acceptable for you? I find it even clearer in its intent.
>>>
>>> (Bitfields are guaranteed to have no padding and uint8_t is pretty
>>> useless other than to guarantee that padding property or that its size
>>> is 1.)
>>>
>>
>> In practice, this works fine - but the guarantees in the standard are
>> weak. I /use/ bitfields regularly, with different types and enum types
>> in the bitfields. But I would prefer that the standards said that such
>> usage was completely well-defined.
>
> can't agree on that, the standard describes exactly how this has to be
> layed out. (well it could decide to pad it to 64 bit, but that's it.)
>
I am beginning to suspect that the bitfields are a little better
specified than I had thought... but I still see problems.
The big unspecified issue is the ordering of the bitfields, as shown by
another poster, which is often different according to the endianness of
the target. It can also vary between compilers for the same target, and
even between compiler versions on the same target (it changed between
two versions of MS' C compiler on x86). The standards say it is
"implementation dependent", which is a real problem if you want to use
bitfields for hardware register access, or within communication
protocols, filesystems, file formats, etc.
(I am assuming 8-bit char here, though I occasionally have to deal with
targets with 16-bit or even 32-bit char - these are typically DSP's, and
they are typically hideous to work with anyway.)
Back to the padding, alignment, etc. I gather you are correct that the
standards guarantees that no padding is added as long as the fields fit
within the space. But there are a few points I find problematic (I am
referring here to the C99 standards, document WG14/N1256 of September
2007). In section 6.7.2.1 "Structure and union specifiers", we have:
4. "Abit-field shall have a type that is a qualified or unqualified
version of _Bool, signed int, unsigned int,orsome other
implementation-defined type."
Most compilers I have used allow different types, but it is
implementation dependent. In particular, if I want an 8-bit struct
consisting of bitfields, I will normally use bitfields of type
"uint8_t". Using "unsigned int" is likely to make the whole struct
16-bit or 32-bit, depending on sizeof(int). I don't see why this is not
specified exactly (I believe the use of other bitfield types /is/
specified in C++, but I haven't read the standards).
10. "An implementation may allocate anyaddressable storage unit large
enough to hold a bit-field. If enough space remains, a bit-field that
immediately follows another bit-field in a structure shall be packed
into adjacent bits of the same unit. If insufficient space remains,
whether a bit-field that does not fit is put into the next unit or
overlaps adjacent units is implementation-defined. The order of
allocation of bit-fields within a unit (high-order to low-order or
low-order to high-order) is implementation-defined. The alignment of the
addressable storage unit is unspecified."
That's a lot of "unspecified" and "implementation-defined" ! The size
of bitfield container units, and their alignment, is not specified. It
is not even guaranteed to be the same alignment as is otherwise used for
that type (which is also implementation dependent).
The sizes of the "units" are not specified, which means that the whole
bitfield can have different sizes according to target. This could be
particularly bad if you have a bitfield ordering that does not match the
endianness - simply be choosing different unit sizes, the compiler could
make significantly different layouts. (I can't think off-hand of
targets that have this mixture, but it is certainly legal - and may
perhaps be used on targets such as the PPC in little-endian mode.)
And if you throw "volatile" into the mix - as you might well do for
hardware register access - it gets even worse. The size of "unit" used
to access the hardware can be critically important. Recent versions of
gcc make this explicit - the field will be accessed using a data size to
match the underlying type used in the bitfield. But that is just one
compiler - it is not in the standards.
mvh.,
David
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 12:39 -0400 |
| Message-ID | <503CF454.6010207@verizon.net> |
| In reply to | #25239 |
On 08/28/2012 09:32 AM, David Brown wrote: ... > Ultimately, I'd like some way to tell the compiler what data, pointers > and/or types can alias what. If you put two types in a union, within the scope of that union declaration a conforming implementation must take aliasing between those two types into consideration any time it's dealing with pointers that could be pointing at different members of the same union object. This won't help you, of course, if you want it to consider aliasing in contexts where it's impossible that they refer to the same union object.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-29 09:41 +0200 |
| Message-ID | <aeOdnYHHr_whWqDNnZ2dnUVZ8sydnZ2d@lyse.net> |
| In reply to | #25259 |
On 28/08/2012 18:39, James Kuyper wrote: > On 08/28/2012 09:32 AM, David Brown wrote: > ... >> Ultimately, I'd like some way to tell the compiler what data, pointers >> and/or types can alias what. > > If you put two types in a union, within the scope of that union > declaration a conforming implementation must take aliasing between those > two types into consideration any time it's dealing with pointers that > could be pointing at different members of the same union object. > Correct me if I'm wrong, but I believe this is actually just an "unwritten rule" that all compilers have agreed to follow. If you make a union of two types (say, a "float" and a "uint32_t"), then the compiler must put the two entries in the same space, and the programmer may access either field. But if the program writes to one field, then reads to the other field are undefined according to the standards. The compiler can therefore ignore aliasing issues, and even ignore the data completely, if it sees this situation. Type-punning unions only work because all compiler vendors make it work - not because the standards say so. Section 6.2.6.1 "Representations of types", C99: 7. When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members takeunspecified values. A special exception is made if the members of the union are structs which contain compatible types at the start - then accessing the common initial parts of the structs is legal. > This won't help you, of course, if you want it to consider aliasing in > contexts where it's impossible that they refer to the same union object. > That's the real problem.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-29 10:19 +0200 |
| Message-ID | <503DD089.2020106@loria.fr> |
| In reply to | #25359 |
Am 29.08.2012 09:41, schrieb David Brown: > On 28/08/2012 18:39, James Kuyper wrote: >> On 08/28/2012 09:32 AM, David Brown wrote: >> ... >>> Ultimately, I'd like some way to tell the compiler what data, pointers >>> and/or types can alias what. >> >> If you put two types in a union, within the scope of that union >> declaration a conforming implementation must take aliasing between those >> two types into consideration any time it's dealing with pointers that >> could be pointing at different members of the same union object. >> > > Correct me if I'm wrong, but I believe this is actually just an > "unwritten rule" that all compilers have agreed to follow. If you make > a union of two types (say, a "float" and a "uint32_t"), then the > compiler must put the two entries in the same space, and the programmer > may access either field. But if the program writes to one field, then > reads to the other field are undefined according to the standards. The > compiler can therefore ignore aliasing issues, and even ignore the data > completely, if it sees this situation. Type-punning unions only work > because all compiler vendors make it work - not because the standards > say so. No, this is not an "unwritten rule" for C. C99 originally had a wording that could be interpreted as you state. A corrigendum has made it clear that it is not intended. Type-punning in C works as long as the value that you are reading is valid for the type through which you are doing so. A footnote in the C standard clarifies that: 95) If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be a trap representation. So if you happen to have a platform that implements uint32_t (or another type that has not trap and no padding) it is always safe to use a union that overlays your data with such a beast or even an array of these. You'd just have to be careful when interpreting this data, but it is not UB as such. AFAIK C++ stayed with the original wording, and so now the interpretation of union is different in both languages. Basically the only use of union in C++ would be to save storage in low level implementations. (real highlevel C++ has completely different means to achieve that.) The main intent of unions in C, namely type-punning, isn't guaranteed in C++. Jens
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-29 10:44 +0200 |
| Message-ID | <__mdnROQP6wWS6DNnZ2dnUVZ8qCdnZ2d@lyse.net> |
| In reply to | #25363 |
On 29/08/2012 10:19, Jens Gustedt wrote: > Am 29.08.2012 09:41, schrieb David Brown: >> On 28/08/2012 18:39, James Kuyper wrote: >>> On 08/28/2012 09:32 AM, David Brown wrote: >>> ... >>>> Ultimately, I'd like some way to tell the compiler what data, pointers >>>> and/or types can alias what. >>> >>> If you put two types in a union, within the scope of that union >>> declaration a conforming implementation must take aliasing between those >>> two types into consideration any time it's dealing with pointers that >>> could be pointing at different members of the same union object. >>> >> >> Correct me if I'm wrong, but I believe this is actually just an >> "unwritten rule" that all compilers have agreed to follow. If you make >> a union of two types (say, a "float" and a "uint32_t"), then the >> compiler must put the two entries in the same space, and the programmer >> may access either field. But if the program writes to one field, then >> reads to the other field are undefined according to the standards. The >> compiler can therefore ignore aliasing issues, and even ignore the data >> completely, if it sees this situation. Type-punning unions only work >> because all compiler vendors make it work - not because the standards >> say so. > > No, this is not an "unwritten rule" for C. C99 originally had a > wording that could be interpreted as you state. A corrigendum has made > it clear that it is not intended. Type-punning in C works as long as > the value that you are reading is valid for the type through which you > are doing so. The great thing about standards is that there are so many to choose from! > > A footnote in the C standard clarifies that: > > 95) If the member used to read the contents of a union object is not > the same as the member last used to store a value in the object, the > appropriate part of the object representation of the value is > reinterpreted as an object representation in the new type as described > in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be > a trap representation. > It sounds very much like someone wrote down the "unwritten rule", which was nice of them. > So if you happen to have a platform that implements uint32_t (or > another type that has not trap and no padding) it is always safe to > use a union that overlays your data with such a beast or even an array > of these. You'd just have to be careful when interpreting this data, > but it is not UB as such. > > AFAIK C++ stayed with the original wording, and so now the > interpretation of union is different in both languages. Basically the > only use of union in C++ would be to save storage in low level > implementations. (real highlevel C++ has completely different means to > achieve that.) > > The main intent of unions in C, namely type-punning, isn't guaranteed > in C++. I don't know that type-punning was the "main intent" of unions - I think saving storage space was the main motivation. Type-punning just became a popular use of it, and has been even more important since alias analysis has broken older methods of type-punning. This is backed up by the fact that unions for saving space have been around as long as C, but type-punning unions have only been officially supported since a correction to C99. I guess with C++, the "correct" way to handle type-punning is with static_cast. I don't know whether this guarantees the same alias-safe characteristics as a type-punning union in C. > > Jens >
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-29 12:24 +0200 |
| Message-ID | <503DEDD2.3010201@loria.fr> |
| In reply to | #25365 |
Am 29.08.2012 10:44, schrieb David Brown: > On 29/08/2012 10:19, Jens Gustedt wrote: > The great thing about standards is that there are so many to choose from! :) > I don't know that type-punning was the "main intent" of unions - I think > saving storage space was the main motivation. I was perhaps pushing a bit too far, but type punning has been around since the beginning. And if I understand it right it was the idea of the committee to affirm that it always had been an intented use case, and that just the wording in the standard had been too ambiguous. > Type-punning just became > a popular use of it, and has been even more important since alias > analysis has broken older methods of type-punning. This is backed up by > the fact that unions for saving space have been around as long as C, but > type-punning unions have only been officially supported since a > correction to C99. The most prominent use case of type-puning is the network layer in POSIX and probably all its predecessors. It is really there since the beginning. > I guess with C++, the "correct" way to handle type-punning is with > static_cast. I don't know whether this guarantees the same alias-safe > characteristics as a type-punning union in C. No, I don't think that static_cast will do. Probably reinterpret_cast would be better. But I am not sure that I personally would be capable to come up with code that is strictly conforming to C++ and that would deal with the socket layer correctly. Jens
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-09-07 06:13 -0700 |
| Message-ID | <kfnvcfqkmcd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #25368 |
Jens Gustedt <jens.gustedt@loria.fr> writes: > Am 29.08.2012 10:44, schrieb David Brown: >> On 29/08/2012 10:19, Jens Gustedt wrote: >> The great thing about standards is that there are so many to choose from! > > :) > >> I don't know that type-punning was the "main intent" of unions - I think >> saving storage space was the main motivation. > > I was perhaps pushing a bit too far, but type punning has been around > since the beginning. And if I understand it right it was the idea of > the committee to affirm that it always had been an intented use case, > and that just the wording in the standard had been too ambiguous. > [snip unrelated] The phrasing in C90 made the type punning semantics obvious. The original wording in C99 had the same semantics as was intended for C90, but this was not obvious. The DR that introduced the clarifying footnote makes it clear that there was no change in intention, only a change in wording.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-29 08:07 -0400 |
| Message-ID | <k1l0m6$972$1@dont-email.me> |
| In reply to | #25365 |
On 08/29/2012 04:44 AM, David Brown wrote: ... > I guess with C++, the "correct" way to handle type-punning is with > static_cast. I don't know whether this guarantees the same alias-safe > characteristics as a type-punning union in C. The relevant named cast is reinterpret_cast<>, not static_cast<>. While it is safer than the corresponding C cast for a number of reasons, avoiding aliasing issues is not one of those reasons. reinterpret_cast is the least safe of the named casts, and should always be regarded as a danger sign. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-29 14:49 +0200 |
| Message-ID | <EZydnVAuK62HjaPNnZ2dnUVZ8tKdnZ2d@lyse.net> |
| In reply to | #25377 |
On 29/08/2012 14:07, James Kuyper wrote:
> On 08/29/2012 04:44 AM, David Brown wrote:
> ...
>> I guess with C++, the "correct" way to handle type-punning is with
>> static_cast. I don't know whether this guarantees the same alias-safe
>> characteristics as a type-punning union in C.
>
> The relevant named cast is reinterpret_cast<>, not static_cast<>. While
> it is safer than the corresponding C cast for a number of reasons,
> avoiding aliasing issues is not one of those reasons. reinterpret_cast
> is the least safe of the named casts, and should always be regarded as a
> danger sign.
>
Accessing data through aliases with different types is always a
"dangerous" operation.
The key point is whether or not this is guaranteed to work (assuming
32-bit sizes for everything) :
unsigned int foo(float f) {
float x;
unsigned int y;
x = f;
y = * (reinterpret_cast <unsigned int*> &x);
return y; // Return binary representation of float
}
In C, if the line used is "y = * ((unsigned int*) &x);", then the
behaviour is undefined - the compiler "knows" that the float "x" cannot
alias something that an "unsigned int *" pointer points at.
The safe way to do it in C is:
unsigned int fooC(float f) {
union {
float x;
unsigned int y;
} u;
u.x = f;
return u.y; // Return binary representation of float
}
But I gather that is not guaranteed safe in C++.
[toc] | [prev] | [next] | [standalone]
| From | Adrian Ratnapala <raka@scooter.fritz.box> |
|---|---|
| Date | 2012-08-30 04:44 +0000 |
| Message-ID | <slrnk3trtj.7sf.raka@scooter.fritz.box> |
| In reply to | #25380 |
On 2012-08-29, David Brown <david@westcontrol.removethisbit.com> wrote:
> x = f;
> y = * (reinterpret_cast <unsigned int*> &x);
My C++ casting-fu is weak, but I would have thought
y = reinterpret_cast<unsigned int>(f)
would do the job, because reinterpret_cast is explicitly about
preserving the bit pattern anyway, there is no need to play around with
memory addresses. Of course the C style cast (unsigned int)f is totally
different.
[toc] | [prev] | [next] | [standalone]
| From | Casey Carter <Casey_at_Carter_dot_net@dontspam.me.invalid> |
|---|---|
| Date | 2012-08-30 00:20 -0500 |
| Message-ID | <k1mt7l$di5$1@dont-email.me> |
| In reply to | #25500 |
On 2012-08-29 23:44, Adrian Ratnapala wrote:
> On 2012-08-29, David Brown <david@westcontrol.removethisbit.com> wrote:
>
>> x = f;
>> y = * (reinterpret_cast <unsigned int*> &x);
>
> My C++ casting-fu is weak, but I would have thought
>
> y = reinterpret_cast<unsigned int>(f)
>
> would do the job, because reinterpret_cast is explicitly about
> preserving the bit pattern anyway, there is no need to play around with
> memory addresses. Of course the C style cast (unsigned int)f is totally
> different.
>
Casting from floating point to integral type is not within the purview
of reinterpret_cast. From C++11 5.2.10, the possible conversions are
* pointer to integral
* integral to pointer
* function pointer to different function pointer
* object pointer to different object pointer
* function pointer to object pointer (and vice versa) with
implementation-defined semantics
* pointer to member-function to different pointer to member-function
* pointer to data member to different pointer to data member
* reference to different reference where the pointer conversion is
defined (i.e., reinterpret_cast<T&>(u) is defined to be the same as
*reinterpret_cast<T*>(&u)) [footnote actually refers to this as type
punning]
The type pun from the OP is then simply:
unsigned int foo(float f) {
return reinterpret_cast<unsigned int&>(f);
}
or - since I'm a C++ programmer and I like to overcomplicate things:
template <typename Target, typename Source>
Target& pun_as(Source& s) {
return reinterpret_cast<Target&>(s);
}
so I can simply write
pun_as<unsigned int>(some_float) = 21369U;
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-30 09:01 +0200 |
| Message-ID | <QZOdnTnYKIqUjaLNnZ2dnUVZ8n-dnZ2d@lyse.net> |
| In reply to | #25500 |
On 30/08/2012 06:44, Adrian Ratnapala wrote: > On 2012-08-29, David Brown <david@westcontrol.removethisbit.com> wrote: > >> x = f; >> y = * (reinterpret_cast <unsigned int*> &x); > > My C++ casting-fu is weak, but I would have thought > > y = reinterpret_cast<unsigned int>(f) > > would do the job, because reinterpret_cast is explicitly about > preserving the bit pattern anyway, there is no need to play around with > memory addresses. Of course the C style cast (unsigned int)f is totally > different. > I have never actually used reinterpret_cast in C++ - my C++ experience is fairly minimal in general - so I'm happy to be corrected! However, in this case I specifically wanted to go through a pointer. I realise that reinterpret_cast will not change the bit pattern (unlike with C "y = (unsigned int) f"), and that therefore the effect should be the same with or without the pointer syntax. But what I am interested in is how the aliasing rules work when using pointers. Without pointers, the compiler will clearly see that the variables are being used directly, and use the data correctly. But with pointers, will it assume that a "unsigned int*" pointer cannot alias a float? Real world uses of this sort of thing often involve moving lumps of data around using pointers - this is just a simple example in which the "lump" is a single item in size.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-29 16:19 -0700 |
| Message-ID | <lntxvlwajy.fsf@nuthaus.mib.org> |
| In reply to | #25363 |
Jens Gustedt <jens.gustedt@loria.fr> writes:
[...]
> No, this is not an "unwritten rule" for C. C99 originally had a
> wording that could be interpreted as you state. A corrigendum has made
> it clear that it is not intended. Type-punning in C works as long as
> the value that you are reading is valid for the type through which you
> are doing so.
>
> A footnote in the C standard clarifies that:
>
> 95) If the member used to read the contents of a union object is not
> the same as the member last used to store a value in the object, the
> appropriate part of the object representation of the value is
> reinterpreted as an object representation in the new type as described
> in 6.2.6 (a process sometimes called ‘‘type punning’’). This might be
> a trap representation.
Yes. That footnote was added by Technical Corrigendum 3. It appears
in N1256 (though oddly without a change bar), and of course in C11
(or at least N1570).
[...]
--
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 06:17 -0700 |
| Message-ID | <kfnr4qekm5r.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #25466 |
Keith Thompson <kst-u@mib.org> writes: > Jens Gustedt <jens.gustedt@loria.fr> writes: > [...] >> No, this is not an "unwritten rule" for C. C99 originally had a >> wording that could be interpreted as you state. A corrigendum has made >> it clear that it is not intended. Type-punning in C works as long as >> the value that you are reading is valid for the type through which you >> are doing so. >> >> A footnote in the C standard clarifies that: >> >> 95) If the member used to read the contents of a union object is not >> the same as the member last used to store a value in the object, the >> appropriate part of the object representation of the value is >> reinterpreted as an object representation in the new type as described >> in 6.2.6 (a process sometimes called ''type punning''). This might be >> a trap representation. > > Yes. That footnote was added by Technical Corrigendum 3. It appears > in N1256 (though oddly without a change bar), [snip] If you look near the top of the page the footnote is on, you should find the change bar next to paragraph 3, to show that the footnote was added.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-09-07 14:22 -0700 |
| Message-ID | <lnr4qdsf3c.fsf@nuthaus.mib.org> |
| In reply to | #26045 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Jens Gustedt <jens.gustedt@loria.fr> writes:
>> [...]
>>> No, this is not an "unwritten rule" for C. C99 originally had a
>>> wording that could be interpreted as you state. A corrigendum has made
>>> it clear that it is not intended. Type-punning in C works as long as
>>> the value that you are reading is valid for the type through which you
>>> are doing so.
>>>
>>> A footnote in the C standard clarifies that:
>>>
>>> 95) If the member used to read the contents of a union object is not
>>> the same as the member last used to store a value in the object, the
>>> appropriate part of the object representation of the value is
>>> reinterpreted as an object representation in the new type as described
>>> in 6.2.6 (a process sometimes called ''type punning''). This might be
>>> a trap representation.
>>
>> Yes. That footnote was added by Technical Corrigendum 3. It appears
>> in N1256 (though oddly without a change bar), [snip]
>
> If you look near the top of the page the footnote is on,
> you should find the change bar next to paragraph 3,
> to show that the footnote was added.
You're right (though it would have made sense to have a change bar on
the footnote itself as well).
For those following along, this is footnote 82, section 6.5.2.3p3 in
N1256, foonote 95, same section in N1570.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | lawrence.jones@siemens.com |
|---|---|
| Date | 2012-09-10 17:21 -0400 |
| Message-ID | <h722i9-hhn.ln1@jones.homeip.net> |
| In reply to | #26090 |
Keith Thompson <kst-u@mib.org> wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: > > Keith Thompson <kst-u@mib.org> writes: > >> > >> Yes. That footnote was added by Technical Corrigendum 3. It appears > >> in N1256 (though oddly without a change bar), [snip] > > > > If you look near the top of the page the footnote is on, > > you should find the change bar next to paragraph 3, > > to show that the footnote was added. > > You're right (though it would have made sense to have a change bar on > the footnote itself as well). Indeed. The automated diff mark process falls down in this case due to the way footnotes are handled in troff and mm. The editor usualy makes an effort to correct such misses manually, but managed to overlook that one. -- Larry Jones It's either spectacular, unbelievable success, or crushing, hopeless defeat! There is no middle ground! -- Calvin
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-09-07 06:03 -0700 |
| Message-ID | <kfnzk52kmst.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #25359 |
David Brown <david@westcontrol.removethisbit.com> writes: > On 28/08/2012 18:39, James Kuyper wrote: >> On 08/28/2012 09:32 AM, David Brown wrote: >> ... >>> Ultimately, I'd like some way to tell the compiler what data, pointers >>> and/or types can alias what. >> >> If you put two types in a union, within the scope of that union >> declaration a conforming implementation must take aliasing between those >> two types into consideration any time it's dealing with pointers that >> could be pointing at different members of the same union object. >> > > Correct me if I'm wrong, but I believe this is actually just an > "unwritten rule" that all compilers have agreed to follow. [snip] Actually it (ie, the semantics of union member access) is a written rule, it's just not written in a way that makes it obvious.
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web