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 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-22 01:23 +0000 |
| Message-ID | <k8juqm$asj$1@speranza.aioe.org> |
| In reply to | #28552 |
Keith Thompson <kst-u@mib.org> wrote: (snip) >> 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? As the number of cases gets larger, it looks much more readable compared to if/elseif/else. Also, if you implement a binary search (tree of if/else) instead of linear search (if/elseif/elseif... /else) it is a lot of work to get right, the nesting levels look horrible, and it is pretty much impossible to extend. (Not that you could do that with the first match logic, though.) > 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? Seems to me that it has a big advantage in the cases where it applies for large number of cases. How often that happens in actual programs, I don't know. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-22 08:19 -0500 |
| Message-ID | <k8l8p3$ab5$1@dont-email.me> |
| In reply to | #28553 |
On 11/21/2012 8:23 PM, glen herrmannsfeldt wrote:
> [...]
> Also, if you implement a binary search (tree of if/else) instead
> of linear search (if/elseif/elseif... /else) it is a lot of work to
> get right, the nesting levels look horrible, and it is pretty much
> impossible to extend. (Not that you could do that with the first
> match logic, though.)
Getting "first match" with a slightly elaborated binary
search isn't hard. But wasn't this whole construct proposed
for the sake of "case" values not known until run-time? How
will you perform a binary search among those cases? Sort
them every time you execute the "switch" (because they may
have changed since the previous execution)?
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-11-22 15:34 +1300 |
| Message-ID | <ah5h9kFsvchU7@mid.individual.net> |
| In reply to | #28552 |
On 11/22/12 13:47, Keith Thompson wrote:
>
> 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?
One use case for an extension to switch would be where the label type
doesn't have a built in equality operation. For example a syntax like:
switch( variable, binary comparison ) { }
would be useful for matching strings:
bool matchString( const char* s1, const char* s2 ) {
return strcmp( s1, s2 ) == 0;
}
switch( input, matchString )
{
case "one":
//
break;
case "two":
//
break;
}
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-11-22 04:18 +0000 |
| Message-ID | <k8k92n$ie7$1@dont-email.me> |
| In reply to | #28555 |
Ian Collins wrote:
> One use case for an extension to switch would be where the label type
> doesn't have a built in equality operation. For example a syntax like:
>
> switch( variable, binary comparison ) { }
>
> would be useful for matching strings:
>
> bool matchString( const char* s1, const char* s2 ) {
> return strcmp( s1, s2 ) == 0;
> }
>
> switch( input, matchString )
> {
> case "one":
> //
> break;
>
> case "two":
> //
> break;
> }
Why not let a function map a comparisson between matchString and a set of
strings to a set of integer/enum values, and then pass that value to a
switch?
<example>
#include <stdio.h>
/**
Compares string text with the set of n strings stored in matches[]
@param test string to be tested
@param matches set of n strings that will be compared with string test
@param n number of strings stored in matches[]
@return 0 if test matches no string, i+1 if test matches the i-th string
**/
int matchStrings(const char *test, const char *matches[], unsigned int n)
{
char const *tp, *mp; /* test pointer, matches pointer */
for(unsigned int i = 0; i < n; ++i)
{
tp = test;
mp = matches[i];
while( *tp != '\0' && *mp != '\0')
{
if(*tp != *mp)
break;
++tp;
++mp;
}
if( *tp == '\0' && *mp == '\0')
{
/* test matched match[i] */
return i+1;
}
}
/* default return value: no match */
return 0;
}
int main(void)
{
char const *matches[] = {"one", "two", "three"};
switch(matchStrings("three", matches, 3) )
{
case 0:
puts("no match");
break;
case 1:
puts("matched one");
break;
case 2:
puts("matched two");
break;
case 3:
puts("matched three");
break;
default:
puts("some error occurred");
break;
}
return 0;
}
</code>
No need to bloat the C programming language to be able to pull this off.
Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-11-22 17:31 +1300 |
| Message-ID | <ah5o5bFsvchU8@mid.individual.net> |
| In reply to | #28557 |
On 11/22/12 17:18, Rui Maciel wrote:
> Ian Collins wrote:
>
>> One use case for an extension to switch would be where the label type
>> doesn't have a built in equality operation. For example a syntax like:
>>
>> switch( variable, binary comparison ) { }
>>
>> would be useful for matching strings:
>>
>> bool matchString( const char* s1, const char* s2 ) {
>> return strcmp( s1, s2 ) == 0;
>> }
>>
>> switch( input, matchString )
>> {
>> case "one":
>> //
>> break;
>>
>> case "two":
>> //
>> break;
>> }
>
> Why not let a function map a comparisson between matchString and a set of
> strings to a set of integer/enum values, and then pass that value to a
> switch?
Less to type!
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-11-22 14:18 +0000 |
| Message-ID | <k8lc8l$v34$1@dont-email.me> |
| In reply to | #28558 |
Ian Collins wrote: >> Why not let a function map a comparisson between matchString and a set of >> strings to a set of integer/enum values, and then pass that value to a >> switch? > > Less to type! If, in my matchStrings(), the string matching code was replaced with a call to strcmp() or strncmp(), it would consist of a single for() loop iterating a call to strncmp(), which would require about half a dozen lines of code (LoC). I don't believe it would be a good idea to bloat the C standard just to be able to save at best half a dozen LoC on a corner case which no one actually needs. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-22 09:28 +0000 |
| Message-ID | <k8kr8a$5dm$1@speranza.aioe.org> |
| In reply to | #28557 |
Rui Maciel <rui.maciel@gmail.com> wrote:
> Ian Collins wrote:
>> One use case for an extension to switch would be where the label type
>> doesn't have a built in equality operation. For example a syntax like:
>> switch( variable, binary comparison ) { }
>> would be useful for matching strings:
>> bool matchString( const char* s1, const char* s2 ) {
>> return strcmp( s1, s2 ) == 0;
>> }
>> switch( input, matchString )
>> {
>> case "one":
>> //
>> break;
>>
>> case "two":
>> //
>> break;
>> }
> Why not let a function map a comparisson between matchString and a set of
> strings to a set of integer/enum values, and then pass that value to a
> switch?
Doesn't that just move the problem around?
It seems that String case might be added to Java in a future
version, but you could just case on the hashCode() of a String.
If the String hash function is fixed, you could just calculate
the hashCodes.
switch(str.hashCode) {
case "abc".hashCode():
except that, as far as I know, hashCode isn't evaluate at compile
time, so it is back to the run-time evaluation problem.
One could precompute the hashCode values, check that there
aren't any collisions, and put those in.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-11-22 14:10 +0000 |
| Message-ID | <k8lbnq$rv5$1@dont-email.me> |
| In reply to | #28562 |
glen herrmannsfeldt wrote: > Doesn't that just move the problem around? The problem, in this example, is exactly the same, as is the way it is solved: writing a string matching function whose return value is passed to a switch statement. The only difference is that the solution I suggested doesn't require a fancy switch() statement which is, at best, somewhere between useless and redundant. So, although the problem might not have been moved around, the solution was: back to the realm of plain standard C, the kind that already exists for some decades now. This was in itself a major problem. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2012-11-28 01:12 -0500 |
| Message-ID | <bpabb81td9tp7fj2r7tsslvs2uoljfdfqp@4ax.com> |
| In reply to | #28562 |
On Thu, 22 Nov 2012 09:28:42 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
> Rui Maciel <rui.maciel@gmail.com> wrote:
> > Ian Collins wrote:
>
> >> One use case for an extension to switch would be where the label type
> >> doesn't have a built in equality operation. For example <snip: string>
> > Why not let a function map a comparisson between matchString and a set of
> > strings to a set of integer/enum values, and then pass that value to a
> > switch?
>
> Doesn't that just move the problem around?
>
> It seems that String case might be added to Java in a future
> version, but you could just case on the hashCode() of a String.
>
(Suncle) JavaSE 7, out a year now, has switch on String. (They used to
number things separately, so to be pedantically correct we had to say
things like "the JDK 6 implementation of JLS 3". For 7 they numbered
JLS and JVMS changes to match the JDK.)
> If the String hash function is fixed, you could just calculate
> the hashCodes.
>
> switch(str.hashCode) {
> case "abc".hashCode():
>
> except that, as far as I know, hashCode isn't evaluate at compile
> time, so it is back to the run-time evaluation problem.
>
> One could precompute the hashCode values, check that there
> aren't any collisions, and put those in.
>
It actually uses a combination of your ideas here: it first compares
the hashCode of the value to those of the case labels, which must be
compile-time constant expressions, and then compares the full string
values to protect against collisions and other false hash matches, and
maps to a small integer value (or -1); it then dispatches on that
integer value to the statements, in the same way as for a (since
forever IINM) switch-on-integer.
Note in Java Object.hashCode can be overridden for user-defined
classes as long as you maintain the constraint that two objects with
the same semantic value give the same hashcode -- but not necessarily
vice versa. But for the language-defined and library-defined classes
hashCode is fixed, so the compiler knows what it is for String.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-28 09:50 +0000 |
| Message-ID | <k94mp0$107$1@speranza.aioe.org> |
| In reply to | #28720 |
David Thompson <dave.thompson2@verizon.net> wrote:
(snip, I wrote)
>> It seems that String case might be added to Java in a future
>> version, but you could just case on the hashCode() of a String.
The one I read must have been out of date.
> (Suncle) JavaSE 7, out a year now, has switch on String. (They used to
> number things separately, so to be pedantically correct we had to say
> things like "the JDK 6 implementation of JLS 3". For 7 they numbered
> JLS and JVMS changes to match the JDK.)
>> If the String hash function is fixed, you could just calculate
>> the hashCodes.
>> switch(str.hashCode) {
>> case "abc".hashCode():
>> except that, as far as I know, hashCode isn't evaluate at compile
>> time, so it is back to the run-time evaluation problem.
>> One could precompute the hashCode values, check that there
>> aren't any collisions, and put those in.
> It actually uses a combination of your ideas here: it first compares
> the hashCode of the value to those of the case labels, which must be
> compile-time constant expressions, and then compares the full string
> values to protect against collisions and other false hash matches, and
> maps to a small integer value (or -1); it then dispatches on that
> integer value to the statements, in the same way as for a (since
> forever IINM) switch-on-integer.
Earlier in the thread I noted that "abcd"[2] isn't a constant
expression in C. I found that out when I tried to use a string
as an argument to a preprocessor macro to generate case labels.
#define hash(x) (2*x[0]+3*x[1]+5*x[2]+7*x[3])
(Though I had a better hash function.)
But it doesn't work for case labels.
> Note in Java Object.hashCode can be overridden for user-defined
> classes as long as you maintain the constraint that two objects with
> the same semantic value give the same hashcode -- but not necessarily
> vice versa. But for the language-defined and library-defined classes
> hashCode is fixed, so the compiler knows what it is for String.
It seems that the hash function for String is actually in the Sun
(oops, Oracle) documentation for the class.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-22 11:43 +0000 |
| Message-ID | <xdors.519819$A%.183457@fx26.am4> |
| In reply to | #28555 |
"Ian Collins" <ian-news@hotmail.com> wrote in message
news:ah5h9kFsvchU7@mid.individual.net...
> On 11/22/12 13:47, Keith Thompson wrote:
>> 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?
>
> One use case for an extension to switch would be where the label type
> doesn't have a built in equality operation. For example a syntax like:
That's a totally different kind of use.
> switch( variable, binary comparison ) { }
>
> would be useful for matching strings:
>
> bool matchString( const char* s1, const char* s2 ) {
> return strcmp( s1, s2 ) == 0;
> }
>
> switch( input, matchString )
> {
> case "one":
> //
> break;
>
> case "two":
> //
> break;
> }
>
You don't really need the matchString thing. Usually only == matching makes
sense for strings. Better to have a streamlined version just for that
purpose:
strswitch (input) {
case "one": ...
case "two": ...
default:
}
Use the opportunity to get rid of break, too! (That was a bad mistake in the
original switch statement.)
Also the compiler can not optimise the matching of these strings, by using
one of the usual search techniques for example.
(It's possible to just use a string table, and a function, to do this lookup
now, but that doesn't give you the convenience of placing the handler code
directly against each string.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-22 11:34 +0000 |
| Message-ID | <wdors.519818$A%.271846@fx26.am4> |
| In reply to | #28552 |
"Keith Thompson" <kst-u@mib.org> wrote in message news:lnvccytqeo.fsf@nuthaus.mib.org... > "BartC" <bc@freeuk.com> writes: > statements. Presumably it would test a given value against a > sequence of other values. That's the main thing. Would those tests be limited to equality, > or would it permit "<", ranges, and so forth? Even limiting switch to just matching an integer expression against a number constant values, there's a bunch of things that are more useful to get right first: o Allow case 10,20,30,40,50: instead of case 10: case 20: case 30: case 40: case 50: o Allow case 1..5: instead of case 1: case 2: case 3: case 4: case 5: o Although not so important if the above is present, allow mixed scalars and ranges: case 1..5,7..10: (but the comma is a problem in C) o Get rid of the need for break (but that would need an alternative keyword for switch, and perhaps for case, to form a new syntax where break is not needed and case labels are well-behaved (not allowed in every conceivable place). o Possibly, allow switch to return a value (although I mainly use such a feature in a streamlined version of switch, where the case values are omitted and assumed to be (0,) 1, 2, 3 ..., and with an abbreviated syntax. In C, that might look like: x = (n ? a, b, a+b : z); if you excuse the commas again. Assign a, b or a+b to x when n is 0, 1 or 2, otherwise z. Only one right-side-side value is evaluated). > 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? I use another version of switch when: o I don't care whether a jumptable is created o Integer case values are too big or disparate to form a jump table o Non-integer case values are used o Non-constant case values are being tested That last one is the proposal here, but I have say there is very rarely a need for that (in my own code); the other reasons are more likely ones to use this alternate (in my case) form of switch. But why not allow it anyway? Just to have the 'expressive power' when you need it. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-22 09:57 -0800 |
| Message-ID | <lnmwy9tta4.fsf@nuthaus.mib.org> |
| In reply to | #28564 |
"BartC" <bc@freeuk.com> writes:
[...]
> I use another version of switch when:
>
> o I don't care whether a jumptable is created
> o Integer case values are too big or disparate to form a jump table
> o Non-integer case values are used
> o Non-constant case values are being tested
>
> That last one is the proposal here, but I have say there is very rarely a
> need for that (in my own code); the other reasons are more likely ones to
> use this alternate (in my case) form of switch. But why not allow it anyway?
> Just to have the 'expressive power' when you need it.
It already is allowed; any compiler can add this as an extension, as
long as it doesn't break conformance.
As for adding it to the standard, "why not" is the wrong question.
There are a plethora of featuers that would be "nice to have".
Adding all of them to the standard would make for a huge language.
There's a strong burden of proof on anyone proposing a new feature
to convince the committee that it's worth the substantial cost.
--
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 | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-22 18:47 +0000 |
| Message-ID | <3yurs.463413$Bz2.433851@fx11.am4> |
| In reply to | #28573 |
"Keith Thompson" <kst-u@mib.org> wrote in message news:lnmwy9tta4.fsf@nuthaus.mib.org... > "BartC" <bc@freeuk.com> writes: >> But why not allow it anyway? >> Just to have the 'expressive power' when you need it. > > It already is allowed; any compiler can add this as an extension, as > long as it doesn't break conformance. > > As for adding it to the standard, "why not" is the wrong question. > There are a plethora of featuers that would be "nice to have". > Adding all of them to the standard would make for a huge language. I don't agree. If you have restrictions, they have to be documented and enforced. Sometimes it's easier to just allow something, than try and explain exactly why it can't be done! And if the need really is there, then the workaround needed will increase the size of that specific program anyway. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-22 11:39 -0800 |
| Message-ID | <lnip8xtoje.fsf@nuthaus.mib.org> |
| In reply to | #28576 |
"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnmwy9tta4.fsf@nuthaus.mib.org...
>> "BartC" <bc@freeuk.com> writes:
>
>>> But why not allow it anyway?
>>> Just to have the 'expressive power' when you need it.
>>
>> It already is allowed; any compiler can add this as an extension, as
>> long as it doesn't break conformance.
>>
>> As for adding it to the standard, "why not" is the wrong question.
>> There are a plethora of featuers that would be "nice to have".
>> Adding all of them to the standard would make for a huge language.
>
> I don't agree. If you have restrictions, they have to be documented and
> enforced.
The current restrictions on the switch statement are clearly documented
and enforced.
> Sometimes it's easier to just allow something, than try and
> explain exactly why it can't be done!
But not in this case. You're talking about a new flow control
construct, one whose implementation is *very* different from the current
switch statement. Are you volunteering to provide the implementation
for every C compiler on the market? (Good luck with the closed source
ones.)
> And if the need really is there, then the workaround needed will increase
> the size of that specific program anyway.
As opposed to increasing the size of the language specification and of
every C compiler.
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 14:08 -0500 |
| Message-ID | <50AA83C2.9070006@verizon.net> |
| In reply to | #28403 |
On 11/19/2012 01:25 PM, BartC wrote: > "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message > news:k8dljp$db3$1@dont-email.me... >> On 11/18/2012 7:04 PM, BartC wrote: > >>> So when victim is compiled, it will use the current value of table_max >>> in whichever file1 or file2 has been chosen. To create two programs with >>> two different values of table_max, requires recompilation of victim in >>> each case. >> >> ... which was James' point: "Any language that allows you >> to do this does not support true separate compilation." If I >> must recompile victim.c for each potential partner fileX.c, there >> is no more separate compilation. > > In your example, you were constructing two different programs: victim+file1, > or victim+file2. > > You were deferring the selection of that companion file until 'link-time', > using a mechanism which I guess is not defined by the language. Well, yes. Mechanisms are the domain of implementers, they are outside the scope of the C standard. Consider files containing the following lines, among others: > /* file1.c */ > const int table_max = 100; > > /* file2.c */ > const int table_max = 200; > > /* victim.c */ > extern const int table_max; The standard says the behavior is undefined if file1 and file2 are both linked into the same program. Otherwise, if file1 and victim are linked into a single strictly conforming program, the value of table_max in that program must be 100. If file2 and victim are linked, it must be 200. The standard doesn't specify the mechanism used to achieve this, but it does require that some mechanism be used to make it happen. > In my example, I was suggesting that the selection was made at compile-time, > either victim+file1, or victim+file2 (with a mechanism not known to C > either). There isn't that much difference. The difference is that C mandates the behavior we describe, regardless of what mechanism is used to achieve it. To have the behavior occur at compile time, as you described, file1.c or file2.c would have to be #included into victim.c during the compilation phase, rather than linked to it after compilation. As far as C is concerned, "victim.c + #included file1.c" is one translation unit, and "victim.c + #included file2.c" would be a different one.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-19 21:32 +0000 |
| Message-ID | <k8e8h1$mnp$1@speranza.aioe.org> |
| In reply to | #28411 |
James Kuyper <jameskuyper@verizon.net> wrote: (snip) >> In your example, you were constructing two different programs: victim+file1, >> or victim+file2. >> You were deferring the selection of that companion file until 'link-time', >> using a mechanism which I guess is not defined by the language. > Well, yes. Mechanisms are the domain of implementers, they are outside > the scope of the C standard. Consider files containing the following > lines, among others: >> /* file1.c */ >> const int table_max = 100; >> /* file2.c */ >> const int table_max = 200; >> /* victim.c */ >> extern const int table_max; Before there was C, there was Fortran and BLOCK DATA, which requires a similar implementation. So, linkers would already know how to do this even if implemented before C existed. The OS/360 linker, for example, takes the first CSECT that it finds if there are duplicates. That allows for the actual editing in the name linkage editor. If you need to replace one CSECT in a previously compiled and linked program, load the new one in, then INCLUDE the old load module. The linkage editor keeps the new CSECT in place of the old one with the same name, updates all the address constants, and everything works. > The standard says the behavior is undefined if file1 and file2 are both > linked into the same program. Otherwise, if file1 and victim are linked > into a single strictly conforming program, the value of table_max in > that program must be 100. If file2 and victim are linked, it must be > 200. The standard doesn't specify the mechanism used to achieve this, > but it does require that some mechanism be used to make it happen. >> In my example, I was suggesting that the selection was made at compile-time, >> either victim+file1, or victim+file2 (with a mechanism not known to C >> either). There isn't that much difference. > The difference is that C mandates the behavior we describe, regardless > of what mechanism is used to achieve it. To have the behavior occur at > compile time, as you described, file1.c or file2.c would have to be > #included into victim.c during the compilation phase, rather than linked > to it after compilation. As far as C is concerned, "victim.c + #included > file1.c" is one translation unit, and "victim.c + #included file2.c" > would be a different one. Or a fancier linker than we usually have. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 16:35 -0500 |
| Message-ID | <50AAA60A.7030902@verizon.net> |
| In reply to | #28422 |
On 11/19/2012 04:32 PM, glen herrmannsfeldt wrote: > James Kuyper <jameskuyper@verizon.net> wrote: ... >>> In my example, I was suggesting that the selection was made at compile-time, >>> either victim+file1, or victim+file2 (with a mechanism not known to C >>> either). There isn't that much difference. > >> The difference is that C mandates the behavior we describe, regardless >> of what mechanism is used to achieve it. To have the behavior occur at >> compile time, as you described, file1.c or file2.c would have to be >> #included into victim.c during the compilation phase, rather than linked >> to it after compilation. As far as C is concerned, "victim.c + #included >> file1.c" is one translation unit, and "victim.c + #included file2.c" >> would be a different one. > > Or a fancier linker than we usually have. If the determination of the value is done during linkage, it's not a "compile time constant".
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 21:51 +0000 |
| Message-ID | <%Yxqs.598785$Ol2.250434@fx25.am4> |
| In reply to | #28411 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message
news:50AA83C2.9070006@verizon.net...
> On 11/19/2012 01:25 PM, BartC wrote:
> Well, yes. Mechanisms are the domain of implementers, they are outside
> the scope of the C standard. Consider files containing the following
> lines, among others:
>
>> /* file1.c */
>> const int table_max = 100;
>>
>> /* file2.c */
>> const int table_max = 200;
>>
>> /* victim.c */
>> extern const int table_max;
>
> The standard says the behavior is undefined if file1 and file2 are both
> linked into the same program.
(Actually, in the counter-example I gave, it's possible to have both
table_max constants at the same time! It looks like this:
import file1
import file2
println file1.table_max
println file2.table_max
Although it does need a qualifier to disambiguate the two. But this is
something is that is also quite handy.)
>> In my example, I was suggesting that the selection was made at
>> compile-time,
>> either victim+file1, or victim+file2 (with a mechanism not known to C
>> either). There isn't that much difference.
>
> The difference is that C mandates the behavior we describe, regardless
> of what mechanism is used to achieve it. To have the behavior occur at
> compile time, as you described, file1.c or file2.c would have to be
> #included into victim.c during the compilation phase, rather than linked
> to it after compilation.
That of course is also possible. If victim.c and file1.c were originally one
file, then later split into two, you're saying the two files can no longer
share the same constants, at least not without putting the common values in
a third file, a common header, except that is often not practical (because
the values might depend on something in the body of file1.c).
However that is not necessary. Suppose file1.c contained the following:
#define abc 90215 /* global constant */
And you ran some program on file1.c which picked out defines that had a
'global constant' comment, and produced a file file1.h containing:
#define abc 90215
This file is then included in victim.c. You're now exporting a constant from
file1.c into victim.c - congratulations! See it wasn't that difficult, and
/you don't need file1.c at the point where victim.c is compiled/. Although
you have introduced an extra dependency which has to be borne in mind when
updating these files (but that's nothing new in C).
Of course such a mechanism is crude: it wouldn't work here for example:
int a[] = {10,20,30};
#define alength (sizeof(a)/sizeof(a[0])) /* global constant */
because '(sizeof(a)...' would be meaningless outside this module. You need a
cleverer utility, or be supported by the language, so that the output is
something like:
#define alength 3
Anyhow, I use this stuff and find it very convenient. If you don't want it
in C (and it's never going to happen anyway) I don't really care! I'm just
pointing out that it can be done, whatever excuses you keep coming up with
why it would never work...
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-18 18:38 -0500 |
| Message-ID | <k8brh9$s33$1@dont-email.me> |
| In reply to | #28354 |
On 11/18/2012 05:45 PM, BartC wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:k8bm1u$rqm$1@dont-email.me...
...
>> Object-like macros have a name, and can expand into constant
>> expressions. Enumeration constants have a name and a constant value. In
>> what way do either them fail to qualify as "true named constants"?
>> You'll need to add at least one additional adjective to the phrase
>> "named constants" to justify rejecting them.
>
> In another post in this thread, I gave the example of a proposed 'constant'
> attribute which illustrates what I had in mind for a 'true named constant'.
> This does exactly what is intended, without going around the houses trying
> to achieve the same with whatever else C has lying around.
I'll have to take a look at that other message, and perhaps respond
there, but all a "named constant" needs to be "true" is to be named, and
constant. If you have a more sophisticated concept in mind, it needs a
more complicated name to cover the additional features.
> Actually I can't see why something so simple is not part of the language
> anyway, *even if* the same thing can be achieved in several other indirect
> ways.
>
> The problem with named macros is mainly that of scope. Also, while you can
> have a macro ABC that expands to the literal '73128', it could also expand
> to '73)+*('!
I appreciate the value that scoping adds to a named constant, but a lack
of scoping doesn't disqualify macros or enumeration constants from the
category of "true named constants", but only from the more restricted
category of "true named scoped constants". The fact that macros can be
#defined to expand into things other than constant expressions excludes
such macros from the category of "named constants" - but that doesn't
prevent macros which DO expand into constant expressions from qualifying
as "true named constants".
> The problem with enums I think is more of 'type' (only available for int).
> Also you always get the impression they were created for a specific purpose
> (related sets of constants), and it seems like you're hijacking the feature
> when you use it just because 'constant' isn't available.
It's just a related set of constants, where the set size is 1 (rendering
"related" rather irrelevant). It seems to me a reasonable special case
use of a more general construct, though the general case is a more
reasonable use.
I don't object to bringing C into alignment with C++ on this issue; only
to mis characterization of the way in which the C alternatives differ
from what you can do in C++ and other languages.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web