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 1 of 12 [1] 2 3 … 12 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-18 01:21 -0800 |
| Subject | some well known stupidness in c99 |
| Message-ID | <691430a0-0d95-40ac-8ca4-5ceab7db74db@googlegroups.com> |
It is sad to say so but there is some real and terrible stupidnes in c99. When i wrote programs in c (and I am involved c user) I just use const int for array boundaries but in c99 (and some previous too, terribly) it will not compile (see for example http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong thing for ppl who just wants to use const int to this purposes and not to use preprocesor - as I do. It is terribly stupidness in my opinion, it have to be changed.
[toc] | [next] | [standalone]
| From | Thomas Richter <thor@math.tu-berlin.de> |
|---|---|
| Date | 2012-11-18 10:41 +0100 |
| Message-ID | <k8aafk$vhl$1@news2.informatik.uni-stuttgart.de> |
| In reply to | #28322 |
Am 18.11.2012 10:21, schrieb fir: > It is sad to say so but there is some real > and terrible stupidnes in c99. When i wrote > programs in c (and I am involved c user) I > just use const int for array boundaries but > in c99 (and some previous too, terribly) it > will not compile (see for example > http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong > thing for ppl who just wants to use const int to this > purposes and not to use preprocesor - as I do. > It is terribly stupidness in my opinion, it have to > be changed. This is valid C++ code, thus one option would be just to switch to C++. In C, however, const is probably not quite what you expect it to be.
[toc] | [prev] | [next] | [standalone]
| From | SG <sgesemann@gmail.invalid> |
|---|---|
| Date | 2012-11-18 10:41 +0100 |
| Message-ID | <k8aah3$kdd$1@news.albasani.net> |
| In reply to | #28322 |
Am 18.11.2012 10:21, schrieb fir: > It is sad to say so but there is some real > and terrible stupidnes in c99. When i wrote > programs in c (and I am involved c user) I > just use const int for array boundaries but > in c99 (and some previous too, terribly) it > will not compile (see for example > http://stackoverflow.com/questions/1712592/ ) It is terribly wrong > thing for ppl who just wants to use const int to this > purposes and not to use preprocesor - as I do. > It is terribly stupidness in my opinion, it have to > be changed. To my knowledge this has been the way in C for ever. Are you complaining about C99 not adopting the C++ style in treating a file-scope const "variable" with a constant initializer as a constant [compile-time] expression? Or are you suggesting that C90 handles this any better and that C99 is actually a regression in this department? In C++ you can actually do this and const int foo = 10; is implicitly static (file-scope) due to the top-level constness and foo can be used as compile-time constant expression. This is by design because B. Stroustrup doesn't like macros very much, either. I sort of accepted this difference between C and C++. In C you just have to #define something like this in order to be able to use it as the size of a non-VL array. But I would appreciate it if this unnecessary incompatibility went away...
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-18 02:02 -0800 |
| Message-ID | <b4ba730c-3736-474e-b1a2-e616dc57ebd2@googlegroups.com> |
| In reply to | #28324 |
W dniu niedziela, 18 listopada 2012 10:41:55 UTC+1 użytkownik SG napisał: > Am 18.11.2012 10:21, schrieb fir: > > > It is sad to say so but there is some real > > > and terrible stupidnes in c99. When i wrote > > > programs in c (and I am involved c user) I > > > just use const int for array boundaries but > > > in c99 (and some previous too, terribly) it > > > will not compile (see for example > > > http://stackoverflow.com/questions/1712592/ ) It is terribly wrong > > > thing for ppl who just wants to use const int to this > > > purposes and not to use preprocesor - as I do. > > > It is terribly stupidness in my opinion, it have to > > > be changed. > > > > To my knowledge this has been the way in C for ever. Are you complaining > > about C99 not adopting the C++ style in treating a file-scope const > > "variable" with a constant initializer as a constant [compile-time] > > expression? Or are you suggesting that C90 handles this any better and > > that C99 is actually a regression in this department? > > > > In C++ you can actually do this and > > > > const int foo = 10; > > > > is implicitly static (file-scope) due to the top-level constness and foo > > can be used as compile-time constant expression. This is by design > > because B. Stroustrup doesn't like macros very much, either. > > > > I sort of accepted this difference between C and C++. In C you just have > > to #define something like this in order to be able to use it as the size > > of a non-VL array. But I would appreciate it if this unnecessary > > incompatibility went away... yes, i know; i dislike #define and must to switch to c++ compatybility mode to compile my besides that pure c codes it is terrible, it should just change becouse in other way though I am c (not c++) coder I must throw c compilers to trashbin - becouse I dislike macros and do not use no one of them c should just accept const int table_max = 1000; int table[table_max}; I do not know where this no 'const int array boundaries' dirty shit originates but it seem to me that in older c there it was possible to use const ints as array boundaries, (not sure to this, usualy switched to c++ mode to resolve other old c troubles with int i before for loop and so :/ ) make c const int usable in c, call the comitee or compiler writers to include some switch :/
[toc] | [prev] | [next] | [standalone]
| From | SG <sgesemann@gmail.invalid> |
|---|---|
| Date | 2012-11-18 11:23 +0100 |
| Message-ID | <k8acvo$rd4$1@news.albasani.net> |
| In reply to | #28325 |
Am 18.11.2012 11:02, schrieb fir: > W dniu niedziela, 18 listopada 2012 10:41:55 UTC+1 użytkownik SG napisał: >> Am 18.11.2012 10:21, schrieb fir: >> >>> It is sad to say so but there is some real >>> and terrible stupidnes in c99. When i wrote >>> programs in c (and I am involved c user) I >>> just use const int for array boundaries but >>> in c99 (and some previous too, terribly) it >>> will not compile (see for example >>> http://stackoverflow.com/questions/1712592/ ) [snip] >> To my knowledge this has been the way in C for ever. [snip] >> of a non-VL array. But I would appreciate it if this unnecessary >> incompatibility went away... > > yes, i know; i dislike #define and must to switch to c++ compatybility mode to compile > my besides that pure c codes [snip] > c should just accept > > const int table_max = 1000; > int table[table_max}; > > I do not know where this no 'const int array boundaries' dirty shit originates > but it seem to me that in older c there it was possible to use const ints as array boundaries, (not sure to this, usualy switched to c++ mode to resolve other old c troubles with int i before for loop and so :/ ) I don't think you're right. "older C" wasn't "better" in that respect.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-18 02:26 -0800 |
| Message-ID | <97c01bdb-0e63-4e70-8c47-5f3f4cba3aac@googlegroups.com> |
| In reply to | #28326 |
> > > I don't think you're right. "older C" wasn't "better" in that respect. ok :-(
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-18 12:16 +0000 |
| Message-ID | <0.a00d1f027ab21de2d9d1.20121118121646GMT.87r4nrayxd.fsf@bsb.me.uk> |
| In reply to | #28325 |
fir <profesor.fir@gmail.com> writes: <snip> > I do not know where this no 'const int array boundaries' dirty shit > originates but it seem to me that in older c there it was possible to > use const ints as array boundaries, (not sure to this, usualy switched > to c++ mode to resolve other old c troubles with int i before for loop > and so :/ ) It seems you've been writing C++ for some years now, so why not just be a happy C++ programmer rather than an unhappy C one? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-18 05:27 -0800 |
| Message-ID | <76a2b26b-15e0-44a0-8c6f-63cfe386e643@googlegroups.com> |
| In reply to | #28329 |
W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał: > fir <profesor.fir@gmail.com> writes: > > <snip> > > > I do not know where this no 'const int array boundaries' dirty shit > > > originates but it seem to me that in older c there it was possible to > > > use const ints as array boundaries, (not sure to this, usualy switched > > > to c++ mode to resolve other old c troubles with int i before for loop > > > and so :/ ) > > > > It seems you've been writing C++ for some years now, so why not just be > > a happy C++ programmer rather than an unhappy C one? > becouse i dislike all c++ features (and soul), and deply appreciate most of c features (and its spirit), this const int table_max = 100; int table[table_max]; i consider as it should belong to c language also It should be, it is terrible that it fails here, (indeed i write in c but i change to c++ becouse of some old c slight quirks and was unaware that this terrible const int boundary distaster is present here
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-18 14:24 +0000 |
| Message-ID | <0.2c82b035821c277b9cfb.20121118142432GMT.87lidzat0f.fsf@bsb.me.uk> |
| In reply to | #28331 |
fir <profesor.fir@gmail.com> writes:
You might want to look into using either the older Google groups
interface or a stand-alone news reader. The new Google groups seems to
mess up posts that go to Usenet very badly. (You might also consider
using your shift key.)
> W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:
>> fir <profesor.fir@gmail.com> writes:
>>
>> <snip>
>>
>> > I do not know where this no 'const int array boundaries' dirty shit
>>
>> > originates but it seem to me that in older c there it was possible to
>>
>> > use const ints as array boundaries, (not sure to this, usualy switched
>>
>> > to c++ mode to resolve other old c troubles with int i before for loop
>>
>> > and so :/ )
>>
>>
>>
>> It seems you've been writing C++ for some years now, so why not just be
>>
>> a happy C++ programmer rather than an unhappy C one?
>>
>
> becouse i dislike all c++ features (and soul), and deply appreciate
> most of c features (and its spirit),
You obviously don't dislike all C++ features since you want C to adopt
one of them!
> this
> const int table_max = 100;
> int table[table_max];
You don't *have* to use a macro. You can use an enum constant instead:
enum { table_max = 100 };
int table[table_max];
> i consider as it should belong to c language also It should be, it is
> terrible that it fails here, (indeed i write in c but i change to c++
> becouse of some old c slight quirks and was unaware that this terrible
> const int boundary distaster is present here
You have only two realistic options: keep using C++, or switch back to C
and use a macro or an enum. There is no hope at all that the C
committee will change the meaning of const any time soon. It's likely
to be 10 years before the next major revision of the language and even
then I don't think it's likely. If you want to try, posting here is
going to be of little use. You'll need a proposal and, probably,
backing from your national standards body.
BTW, I agree with you in theory: C should have used C++'s meaning of
const from the start, but back in the late 80s no one new that C++ would
become what it has, and C compilers were already using the more
restricted notion that became standard.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-18 06:44 -0800 |
| Message-ID | <45cdc40c-2fd1-4322-8b62-9ce2fb2ab9af@googlegroups.com> |
| In reply to | #28332 |
W dniu niedziela, 18 listopada 2012 15:24:34 UTC+1 użytkownik Ben Bacarisse napisał:
> fir <profesor.fir@gmail.com> writes:
>
>
>
> You might want to look into using either the older Google groups
>
> interface or a stand-alone news reader. The new Google groups seems to
>
> mess up posts that go to Usenet very badly. (You might also consider
>
> using your shift key.)
>
>
>
> > W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał:
>
> >> fir <profesor.fir@gmail.com> writes:
>
> >>
>
> >> <snip>
>
> >>
>
> >> > I do not know where this no 'const int array boundaries' dirty shit
>
> >>
>
> >> > originates but it seem to me that in older c there it was possible to
>
> >>
>
> >> > use const ints as array boundaries, (not sure to this, usualy switched
>
> >>
>
> >> > to c++ mode to resolve other old c troubles with int i before for loop
>
> >>
>
> >> > and so :/ )
>
> >>
>
> >>
>
> >>
>
> >> It seems you've been writing C++ for some years now, so why not just be
>
> >>
>
> >> a happy C++ programmer rather than an unhappy C one?
>
> >>
>
> >
>
> > becouse i dislike all c++ features (and soul), and deply appreciate
>
> > most of c features (and its spirit),
>
>
>
> You obviously don't dislike all C++ features since you want C to adopt
>
> one of them!
>
>
>
> > this
>
> > const int table_max = 100;
>
> > int table[table_max];
>
>
>
> You don't *have* to use a macro. You can use an enum constant instead:
>
>
>
> enum { table_max = 100 };
>
> int table[table_max];
>
>
>
> > i consider as it should belong to c language also It should be, it is
>
> > terrible that it fails here, (indeed i write in c but i change to c++
>
> > becouse of some old c slight quirks and was unaware that this terrible
>
> > const int boundary distaster is present here
>
>
>
> You have only two realistic options: keep using C++, or switch back to C
>
> and use a macro or an enum. There is no hope at all that the C
>
> committee will change the meaning of const any time soon. It's likely
>
> to be 10 years before the next major revision of the language and even
>
> then I don't think it's likely. If you want to try, posting here is
>
> going to be of little use. You'll need a proposal and, probably,
>
> backing from your national standards body.
>
>
>
> BTW, I agree with you in theory: C should have used C++'s meaning of
>
> const from the start, but back in the late 80s no one new that C++ would
>
> become what it has, and C compilers were already using the more
>
> restricted notion that became standard.
>
I could try to talk with some ppl in this comitee if i would konow how to do it, couse
I am curious what they would say to me
(though have neber tried this yet)
I am far involved in area of c language
improvements, as I said few weeks ago,
and I am working on my own compiler and
language (which I consider is still c )
so one options is to write my own
compiler (can do, and will do that)
other option is also to say to some
compiler makers to make some switch which
would accept const ints as array boundaries
(though they probably would say that i can
use c-like subset of c++ as I am doing
now (it is ok though i would feel bad if
it would be named as writing in c++, I am
absolutely c spitit not c++ programmer
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-18 06:50 -0800 |
| Message-ID | <7c1e8154-1c9d-479f-a95e-fb7a89421acf@googlegroups.com> |
| In reply to | #28333 |
> > language (which I consider is still c ) > or, at least, I would like it to be still c (this may need some smewhat difficult care maybe to feel what c is, especially on improved area :-()
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-18 11:07 -0500 |
| Message-ID | <k8b14k$ho2$1@dont-email.me> |
| In reply to | #28334 |
On 11/18/2012 09:50 AM, fir wrote: >> >> language (which I consider is still c ) >> > > or, at least, I would like it to be still c > (this may need some smewhat difficult care > maybe to feel what c is, especially on improved > area :-() You compiler could qualify as C, so long as every feature that it supports which deviates from the requirements specified by the standard can either be disabled by a compiler option, or requires the use of a #pragma or a C feature with undefined behavior to enable it. If your extension always involves something that constitutes a syntax error or a constraint violation in C, your compiler can fully conform to the standard simply by issuing a diagnostic message (such as "Warning: this program relies upon our file scope VLA extension to standard C") whenever the program uses the feature. However, you'll need to know precisely what the C standard requires, in order to meet those requirements. Since this issue surprised you, and particularly since you mis-identified it as something new in C99, I suspect that you have a lot to learn before you'll be able to build a standard-conforming implementation of C. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-11-18 12:22 -0500 |
| Message-ID | <k6CdnWuVpab7hDTNnZ2dnUVZ_qmdnZ2d@bestweb.net> |
| In reply to | #28331 |
On 11/18/2012 8:27 AM, fir wrote: > W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał: [...] >> It seems you've been writing C++ for some years now, so why not just be >> a happy C++ programmer rather than an unhappy C one? >> > > becouse i dislike all c++ features (and soul), and deply appreciate most of c features (and its spirit), this > > const int table_max = 100; > int table[table_max]; > > i consider as it should belong to c language also It should be, it is terrible that it fails here, (indeed i write in c but i change > to c++ becouse of some old c slight quirks > and was unaware that this terrible const int > boundary distaster is present here I find it highly unlikely that this fart of the language will change, considering the fact that you can have: ===== file1.c const int table_max = 100; ===== file2.c extern const int table_max; .... references to "table_max" that cannot be a compile-time constant ... -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-18 09:39 -0800 |
| Message-ID | <d4c81f5c-74f6-4e3d-93c8-7e7899214e6c@googlegroups.com> |
| In reply to | #28340 |
W dniu niedziela, 18 listopada 2012 18:22:47 UTC+1 użytkownik Kenneth Brody napisał: > On 11/18/2012 8:27 AM, fir wrote: > > > W dniu niedziela, 18 listopada 2012 13:16:48 UTC+1 użytkownik Ben Bacarisse napisał: > > [...] > > >> It seems you've been writing C++ for some years now, so why not just be > > >> a happy C++ programmer rather than an unhappy C one? > > >> > > > > > > becouse i dislike all c++ features (and soul), and deply appreciate most of c features (and its spirit), this > > > > > > const int table_max = 100; > > > int table[table_max]; > > > > > > i consider as it should belong to c language also It should be, it is terrible that it fails here, (indeed i write in c but i change > > > to c++ becouse of some old c slight quirks > > > and was unaware that this terrible const int > > > boundary distaster is present here > > > > I find it highly unlikely that this fart of the language will change, > > considering the fact that you can have: > > > > ===== file1.c > > > > const int table_max = 100; > > > > ===== file2.c > > > > extern const int table_max; > > > > .... references to "table_max" that cannot be a compile-time constant ... > > here, it should be just some requirement that array boundary const int must be defined in the same module as aray itself (end compile error if not) it is not general problem with const int here
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-18 20:22 +0000 |
| Message-ID | <8sbqs.308057$Wc4.142651@fx10.am4> |
| In reply to | #28340 |
"Kenneth Brody" <kenbrody@spamcop.net> wrote in message news:k6CdnWuVpab7hDTNnZ2dnUVZ_qmdnZ2d@bestweb.net... > On 11/18/2012 8:27 AM, fir wrote: >> const int table_max = 100; >> int table[table_max]; > I find it highly unlikely that this fart of the language will change, > considering the fact that you can have: > > ===== file1.c > > const int table_max = 100; > > ===== file2.c > > extern const int table_max; > > .... references to "table_max" that cannot be a compile-time constant ... Why not? I can do this in another language (albeit using true named constants, rather than read-only variables, although the latter can be possible in the same way). In any case, the language ought to provide true named constants, which are pretty fundamental, not expect everyone to mess around with enums, defines, and const attributes. Then the above won't be a problem. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-18 17:04 -0500 |
| Message-ID | <k8bm1u$rqm$1@dont-email.me> |
| In reply to | #28344 |
On 11/18/2012 03:22 PM, BartC wrote: > "Kenneth Brody" <kenbrody@spamcop.net> wrote in message > news:k6CdnWuVpab7hDTNnZ2dnUVZ_qmdnZ2d@bestweb.net... ... >> I find it highly unlikely that this fart of the language will change, >> considering the fact that you can have: >> >> ===== file1.c >> >> const int table_max = 100; >> >> ===== file2.c >> >> extern const int table_max; >> >> .... references to "table_max" that cannot be a compile-time constant ... > > Why not? I can do this in another language Because, at compile time for file2.c, file1.c is not visible, and the value of table_max cannot be known. Any language that allows you to do this does not support true separate compilation. > In any case, the language ought to provide true named constants, which are > pretty fundamental, not expect everyone to mess around with enums, defines, > and const attributes. Then the above won't be a problem. 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. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-18 22:45 +0000 |
| Message-ID | <Cydqs.418031$Tf3.217168@fx12.am4> |
| In reply to | #28351 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message
news:k8bm1u$rqm$1@dont-email.me...
> On 11/18/2012 03:22 PM, BartC wrote:
>> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message
>> news:k6CdnWuVpab7hDTNnZ2dnUVZ_qmdnZ2d@bestweb.net...
>>> ===== file1.c
>>>
>>> const int table_max = 100;
>>>
>>> ===== file2.c
>>>
>>> extern const int table_max;
>>>
>>> .... references to "table_max" that cannot be a compile-time constant
>>> ...
>>
>> Why not? I can do this in another language
>
> Because, at compile time for file2.c, file1.c is not visible, and the
> value of table_max cannot be known. Any language that allows you to do
> this does not support true separate compilation.
Well, OK, in the language I had in mind, it would be tricky to do mutual
imports and exports (file1 importing names from file2, and vice versa). But
just to do the above example, it would look like this:
In file1:
global const table_max = 100
And in file2:
import file1
which makes available 'table_max' as a compile-time constant.
It does require that file1 is compiled (or somehow processed) first. After
that, the source does not need to be visible to file2 (what's important is
the exports file created for file1, which is what is processed by the
'import' statement, but this is little different to the common header file
that C might use, if 'table_max' is to be accessed from several other
modules).
It's also possible to write:
global const table_max = a + b + c.len # a bit like sizeof(c)
where a, b and c are locals, but only table_max is exported.
This sort of stuff is fiddly to do in C. Apparently you can't even export
the size of a local array as a compile-time constant (according to a recent
thread). And most global names seem to need to be defined twice: a shared
declaration, and a definition. It seems weak on importing and exporting
(imo).
>> In any case, the language ought to provide true named constants, which
>> are
>> pretty fundamental, not expect everyone to mess around with enums,
>> defines,
>> and const attributes. Then the above won't be a problem.
>
> 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.
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)+*('!
There are one or two other things, for example a macro defined as a complex
100-term expression, used in 100 places in the code, could mean parsing
10000 tokens and evaluating the expression 100 times. A dedicated 'constant
feature would evaluate the expression once, and would occupy 100 tokens in
the code.
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.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-18 18:02 -0500 |
| Message-ID | <k8bpeq$h0m$1@dont-email.me> |
| In reply to | #28354 |
On 11/18/2012 5:45 PM, BartC wrote:
>
>
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:k8bm1u$rqm$1@dont-email.me...
>> On 11/18/2012 03:22 PM, BartC wrote:
>>> "Kenneth Brody" <kenbrody@spamcop.net> wrote in message
>>> news:k6CdnWuVpab7hDTNnZ2dnUVZ_qmdnZ2d@bestweb.net...
>
>>>> ===== file1.c
>>>>
>>>> const int table_max = 100;
>>>>
>>>> ===== file2.c
>>>>
>>>> extern const int table_max;
>>>>
>>>> .... references to "table_max" that cannot be a compile-time constant
>>>> ...
>>>
>>> Why not? I can do this in another language
>>
>> Because, at compile time for file2.c, file1.c is not visible, and the
>> value of table_max cannot be known. Any language that allows you to do
>> this does not support true separate compilation.
>
> Well, OK, in the language I had in mind, it would be tricky to do mutual
> imports and exports (file1 importing names from file2, and vice versa). But
> just to do the above example, it would look like this:
>[...]
You've missed James' point. Try this example:
/* file1.c */
const int table_max = 100;
/* file2.c */
const int table_max = 200;
/* victim.c */
extern const int table_max;
int table[table_max];
From these three files I want to make two programs: One
that links file1.o+victim.o, the other using file2.o+victim.o.
Explain how table_max is a compile-time constant in victim.
Also, I just wrote file1.c and file2.c today, but I wrote
and compiled victim.c->victim.o a month ago. Again, explain
how table_max was a compile-time constant a month before I
decided on any of the values it might someday have.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 00:04 +0000 |
| Message-ID | <QKeqs.444766$9D6.98494@fx27.am4> |
| In reply to | #28355 |
"Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
news:k8bpeq$h0m$1@dont-email.me...
> On 11/18/2012 5:45 PM, BartC wrote:
>> "James Kuyper" <jameskuyper@verizon.net> wrote in message
>>> Because, at compile time for file2.c, file1.c is not visible, and the
>> Well, OK, in the language I had in mind
>> ... it would look like this:
>>[...]
>
> You've missed James' point. Try this example:
>
> /* file1.c */
> const int table_max = 100;
>
> /* file2.c */
> const int table_max = 200;
>
> /* victim.c */
> extern const int table_max;
> int table[table_max];
>
> From these three files I want to make two programs: One
> that links file1.o+victim.o, the other using file2.o+victim.o.
> Explain how table_max is a compile-time constant in victim.
We're talking about compile-time constants, not link-time ones.
Also about something that C might be made to do, not as it is now. However
I'm assuming that this new C would need still the dimension of table[] -
table_max - to be known to the compiler.
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.
I haven't proposed any mechanism for making this selection in C. My point is
simply that it is practical. (In another language, I've just tried this on
one of my projects:
file1:
global const table_max = 100 # ('int' is implied here)
file2:
global const table_max = 200
victim (actually it's called 'test'):
import file2 # choose file2 in this instance
[table_max]int table
...
println table.len
The above translates into C code, the crux of which is
static int table[200];
printi(200);
println();
It works.)
> Also, I just wrote file1.c and file2.c today, but I wrote
> and compiled victim.c->victim.o a month ago. Again, explain
> how table_max was a compile-time constant a month before I
> decided on any of the values it might someday have.
Yes, there are still build dependencies, the same as there might be now when
you use header files:
you compiled victim.c a month ago, using a header file1.h containing some
particular function prototype which is contained in file1.c. Today you
modify the function in file1.c so that the prototype needs to change.
victim.c needs to be recompiled if you want to link it with a file1 object
file created today.
The information exported automatically in my file1/2 examples above, is
little different from manually creating a header containing the same
information (except some are harder in C, such as array dimensions).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-18 19:20 -0500 |
| Message-ID | <k8btvi$e91$1@dont-email.me> |
| In reply to | #28360 |
On 11/18/2012 07:04 PM, BartC wrote:
> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
> news:k8bpeq$h0m$1@dont-email.me...
>> On 11/18/2012 5:45 PM, BartC wrote:
>>> "James Kuyper" <jameskuyper@verizon.net> wrote in message
>
>>>> Because, at compile time for file2.c, file1.c is not visible, and the
...
>> You've missed James' point. Try this example:
>>
>> /* file1.c */
>> const int table_max = 100;
>>
>> /* file2.c */
>> const int table_max = 200;
>>
>> /* victim.c */
>> extern const int table_max;
>> int table[table_max];
>>
>> From these three files I want to make two programs: One
>> that links file1.o+victim.o, the other using file2.o+victim.o.
>> Explain how table_max is a compile-time constant in victim.
>
> We're talking about compile-time constants, not link-time ones.
Precisely. Since victim.o has already been compiled before being linked
to either file1.o of file2.o, it can't be known at compile time for
victim.o whether table_max is 100 or 200, so it is not a compile-time
constant.
> Also about something that C might be made to do, not as it is now. However
> I'm assuming that this new C would need still the dimension of table[] -
> table_max - to be known to the compiler.
>
> So when victim is compiled, it will use the current value of table_max in
> whichever file1 or file2 has been chosen.
At compile time, neither file1 nor file2 has yet been chosen. Connecting
victim.o to either file1 or file2 is part of linkage, not compilation.
> ... To create two programs with two
> different values of table_max, requires recompilation of victim in each
> case.
No, it requires linkage of victim, not recompilation.
> I haven't proposed any mechanism for making this selection in C. My point is
> simply that it is practical. (In another language, I've just tried this on
> one of my projects:
>
> file1:
> global const table_max = 100 # ('int' is implied here)
>
> file2:
> global const table_max = 200
>
> victim (actually it's called 'test'):
> import file2 # choose file2 in this instance
> [table_max]int table
If that's inside victim , then you're not doing true separate
compilation, which is precisely what I pointed out in my earlier
message. Compilation of victim requires compilation of file2.
> ...
> println table.len
>
> The above translates into C code, the crux of which is
>
> static int table[200];
>
> printi(200);
> println();
>
> It works.)
>
>> Also, I just wrote file1.c and file2.c today, but I wrote
>> and compiled victim.c->victim.o a month ago. Again, explain
>> how table_max was a compile-time constant a month before I
>> decided on any of the values it might someday have.
>
> Yes, there are still build dependencies, the same as there might be now when
> you use header files:
And a #defined macro in a C header file serves the same purpose.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 1 of 12 [1] 2 3 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web