Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #28322 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2012-11-18 01:21 -0800 |
| Last post | 2012-11-27 17:22 -0800 |
| Articles | 20 on this page of 221 — 27 participants |
Back to article view | Back to comp.lang.c
some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 01:21 -0800
Re: some well known stupidness in c99 Thomas Richter <thor@math.tu-berlin.de> - 2012-11-18 10:41 +0100
Re: some well known stupidness in c99 SG <sgesemann@gmail.invalid> - 2012-11-18 10:41 +0100
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 02:02 -0800
Re: some well known stupidness in c99 SG <sgesemann@gmail.invalid> - 2012-11-18 11:23 +0100
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 02:26 -0800
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-18 12:16 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 05:27 -0800
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-18 14:24 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 06:44 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 06:50 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 11:07 -0500
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-18 12:22 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 09:39 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-18 20:22 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 17:04 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-18 22:45 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-18 18:02 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 00:04 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 19:20 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 00:59 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 20:13 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 01:36 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 21:12 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 11:20 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 11:09 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 18:25 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 14:02 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 21:55 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 17:50 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 23:05 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 18:16 -0500
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-20 08:14 -0500
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 08:33 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 23:38 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-20 08:19 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 15:28 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 13:25 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 22:22 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 22:26 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-21 00:16 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-21 01:05 +0000
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-20 13:24 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 18:54 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 22:31 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 20:38 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-21 12:00 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-21 18:30 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-21 13:51 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-21 19:47 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-21 20:21 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-21 21:25 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-21 23:02 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 11:56 +0000
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 15:01 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 18:43 +0000
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-21 23:58 +0000
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 14:37 +0000
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-22 17:12 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-21 16:47 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-22 01:23 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-22 08:19 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-22 15:34 +1300
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 04:18 +0000
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-22 17:31 +1300
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 14:18 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-22 09:28 +0000
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 14:10 +0000
Re: some well known stupidness in c99 David Thompson <dave.thompson2@verizon.net> - 2012-11-28 01:12 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-28 09:50 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 11:43 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 11:34 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-22 09:57 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 18:47 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-22 11:39 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 14:08 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 21:32 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 16:35 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 21:51 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 18:38 -0500
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-19 14:05 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 21:25 +0000
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-20 12:21 -0500
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-19 13:57 -0500
Re: some well known stupidness in c99 Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-18 03:47 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 10:56 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 09:11 -0800
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-18 15:10 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 12:52 -0800
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-18 21:29 +0000
Re: some well known stupidness in c99 "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2012-11-18 22:35 +0100
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-18 17:00 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-19 14:38 +1300
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 21:14 -0500
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-19 03:56 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-18 22:06 +0000
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-18 23:44 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 01:16 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-18 14:20 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 15:33 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 01:21 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 01:45 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 11:35 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 05:01 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-19 15:37 -0500
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 08:21 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 05:42 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 06:06 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 10:02 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 08:51 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 21:35 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 09:06 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 14:25 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 11:42 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 09:06 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 12:31 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 09:42 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 13:36 -0500
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-19 11:57 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 15:07 -0500
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 15:21 -0500
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 15:37 -0500
Re: some well known stupidness in c99 Greg Martin <greg@softsprocket.com> - 2012-11-19 11:10 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 11:22 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 14:41 -0500
Re: some well known stupidness in c99 Greg Martin <greg@softsprocket.com> - 2012-11-19 12:04 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-20 12:08 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 11:37 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 15:33 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 21:14 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 16:39 -0500
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 13:57 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 17:01 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-21 11:07 +1300
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 17:23 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 14:46 -0800
Re: some well known stupidness in c99 Greg Martin <greg@softsprocket.com> - 2012-11-20 14:56 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 15:10 -0800
Re: some well known stupidness in c99 Greg Martin <greg@softsprocket.com> - 2012-11-20 15:26 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 16:00 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-21 12:10 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-21 09:45 -0800
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-21 13:43 -0500
Re: some well known stupidness in c99 Rosario1903 <Rosario@invalid.invalid> - 2012-11-22 10:25 +0100
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-21 12:08 -0800
Re: some well known stupidness in c99 Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-11-21 16:42 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-22 10:49 +1300
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-21 15:55 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 14:58 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-21 11:49 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-21 11:12 +1300
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 22:41 +0000
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-19 15:46 -0500
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 16:39 -0500
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-19 16:33 -0800
Re: some well known stupidness in c99 Robert Wessel <robertwessel2@yahoo.com> - 2012-11-20 00:20 -0600
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 22:12 +0000
Re: some well known stupidness in c99 Robert Wessel <robertwessel2@yahoo.com> - 2012-11-20 00:34 -0600
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 10:20 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 13:40 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 22:00 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 17:49 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 11:05 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 21:48 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 17:58 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 23:16 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-19 16:39 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 01:28 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-20 08:22 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 19:01 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 23:50 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 23:18 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 23:28 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 10:53 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 03:19 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 03:39 -0800
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-20 12:52 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 04:59 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 15:47 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 11:21 -0800
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-20 16:11 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 19:18 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 02:51 -0800
Re: some well known stupidness in c99 Shao Miller <sha0.miller@gmail.com> - 2012-12-14 23:28 -0500
Re: some well known stupidness in c99 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:37 +0200
Re: some well known stupidness in c99 Shao Miller <sha0.miller@gmail.com> - 2012-12-17 06:00 -0500
Re: some well known stupidness in c99 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 23:43 +0200
Re: some well known stupidness in c99 pete <pfiland@mindspring.com> - 2012-12-17 19:23 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-12-18 13:31 +1300
Re: some well known stupidness in c99 pete <pfiland@mindspring.com> - 2012-12-17 20:17 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-18 00:48 +0000
Re: some well known stupidness in c99 lawrence.jones@siemens.com - 2012-12-18 15:38 -0500
Re: some well known stupidness in c99 pete <pfiland@mindspring.com> - 2012-12-16 10:50 -0500
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-16 10:58 -0500
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-12-16 16:47 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 14:17 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 00:38 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 02:34 -0800
Re: some well known stupidness in c99 pete <pfiland@mindspring.com> - 2012-11-20 07:38 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 04:47 -0800
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 13:14 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 21:27 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 16:48 -0500
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-20 16:28 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-21 10:29 +1300
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-20 22:32 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 18:14 -0500
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-21 01:52 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 22:31 -0500
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-21 04:40 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-21 08:11 -0500
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 14:02 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 15:29 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 16:54 -0800
Re: some well known stupidness in c99 gof@somewhere.invalid (Adam Wysocki) - 2012-11-20 15:51 +0000
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-18 21:26 +0000
Re: some well known stupidness in c99 Ben Pfaff <blp@cs.stanford.edu> - 2012-11-18 10:57 -0800
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-18 13:44 -0800
Re: some well known stupidness in c99 Richard Damon <news.x.richarddamon@xoxy.net> - 2012-11-18 23:38 -0500
Re: some well known stupidness in c99 Shao Miller <sha0.miller@gmail.com> - 2012-12-14 23:13 -0500
Re: some well known stupidness in c99 Stanley Rice <heconghui@gmail.com> - 2012-11-27 17:22 -0800
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-21 00:16 +0000 |
| Message-ID | <k8h6g4$mu4$1@speranza.aioe.org> |
| In reply to | #28501 |
BartC <bc@freeuk.com> wrote: (snip) > Finally someone seems to get what I'm talking about... (Keith wrote) >> But if you add a language feature that creates such a dependency, >> then you break C's concept of separate compilation. > But it needn't be an actual dependency on the source code of another module. > Let's take the example files used before: victim.c and file1.c (we don't > need file2.c). > victim.c makes use of resources in file1.c, and currently this is done by > creating a header file1.h. The compiler of victim.c doesn't need to see > file1.c, only file1.h. This sounds, as I previously mentioned, a lot like the module (.MOD) facility in Fortran since, I believe, Fortran 90. The compiler writes out a (usually with extension .MOD) file, and compilation of programs that USE the module read them in. > My suggestion, if the concept of an 'import' statement was supported by the > language, could work the same way: the import statement could simply make > use of an 'exports' file called file1.h. The difference is that file1.h > might be generated automatically, by a separate process that does need > access to file1.c, but need have nothing to do with the compiler of > victim.c. The .MOD files are not portable between compilers, maybe not even with different versions of the same compiler. C header (.h) files are often portable, though sometimes contain system dependencies. > In fact, file1.c could be on the other side of the world (locked in a vault > below ground); all that's needed by the compiler of victim.c, is the public > exports file (eg. file1.h), which has been generated at some time in the > past. (snip) > As I've explained above, that model can stay largely the same. Actually we > don't even need a new 'import' statement (although it's a lot tidier); just > 'include' will suffice. It boils down to whether the exported names in > file1.c (functions which are not static, file-scope variables which are not > static, and I would extend it to explicitly exported typedefs, enums and so > on) make their way into file1.h with the help of the language or not. -- glen
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-21 01:05 +0000 |
| Message-ID | <8OVqs.345067$W63.196263@fx05.am4> |
| In reply to | #28515 |
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:k8h6g4$mu4$1@speranza.aioe.org... > BartC <bc@freeuk.com> wrote: > (Keith wrote) >>> But if you add a language feature that creates such a dependency, >>> then you break C's concept of separate compilation. > >> But it needn't be an actual dependency on the source code of another >> module. >> Let's take the example files used before: victim.c and file1.c (we don't >> need file2.c). > >> victim.c makes use of resources in file1.c, and currently this is done by >> creating a header file1.h. The compiler of victim.c doesn't need to see >> file1.c, only file1.h. > > This sounds, as I previously mentioned, a lot like the module (.MOD) > facility in Fortran since, I believe, Fortran 90. The compiler writes > out a (usually with extension .MOD) file, and compilation of programs > that USE the module read them in. Yes, I think the concept is quite well known, it's just in this newsgroup that any new-fangled ideas seem to be viewed with suspicion! In this case it seems a public interface is exported, which is a better way of putting it. If using such a feature means compilation is not technically separate, then.. so what? I use the idea in my own projects, and I can export functions, types, variables, named constants (that is, proper ones!), and macros. If I want to share one of these, I just stick 'global' in front of the definition; then it will be added to the exports file when it's compiled, and is available to any other module that imports this one. It's a joy not to mess around with separate include or header files, and have to declare/define everything twice and make sure the two correspond. Maybe those who use advanced IDEs get help with this stuff, and don't need support from the language, but some of us don't and do! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-11-20 13:24 -0500 |
| Message-ID | <vZedndHyhfBXVzbNnZ2dnUVZ_rCdnZ2d@bestweb.net> |
| In reply to | #28437 |
On 11/19/2012 6:38 PM, BartC wrote:
> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
> news:k8ed3v$brk$1@dont-email.me...
>> On 11/19/2012 4:55 PM, BartC wrote:
[...]
> >> Or I might be able to write:
>>>
>>> switch (a) {
>>> case table_max:
>
>>> You can't deny these can be advantages.
>>
>> Sure, I can.
>>
>> extern const int table_max;
>> ...
>> switch(a) {
>> case table_max: puts("Yes"); break;
>> case 1: puts("NO!"); break;
>> }
>>
>> See the duplicate case label? No?
>
> Yes, actually I can see the possibility, because it would be bad practice to
> mix named and explicit constants like this (even if the compiler will anyway
> pick up the error).
>
>> Well, you can't deny that
>> it might *become* a duplicate case label with next week's edit
>> to some entirely different module. Once again, you've done
>> away with separate compilation.
>
> How is the above example different from this:
>
> #include <windows.h>
>
> switch (a) {
> case CBN_DBLCLICK: ...
> case 1: ...
>
> That might *also* become a duplicate label with next week's version of
> windows.h. (Or substitute any header that you haven't written yourself.)
The difference is that the latter, using compile-time constants, can (and
*must*, AFAIK) be picked up at compile time. In the former, using runtime
"constants", the clash *cannot* be detected until the code is executed, at
which point it's too late. (Though, I suppose, it might theoretically be
able to be caught at link time.)
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-20 18:54 +0000 |
| Message-ID | <qmQqs.561916$vW7.32409@fx19.am4> |
| In reply to | #28478 |
"Kenneth Brody" <kenbrody@spamcop.net> wrote in message
news:vZedndHyhfBXVzbNnZ2dnUVZ_rCdnZ2d@bestweb.net...
> On 11/19/2012 6:38 PM, BartC wrote:
>> How is the above example different from this:
>>
>> #include <windows.h>
>>
>> switch (a) {
>> case CBN_DBLCLICK: ...
>> case 1: ...
>>
>> That might *also* become a duplicate label with next week's version of
>> windows.h. (Or substitute any header that you haven't written yourself.)
>
> The difference is that the latter, using compile-time constants, can (and
> *must*, AFAIK) be picked up at compile time. In the former, using runtime
> "constants", the clash *cannot* be detected until the code is executed, at
> which point it's too late. (Though, I suppose, it might theoretically be
> able to be caught at link time.)
I think there's been some confusion because:
o Someone (the OP) was using 'const int' for named constants, but complained
it no longer worked
o Someone else (I think you) pointed out an example of 'const int' where the
value could not be known ('extern const int').
o I suggested that this could be made to work, but gave an example using
true named constants as used in another language.
o Others didn't think such an idea could work in C (whether for true
constants or not), and came up with a range of reasons why it wouldn't (eg.
it wouldn't be 'separate compilation', but I've already said what I think of
that).
So on my part, I've been talking mainly about true named constants (such as
you get with enums), while others, perhaps not realising we were also
discussing a hypothetical extension, may have had 'const ints' in mind.
After all that, it still leaves the OP's problem that 'const int' can't
reliably be used for true named constants, and he doesn't like using enum or
#define. Any other solutions I mentioned involve changes to the language,
which apart from everyone knowing will never happen, some people think are
impossible (even though I've implemented them elsewhere and they work well,
and I've also outlined some approaches to making them work in C using
add-ons).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-20 22:31 +0000 |
| Message-ID | <k8h0bk$7fp$1@speranza.aioe.org> |
| In reply to | #28478 |
Kenneth Brody <kenbrody@spamcop.net> wrote:
(snip)
>> How is the above example different from this:
>> #include <windows.h>
>> switch (a) {
>> case CBN_DBLCLICK: ...
>> case 1: ...
>> That might *also* become a duplicate label with next week's version of
>> windows.h. (Or substitute any header that you haven't written yourself.)
> The difference is that the latter, using compile-time constants, can (and
> *must*, AFAIK) be picked up at compile time. In the former, using runtime
> "constants", the clash *cannot* be detected until the code is executed, at
> which point it's too late. (Though, I suppose, it might theoretically be
> able to be caught at link time.)
The tradition of switch/case is that they be resolved at compile
time, but is that required?
Yes, link time is an extension of compile time, and some things could
be resolved at link time.
For a long time I have thought that the tradition of linkers was to
follow the requirements of Fortran, and for other languages to then
use those features.
(Though the pseudo-registers used by OS/360 PL/I compilers for global
data that is task local on multitasking systems, seems to have been
a special addition to the OS/360 linker.)
It is nice for compilers to optimize the switch statement in the
case where simple jump tables can be used. One could also imagine
a hash table being used, where the table is generated at link time
and loaded into the previously compiled object program.
Many years ago, I found that some expressions wouldn't work in
case statements, such as ones of the form: "abcd"[1].
So, even what seems to be a compile time constant might not
be in C terms.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-20 20:38 -0800 |
| Message-ID | <lnmwybmuz6.fsf@nuthaus.mib.org> |
| In reply to | #28502 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> Many years ago, I found that some expressions wouldn't work in
> case statements, such as ones of the form: "abcd"[1].
> So, even what seems to be a compile time constant might not
> be in C terms.
Right, the C standard has a rigorous definition of "constant
expression". It's designed so that all "constant expression"s can be
evaluated at compile time, but not necessarily so that all expression
that can be evaluated at compile time are constant expressions.
N1370 6.6p6 defines the operands that may appear in an integer constant
expression:
An *integer constant expression* shall have integer type
and shall only have operands that are integer constants,
enumeration constants, character constants, sizeof expressions
whose results are integer constants, _Alignof expressions,
and floating constants that are the immediate operands of
casts. Cast operators in an integer constant expression shall
only convert arithmetic types to integer types, except as part
of an operand to the sizeof or _Alignof operator.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-11-21 12:00 -0500 |
| Message-ID | <79KdncHJpKEslTDNnZ2dnUVZ_gmdnZ2d@bestweb.net> |
| In reply to | #28502 |
On 11/20/2012 5:31 PM, glen herrmannsfeldt wrote:
> Kenneth Brody <kenbrody@spamcop.net> wrote:
>
> (snip)
>>> How is the above example different from this:
>
>>> #include <windows.h>
>
>>> switch (a) {
>>> case CBN_DBLCLICK: ...
>>> case 1: ...
>
>>> That might *also* become a duplicate label with next week's version of
>>> windows.h. (Or substitute any header that you haven't written yourself.)
>
>> The difference is that the latter, using compile-time constants, can (and
>> *must*, AFAIK) be picked up at compile time. In the former, using runtime
>> "constants", the clash *cannot* be detected until the code is executed, at
>> which point it's too late. (Though, I suppose, it might theoretically be
>> able to be caught at link time.)
>
> The tradition of switch/case is that they be resolved at compile
> time, but is that required?
If the value cannot be determined at compile time, the compiler cannot know
if there will be a conflict at link time.
[...]
> It is nice for compilers to optimize the switch statement in the
> case where simple jump tables can be used. One could also imagine
> a hash table being used, where the table is generated at link time
> and loaded into the previously compiled object program.
I think it boils down to the fact that every "case" must be distinct, and
there is no way to know this if the value cannot be determined at compile time.
> Many years ago, I found that some expressions wouldn't work in
> case statements, such as ones of the form: "abcd"[1].
> So, even what seems to be a compile time constant might not
> be in C terms.
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-21 18:30 +0000 |
| Message-ID | <k8j6kt$fts$1@speranza.aioe.org> |
| In reply to | #28527 |
Kenneth Brody <kenbrody@spamcop.net> wrote: (snip, I wrote) >> The tradition of switch/case is that they be resolved at compile >> time, but is that required? > If the value cannot be determined at compile time, the compiler cannot know > if there will be a conflict at link time. (snip) > I think it boils down to the fact that every "case" must be distinct, and > there is no way to know this if the value cannot be determined at compile time. But why does it have to be resolved an detected at compile time? Well, new functionality, including labels that aren't resolved at compile time and that don't have to be distinct should probably come with a new and differently named statement. How about select/case that takes the first among the choices, and where values can be determined at run time? Maybe a slightly less efficient implementation, but that is the programmer's choice. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-21 13:51 -0500 |
| Message-ID | <k8j7qq$f75$1@dont-email.me> |
| In reply to | #28532 |
On 11/21/2012 1:30 PM, glen herrmannsfeldt wrote:
> [...]
> Well, new functionality, including labels that aren't resolved at
> compile time and that don't have to be distinct should probably come
> with a new and differently named statement.
>
> How about select/case that takes the first among the choices, and where
> values can be determined at run time?
Like if/else if/else if/.../else?
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-21 19:47 +0000 |
| Message-ID | <Cdars.371372$W63.74677@fx05.am4> |
| In reply to | #28534 |
"Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
news:k8j7qq$f75$1@dont-email.me...
> On 11/21/2012 1:30 PM, glen herrmannsfeldt wrote:
>> [...]
>> Well, new functionality, including labels that aren't resolved at
>> compile time and that don't have to be distinct should probably come
>> with a new and differently named statement.
>>
>> How about select/case that takes the first among the choices, and where
>> values can be determined at run time?
>
> Like if/else if/else if/.../else?
Yes. Except it's written as:
switch(x) { case a: ... case b: ... case c: ... default: ...}
(with perhaps a new keyword as suggested) instead of:
if (x==a) ... else if (x==b) ... else if (x==c) ... else ...
with the same advantages that a, b, etc can be run-time expressions of any
type, but without the disadvantage that x is can be evaluated more then
once).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-21 20:21 +0000 |
| Message-ID | <k8jd52$15q$1@speranza.aioe.org> |
| In reply to | #28534 |
Eric Sosman <esosman@comcast-dot-net.invalid> wrote: > On 11/21/2012 1:30 PM, glen herrmannsfeldt wrote: >> Well, new functionality, including labels that aren't resolved at >> compile time and that don't have to be distinct should probably come >> with a new and differently named statement. > >> How about select/case that takes the first among the choices, and where >> values can be determined at run time? > Like if/else if/else if/.../else? Yes, but in a more structured form. As Fortran I showed, you can do everything with IF and GOTO, but it is much nicer to program with more structured languages. Why not a structured form, like switch, for the case where the choices aren't known until run time? Much more readable than the if/else if/else series. (Most likely the generated code is in if/else form.) -- glen
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-21 21:25 +0000 |
| Message-ID | <YEbrs.371789$W63.179339@fx05.am4> |
| In reply to | #28541 |
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:k8jd52$15q$1@speranza.aioe.org... > Eric Sosman <esosman@comcast-dot-net.invalid> wrote: >> On 11/21/2012 1:30 PM, glen herrmannsfeldt wrote: > >>> Well, new functionality, including labels that aren't resolved at >>> compile time and that don't have to be distinct should probably come >>> with a new and differently named statement. >> >>> How about select/case that takes the first among the choices, and where >>> values can be determined at run time? > >> Like if/else if/else if/.../else? > > Yes, but in a more structured form. > > As Fortran I showed, you can do everything with IF and GOTO, but it > is much nicer to program with more structured languages. > > Why not a structured form, like switch, for the case where the choices > aren't known until run time? Much more readable than the if/else if/else > series. (Most likely the generated code is in if/else form.) Does any recent Fortran (or any language for that matter) actually have such a statement? (BTW we are in 2012 now you know, with all this talk of Fortran I and OS 360. I think they were already obsolete when I started programming 35 years ago...) In my own language projects, obviously I will have these two kinds of statements, plus various variations I won't bore you with. But I have found that people don't seem like useful extra syntax in their favourite languages. Or perhaps more accurately, if their favourite language doesn't have a particularly handy construction, they will defend the lack of it to the death! So, we don't need an if-else version of switch, because we can just use if-else, and the compiler will end up generating the same code anyway. But like you say, there would never be a reason to progress beyond if-then-goto in that case. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-21 23:02 +0000 |
| Message-ID | <k8jmia$pdg$1@speranza.aioe.org> |
| In reply to | #28544 |
BartC <bc@freeuk.com> wrote: (snip, someone wrote) >>>> Well, new functionality, including labels that aren't resolved at >>>> compile time and that don't have to be distinct should probably come >>>> with a new and differently named statement. (snip, then I wrote) >>>> How about select/case that takes the first among the choices, and where >>>> values can be determined at run time? >>> Like if/else if/else if/.../else? >> Yes, but in a more structured form. >> As Fortran I showed, you can do everything with IF and GOTO, but it >> is much nicer to program with more structured languages. >> Why not a structured form, like switch, for the case where the choices >> aren't known until run time? Much more readable than the if/else if/else >> series. (Most likely the generated code is in if/else form.) > Does any recent Fortran (or any language for that matter) actually have such > a statement? Verilog has the run-time value switch/case: http://eesun.free.fr/DOC/VERILOG/verilog_manual1.html#7.2 Otherwise, Fortran, I believe since Fortran 90, has SELECT/CASE with the usual compile-time constants and unique CASE values. (Fortran CASE allows for a start:end range in addition to single values, with either start or end, but not both at the same time, optional.) > (BTW we are in 2012 now you know, with all this talk of Fortran I and OS > 360. I think they were already obsolete when I started programming 35 years > ago...) Sorry about that. > In my own language projects, obviously I will have these two kinds of > statements, plus various variations I won't bore you with. > But I have found that people don't seem like useful extra syntax in their > favourite languages. Or perhaps more accurately, if their favourite language > doesn't have a particularly handy construction, they will defend the lack > of it to the death! It does take time to get used to change. In the days before Fortran 77 there were various preprocessors to generate standard Fortran from a new, structured language. RATFOR and MORTRAN are two that I know about. But they never got as popular as you might think, give the advantages of structured programming. > So, we don't need an if-else version of switch, because we can just use > if-else, and the compiler will end up generating the same code anyway. > But like you say, there would never be a reason to progress > beyond if-then-goto in that case. If it isn't needed all that often, maybe it isn't worth adding. There is cost in the complexity of compilers, and the ability of people to remember how to use new features. But people can always use just their favorite subset when writing their own programs. You have to at least have a good reference when reading programs written by others. If I didn't have one, and had a program that needed it, I might write a special use preprocessor to generate the if/elseif/else chain. Another possibity is to code the logic to convert the values, possibly through a loop and look-up table, to constants. Slower, but it might work well enough. -- glen
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-22 11:56 +0000 |
| Message-ID | <qrors.959997$it2.880000@fx22.am4> |
| In reply to | #28547 |
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:k8jmia$pdg$1@speranza.aioe.org...
> BartC <bc@freeuk.com> wrote:
>> Does any recent Fortran (or any language for that matter) actually have
>> such
>> a statement?
> If it isn't needed all that often, maybe it isn't worth adding.
>
> There is cost in the complexity of compilers, and the ability of people
> to remember how to use new features.
Not in syntax. That's one of the easiest parts of a compiler.
In C however everyone is on the one hand encouraged to use macros to
overcome shortcomings in the syntax ('there really is no need for such a
feature because here's a simple macro to do it'); and on the other hand,
discouraged to use tacky macros, implemented in a different way by each
programmer, because it makes the code unreadable to others! Because
effectively each is creating their own dialect.
For example, I hate the C for-statement, since there's a lot of typing, and
things to mistype or get wrong, for a simple A to B iteration, or N-times
repeat.
So in the quite a few thousand lines of C code I've written over the last
few weeks, I've extensively used macros such as FOR(I,A,B) or TO(I,N) (which
just repeats some code N times; I don't need the index, but the macro is
simpler with it).
I've used these dozens of times; the normal 'for' statement I've used twice
(to countdown from B to A instead, and I haven't got round to doing a
downward-counting FOR macro!)
So if I have a problem with a bit of code, I can't just post it on here. But
I don't care! The macros make like life a lot simpler.
But obviously the need is there, so why not have it part of the language? As
I said, adding syntax has virtually zero-cost, but can save costs on
development.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-11-22 15:01 +0000 |
| Message-ID | <k8leos$e56$1@dont-email.me> |
| In reply to | #28566 |
BartC wrote:
> Not in syntax. That's one of the easiest parts of a compiler.
>
> In C however everyone is on the one hand encouraged to use macros to
> overcome shortcomings in the syntax ('there really is no need for such a
> feature because here's a simple macro to do it');
I don't believe this is true. I don't remember ever seeing anyone encourage
the use of macros: quite the opposite, actually. They are seen as a last
resort kind of thing.
What is indeed encouraged is the practice of writing your own routines to
solve your own problems. This isn't a bad thing to do, because it is
essentially all that a programmer does.
> and on the other hand,
> discouraged to use tacky macros, implemented in a different way by each
> programmer, because it makes the code unreadable to others! Because
> effectively each is creating their own dialect.
That's essentially what every API or every helper routine is: a dialect.
Whenever someone develops their own library or adopts one developed by a
third-party, that person is defining their own dialect.
> For example, I hate the C for-statement, since there's a lot of typing,
> and things to mistype or get wrong, for a simple A to B iteration, or
> N-times repeat.
>
> So in the quite a few thousand lines of C code I've written over the last
> few weeks, I've extensively used macros such as FOR(I,A,B) or TO(I,N)
> (which just repeats some code N times; I don't need the index, but the
> macro is simpler with it).
What's the difference between for(int I = A; i < B; i++) and FOR(I, A, B) ?
> But obviously the need is there, so why not have it part of the language?
Because the suggestions that have been presented are already a part of the
language. A concept might not be expressed with a particular syntactic
sugar, but that doesn't mean the language doesn't support it, and if we have
a choice between a concise language and an inflated one to express the exact
same concepts, conciseness always wins.
This doesn't mean that all suggestions are bad, or that the C programming
language can't be improved. Yet, this doesn't mean that every single
suggestion should be considered, let alone accepted, just because someone,
once in its life, stumbled on an obscure corner case that could be expressed
differently if a very specific and equally obscure statement was supported
by a programming language.
Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-22 18:43 +0000 |
| Message-ID | <_nurs.532175$Tf3.421518@fx12.am4> |
| In reply to | #28571 |
"Rui Maciel" <rui.maciel@gmail.com> wrote in message
news:k8leos$e56$1@dont-email.me...
> BartC wrote:
>> In C however everyone is on the one hand encouraged to use macros to
>> overcome shortcomings in the syntax ('there really is no need for such a
>> feature because here's a simple macro to do it');
>
> I don't believe this is true. I don't remember ever seeing anyone
> encourage
> the use of macros: quite the opposite, actually. They are seen as a last
> resort kind of thing.
>
> What is indeed encouraged is the practice of writing your own routines to
> solve your own problems. This isn't a bad thing to do, because it is
> essentially all that a programmer does.
Writing routines is OK; that's just programming. And it doesn't change the
syntax.
Using macros however can effectively change the language.
>> and on the other hand,
>> discouraged to use tacky macros, implemented in a different way by each
>> programmer, because it makes the code unreadable to others! Because
>> effectively each is creating their own dialect.
>
> That's essentially what every API or every helper routine is: a dialect.
> Whenever someone develops their own library or adopts one developed by a
> third-party, that person is defining their own dialect.
But it's a well-understood way of extending a language. A function call
looks like a function call. A macro invocation can involve anything. You
look at the body of a function, and you still see normal C code. You look at
a macro
definition and it's quite often gobbledygook.
>> So in the quite a few thousand lines of C code I've written over the last
>> few weeks, I've extensively used macros such as FOR(I,A,B) or TO(I,N)
>> (which just repeats some code N times; I don't need the index, but the
>> macro is simpler with it).
>
> What's the difference between for(int I = A; i < B; i++) and FOR(I, A, B)
> ?
My FOR(I,A,B) macro iterates between A and B inclusively, and does so
reliably between having to write the loop index 3 times (you've mixed up a I
with i), or remembering to use a <= instead of = (you've used <), or just
having to bother to write all those parts of a loop which are the compiler's
job not mine:
#define FOR(i,a,b) for (i=a; i<=b; ++i)
#define TO(i,x) for (i=x; i; --i)
With FOR, I just give it the 3 elements that are all that are really needed
to define the loop, and can concentrate the loop body!
>> But obviously the need is there, so why not have it part of the language?
>
> Because the suggestions that have been presented are already a part of the
> language. A concept might not be expressed with a particular syntactic
> sugar, but that doesn't mean the language doesn't support it, and if we
> have
> a choice between a concise language and an inflated one to express the
> exact
> same concepts, conciseness always wins.
Syntax, especially basic constructs that practically every other language
have had for decades, will hardly inflate the language. What does inflate it
are the 1000 or so functions in the run-time library. And endless blocks of
macros like this:
#define INT_MAX +32767
#define INT_MIN -32767
#define LONG_MAX +2147483647
#define LONG_MIN -2147483647
#define LLONG_MAX +9223372036854775807
#define LLONG_MIN -9223372036854775807
#define MB_LEN_MAX 1
#define SCHAR_MAX +127
#define SCHAR_MIN -127
#define SHRT_MAX +32767
#define SHRT_MIN -32767
#define UCHAR_MAX 255
#define USHRT_MAX 65535
#define UINT_MAX 65535
#define ULONG_MAX 4294967295
#define ULLONG_MAX 18446744073709551615
when all that is really needed is a single syntax feature that can be
applied to any type in the same way as sizeof().
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-21 23:58 +0000 |
| Message-ID | <0.855826e056bc6f2e6659.20121121235824GMT.874nki5x0f.fsf@bsb.me.uk> |
| In reply to | #28544 |
"BartC" <bc@freeuk.com> writes:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
> news:k8jd52$15q$1@speranza.aioe.org...
>> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>> On 11/21/2012 1:30 PM, glen herrmannsfeldt wrote:
>>
>>>> Well, new functionality, including labels that aren't resolved at
>>>> compile time and that don't have to be distinct should probably come
>>>> with a new and differently named statement.
>>>
>>>> How about select/case that takes the first among the choices, and where
>>>> values can be determined at run time?
>>
>>> Like if/else if/else if/.../else?
>>
>> Yes, but in a more structured form.
>>
>> As Fortran I showed, you can do everything with IF and GOTO, but it
>> is much nicer to program with more structured languages.
>>
>> Why not a structured form, like switch, for the case where the choices
>> aren't known until run time? Much more readable than the if/else if/else
>> series. (Most likely the generated code is in if/else form.)
>
> Does any recent Fortran (or any language for that matter) actually have such
> a statement?
Perl has a wonderful construct that looks like the proposed case
statement but can't quite be described in these terms. An example:
given ($x) {
$y = 'a' when $a;
$y = 'b' when $b;
$y = 'c' when $c;
}
The reason it's not exactly as described is that the "given" part and
the "when" parts are not connected syntactically. You can, for example,
have a set of "when" clauses in a "while" or "for" loop, and you don't
have to have any inside a "given" statement.
It's an extraordinarily powerful construct, mainly due to the magic
that a "when" clause can do.
Also, I remember an old variant of Algol called Algol-S had exactly
what's been proposed. I've not used it since 1978.
> (BTW we are in 2012 now you know, with all this talk of Fortran I and OS
> 360. I think they were already obsolete when I started programming 35 years
> ago...)
35 years ago system 360 was current. It's what I learnt to program on,
though the systems people hankered after a newer and faster 370...
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-11-22 14:37 +0000 |
| Message-ID | <k8ldal$5a8$1@dont-email.me> |
| In reply to | #28551 |
Ben Bacarisse wrote:
> Perl has a wonderful construct that looks like the proposed case
> statement but can't quite be described in these terms. An example:
>
> given ($x) {
> $y = 'a' when $a;
> $y = 'b' when $b;
> $y = 'c' when $c;
> }
>
> The reason it's not exactly as described is that the "given" part and
> the "when" parts are not connected syntactically. You can, for example,
> have a set of "when" clauses in a "while" or "for" loop, and you don't
> have to have any inside a "given" statement.
>
> It's an extraordinarily powerful construct, mainly due to the magic
> that a "when" clause can do.
The description of that feature in Perl isn't very reassuring.
Quoted from:
http://perldoc.perl.org/perlsyn.html#Switch-Statements
<quote>
Exactly what the EXPR argument to when does is hard to describe precisely,
but in general, it tries to guess what you want done. Sometimes it is
interpreted as $_ ~~ EXPR, and sometimes it does not. It also behaves
differently when lexically enclosed by a given block than it does when
dynamically enclosed by a foreach loop. The rules are far too difficult to
understand to be described here.
</quote>
I don't doubt it can be wonderful or useful to some people, but I really
doubt that it is a good idea do adopt a feature whose rules are described as
"far too difficult to understand" in the language's documentation.
Maybe that kind of stuff is valued in the Perl community, but gratuituously
adding features which are "far too difficult to understand", particularly
when they don't provide anything which isn't already offered by features
that exist for decades, only creates problems and needlessly complicates
things.
Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-22 17:12 +0000 |
| Message-ID | <0.68d0b987edb9a0fc3316.20121122171214GMT.878v9t4l5d.fsf@bsb.me.uk> |
| In reply to | #28570 |
Rui Maciel <rui.maciel@gmail.com> writes:
> Ben Bacarisse wrote:
>
>> Perl has a wonderful construct that looks like the proposed case
>> statement but can't quite be described in these terms. An example:
>>
>> given ($x) {
>> $y = 'a' when $a;
>> $y = 'b' when $b;
>> $y = 'c' when $c;
>> }
>>
>> The reason it's not exactly as described is that the "given" part and
>> the "when" parts are not connected syntactically. You can, for example,
>> have a set of "when" clauses in a "while" or "for" loop, and you don't
>> have to have any inside a "given" statement.
>>
>> It's an extraordinarily powerful construct, mainly due to the magic
>> that a "when" clause can do.
>
> The description of that feature in Perl isn't very reassuring.
>
> Quoted from:
> http://perldoc.perl.org/perlsyn.html#Switch-Statements
>
> <quote>
> Exactly what the EXPR argument to when does is hard to describe precisely,
> but in general, it tries to guess what you want done. Sometimes it is
> interpreted as $_ ~~ EXPR, and sometimes it does not. It also behaves
> differently when lexically enclosed by a given block than it does when
> dynamically enclosed by a foreach loop. The rules are far too difficult to
> understand to be described here.
> </quote>
>
>
> I don't doubt it can be wonderful or useful to some people, but I really
> doubt that it is a good idea do adopt a feature whose rules are described as
> "far too difficult to understand" in the language's documentation.
You mean in C? I was not proposing it for C! Perl programmers tend to
be rather relaxed people, and they'll just avoid this construct in
production code until the exact definition is pinned down. But in Perl,
the advantage of adopting a feature with evolving rules is that language
developers will get real freedback about real use cases. When the
semantics are finally cast in stone, the feature will be all the better
for it.
I've used it a few times just to get a job done fast, and it's very
expressive. I doubt any of these script will actually break down the
line because the "natural" uses are the ones that are going to be
preserved. It's the corner cases that are in flux.
> Maybe that kind of stuff is valued in the Perl community, but gratuituously
> adding features which are "far too difficult to understand", particularly
> when they don't provide anything which isn't already offered by features
> that exist for decades, only creates problems and needlessly complicates
> things.
You've subtly changed the meaning there! "far too difficult to
understand" is not the same as "far too difficult to understand to be
described here". There is a much fuller explanation elsewhere.
Perl did not have a switch statement, and I think it would have been
considered "underpowered" to add one that just compared expressions for
equality.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-21 16:47 -0800 |
| Message-ID | <lnvccytqeo.fsf@nuthaus.mib.org> |
| In reply to | #28544 |
"BartC" <bc@freeuk.com> writes:
[...]
> But I have found that people don't seem like useful extra syntax in their
> favourite languages. Or perhaps more accurately, if their favourite language
> doesn't have a particularly handy construction, they will defend the lack
> of it to the death!
For C, there's a *lot* of resistance to any changes that would break
existing code.
New features that don't break existing code still have a very large
burden of proof that they're sufficiently useful to justify the
substantial cost of (a) defining them rigorously, and (b) implementing
them in *all* conforming implementations. The agonizingly slow adoption
of C99 is a prime example of what can happen when that's ignored -- or
even when it isn't.
> So, we don't need an if-else version of switch, because we can just use
> if-else, and the compiler will end up generating the same code anyway. But
> like you say, there would never be a reason to progress beyond if-then-goto
> in that case.
If you're talking about either changing the existing switch
statement, or adding a new kind of switch statement, that allows
non-constant labels and jumps to the first matching case, I honestly
don't see that it's much better than a sequence of if/else if/else
statements. Presumably it would test a given value against a
sequence of other values. Would those tests be limited to equality,
or would it permit "<", ranges, and so forth?
It would evaluate the given expression only once rather than
re-evaluating it for each test -- but that's trivally accomplished
by using a temporary variable.
Am I missing some significant advantage in expressive power, safety,
performance, or something else that would make a dynamic switch
worth adding to the core language?
--
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]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web