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 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 10:57 +0200 |
| Message-ID | <503C87E2.5080504@loria.fr> |
| In reply to | #25203 |
Am 28.08.2012 10:21, schrieb David Brown: > Basically, I just want to be able to mix and match C and C++ code > freely. I want to be able to write in the same style in each language. > If I am not using C++ features, I want the code to be compilable as C > or C++, with the same functionality each time. And I want to be able to > do so without artificially restricting the features I can use in C. It's > okay if I have to #include a few standard headers, and put in a few > extern "C" wrappers. > > Am I really asking too much? personnaly, I don't think so, but seen in the historical context, most likely. > (Here's another thing C should support - it should accept extern "C".) Ah, yes, a good one. Sometime the next days, if and when I find the time, I'll probably start to compile a list of these things. Or better three list - C features missing in C++ - C++ features missing in C - points where both should (and could) move to meet on a common ground I already have a list of defects and feature requests for C. That would perfectly fit, there. Jens
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 09:42 -0400 |
| Message-ID | <k1iht3$f84$1@dont-email.me> |
| In reply to | #25203 |
On 08/28/2012 04:21 AM, David Brown wrote: ... > Basically, I just want to be able to mix and match C and C++ code > freely. I want to be able to write in the same style in each language. > If I am not using C++ features, I want the code to be compilable as C > or C++, with the same functionality each time. And I want to be able to > do so without artificially restricting the features I can use in C. > It's okay if I have to #include a few standard headers, and put in a few > extern "C" wrappers. > > Am I really asking too much? Yes, you are. In essence, what you're really asking for is a single language (we could call it "C/C++", converting a popular misconception into reality :-) ), with two modes it can be used in. What you're actually faced with is two different languages, and it really doesn't make sense for either one of them to be as tightly integrated with the other as they would have to be to make what you want work. If you can convince the C++ committee to port over a few more of C's new features, then the C subset of C++ would provide virtually everything you're asking for of C. That's a far more feasible goal to achieve than integrating C and C++ together as tightly as you want. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-28 15:59 +0200 |
| Message-ID | <V8mdndRu9stSU6HNnZ2dnUVZ8iydnZ2d@lyse.net> |
| In reply to | #25240 |
On 28/08/2012 15:42, James Kuyper wrote: > On 08/28/2012 04:21 AM, David Brown wrote: > ... >> Basically, I just want to be able to mix and match C and C++ code >> freely. I want to be able to write in the same style in each language. >> If I am not using C++ features, I want the code to be compilable as C >> or C++, with the same functionality each time. And I want to be able to >> do so without artificially restricting the features I can use in C. >> It's okay if I have to #include a few standard headers, and put in a few >> extern "C" wrappers. >> >> Am I really asking too much? > > Yes, you are. In essence, what you're really asking for is a single > language (we could call it "C/C++", converting a popular misconception > into reality :-) ), with two modes it can be used in. What you're > actually faced with is two different languages, and it really doesn't > make sense for either one of them to be as tightly integrated with the > other as they would have to be to make what you want work. > > If you can convince the C++ committee to port over a few more of C's new > features, then the C subset of C++ would provide virtually everything > you're asking for of C. That's a far more feasible goal to achieve than > integrating C and C++ together as tightly as you want. > I'd be happy enough with a reasonable common subset - but bigger than there is today. For example, I don't mind putting casts at void* pointers, and clearly I'd be happy avoiding C variables called "new" or "class". I don't really count such things as "artificial" restrictions of C features. But things like designated initialisers or "restrict" pointers /are/ artificial restrictions since there is no particular reason they can't be added to C++. (To be honest, I can get much of this with gcc - it allows a wider common subset in both languages as an extension. But it would be nice to see it in the standards.)
[toc] | [prev] | [next] | [standalone]
| From | "Ansel" <tinker454@trytospammenowloser.com> |
|---|---|
| Date | 2012-08-26 21:26 -0600 |
| Message-ID | <k1epbf$nit$2@speranza.aioe.org> |
| In reply to | #25039 |
David Brown wrote: > On 26/08/2012 23:19, Keith Thompson wrote: >> David Brown <david@westcontrol.removethisbit.com> writes: >> I'm less sure about the consequence of making C++ adopt the C rule, >> but I suspect it would break something having to do with templates >> and/or overloading. > > I think requiring an explicit cast in C would help avoid errors in > code - but obviously you want to be careful introducing a feature > that would break so much existing code. Equally, you don't want to > remove the feature from C++ - so this would have to stand as a > difference. Well, there is "standard" and "de facto standard". Once embarked upon the path toward greater compatibility, one need not stop at the ISO level. Beyond that, there is the implementation (vendor) level, and it appears (to me) that a few "de facto standard" compiler switches might be the solution to issues where C and C++ cannot "get it together". Of course, that is not to be used as a crutch for not making some "painful" changes, but it is another dimension of the project. That said, there is nothing stopping some compiler vendor(s) from bypassing all the formalities and "just doing it!" that way and letting users decide. It may even be the best way to go about it, for it could "happen overnight" instead of next year. Compiler switches: ye or nay? Vendor-driven approach: ye or nay?
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-26 23:41 +0200 |
| Message-ID | <503A9824.7050805@loria.fr> |
| In reply to | #25038 |
Am 26.08.2012 23:19, schrieb Keith Thompson:
> The two committees do make some effort to avoid too many
> incompatibilities
definitively
> -- and I'd *like* to see C++ adopt a few more
> C99 and C11 features than it has so far.
on my wish list would be
- variably modified types (not necessarily VLA but pointers to VLA are
nice)
- restrict
- designated initializers
- compound literals
- type punning through unions
- compatible complex types
the other way round there would probably also be some things from C++
that would be worth considering in C. Simple things such as {} for
default initializers, a larger concept of compile time constants, the
same possibilities for declarations inside control structures (static
objects, and extend the concept to "if" and "while", not only
"for"). But I probably don't know enough of modern C++ to completely
appreciate what this could offer to C.
Then the two could come together to enforce some revolutionary new
things like fixing signed integer representations to two's complement,
disallowing padding bits for integral types, disallowing trap
representations, force definition of [u]intptr_t and other crude stuff
like that.
Jens
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-27 10:40 +0200 |
| Message-ID | <Gp6dnekZmbw3r6bNnZ2dnUVZ8i6dnZ2d@lyse.net> |
| In reply to | #25041 |
On 26/08/2012 23:41, Jens Gustedt wrote:
> Am 26.08.2012 23:19, schrieb Keith Thompson:
>> The two committees do make some effort to avoid too many
>> incompatibilities
>
> definitively
>
>> -- and I'd *like* to see C++ adopt a few more
>> C99 and C11 features than it has so far.
>
> on my wish list would be
>
> - variably modified types (not necessarily VLA but pointers to VLA are
> nice)
> - restrict
> - designated initializers
> - compound literals
> - type punning through unions
> - compatible complex types
>
I'd add fixed point types to that list - as well as a proper way to
define exact sized fixed point types (sort of like "stdint.h").
> the other way round there would probably also be some things from C++
> that would be worth considering in C. Simple things such as {} for
> default initializers, a larger concept of compile time constants, the
> same possibilities for declarations inside control structures (static
> objects, and extend the concept to "if" and "while", not only
> "for"). But I probably don't know enough of modern C++ to completely
> appreciate what this could offer to C.
>
> Then the two could come together to enforce some revolutionary new
> things like fixing signed integer representations to two's complement,
> disallowing padding bits for integral types, disallowing trap
> representations, force definition of [u]intptr_t and other crude stuff
> like that.
>
If someone is making a wish list here, I'd add support for defining
endianness (allowing code to explicitly define and use variables and
types as big endian or little endian independently of the architecture)
and bit field ordering. That would be great for portable code.
Support for types bigger than "char" which are "can always alias" would
be a big help whenever you need to move data around, and an 8-bit type
that does not alias would be nice for small systems.
Proper, standardised memory barriers of different types and granularity
would be a help for some low-level programming.
Generally speaking, it would be nice to be able to do more C++ in
low-level and embedded code, and cut out some more of the last remnants
of assembly that is still needed.
> Jens
>
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-27 18:34 +0200 |
| Message-ID | <503BA19E.4030804@loria.fr> |
| In reply to | #25076 |
Am 27.08.2012 10:40, schrieb David Brown: > If someone is making a wish list here, I'd add support for defining > endianness (allowing code to explicitly define and use variables and > types as big endian or little endian independently of the architecture) > and bit field ordering. I think this is more strictly defined for C already than for C++, perhaps the definition that C has would be sufficient for your needs? > That would be great for portable code. > > Support for types bigger than "char" which are "can always alias" would > be a big help whenever you need to move data around, and an 8-bit type > that does not alias would be nice for small systems. I am not sure that I understand this one. C has the optional uintXX_t that are guaranteed to have a fixed width no padding etc, if they exist. Would it for your purpose just suffice to make some of these types mandatory e.g for 8, 16, 32 and 64 bit integers? > Proper, standardised memory barriers of different types and granularity > would be a help for some low-level programming. My understanding is that these are included in C11 atomics, and since this part basically identical to C++11, it should be there, too. > Generally speaking, it would be nice to be able to do more C++ in > low-level and embedded code, and cut out some more of the last remnants > of assembly that is still needed. The atomics extension (optional in C11) should already do a lot in that direction. Jens
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-28 12:40 +0200 |
| Message-ID | <7PudnZ3UTK63PaHNnZ2dnUVZ8v2dnZ2d@lyse.net> |
| In reply to | #25106 |
On 27/08/2012 18:34, Jens Gustedt wrote: > Am 27.08.2012 10:40, schrieb David Brown: >> If someone is making a wish list here, I'd add support for defining >> endianness (allowing code to explicitly define and use variables and >> types as big endian or little endian independently of the architecture) > > >> and bit field ordering. > > I think this is more strictly defined for C already than for C++, > perhaps the definition that C has would be sufficient for your needs? > No, it is not defined nearly well enough. There are ambiguities regarding padding, alignment, etc., especially as the size of the fields change. Different underlying types of the fields can make a difference (especially if you want something like an enum type), and compiler flags often affect the structure. The biggest failing is that there is no way to relate the order to the underlying bits - the first field could be the least significant bit on one architecture, and the most significant bit on another architecture (or even different compilers on the same target). Bitfields /can/ be a very convenient way to pack data, but are only really safe if the data stays within the same program. You have to mess around with a lot of #ifdef's and alternative definitions to get something portable (you can see this sort of mess in the Linux source code for filesystems, for example). Some clear and unambiguous method of fixing this would be very useful - something like "__attribute__((packed, lsbfirst))", using gcc attribute syntax. >> That would be great for portable code. >> >> Support for types bigger than "char" which are "can always alias" would >> be a big help whenever you need to move data around, and an 8-bit type >> that does not alias would be nice for small systems. > > I am not sure that I understand this one. C has the optional uintXX_t > that are guaranteed to have a fixed width no padding etc, if they > exist. Would it for your purpose just suffice to make some of these > types mandatory e.g for 8, 16, 32 and 64 bit integers? No, these types are fine (I use them all the time). The issue is with aliasing. Sometimes in programming, you need to move data around in a format other than the data's "natural" format. Maybe you've got data held in a struct, and you want to make a copy of the whole struct. Or maybe you want to pass data around using the Modbus protocol, which likes to treat everything using 16-bit words. The trouble comes when you want to work with a pointer to the struct data using a *uint16_t pointer (or any other "incompatible" pointer). The compiler knows that the struct is incompatible with a uint16_t, so the pointer cannot point to the struct, and therefore nothing read or written to the struct can affect anything read or written through the pointer. Chars, or pointers to char, have the opposite problem - because they can alias anything, the compiler has to assume that any access through a char pointer can hit any other data (well, not /any/ other data - local data in registers is safe). This can lead to lost optimisation opportunities. So I would like to see types other than inefficient 8-bit types that have the "alias everything" property, and 8-bit types that don't alias anything. An alternative is to be able to specify aliasing more conveniently, without having to use type-punning unions. > >> Proper, standardised memory barriers of different types and granularity >> would be a help for some low-level programming. > > My understanding is that these are included in C11 atomics, and since > this part basically identical to C++11, it should be there, too. Well, atomics helps a bit - but they are overkill. Mostly all you need is to be able to say "make sure the store to variable X is completed here", or "don't move the read before this point". You can get a fair amount of this using volatile accesses, but sometimes it is much more convenient with general barriers. Depending on the target cpu, you may also want the barriers to issue additional instructions to flush buffers. > >> Generally speaking, it would be nice to be able to do more C++ in >> low-level and embedded code, and cut out some more of the last remnants >> of assembly that is still needed. > > The atomics extension (optional in C11) should already do a lot in > that direction. > > Jens >
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 14:06 +0200 |
| Message-ID | <503CB43A.3070001@loria.fr> |
| In reply to | #25217 |
Am 28.08.2012 12:40, schrieb David Brown: > On 27/08/2012 18:34, Jens Gustedt wrote: >> Am 27.08.2012 10:40, schrieb David Brown: >>> If someone is making a wish list here, I'd add support for defining >>> endianness (allowing code to explicitly define and use variables and >>> types as big endian or little endian independently of the architecture) >> >> >>> and bit field ordering. >> >> I think this is more strictly defined for C already than for C++, >> perhaps the definition that C has would be sufficient for your needs? >> > > No, it is not defined nearly well enough. > > There are ambiguities regarding padding, alignment, etc., especially as > the size of the fields change. Different underlying types of the fields > can make a difference (especially if you want something like an enum > type), well C does only allow enums as implementation specific. For C the only portable types are of signed and unsigned int and _Bool. And the only real ambiguity that I see is for bit-fields that may cross storage boundaries, here the standard allows either realize part of the bitfield in one unit and the other part in the other or to accumulate them in the second unit. As long as all bits fit, they must be placed in the same unit, and if you want to force it to move to the next unit you can place a :0. >> I am not sure that I understand this one. C has the optional uintXX_t >> that are guaranteed to have a fixed width no padding etc, if they >> exist. Would it for your purpose just suffice to make some of these >> types mandatory e.g for 8, 16, 32 and 64 bit integers? > > No, these types are fine (I use them all the time). The issue is with > aliasing. > > Sometimes in programming, you need to move data around in a format other > than the data's "natural" format. Maybe you've got data held in a > struct, and you want to make a copy of the whole struct. Or maybe you > want to pass data around using the Modbus protocol, which likes to treat > everything using 16-bit words. The trouble comes when you want to work > with a pointer to the struct data using a *uint16_t pointer (or any > other "incompatible" pointer). The compiler knows that the struct is > incompatible with a uint16_t, so the pointer cannot point to the struct, > and therefore nothing read or written to the struct can affect anything > read or written through the pointer. wouldn't something like struct toto _Alignas(uint16_t) t; struct toto volatile _Alignas(uint16_t) vt = t; uint16_t volatile*words = (uint16_t*)&vt; /* do the fiddling that you want */ t = vt; do the trick? But perhaps I am too naive :) > Chars, or pointers to char, have the opposite problem - because they can > alias anything, the compiler has to assume that any access through a > char pointer can hit any other data (well, not /any/ other data - local > data in registers is safe). This can lead to lost optimisation > opportunities. as long as the char* receives is value in the same spot modern compilers should be able to avoid most problems, I would guess. But yes if you have a char* that might point anywhere, it might impact any of your variables. But such a pointer you usually receive as a parameter of a function, so you should carefully use "restrict" to tell the compiler what he may assume. (and oops we are back on track for the the C - C++ incompabilities :) I still not sure that I understand what you'd want. One generic data type for each possible alignment specification? > So I would like to see types other than inefficient 8-bit types that > have the "alias everything" property, and 8-bit types that don't alias > anything. You mean that any "char*" parameter to a function could ruin some optimization? Never thought of it like that. But if you have a "char*" (and not "char const*") then probably it is a good idea to add a "restrict" where ever you may. > An alternative is to be able to specify aliasing more conveniently, > without having to use type-punning unions. "uintXX_t*" would be good candidates, here. >> >>> Proper, standardised memory barriers of different types and granularity >>> would be a help for some low-level programming. >> >> My understanding is that these are included in C11 atomics, and since >> this part basically identical to C++11, it should be there, too. > > Well, atomics helps a bit - but they are overkill. Mostly all you need > is to be able to say "make sure the store to variable X is completed > here", or "don't move the read before this point". You can get a fair > amount of this using volatile accesses, but sometimes it is much more > convenient with general barriers. Depending on the target cpu, you may > also want the barriers to issue additional instructions to flush buffers. Declaring a variable that you'd want to flush as atomic would certainly be overkill. But I don't see completely why atomic_thread_fence couldn't serve your purpose, at least aproximatively. True, it doesn't ensure a fence for just one variable, but then again with aliasing you'd have to make pretty much sure that your memory bus calmed down before supposing that no other variable is affected by a load or store. So my idea would be that atomic_thread_fence with a careful selection of the memory_order that you pass as argument would come relatively close to what you want. Jens
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-28 15:32 +0200 |
| Message-ID | <eeidnQzTHuUaVaHNnZ2dnUVZ8gCdnZ2d@lyse.net> |
| In reply to | #25227 |
On 28/08/2012 14:06, Jens Gustedt wrote:
> Am 28.08.2012 12:40, schrieb David Brown:
>> On 27/08/2012 18:34, Jens Gustedt wrote:
>>> Am 27.08.2012 10:40, schrieb David Brown:
>>>> If someone is making a wish list here, I'd add support for defining
>>>> endianness (allowing code to explicitly define and use variables and
>>>> types as big endian or little endian independently of the architecture)
>>>
>>>
>>>> and bit field ordering.
>>>
>>> I think this is more strictly defined for C already than for C++,
>>> perhaps the definition that C has would be sufficient for your needs?
>>>
>>
>> No, it is not defined nearly well enough.
>>
>> There are ambiguities regarding padding, alignment, etc., especially as
>> the size of the fields change. Different underlying types of the fields
>> can make a difference (especially if you want something like an enum
>> type),
>
> well C does only allow enums as implementation specific. For C the
> only portable types are of signed and unsigned int and _Bool.
>
> And the only real ambiguity that I see is for bit-fields that may
> cross storage boundaries, here the standard allows either realize part
> of the bitfield in one unit and the other part in the other or to
> accumulate them in the second unit. As long as all bits fit, they must
> be placed in the same unit, and if you want to force it to move to the
> next unit you can place a :0.
>
That's true - but I want to be able to unambiguously place fields across
boundaries, and I want to be able to use fields of different types in a
well-defined, portable and cross-platform way. For example, I want to
be able to write:
struct {
uint8_t a;
uint8_t b;
uint8_t c : 4;
uint8_t d : 4;
uint8_t e;
}
I want to be guaranteed that this struct takes 32 bits, and is aligned
to 8-bit boundaries.
Most C compilers allow such code, but it is not in the standards. They
also (mostly) allow enumerated types, and the size and alignment of the
field comes from the size of the bitfield rather than the size of the
underlying enum (which in standard C is a signed or unsigned int, or
possibly a signed or unsigned long - but compiler options may allow it
to be smaller).
AFAIK, C++ allows such code in the standards.
However, no standards give any guarantees about alignment and padding.
And certainly bit ordering is not mentioned.
>>> I am not sure that I understand this one. C has the optional uintXX_t
>>> that are guaranteed to have a fixed width no padding etc, if they
>>> exist. Would it for your purpose just suffice to make some of these
>>> types mandatory e.g for 8, 16, 32 and 64 bit integers?
>>
>> No, these types are fine (I use them all the time). The issue is with
>> aliasing.
>>
>> Sometimes in programming, you need to move data around in a format other
>> than the data's "natural" format. Maybe you've got data held in a
>> struct, and you want to make a copy of the whole struct. Or maybe you
>> want to pass data around using the Modbus protocol, which likes to treat
>> everything using 16-bit words. The trouble comes when you want to work
>> with a pointer to the struct data using a *uint16_t pointer (or any
>> other "incompatible" pointer). The compiler knows that the struct is
>> incompatible with a uint16_t, so the pointer cannot point to the struct,
>> and therefore nothing read or written to the struct can affect anything
>> read or written through the pointer.
>
> wouldn't something like
>
> struct toto _Alignas(uint16_t) t;
>
> struct toto volatile _Alignas(uint16_t) vt = t;
> uint16_t volatile*words = (uint16_t*)&vt;
> /* do the fiddling that you want */
> t = vt;
>
> do the trick?
>
> But perhaps I am too naive :)
Using volatile accesses will force data to be written, and negate
aliasing issues - since the compiler must read or write the data exactly
as the volatile accesses dictate, it can't optimise on the basis of
non-aliasing types.
However, typically we are talking about lumps of data rather than a
single item (if not, then pass-by-value is probably going to be more
efficient than using pointers), so extra copies are to be avoided.
And there is the choice between making the data volatile, and thereby
making most of the "normal" accesses much less efficient, or making only
some of the accesses explicitly volatile - and thereby risk missing some
(or at least making messy code).
Usually a memory barrier or two, along with some volatile accesses,
gives correct code without too much run-time overhead or messy source
code. But I can always wish for something better!
>
>> Chars, or pointers to char, have the opposite problem - because they can
>> alias anything, the compiler has to assume that any access through a
>> char pointer can hit any other data (well, not /any/ other data - local
>> data in registers is safe). This can lead to lost optimisation
>> opportunities.
>
> as long as the char* receives is value in the same spot modern
> compilers should be able to avoid most problems, I would guess. But
> yes if you have a char* that might point anywhere, it might impact any
> of your variables. But such a pointer you usually receive as a
> parameter of a function, so you should carefully use "restrict" to
> tell the compiler what he may assume. (and oops we are back on track
> for the the C - C++ incompabilities :)
>
> I still not sure that I understand what you'd want. One generic data
> type for each possible alignment specification?
Ultimately, I'd like some way to tell the compiler what data, pointers
and/or types can alias what. But I'd settle for a set of types of
different fixed sizes that may alias anything else.
"Restrict" is useful, and lets you tell the compiler that a particular
char* pointer does not alias anything else. But maybe I want to say the
pointer doesn't alias other data - but it /might/ alias another char*.
(OK, I'll accept that maybe I'm a little demanding here - after all,
"restrict" handles most situations. If only it worked in C++...)
>
>> So I would like to see types other than inefficient 8-bit types that
>> have the "alias everything" property, and 8-bit types that don't alias
>> anything.
>
> You mean that any "char*" parameter to a function could ruin some
> optimization? Never thought of it like that. But if you have a "char*"
> (and not "char const*") then probably it is a good idea to add a
> "restrict" where ever you may.
I doubt if there would actually be many missed optimisations in
practice, but the fact that the char* may alias any data will mean that
sometimes the compiler will have to commit stores that could otherwise
be kept in registers, or re-load data from memory that could otherwise
have been re-used from registers. (Most of the targets I use have lots
of registers - x86 users won't see this sort of effect.)
>
>> An alternative is to be able to specify aliasing more conveniently,
>> without having to use type-punning unions.
>
> "uintXX_t*" would be good candidates, here.
Yes, except that the compiler can assume that these will never alias
incompatible types.
In effect, the compiler can treat "uint16_t * p16" and "uint32_t * p32"
as though there is a "restrict" qualifier that declares that their
memory does not coincide. There is no good way to tell the compiler
that they might, in fact, coincide.
>
>>>
>>>> Proper, standardised memory barriers of different types and granularity
>>>> would be a help for some low-level programming.
>>>
>>> My understanding is that these are included in C11 atomics, and since
>>> this part basically identical to C++11, it should be there, too.
>>
>> Well, atomics helps a bit - but they are overkill. Mostly all you need
>> is to be able to say "make sure the store to variable X is completed
>> here", or "don't move the read before this point". You can get a fair
>> amount of this using volatile accesses, but sometimes it is much more
>> convenient with general barriers. Depending on the target cpu, you may
>> also want the barriers to issue additional instructions to flush buffers.
>
> Declaring a variable that you'd want to flush as atomic would
> certainly be overkill. But I don't see completely why
>
> atomic_thread_fence
>
> couldn't serve your purpose, at least aproximatively. True, it doesn't
> ensure a fence for just one variable, but then again with aliasing
> you'd have to make pretty much sure that your memory bus calmed down
> before supposing that no other variable is affected by a load or
> store. So my idea would be that atomic_thread_fence with a careful
> selection of the memory_order that you pass as argument would come
> relatively close to what you want.
>
> Jens
>
The atomic_thread_fence may be an answer here. I'll need to wait a bit
for support to make it into the tools I use, and then see what the code
is actually generated for it (and for the atomic types). But it is
always possible that I'll be able to strike this one from my wishlist.
mvh.,
David
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 16:04 +0200 |
| Message-ID | <503CCFFF.5040202@loria.fr> |
| In reply to | #25239 |
Am 28.08.2012 15:32, schrieb David Brown:
> On 28/08/2012 14:06, Jens Gustedt wrote:
>> Am 28.08.2012 12:40, schrieb David Brown:
>>> On 27/08/2012 18:34, Jens Gustedt wrote:
>>>> Am 27.08.2012 10:40, schrieb David Brown:
>>>>> If someone is making a wish list here, I'd add support for defining
>>>>> endianness (allowing code to explicitly define and use variables and
>>>>> types as big endian or little endian independently of the
>>>>> architecture)
>>>>
>>>>
>>>>> and bit field ordering.
>>>>
>>>> I think this is more strictly defined for C already than for C++,
>>>> perhaps the definition that C has would be sufficient for your needs?
>>>>
>>>
>>> No, it is not defined nearly well enough.
>>>
>>> There are ambiguities regarding padding, alignment, etc., especially as
>>> the size of the fields change. Different underlying types of the fields
>>> can make a difference (especially if you want something like an enum
>>> type),
>>
>> well C does only allow enums as implementation specific. For C the
>> only portable types are of signed and unsigned int and _Bool.
>>
>> And the only real ambiguity that I see is for bit-fields that may
>> cross storage boundaries, here the standard allows either realize part
>> of the bitfield in one unit and the other part in the other or to
>> accumulate them in the second unit. As long as all bits fit, they must
>> be placed in the same unit, and if you want to force it to move to the
>> next unit you can place a :0.
>>
>
> That's true - but I want to be able to unambiguously place fields across
> boundaries, and I want to be able to use fields of different types in a
> well-defined, portable and cross-platform way. For example, I want to
> be able to write:
>
> struct {
> uint8_t a;
> uint8_t b;
> uint8_t c : 4;
> uint8_t d : 4;
> uint8_t e;
> }
>
> I want to be guaranteed that this struct takes 32 bits, and is aligned
> to 8-bit boundaries.
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.)
> The atomic_thread_fence may be an answer here. I'll need to wait a bit
> for support to make it into the tools I use, and then see what the code
> is actually generated for it (and for the atomic types). But it is
> always possible that I'll be able to strike this one from my wishlist.
What I have seen so far of the preliminary implementations in gcc and
clang it looked quite ok, there.
> mvh.,
?
Jens
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david@westcontrol.removethisbit.com> |
|---|---|
| Date | 2012-08-28 17:57 +0200 |
| Message-ID | <U4GdnXTw6oEzd6HNnZ2dnUVZ8oOdnZ2d@lyse.net> |
| In reply to | #25245 |
On 28/08/2012 16:04, Jens Gustedt wrote:
> Am 28.08.2012 15:32, schrieb David Brown:
>> On 28/08/2012 14:06, Jens Gustedt wrote:
>>> Am 28.08.2012 12:40, schrieb David Brown:
>>>> On 27/08/2012 18:34, Jens Gustedt wrote:
>>>>> Am 27.08.2012 10:40, schrieb David Brown:
>>>>>> If someone is making a wish list here, I'd add support for defining
>>>>>> endianness (allowing code to explicitly define and use variables and
>>>>>> types as big endian or little endian independently of the
>>>>>> architecture)
>>>>>
>>>>>
>>>>>> and bit field ordering.
>>>>>
>>>>> I think this is more strictly defined for C already than for C++,
>>>>> perhaps the definition that C has would be sufficient for your needs?
>>>>>
>>>>
>>>> No, it is not defined nearly well enough.
>>>>
>>>> There are ambiguities regarding padding, alignment, etc., especially as
>>>> the size of the fields change. Different underlying types of the fields
>>>> can make a difference (especially if you want something like an enum
>>>> type),
>>>
>>> well C does only allow enums as implementation specific. For C the
>>> only portable types are of signed and unsigned int and _Bool.
>>>
>>> And the only real ambiguity that I see is for bit-fields that may
>>> cross storage boundaries, here the standard allows either realize part
>>> of the bitfield in one unit and the other part in the other or to
>>> accumulate them in the second unit. As long as all bits fit, they must
>>> be placed in the same unit, and if you want to force it to move to the
>>> next unit you can place a :0.
>>>
>>
>> That's true - but I want to be able to unambiguously place fields across
>> boundaries, and I want to be able to use fields of different types in a
>> well-defined, portable and cross-platform way. For example, I want to
>> be able to write:
>>
>> struct {
>> uint8_t a;
>> uint8_t b;
>> uint8_t c : 4;
>> uint8_t d : 4;
>> uint8_t e;
>> }
>>
>> I want to be guaranteed that this struct takes 32 bits, and is aligned
>> to 8-bit boundaries.
>
> 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.
>> The atomic_thread_fence may be an answer here. I'll need to wait a bit
>> for support to make it into the tools I use, and then see what the code
>> is actually generated for it (and for the atomic types). But it is
>> always possible that I'll be able to strike this one from my wishlist.
>
> What I have seen so far of the preliminary implementations in gcc and
> clang it looked quite ok, there.
>
It will be fun to try it out. For my professional work, I am reliant on
"official" builds of gcc from various sources for various targets (as
well as a few other non-gcc compilers), but I like to keep track of the
latest developments too.
>> mvh.,
>
"Med vennlig hilsen" - "with friendly greetings" in Norwegian. It's a
habit, and I sometimes use it in English-language emails without
thinking about it.
>
> Jens
>
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 18:45 +0200 |
| Message-ID | <503CF59D.3070800@loria.fr> |
| In reply to | #25253 |
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.)
>>> The atomic_thread_fence may be an answer here. I'll need to wait a bit
>>> for support to make it into the tools I use, and then see what the code
>>> is actually generated for it (and for the atomic types). But it is
>>> always possible that I'll be able to strike this one from my wishlist.
>>
>> What I have seen so far of the preliminary implementations in gcc and
>> clang it looked quite ok, there.
>>
>
> It will be fun to try it out. For my professional work, I am reliant on
> "official" builds of gcc from various sources for various targets (as
> well as a few other non-gcc compilers), but I like to keep track of the
> latest developments too.
starting with gcc 4.7 they have moved to new interfaces for the
builtins that come close to what the standards (C and C++) describe
>>> mvh.,
>>
>
> "Med vennlig hilsen" - "with friendly greetings" in Norwegian. It's a
> habit, and I sometimes use it in English-language emails without
> thinking about it.
ah, my first name might have triggered that reflex
Jens
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2012-08-28 18:08 +0000 |
| Message-ID | <iO7%r.58656$w06.34770@fed15.iad> |
| In reply to | #25261 |
Jens Gustedt <jens.gustedt@loria.fr> writes:
>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.)
Until you build code that must compile and run on both big-endian and
little-endian architectures, where the order of the bits _will_ change. Not
a problem unless the bits are mapped to hardware or are serialized as a
larger unit (e.g. uint32_t).
z.b.:
union u_reg_0x351 {
uint32 u32;
struct {
uint32
#if __BYTE_ORDER__ == __BIG_ENDIAN
:27,
enable:1, // [4] Enable access
dsb:1, // [3] Disable S Bypass
dib:1, // [2] Disable I Bypass
dfb:1, // [1] Disable F Bypass
sre:1; // [0] System Register Enable
#else
sre:1, // [0] System Register Enable
dfb:1, // [1] Disable F Bypass
dib:1, // [2] Disable I Bypass
dsb:1, // [3] Disable S Bypass
enable:1, // [4] Enable access
:27;
#endif
} s;
};
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 20:44 +0200 |
| Message-ID | <503D11AA.3090506@loria.fr> |
| In reply to | #25267 |
Am 28.08.2012 20:08, schrieb Scott Lurndal: > Jens Gustedt <jens.gustedt@loria.fr> writes: > Until you build code that must compile and run on both big-endian and > little-endian architectures, where the order of the bits _will_ change. Not > a problem unless the bits are mapped to hardware or are serialized as a > larger unit (e.g. uint32_t). ah ok, the standard effectively only make a statement about the value (bit pattern seen as unsigned value) of such a beast. How and in which order this is stored depends on endianess of the architecture. But that is not a problem of bit-fields per se, but the fact that C still has to run on two different types of architectures with respect to that. Jens
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 14:50 -0400 |
| Message-ID | <503D12EC.4030106@verizon.net> |
| In reply to | #25261 |
On 08/28/2012 12:45 PM, 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.)
That's not consistent with my understanding of the standard. Could you
specify precisely how you thought the standard required that structure
to be laid out?
The relevant clause from the C standard is 6.7.2.1p11:
> An implementation may allocate any addressable storage unit large enough to hold a bitfield.
> 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.
In the C++ standard, 9.6p1 says much the same thing, in somewhat less
formal language.
Neither standard specifies the size of the allocation unit from which
bit-fields are allocated. Which size were you assuming was specified by
the standard?
If there's enough space to store b in the same allocation unit as 'a',
the C standard requires that 'b' be stored in bits adjacent to 'a', but
it does not specify the relative order of 'a' and 'b'. Both standards
explicitly state that the order of bit-fields within an allocation unit
is unspecified . What order were you assuming was specified by the standard?
Both standards explicitly leave unspecified whether bit-fields can
overlap adjacent allocation units. Since the assumption that CHAR_BIT==8
was specified, that problem won't come up in this particular case, but
with different bit-field sizes, or even with the same sizes in a
different order, that could be an issue even on entirely conventional
systems. For instance, if "c" were moved before "b", and the allocation
unit was either 8 or 16 bits in size, then "b" might, or might not,
overlap two consecutive allocation unit, depending upon the
implementation. Were you making any assumptions about how such overlaps
would be handled, or were you relying upon the assumption that
CHAR_BIT==8 to conclude that this particular structure has a uniquely
specified layout?
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 22:36 +0200 |
| Message-ID | <503D2BB1.708@loria.fr> |
| In reply to | #25275 |
Am 28.08.2012 20:50, schrieb James Kuyper:
> On 08/28/2012 12:45 PM, 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.)
>
> That's not consistent with my understanding of the standard. Could you
> specify precisely how you thought the standard required that structure
> to be laid out?
>
> The relevant clause from the C standard is 6.7.2.1p11:
>> An implementation may allocate any addressable storage unit large enough to hold a bitfield.
>> 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.
>
> In the C++ standard, 9.6p1 says much the same thing, in somewhat less
> formal language.
I have the vague memory of someone claiming that C++ allowed for an
out of order storage of bit-fields, but I would be happy to learn the
contrary.
> Neither standard specifies the size of the allocation unit from which
> bit-fields are allocated. Which size were you assuming was specified by
> the standard?
It must be an addressable storage unit, so it must be a multiple of 8
bit (I assumed that CHAR_BITS is 8). So what ever multiple of 8 is
chosen for it c and d will always fit into the same unit. So the order
will always be a-b-c-d-e or the other way around.
> If there's enough space to store b in the same allocation unit as 'a',
> the C standard requires that 'b' be stored in bits adjacent to 'a', but
> it does not specify the relative order of 'a' and 'b'. Both standards
> explicitly state that the order of bit-fields within an allocation unit
> is unspecified . What order were you assuming was specified by the standard?
>
> Both standards explicitly leave unspecified whether bit-fields can
> overlap adjacent allocation units. Since the assumption that CHAR_BIT==8
> was specified, that problem won't come up in this particular case, but
> with different bit-field sizes, or even with the same sizes in a
> different order, that could be an issue even on entirely conventional
> systems. For instance, if "c" were moved before "b", and the allocation
> unit was either 8 or 16 bits in size, then "b" might, or might not,
> overlap two consecutive allocation unit, depending upon the
> implementation.
I was refering to this example only. Perhaps you missed the fact that
I referred to the case of potential overlap upthread already and that
we were discussing a specific case here that came from an example by
David where he wanted a layout that respected byte (uint8_t)
boundaries.
But, point taken, it has two different layouts.
Jens
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 16:56 -0400 |
| Message-ID | <503D3099.7030805@verizon.net> |
| In reply to | #25294 |
On 08/28/2012 04:36 PM, Jens Gustedt wrote:
> Am 28.08.2012 20:50, schrieb James Kuyper:
>> On 08/28/2012 12:45 PM, 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.)
>>
>> That's not consistent with my understanding of the standard. Could you
>> specify precisely how you thought the standard required that structure
>> to be laid out?
>>
>> The relevant clause from the C standard is 6.7.2.1p11:
>>> An implementation may allocate any addressable storage unit large enough to hold a bitfield.
>>> 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.
>>
>> In the C++ standard, 9.6p1 says much the same thing, in somewhat less
>> formal language.
>
> I have the vague memory of someone claiming that C++ allowed for an
> out of order storage of bit-fields, but I would be happy to learn the
> contrary.
You won't be happy. "in-order" has two different possible meanings, and
each implementation has the option of choosing either one. Both C and
C++ are in agreement on this. Different implementations for the same
platform could make different choices (though market forces make that
unlikely); a single implementation could even make it a command-line option.
C++ allows more freedom than C, because it doesn't require consecutive
bit-fields in the same allocation unit to occupy adjacent sets of bits.
That means that there's a lot more than just two different possible orders.
>> Neither standard specifies the size of the allocation unit from which
>> bit-fields are allocated. Which size were you assuming was specified by
>> the standard?
>
> It must be an addressable storage unit, so it must be a multiple of 8
> bit (I assumed that CHAR_BITS is 8). So what ever multiple of 8 is
> chosen for it c and d will always fit into the same unit. So the order
> will always be a-b-c-d-e or the other way around.
Even in C, there's a lot more than just two possible orders. If, for
example, the allocation unit size is 16, a and b will have to be in the
same allocation unit, and c, d, and e will have to be in the same
allocation unit, but depending upon the allocation order chosen by the
implementation, the fields within each allocation unit could be stored
in either order: "ab cde" or "ba edc". The implementation's definition
of allocation order could even specify different orders in even and odd
numbered words (though I can't think of any reason to do so, except on
middle-endian machines with allocation units of at least 32 bits): "ab
edc" or "ba cde".
Do you still feel that the C standard is sufficiently specific?
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-28 23:28 +0200 |
| Message-ID | <503D37E1.1030505@loria.fr> |
| In reply to | #25296 |
Am 28.08.2012 22:56, schrieb James Kuyper: > On 08/28/2012 04:36 PM, Jens Gustedt wrote: >> I have the vague memory of someone claiming that C++ allowed for an >> out of order storage of bit-fields, but I would be happy to learn the >> contrary. > > You won't be happy. "in-order" has two different possible meanings, and > each implementation has the option of choosing either one. Both C and > C++ are in agreement on this. Different implementations for the same > platform could make different choices (though market forces make that > unlikely); a single implementation could even make it a command-line option. > C++ allows more freedom than C, because it doesn't require consecutive > bit-fields in the same allocation unit to occupy adjacent sets of bits. > That means that there's a lot more than just two different possible orders. argh > Even in C, there's a lot more than just two possible orders... 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. But it seems that interpreting such text then becomes more a question of English skills than of anything else. If in fact, people are interpreting this differently in the sense that "given storage location X here is an algorithm to determine the ordering" is sufficient as defintion for an implementation, and so allowing for a determination of that ordering from location of the storage unit inside a bigger unit and stuff like that, then > Do you still feel that the C standard is sufficiently specific? no and then it would need more precision. But my English is probably not good enough to be capable to make a proposal that is better than the existing text, then. Jens
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-28 18:18 -0400 |
| Message-ID | <503D439C.9020308@verizon.net> |
| In reply to | #25308 |
On 08/28/2012 05:28 PM, Jens Gustedt wrote: > Am 28.08.2012 22:56, schrieb James Kuyper: >> On 08/28/2012 04:36 PM, Jens Gustedt wrote: > >>> I have the vague memory of someone claiming that C++ allowed for an >>> out of order storage of bit-fields, but I would be happy to learn the >>> contrary. >> >> You won't be happy. "in-order" has two different possible meanings, and >> each implementation has the option of choosing either one. Both C and >> C++ are in agreement on this. Different implementations for the same >> platform could make different choices (though market forces make that >> unlikely); a single implementation could even make it a command-line option. >> C++ allows more freedom than C, because it doesn't require consecutive >> bit-fields in the same allocation unit to occupy adjacent sets of bits. >> That means that there's a lot more than just two different possible orders. > > argh > >> 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" > 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. That's correct. The comment was actually intended to be about C++, not C. The text in the C++ standard that comes closest to saying the same thing merely gives "left-to-right" and "right-to-left" (sic) as examples of orders that actually occur, without specifying that they are the only permitted orders. >> Do you still feel that the C standard is sufficiently specific? > > no > > and then it would need more precision. But my English is probably not > good enough to be capable to make a proposal that is better than the > existing text, then. It would be a trivial exercise to rewrite this to remove almost all of the freedom implementations currently have in laying out bit fields. It wouldn't require particularly good English skills: 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. The hard part would not be writing up such a change, but getting it approved. It would make bit-fields much more portable, at the cost of breaking huge quantities of existing code when it tries to read data written using a different lay-out, or tries to communicate with existing routines (many of them not written in C) that use a different lay-out.
[toc] | [prev] | [next] | [standalone]
Page 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web