Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #24707 > unrolled thread
| Started by | lovecreatesbeauty <lovecreatesbeauty@gmail.com> |
|---|---|
| First post | 2012-08-22 10:34 -0700 |
| Last post | 2012-08-27 22:41 -0400 |
| Articles | 20 on this page of 192 — 45 participants |
Back to article view | Back to comp.lang.c
GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-22 10:34 -0700
Re: GCC is re-implementing in C++ and C discarded Thomas Richter <thor@math.tu-berlin.de> - 2012-08-22 19:50 +0200
Re: GCC is re-implementing in C++ and C discarded fmassei@gmail.com - 2012-08-22 11:04 -0700
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-22 14:22 -0400
Re: GCC is re-implementing in C++ and C discarded Angel <angel+news@spamcop.net> - 2012-08-22 18:43 +0000
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-22 12:08 -0700
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-22 12:32 -0700
Re: GCC is re-implementing in C++ and C discarded "BartC" <bc@freeuk.com> - 2012-08-22 20:45 +0100
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-22 22:20 +0200
Re: GCC is re-implementing in C++ and C discarded Chicken McNuggets <chicken@mcnuggets.com> - 2012-08-23 10:43 +0100
Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 21:14 +0200
[OT] Re: GCC is re-implementing in C++ and C discarded William Ahern <william@wilbur.25thandClement.com> - 2012-08-23 13:27 -0700
Re: [OT] Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 22:38 +0200
Re: GCC is re-implementing in C++ and C discarded William Ahern <william@wilbur.25thandClement.com> - 2012-08-22 13:40 -0700
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-23 00:15 -0700
Re: GCC is re-implementing in C++ and C discarded 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-23 00:40 -0700
Re: GCC is re-implementing in C++ and C discarded Mark Bluemel <mark_bluemel@pobox.com> - 2012-08-23 09:48 +0100
Re: GCC is re-implementing in C++ and C discarded Robert Wessel <robertwessel2@yahoo.com> - 2012-08-22 15:56 -0500
Re: GCC is re-implementing in C++ and C discarded Chicken McNuggets <chicken@mcnuggets.com> - 2012-08-23 10:49 +0100
Re: GCC is re-implementing in C++ and C discarded Robert Wessel <robertwessel2@yahoo.com> - 2012-08-23 08:32 -0500
Re: GCC is re-implementing in C++ and C discarded Chicken McNuggets <chicken@mcnuggets.com> - 2012-08-23 14:49 +0100
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-23 17:23 +0200
Re: GCC is re-implementing in C++ and C discarded fmassei@gmail.com - 2012-08-23 08:43 -0700
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-23 17:52 +0200
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-23 18:41 +0100
Re: GCC is re-implementing in C++ and C discarded gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-23 17:42 +0000
Re: GCC is re-implementing in C++ and C discarded gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-23 17:43 +0000
Re: GCC is re-implementing in C++ and C discarded Robert Wessel <robertwessel2@yahoo.com> - 2012-08-23 18:54 -0500
Re: GCC is re-implementing in C++ and C discarded David Brown <david@westcontrol.removethisbit.com> - 2012-08-24 09:51 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-24 06:21 -0500
Re: GCC is re-implementing in C++ and C discarded Chicken McNuggets <chicken@mcnuggets.com> - 2012-09-03 16:55 +0100
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-24 13:36 -0400
Re: GCC is re-implementing in C++ and C discarded Andrew Smallshaw <andrews@sdf.lonestar.org> - 2012-08-27 06:05 +0000
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-23 12:56 -0700
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-29 21:10 +0100
Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 21:23 +0200
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-23 18:37 +0100
Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 21:19 +0200
Re: GCC is re-implementing in C++ and C discarded 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-25 02:40 -0700
Re: GCC is re-implementing in C++ and C discarded Melzzzzz <mel@zzzzz.invalid> - 2012-08-23 21:15 +0200
Re: GCC is re-implementing in C++ and C discarded David Brown <david@westcontrol.removethisbit.com> - 2012-08-24 09:52 +0200
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-25 07:51 +0000
Re: GCC is re-implementing in C++ and C discarded David Brown <david@westcontrol.removethisbit.com> - 2012-08-26 23:09 +0200
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-22 17:43 -0400
Re: GCC is re-implementing in C++ and C discarded Anonymous <nobody@remailer.paranoici.org> - 2012-08-23 20:17 +0000
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-24 15:09 +0200
Re: GCC is re-implementing in C++ and C discarded jacob navia <jacob@spamsink.net> - 2012-08-24 17:53 +0200
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-24 19:02 +0200
Re: GCC is re-implementing in C++ and C discarded jacob navia <jacob@spamsink.net> - 2012-08-24 20:53 +0200
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-24 21:33 +0200
Re: GCC is re-implementing in C++ and C discarded Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-25 02:33 -0700
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 11:41 +0200
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-26 08:04 +0000
Re: GCC is re-implementing in C++ and C discarded jacob navia <jacob@spamsink.net> - 2012-08-24 21:08 +0200
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-24 21:37 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-22 15:13 -0700
Re: GCC is re-implementing in C++ and C discarded David Brown <david@westcontrol.removethisbit.com> - 2012-08-23 10:09 +0200
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-23 13:00 -0400
Re: GCC is re-implementing in C++ and C discarded Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 06:33 -0700
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-25 09:06 +0000
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 11:31 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 13:45 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:16 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:37 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:40 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 15:01 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 22:03 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 17:11 -0700
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-26 11:46 +0200
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-25 03:07 -0700
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 12:22 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 09:35 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 17:28 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:00 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:17 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 14:23 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:26 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 15:02 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 22:00 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:50 -0400
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 12:09 -0700
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:20 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 17:32 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-25 17:55 +0200
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 18:49 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:23 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:30 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 02:19 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 02:23 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 18:02 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 09:18 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-26 02:04 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 13:35 +0200
Re: GCC is re-implementing in C++ and C discarded eq mail <eq.mail.id@gmail.com> - 2012-08-31 02:10 -0700
Re: GCC is re-implementing in C++ and C discarded Gareth Owen <gwowen@gmail.com> - 2012-08-25 15:59 +0100
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 17:26 +0200
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-25 13:50 -0500
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:21 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-25 15:27 -0400
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-08-25 21:36 +0200
Re: GCC is re-implementing in C++ and C discarded Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-06 14:41 +0300
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-09-07 17:50 +0200
Re: GCC is re-implementing in C++ and C discarded Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-07 19:13 +0300
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-09-07 19:17 +0200
Re: GCC is re-implementing in C++ and C discarded Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-09 11:12 +0300
Re: GCC is re-implementing in C++ and C discarded Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-07 19:37 +0300
Re: GCC is re-implementing in C++ and C discarded Johannes Bauer <dfnsonfsduifb@gmx.de> - 2012-09-07 19:22 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 12:14 -0700
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-25 23:13 +0000
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-26 00:28 -0700
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-26 11:15 +0000
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-26 17:33 +0100
Re: GCC is re-implementing in C++ and C discarded Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-08-26 18:59 +0000
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-26 14:07 -0700
Re: GCC is re-implementing in C++ and C discarded Andrew Cooper <amc96@cam.ac.uk> - 2012-08-22 22:37 +0100
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-22 15:16 -0700
Re: GCC is re-implementing in C++ and C discarded pacman@kosh.dhis.org (Alan Curry) - 2012-08-22 22:26 +0000
Re: GCC is re-implementing in C++ and C discarded Nobody <nobody@nowhere.com> - 2012-08-23 02:07 +0100
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-22 22:42 -0400
Re: GCC is re-implementing in C++ and C discarded Les Cargill <lcargill99@comcast.com> - 2012-08-23 00:54 -0500
Re: GCC is re-implementing in C++ and C discarded nroberts <roberts.noah@gmail.com> - 2012-08-24 16:16 -0700
Re: GCC is re-implementing in C++ and C discarded Aaron W. Hsu <arcfide@sacrideo.us> - 2012-08-23 13:10 -0500
Re: GCC is re-implementing in C++ and C discarded Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-24 02:15 -0700
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-24 13:58 -0400
Re: GCC is re-implementing in C++ and C discarded "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2012-08-24 23:12 +0000
Re: GCC is re-implementing in C++ and C discarded Anonymous <nobody@remailer.paranoici.org> - 2012-08-25 21:35 +0000
Re: GCC is re-implementing in C++ and C discarded William Ahern <william@wilbur.25thandClement.com> - 2012-08-25 14:59 -0700
Re: GCC is re-implementing in C++ and C discarded Nomen Nescio <nobody@dizum.com> - 2012-08-26 12:34 +0200
Re: GCC is re-implementing in C++ and C discarded "Steven G. Kargl" <sgk@REMOVEtroutmask.apl.washington.edu> - 2012-08-25 23:52 +0000
Re: GCC is re-implementing in C++ and C discarded Fritz Wuehler <fritz@spamexpire-201208.rodent.frell.theremailer.net> - 2012-08-30 03:18 +0200
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-27 13:41 -0400
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 15:23 -0700
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-29 10:55 -0400
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-25 03:14 -0700
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-25 11:18 +0100
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-25 12:18 -0700
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-26 20:06 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-26 21:04 -0700
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-27 00:19 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 01:33 -0700
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 08:26 -0400
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-27 07:36 -0700
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 17:48 +0200
Re: GCC is re-implementing in C++ and C discarded Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-28 06:15 -0700
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 12:27 -0400
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 19:11 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 13:38 -0400
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 21:48 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 21:54 +0200
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 21:56 +0200
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 16:09 -0400
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-27 22:14 +0200
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-27 18:25 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 18:34 -0700
Re: GCC is re-implementing in C++ and C discarded eq mail <eq.mail.id@gmail.com> - 2012-08-27 18:45 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 19:24 -0700
Re: GCC is re-implementing in C++ and C discarded Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 07:00 -0700
Re: GCC is re-implementing in C++ and C discarded lovecreatesbeauty <lovecreatesbeauty@gmail.com> - 2012-08-27 23:47 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-28 01:27 -0700
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 15:20 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 00:55 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 16:43 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:01 +0200
Re: GCC is re-implementing in C++ and C discarded ais523 <ais523@bham.ac.uk> - 2012-08-27 23:16 +0000
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 17:34 -0700
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-28 03:16 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:07 +0200
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-28 13:47 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 16:17 +0200
Re: GCC is re-implementing in C++ and C discarded lawrence.jones@siemens.com - 2012-08-31 17:40 -0400
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-02 00:59 +0200
Re: GCC is re-implementing in C++ and C discarded Szabolcs Nagy <nsz@port70.net> - 2012-09-03 00:31 +0000
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 08:31 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 09:13 +0200
Re: GCC is re-implementing in C++ and C discarded Ike Naar <ike@iceland.freeshell.org> - 2012-09-03 15:38 +0000
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 18:38 +0200
Re: GCC is re-implementing in C++ and C discarded Ike Naar <ike@iceland.freeshell.org> - 2012-09-03 17:04 +0000
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 23:19 +0200
Re: GCC is re-implementing in C++ and C discarded Herbert Rosenau <os2guy@pc-rosenau.de> - 2012-09-03 21:48 +0200
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-03 23:41 +0200
Re: GCC is re-implementing in C++ and C discarded Richard Damon <news.x.richarddamon@xoxy.net> - 2012-09-03 19:37 -0400
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-04 10:14 +0200
Re: GCC is re-implementing in C++ and C discarded Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 07:18 -0700
Re: GCC is re-implementing in C++ and C discarded ais523 <ais523@bham.ac.uk> - 2012-08-28 01:40 +0000
Re: GCC is re-implementing in C++ and C discarded Kenneth Brody <kenbrody@spamcop.net> - 2012-08-29 11:02 -0400
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 22:29 -0400
Re: GCC is re-implementing in C++ and C discarded Rui Maciel <rui.maciel@gmail.com> - 2012-08-28 21:11 +0100
Re: GCC is re-implementing in C++ and C discarded Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-29 01:38 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-28 17:12 -0700
Re: GCC is re-implementing in C++ and C discarded Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 18:41 +0200
Re: GCC is re-implementing in C++ and C discarded Keith Thompson <kst-u@mib.org> - 2012-08-27 15:08 -0700
Re: GCC is re-implementing in C++ and C discarded James Kuyper <jameskuyper@verizon.net> - 2012-08-27 22:41 -0400
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-25 12:09 -0700 |
| Message-ID | <lnzk5ig54s.fsf@nuthaus.mib.org> |
| In reply to | #24918 |
Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> On 25.08.2012 15:35, James Kuyper wrote:
>>> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
>>> Some constructs which are necessary for embedded systems are just syntax
>>> errors in C++, while they work perfectly in C.
>>
>> I can understand the necessity of using C on an embedded system if C++
>> is not available there. However, if a C++ compiler is available, I can't
>> imagine what these "necessary constructs" could be.
>
> Placing an interrupt vector table in ROM:
>
> struct ivtlayout {
> int vec1;
> int vec2;
> int vec3;
> };
>
> struct ivtlayout ivt = {
> .vec1 = 1234,
> };
>
> int main() {
> return 0;
> }
In this particular case, you could just write:
struct ivtlayout ivt = { 1234 };
More generally, you just need to specify the member values in the order
in which they're defined.
Designated initializers are admittedly more convenient, especially when
you don't want to (or can't) make assumptions about member order.
>> If you're talking about something non-portable, is there anything
>> preventing a C++ compiler from providing support for a corresponding
>> non-portable construct?
>
> No, definitely not. Non-portable C++ could definitely provide this. I am
> just really not a big fan of non-portable dialects. Actually, I really
> don't know why this wasn't included in c++0x.
It's C++11 now. The 2011 ISO C++ standard did add a number
of features from C99, including long long, but it didn't add
designated initializers. I also don't know why they aren't in C++11
(I just checked the standard expecting to find them). VLAs and the
`restrict` keyword were also left out of C++11.
--
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 | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2012-08-25 21:20 +0200 |
| Message-ID | <k1b8i0$iut$3@news.albasani.net> |
| In reply to | #24932 |
On 25.08.2012 21:09, Keith Thompson wrote:
> In this particular case, you could just write:
>
> struct ivtlayout ivt = { 1234 };
>
> More generally, you just need to specify the member values in the order
> in which they're defined.
*sigh* Obviously, yes. But that's not the point. The point is being able
to tell what vectors you want to use and not need to search through a
list of 98 vectors and hit the correct array position (which is, quite
frankly, incredibly inconvenient).
> Designated initializers are admittedly more convenient, especially when
> you don't want to (or can't) make assumptions about member order.
That is exactly the case here. There's a definition file in which all
almost 100 IRQ vectors are specified and you want to be able to say: "I
will use IRQs for DMA0 and for USART2". You don't want to look it up
somewhere and modify the 48th and 82th entry in a struct.
>>> If you're talking about something non-portable, is there anything
>>> preventing a C++ compiler from providing support for a corresponding
>>> non-portable construct?
>>
>> No, definitely not. Non-portable C++ could definitely provide this. I am
>> just really not a big fan of non-portable dialects. Actually, I really
>> don't know why this wasn't included in c++0x.
>
> It's C++11 now. The 2011 ISO C++ standard did add a number
> of features from C99, including long long, but it didn't add
> designated initializers. I also don't know why they aren't in C++11
> (I just checked the standard expecting to find them). VLAs and the
> `restrict` keyword were also left out of C++11.
Ah, yes, I still write 0x all the time. Maybe in the next revision
they'll be in.
Best regards,
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-25 17:32 -0700 |
| Message-ID | <ln393afq7f.fsf@nuthaus.mib.org> |
| In reply to | #24939 |
Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> On 25.08.2012 21:09, Keith Thompson wrote:
>> In this particular case, you could just write:
>>
>> struct ivtlayout ivt = { 1234 };
>>
>> More generally, you just need to specify the member values in the order
>> in which they're defined.
>
> *sigh* Obviously, yes. But that's not the point. The point is being able
> to tell what vectors you want to use and not need to search through a
> list of 98 vectors and hit the correct array position (which is, quite
> frankly, incredibly inconvenient).
I understand your point now, but it was not at all clear from your
earlier messages.
[...]
--
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 | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-25 17:55 +0200 |
| Message-ID | <5038F564.7040101@loria.fr> |
| In reply to | #24909 |
Am 25.08.2012 15:35, schrieb James Kuyper: > However, that was basically just a trick (and it took me a long time to > perfect it). As far as I know, everything that can be done using > portable C code can also be done by using (possibly different) C code > that also compiles as C++ code, with the same exact meaning in both > languages (exception: code like that which I described above, whose sole > purpose is to detect which language it was compiled in - by definition > such code must behave differently in order to behave correctly). Could > you give a counter-example? The intersection of C and C++ has - no decent initializers, you'd need designated initializers on the C side and constructors for C++ - no decent temporaries (compound literals for C and constructors for C++) - no consistent way of passing dynamically sizes multi-dimensional arrays to functions - no type puning (union's are standardized differently between the two) - no consistent model for function inlining not very attractive, at least for me Jens
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2012-08-25 18:49 +0200 |
| Message-ID | <k1avma$2o6$1@news.albasani.net> |
| In reply to | #24920 |
On 25.08.2012 17:55, Jens Gustedt wrote: > The intersection of C and C++ has > - no decent initializers, you'd need designated initializers on the C > side and constructors for C++ > - no decent temporaries (compound literals for C and constructors for C++) > - no consistent way of passing dynamically sizes multi-dimensional > arrays to functions > - no type puning (union's are standardized differently between the > two) > - no consistent model for function inlining > > not very attractive, at least for me I'm using C++ (and c++0x at that) for doing very, very low-level work, down to 8 bit microcontrollers. And while most people seem to think that this is impossible, quite the contrary is true: There is a huge benefit in using it (if it is used correctly). For 8 bitters, for example, I do not use fancy stuff (virtual methods, inheritance etc), nor parts of the STL. I use heavily low-level language guarantees, such as strong typing and especially strongly types class enums (gotta love those!). To give an example on how MCU code looks using C and how it's usually done (this is an example from an actual project of mine): TCCR1A = _BV(COM1A1); /* Clear on Compare Match */ TCCR1B = _BV(CS10) | _BV(WGM13); /* 1 / 1 */ TCCR0B = _BV(CS02) | _BV(CS00); where the _BV() macro is defined to be _BV(x) (1 << (x)). All the symbols are defined by the standard library, the lvalues are volatile registers and the rvalues are basically just bit definitions of the hardware's datasheet. This is just horrible. Notice how the settings of two different timers are set, the first two lines refer to Timer 1 while the third refers to timer 0. Both have a prescaler, or clock selection. Notice that the bits in the standard library for this AVR processor are named CSnm, where n is the timer (0, 1) and m is the bitvalue (0, 1, 2, 3). Obviously it is *very* error-prone, because setting the wrong one in either register leads to weird (and hard to debug results). In C++, whith smart constructs, you can basically say TCCR1().PRESCALER() = T1Presc::CKDIV_2; TCCR0().PRESCALER() = T0Presc::CKDIV_16; and it will boil down to the *exact* same code with no performance penalty at all, only added typesafety. The compiler will barf if you try to put the wrong type into a field. I find that quite awesome and this is actually a reason for me to prefer C++ over C for this type of work. Best regards, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-25 15:23 -0400 |
| Message-ID | <k1b8no$p8m$1@dont-email.me> |
| In reply to | #24920 |
On 08/25/2012 11:55 AM, Jens Gustedt wrote:
> Am 25.08.2012 15:35, schrieb James Kuyper:
>> However, that was basically just a trick (and it took me a long time to
>> perfect it). As far as I know, everything that can be done using
>> portable C code can also be done by using (possibly different) C code
>> that also compiles as C++ code, with the same exact meaning in both
>> languages (exception: code like that which I described above, whose sole
>> purpose is to detect which language it was compiled in - by definition
>> such code must behave differently in order to behave correctly). Could
>> you give a counter-example?
>
> The intersection of C and C++ has
> - no decent initializers, you'd need designated initializers on the C
> side and constructors for C++
???
The claim was that use of C was a necessity, not just a convenience. C
doesn't have constructors, and designated initializers are only a
convenience feature that don't do anything that can't already be done
using ordinary initializers - they just make it more convenient.
> - no decent temporaries (compound literals for C and constructors for C++)
???
A compound literal doesn't do any thing that can't be done with an
explicitly declared and named temporary object. Again, it's just a
convenience feature.
> - no consistent way of passing dynamically sizes multi-dimensional
> arrays to functions
???
int func (double *array, rows, cols)
{
// to access column c of row r:
array[r*cols + c]
VLAs are also just a convenience feature - the don't do anything that
can't be done less conveniently by other methods.
It might just be jealousy on my part - I've never been paid to program
in an environment where I was permitted to use either designated
initializers or VLAs; I've regretted having to work within those
restrictions, but never had any trouble working around them, so the
claim that a lack of support for those features renders C++ unusable
strikes me as quite laughable.
> - no type puning (union's are standardized differently between the
> two)
Could you explain the relevant differences? There are things prohibited
in C++ unions that aren't even meaningful in C unions, but I'm not aware
of anything that C unions allow you to do that couldn't also be done in
C++. I'm willing to believe that I might have missed something, but you
need to be more specific.
> - no consistent model for function inlining
There are significant subtle differences between the two languages with
respect to inlining. However, the supposed "necessity" of programming in
C as a result of those differences would be much clearer with a
sufficiently specific example.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2012-08-25 21:30 +0200 |
| Message-ID | <k1b954$lij$1@news.albasani.net> |
| In reply to | #24941 |
On 25.08.2012 21:23, James Kuyper wrote: >> The intersection of C and C++ has >> - no decent initializers, you'd need designated initializers on the C >> side and constructors for C++ > > ??? > The claim was that use of C was a necessity, not just a convenience. C > doesn't have constructors, and designated initializers are only a > convenience feature that don't do anything that can't already be done > using ordinary initializers - they just make it more convenient. By that twisted logic, every Turing complete logic has the same feature set, since they're all Turing complete. Every syntacitical primitive is just "convenience". Give me a break here. That's ridiciulous. Designated initializers are something missing from C++ and they're something that are *actually* incredibly useful, as I can demonstrate. Obviously, you can still get it done somehow, but this is not the point: The point is finding an solution which minimizes effort. This is possible in C, but in this instance it is not with C++. Best regards, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-26 02:19 +0200 |
| Message-ID | <50396B87.3020403@loria.fr> |
| In reply to | #24941 |
Am 25.08.2012 21:23, schrieb James Kuyper:
> On 08/25/2012 11:55 AM, Jens Gustedt wrote:
>> Am 25.08.2012 15:35, schrieb James Kuyper:
>>> However, that was basically just a trick (and it took me a long time to
>>> perfect it). As far as I know, everything that can be done using
>>> portable C code can also be done by using (possibly different) C code
>>> that also compiles as C++ code, with the same exact meaning in both
>>> languages (exception: code like that which I described above, whose sole
>>> purpose is to detect which language it was compiled in - by definition
>>> such code must behave differently in order to behave correctly). Could
>>> you give a counter-example?
>>
>> The intersection of C and C++ has
>> - no decent initializers, you'd need designated initializers on the C
>> side and constructors for C++
>
> ???
> The claim was that use of C was a necessity, not just a convenience. C
> doesn't have constructors, and designated initializers are only a
> convenience feature that don't do anything that can't already be done
> using ordinary initializers - they just make it more convenient.
How would you do
unsigned char errVector[] = { [EINVAL] = true, [ERANGE] = true, };
enum { maxNeeded = sizeof(errVector), };
in C++ ?
>> - no decent temporaries (compound literals for C and constructors for C++)
>
> ???
> A compound literal doesn't do any thing that can't be done with an
> explicitly declared and named temporary object. Again, it's just a
> convenience feature.
E.g you can't easily declare named temporaries in function-like
macros, and you can't easily protect named temporaries from accidental
use elsewhere in your code.
You can easily use anonymous temporaries in both languages for
that, but not with a common syntax.
Convenience is all that higher programming languages bring, no?
>> - no consistent way of passing dynamically sizes multi-dimensional
>> arrays to functions
>
> ???
> int func (double *array, rows, cols)
> {
> // to access column c of row r:
> array[r*cols + c]
>
> VLAs are also just a convenience feature - the don't do anything that
> can't be done less conveniently by other methods.
sizeof *array is a very convenient feature, and much less error prone
than copying the size expression all over your code.
Well again, yes for convenience I can explicitly declare a variable
that holds the size of *array, invent a naming convention for such a
thing as sizeof_array or so. I prefer to have a language (or library)
feature for that. Both C and C++ provide that feature but with
completely different syntax.
> It might just be jealousy on my part - I've never been paid to program
> in an environment where I was permitted to use either designated
> initializers or VLAs; I've regretted having to work within those
> restrictions, but never had any trouble working around them, so the
> claim that a lack of support for those features renders C++ unusable
> strikes me as quite laughable.
Have your laugh, I was not saying that. I was saying that the
intersection of those two languages is not very convenient to use. C++
has its own features that replaces them, more or less. (For designated
initializers there is not really a replacement, since C++ always
forces you to initialize in declaration order.)
>> - no type puning (union's are standardized differently between the
>> two)
>
> Could you explain the relevant differences? There are things prohibited
> in C++ unions that aren't even meaningful in C unions, but I'm not aware
> of anything that C unions allow you to do that couldn't also be done in
> C++. I'm willing to believe that I might have missed something, but you
> need to be more specific.
AFAIK C++ got stuck with the initial wording that has been corrected
for C. In C++ reading another member that was written to is UB. In C
it is perfectly valid unless you happen to encounter a trap
representation for the read-type. Type punning is basically what
unions are made for in C. If you use unions for type punning the
compiler can arbitrarily decide to throw up on you, since this is UB,
anyhow.
>> - no consistent model for function inlining
>
> There are significant subtle differences between the two languages with
> respect to inlining.
subtle? I don't think that there is a valid use of that feature in the
intersection of C and C++ that covers all use cases. Either you may
encounter multiple symbols or the day you compile for debugging a
symbol is missing.
> However, the supposed "necessity" of programming in
> C as a result of those differences would be much clearer with a
> sufficiently specific example.
I didn't say that there is necessity. I said that there are strong
forces that push you to chose a side.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-26 02:23 +0200 |
| Message-ID | <50396C8E.6010200@loria.fr> |
| In reply to | #24968 |
Am 26.08.2012 02:19, schrieb Jens Gustedt: > If you use unions for type punning the > compiler can arbitrarily decide to throw up on you, since this is UB, > anyhow. This sentence is missing a prefix, sorry: In C++, if you use unions ... (It is far too late here.) Jens
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-25 18:02 -0700 |
| Message-ID | <lny5l2ea8z.fsf@nuthaus.mib.org> |
| In reply to | #24968 |
Jens Gustedt <jens.gustedt@loria.fr> writes:
> Am 25.08.2012 21:23, schrieb James Kuyper:
[...]
>> ???
>> The claim was that use of C was a necessity, not just a convenience. C
>> doesn't have constructors, and designated initializers are only a
>> convenience feature that don't do anything that can't already be done
>> using ordinary initializers - they just make it more convenient.
>
> How would you do
>
> unsigned char errVector[] = { [EINVAL] = true, [ERANGE] = true, };
> enum { maxNeeded = sizeof(errVector), };
>
> in C++ ?
Probably something like:
unsigned char errVector[] = { };
enum { maxNeeded = sizeof(errVector), };
...
errVector[EINVAL] = true;
errVector[ERANGE] = true;
And depending on the context, the assignments might go into a
constructor, which avoids the possibility of forgetting to call it.
(This isn't to suggest that designated initializers aren't often
a great convenience, of course.)
--
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 | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-26 09:18 +0200 |
| Message-ID | <5039CDAB.4000701@loria.fr> |
| In reply to | #24971 |
Am 26.08.2012 03:02, schrieb Keith Thompson:
> Jens Gustedt <jens.gustedt@loria.fr> writes:
>>
>> How would you do
>>
>> unsigned char errVector[] = { [EINVAL] = true, [ERANGE] = true, };
>> enum { maxNeeded = sizeof(errVector), };
>>
>> in C++ ?
I should have added a static for the vector, or insist that this is
file scope to make my point clearer, sorry.
> Probably something like:
>
> unsigned char errVector[] = { };
I don't think that this is valid C++. You have to have a size for the
vector if you have an initialization don't you?
> enum { maxNeeded = sizeof(errVector), };
Hm, the sizeof operator isn't well defined here
> errVector[EINVAL] = true;
> errVector[ERANGE] = true;
These are statements and not initializations and thus limited to block
scope. The version with the designated initializers is compile time.
> And depending on the context, the assignments might go into a
> constructor, which avoids the possibility of forgetting to call it.
Well first of all arrays don't have constructors, so you'd have to
wrap the array in a struct. And so you would declare a type for just
the one instance of an array that you need?
Then struct members have to have a size that is determined at compile
time, so you'd have to apply a complicated max function for EINVAL and
ERANGE (and whatever other constants you are interested in.).
Then these statements would go into the executable (function) part of
the constructor, not in the initializer list. So your array-struct
would be runtime initialized.
The "real" C++ to achieve something equivalent (compile time
determination of an array size depending on perhaps lengthy list of
constants) would probably use some complicated templates to do meta
programming. Something like
MaxOf< EINVAL, ERANGE, /* other constants go here */ >::val
(probably there is something like this in C++ already, my C++ is a bit
rusty)
So this is something that is feasible in both languages, but with
completely different syntax.
> (This isn't to suggest that designated initializers aren't often
> a great convenience, of course.)
Well higher level programming languages are for convenience, aren't
they?
And it is not only convenience, it is also for maintainability,
verifiability and so.
Jens
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-26 02:04 -0700 |
| Message-ID | <lnmx1idnxy.fsf@nuthaus.mib.org> |
| In reply to | #24993 |
Jens Gustedt <jens.gustedt@loria.fr> writes:
> Am 26.08.2012 03:02, schrieb Keith Thompson:
>> Jens Gustedt <jens.gustedt@loria.fr> writes:
>>>
>>> How would you do
>>>
>>> unsigned char errVector[] = { [EINVAL] = true, [ERANGE] = true, };
>>> enum { maxNeeded = sizeof(errVector), };
>>>
>>> in C++ ?
>
> I should have added a static for the vector, or insist that this is
> file scope to make my point clearer, sorry.
>
>> Probably something like:
>>
>> unsigned char errVector[] = { };
>
> I don't think that this is valid C++. You have to have a size for the
> vector if you have an initialization don't you?
Right.
>> enum { maxNeeded = sizeof(errVector), };
>
> Hm, the sizeof operator isn't well defined here
And that's the point I missed. In your C version, the length of
errVector depends on the values of EINVAL and ERANGE; specifically, it's
`max(EINVAL, ERANGE) + 1` (given the obvious definition of `max()`).
It's not straightforwardly translatable to C++.
Yeah, I goofed.
Just curious: was your example contrived to demonstrate the point, or is
it based on something in real code?
>> errVector[EINVAL] = true;
>> errVector[ERANGE] = true;
>
> These are statements and not initializations and thus limited to block
> scope. The version with the designated initializers is compile time.
Yes.
>> And depending on the context, the assignments might go into a
>> constructor, which avoids the possibility of forgetting to call it.
>
> Well first of all arrays don't have constructors, so you'd have to
> wrap the array in a struct. And so you would declare a type for just
> the one instance of an array that you need?
Maybe. Or maybe the C++ program would be structured in a way that the
initialization would naturally be inside a class/struct anyway.
> Then struct members have to have a size that is determined at compile
> time, so you'd have to apply a complicated max function for EINVAL and
> ERANGE (and whatever other constants you are interested in.).
>
> Then these statements would go into the executable (function) part of
> the constructor, not in the initializer list. So your array-struct
> would be runtime initialized.
Right, but how important is that? As long as you have a mechanism to
ensure that the code is executed before the values are needed, and it's
only executed once, it shouldn't matter a whole lot. (Or maybe it does
matter for small embedded systems. Hmm.)
[snip]
--
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 | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-26 13:35 +0200 |
| Message-ID | <503A09EA.6010902@loria.fr> |
| In reply to | #25001 |
Am 26.08.2012 11:04, schrieb Keith Thompson:
> Jens Gustedt <jens.gustedt@loria.fr> writes:
>> Am 26.08.2012 03:02, schrieb Keith Thompson:
> And that's the point I missed. In your C version, the length of
> errVector depends on the values of EINVAL and ERANGE; specifically, it's
> `max(EINVAL, ERANGE) + 1` (given the obvious definition of `max()`).
> It's not straightforwardly translatable to C++.
>
> Yeah, I goofed.
>
> Just curious: was your example contrived to demonstrate the point, or is
> it based on something in real code?
yes, kind of. In P99 I use some sort of table that if you boil it down
amounts to something like
char const*const errNames[] = {
#ifdef ERANGE
[ERANGE] = "ERANGE",
#endif
#ifdef EINVAL
[EINVAL] = "EINVAL",
#endif
/* etc for all the EXXX codes that I have heard of */
};
> Maybe. Or maybe the C++ program would be structured in a way that the
> initialization would naturally be inside a class/struct anyway.
maybe
>> Then struct members have to have a size that is determined at compile
>> time, so you'd have to apply a complicated max function for EINVAL and
>> ERANGE (and whatever other constants you are interested in.).
>>
>> Then these statements would go into the executable (function) part of
>> the constructor, not in the initializer list. So your array-struct
>> would be runtime initialized.
>
> Right, but how important is that? As long as you have a mechanism to
> ensure that the code is executed before the values are needed, and it's
> only executed once, it shouldn't matter a whole lot. (Or maybe it does
> matter for small embedded systems. Hmm.)
It does matter for initialization ordering. Forcing initializers for
static objects to be executed in a prescribed order is really a
pain. I once designed such a thing, don't want to do it again.
In the example above, if I'd have any other initializer that depends
on that table of error strings, e.g its size, I am screwed.
An then I simply don't like things that can be checked and done at
compile time (and can thus be properly diagnosed by the compiler) do
be delayed to runtime.
Jens
[toc] | [prev] | [next] | [standalone]
| From | eq mail <eq.mail.id@gmail.com> |
|---|---|
| Date | 2012-08-31 02:10 -0700 |
| Message-ID | <96698179-5466-4094-be6f-5340b799cc08@c4g2000vbe.googlegroups.com> |
| In reply to | #24968 |
On 26.8, 00:19, Jens Gustedt wrote:
> Am 25.08.2012 21:23, schrieb James Kuyper:
> > On 08/25/2012 11:55 AM, Jens Gustedt wrote:
> >> Am 25.08.2012 15:35, schrieb James Kuyper:
> >>> However, that was basically just a trick (and it took me a long time to
> >>> perfect it). As far as I know, everything that can be done using
> >>> portable C code can also be done by using (possibly different) C code
> >>> that also compiles as C++ code, with the same exact meaning in both
> >>> languages (exception: code like that which I described above, whose sole
> >>> purpose is to detect which language it was compiled in - by definition
> >>> such code must behave differently in order to behave correctly). Could
> >>> you give a counter-example?
>
> >> The intersection of C and C++ has
> >> - no decent initializers, you'd need designated initializers on the C
> >> side and constructors for C++
>
> > ???
> > The claim was that use of C was a necessity, not just a convenience. C
> > doesn't have constructors, and designated initializers are only a
> > convenience feature that don't do anything that can't already be done
> > using ordinary initializers - they just make it more convenient.
>
> How would you do
>
> unsigned char errVector[] = { [EINVAL] = true, [ERANGE] = true, };
> enum { maxNeeded = sizeof(errVector), };
>
> in C++ ?
(I apologize for this bunch of C++ in a technically unrelated group,
for those offended.)
This question caught my attention: can this be done? This certainly
falls into the "there's many a way to do this" basket in C++, and
perhaps (like mostly anything) with enough Boost magic and repetitive
overloads, it has always been possible; however, I sought for a
(relatively) expressive solution using the relatively powerful
variadic templates, and came up with this. (Someone better than me
might come up with something cleaner, as most would agree that this
*is* rather wieldy.)
#include <array>
#include <cstddef>
#include <type_traits>
template<std::size_t i, std::size_t... Rest>
struct indices {
typedef typename std::enable_if<sizeof...(Rest) != 0,
indices<Rest...>>::type next;
static constexpr std::size_t value = i,
max = (value + 1 > next::max)
? value + 1
: next::max;
};
template<std::size_t i>
struct indices<i> {
typedef void next;
static constexpr std::size_t value = i,
max = value + 1;
};
template<class U, std::size_t N, class T>
constexpr typename std::enable_if<std::is_void<T>::value, U>::type
get()
{
return U();
}
template<class U, std::size_t N, class T, class V, class... Rest>
constexpr typename std::enable_if<!std::is_void<T>::value, U>::type
get(V&& v, Rest&&... rest)
{
return (T::value == N)
? std::forward<V>(v)
: get<U, N, typename T::next>(std::forward<Rest>(rest)...);
}
template<class U, class Indices, std::size_t... Gen, class... Rest>
constexpr typename std::enable_if<sizeof...(Gen) == Indices::max,
std::array<U, Indices::max>>::type
make_(Rest&&... rest)
{
return {{get<U, Gen, Indices>(std::forward<Rest>(rest)...)...}};
}
template<class U, class Indices, std::size_t... Gen, class... Rest>
constexpr typename std::enable_if<sizeof...(Gen) != Indices::max,
std::array<U, Indices::max>>::type
make_(Rest&&... rest)
{
return make_<U, Indices, Gen..., sizeof...(Gen)>(
std::forward<Rest>(rest)...);
}
template<class U, std::size_t... Indices, class... Rest>
constexpr std::array<U, indices<Indices...>::max> make(Rest&&... rest)
{
return make_<U, indices<Indices...>>(std::forward<Rest>(rest)...);
}
... and what does all of this accomplish? Not a whole lot; at least
not without something similar to the code below (this is a scenario
from a later reply, because the one above seemed too simplistic.)
auto errVector = make<const char*, EBADF, 0, ERANGE>(
"EBADF", "(success)", "ERANGE");
enum { maxNeeded = sizeof(errVector) };
'errVector' above is actually not an array, but rather a std::array
object. It's unavoidable, but luckily std::array is just a very simple
wrapper of one.
One could perhaps achieve something to this end with structs, too,
although the syntax might be relatively even more awkward. (It's
certain that the members would have to be "listed" in some way as
there's no other way to get to know of them.) I'm not 100% certain
about this being doable, however.
...
Now that we've come this far, intuition begs the question: do the C++
folk actually believe they've got the superior tools when they refuse
to incorporate designated initializers into the language, when it's
obvious to anyone that they don't (have them).
I don't think the situation is that simple.
The way I see it, the co-operation of the committees will mostly
revolve around and result in not introducing subtle incompabilities
(the ones that won't show up when compiling) into the languages; and
not in extending the usable common subset of them. Static
initialization, I think, is often simply seen as less important within
C++ circles, because with complex objects you have lots to do at
runtime anyway.
By the way, with only a few values far between, one might want to use
an associative container instead of a mostly-wasted array. C++ has
relatively expressive syntax for those (shown below), but I don't
think C is getting anything similar anytime soon, tricks or not.
std::unordered_map<int, const char*> errMap = { { ERANGE, "ERANGE" },
{ 0, "(success)" }
/* ... */
};
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2012-08-25 15:59 +0100 |
| Message-ID | <87vcg7dnlx.fsf@gmail.com> |
| In reply to | #24903 |
Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> On 25.08.2012 12:07, Malcolm McLean wrote:
>
> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
> Some constructs which are necessary for embedded systems are just syntax
> errors in C++, while they work perfectly in C.
Could you give an example or three?
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2012-08-25 17:26 +0200 |
| Message-ID | <k1aqqk$ogr$1@news.albasani.net> |
| In reply to | #24915 |
On 25.08.2012 16:59, Gareth Owen wrote:
> Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>
>> On 25.08.2012 12:07, Malcolm McLean wrote:
>>
>> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
>> Some constructs which are necessary for embedded systems are just syntax
>> errors in C++, while they work perfectly in C.
>
> Could you give an example or three?
As I said in the previous postings, a construct like this is one of the
last reasons to have some files in C for MCU projects that I'm working
on. Omitting some deatils (like attribute specifiers which specify where
the IVT goes), but that's the gist:
struct ivtlayout {
int vec1;
int vec2;
int vec3;
};
struct ivtlayout ivt = {
.vec1 = 1234,
};
int main() {
return 0;
}
[~/tmp]: gcc -O2 -Wall -Wextra -std=c99 -pedantic x.c
[~/tmp]: g++ -O2 -Wall -Wextra -std=c++0x -pedantic x.c
x.c:8:2: Error: expected primary-expression before ».« token
Best regards,
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-08-25 13:50 -0500 |
| Message-ID | <k1b6gc$br2$1@dont-email.me> |
| In reply to | #24917 |
Johannes Bauer wrote:
> On 25.08.2012 16:59, Gareth Owen wrote:
>> Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
>>
>>> On 25.08.2012 12:07, Malcolm McLean wrote:
>>>
>>> This isn't mere pedanticism ("new" keyword, etc.), but the bare truth:
>>> Some constructs which are necessary for embedded systems are just syntax
>>> errors in C++, while they work perfectly in C.
>>
>> Could you give an example or three?
>
> As I said in the previous postings, a construct like this is one of the
> last reasons to have some files in C for MCU projects that I'm working
> on. Omitting some deatils (like attribute specifiers which specify where
> the IVT goes), but that's the gist:
>
> struct ivtlayout {
> int vec1;
> int vec2;
> int vec3;
> };
>
> struct ivtlayout ivt = {
> .vec1 = 1234,
> };
>
> int main() {
> return 0;
> }
>
>
> [~/tmp]: gcc -O2 -Wall -Wextra -std=c99 -pedantic x.c
> [~/tmp]: g++ -O2 -Wall -Wextra -std=c++0x -pedantic x.c
> x.c:8:2: Error: expected primary-expression before ».« token
>
> Best regards,
> Johannes
>
This seems to work. I commented out the string
".vec1 = 1234", which isn't strictly necessary anyway
( but is a nice thing to have available ).
C:\c\usenet>cat prein.cpp
#include <stdio.h>
struct ivtlayout {
int vec1;
int vec2;
int vec3;
};
struct ivtlayout ivt = {
/*.vec1 =*/ 1234,
};
int main() {
printf("ivt.vec1=%d\n",ivt.vec1);
return 0;
}
C:\c\usenet>g++ prein.cpp
C:\c\usenet>a
ivt.vec1=1234
C:\c\usenet>
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2012-08-25 21:21 +0200 |
| Message-ID | <k1b8k0$iut$4@news.albasani.net> |
| In reply to | #24929 |
On 25.08.2012 20:50, Les Cargill wrote: > This seems to work. I commented out the string > ".vec1 = 1234", which isn't strictly necessary anyway > ( but is a nice thing to have available ). Yes, when you comment out the whole point of the example, it works. Best regards, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-25 15:27 -0400 |
| Message-ID | <k1b8u8$p8m$2@dont-email.me> |
| In reply to | #24940 |
On 08/25/2012 03:21 PM, Johannes Bauer wrote: > On 25.08.2012 20:50, Les Cargill wrote: > >> This seems to work. I commented out the string >> ".vec1 = 1234", which isn't strictly necessary anyway >> ( but is a nice thing to have available ). > > Yes, when you comment out the whole point of the example, it works. But the part that was commented out was pointless; if it was the point of the example, the example had no point. Yes, I'm playing with words - but it's also all literally true. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2012-08-25 21:36 +0200 |
| Message-ID | <k1b9gm$m4j$1@news.albasani.net> |
| In reply to | #24943 |
On 25.08.2012 21:27, James Kuyper wrote:
> On 08/25/2012 03:21 PM, Johannes Bauer wrote:
>> On 25.08.2012 20:50, Les Cargill wrote:
>>
>>> This seems to work. I commented out the string
>>> ".vec1 = 1234", which isn't strictly necessary anyway
>>> ( but is a nice thing to have available ).
>>
>> Yes, when you comment out the whole point of the example, it works.
>
> But the part that was commented out was pointless; if it was the point
> of the example, the example had no point. Yes, I'm playing with words -
> but it's also all literally true.
Alright, then, since you do understand what I'm getting at but are
unwilling to recoginze the point, here's a more complete example.
Imagine there are 3 hardware platforms (these are about 10-20 in
reality) each which have 10 IRQ vectors (these at least 100 in reality):
hw1.h:
struct ivtlayout {
int vec1;
int vec2;
int vec3;
int vec6;
int vec4;
int vec7;
int vec9;
int vec5;
int vec8;
int vec0;
};
hw2.h:
struct ivtlayout {
int vec4;
int vec2;
int vec5;
int vec8;
int vec1;
int vec3;
int vec9;
int vec0;
int vec6;
int vec7;
};
hw3.h:
struct ivtlayout {
int vec7;
int vec6;
int vec9;
int vec8;
int vec4;
int vec1;
int vec3;
int vec0;
int vec5;
int vec2;
};
Now you want to include for each version a IVT which specifies a value
for vector 8. C solution:
struct ivtlayout ivt = {
.vec8 = 1234,
};
I'll leave the C++ solution as an excersise to you. Hopefully you'll see
the point now.
Best regards,
Johannes
--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web