Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #58109 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2015-03-14 23:05 +0100 |
| Last post | 2015-03-18 08:29 -0700 |
| Articles | 20 on this page of 233 — 30 participants |
Back to article view | Back to comp.lang.c
New directions in C jacob navia <jacob@spamsink.net> - 2015-03-14 23:05 +0100
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-15 13:08 +1300
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 14:49 +0100
Re: New directions in C Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-04-07 10:03 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 01:36 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 02:07 -0700
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 11:10 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 10:36 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 11:43 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 11:01 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 13:11 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 12:51 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 06:11 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 13:37 +0000
Re: New directions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 13:44 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 15:23 +0100
Re: New directions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 15:07 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 10:24 -0700
Re: New directions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 19:36 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 16:19 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-16 15:51 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 20:41 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:23 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:34 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:37 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:48 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:52 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 16:05 +0100
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-17 18:58 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-17 12:15 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-17 12:31 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 16:13 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-17 09:50 -0700
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 17:59 +0100
Re: New directions in C Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 17:16 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 18:24 +0100
Re: New directions in C Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 17:46 +0000
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 18:02 +0000
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-17 18:58 +0000
Re: New directions in C fmassei@gmail.com - 2015-03-17 13:04 -0700
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:17 -0700
Re: New directions in C Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-18 14:58 +0000
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-17 11:38 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-03-17 22:59 -0400
Re: New directions in C jacob navia <jacob@jacob.remcomp.fr> - 2015-03-18 09:05 +0100
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-03-18 08:56 -0400
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-18 10:27 +0100
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-17 09:35 -0700
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 17:44 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:11 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:14 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 05:24 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:50 +1300
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 07:21 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-17 01:50 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 21:22 +1300
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:55 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 22:08 +1300
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 07:01 -0700
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-03-16 08:27 -0400
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 13:31 +0100
Re: New directions in C Martin Shobe <martin.shobe@yahoo.com> - 2015-03-16 09:47 -0500
Re: New directions in C Kaz Kylheku <kaz@kylheku.com> - 2015-03-16 17:16 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:15 +0000
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-03-23 12:41 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 10:20 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-16 12:54 +0100
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-16 09:30 -0700
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-03-16 13:14 -0400
Jacob (Was: New directions in C) gazelle@shell.xmission.com (Kenny McCormack) - 2015-03-16 18:07 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 15:27 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-16 16:26 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 10:09 -0700
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-16 11:14 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-17 13:42 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 14:59 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:27 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:34 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 16:18 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:35 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 01:23 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-22 11:00 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-29 16:56 +0000
Re: New directions in C asetofsymbols@gmail.com - 2015-03-29 10:04 -0700
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 10:56 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-29 19:30 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 12:25 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-29 20:46 +0100
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-29 21:46 +0000
Re: New directions in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:43 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 00:33 +0200
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-06 23:13 +0000
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-07 15:46 +1200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 01:37 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-07 21:08 +1200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 02:52 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-07 11:09 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 13:18 +0200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 13:03 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 06:16 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 16:18 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 07:37 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 23:31 +0200
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-07 22:40 -0400
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-08 16:57 +1200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 09:14 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 01:52 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-08 21:36 +1200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 02:51 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-08 22:23 +1200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 13:14 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 04:27 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 14:29 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 06:01 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 15:21 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 06:44 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 16:50 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 08:19 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-08 10:55 -0700
Re: New directions in C asetofsymbols@gmail.com - 2015-04-08 22:27 -0700
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-08 11:13 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 21:27 +0200
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-08 13:12 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 09:34 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-09 00:59 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 12:31 +0200
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-09 08:41 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-08 22:48 +0100
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-08 19:03 -0500
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 10:01 +0200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 09:50 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-09 01:18 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-08 12:32 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-08 08:49 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 06:15 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-10 23:18 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-10 23:50 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-11 15:02 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-11 06:44 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-12 16:53 +0200
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-11 10:01 -0500
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-11 09:23 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-11 13:53 -0400
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-12 02:08 -0500
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-12 03:02 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-12 17:07 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-13 01:59 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-13 08:13 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-13 06:50 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-11 11:57 -0400
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-08 08:36 -0400
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 15:01 +0200
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-07 04:58 -0500
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-07 11:16 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 13:30 +0200
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-07 12:03 +0100
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-07 11:32 -0500
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-07 17:12 +0000
Re: New directions in C jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 19:41 +0200
Re: New directions in C Kaz Kylheku <kaz@kylheku.com> - 2015-03-29 18:21 +0000
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-29 21:29 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 14:26 -0700
Re: New directions in C Les Cargill <lcargill99@comcast.com> - 2015-03-29 19:10 -0500
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-30 09:48 +0000
Re: New directions in C jacob navia <jacob@jacob.remcomp.fr> - 2015-03-30 13:14 +0200
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-04-06 12:39 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-29 10:53 -0700
Re: New directions in C Michael Angelo Ravera <maravera@prodigy.net> - 2015-04-09 18:17 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 01:08 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 17:44 -0700
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-10 02:06 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 10:21 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 10:31 +0100
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 11:26 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 11:53 +0100
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 12:22 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 12:46 +0100
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 13:46 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 13:51 +0100
Re: New directions in C Steve Thompson <stevet810@gmail.com> - 2015-04-10 18:54 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 13:11 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 14:10 -0700
Re: New directions in C Steve Thompson <stevet810@gmail.com> - 2015-04-11 17:46 +0000
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-11 23:38 +0100
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 16:35 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 17:19 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-12 00:54 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-12 01:29 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 17:32 -0700
Re: New directions in C Steve Thompson <stevet810@gmail.com> - 2015-04-11 23:33 +0000
Re: New directions in C Reinhardt Behm <rbehm@hushmail.com> - 2015-04-10 09:23 -0300
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 13:31 +0100
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-10 13:29 -0500
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 12:12 -0700
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-10 13:46 -0700
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-10 18:30 -0500
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-11 12:21 -0700
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-12 01:01 -0500
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-12 13:03 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-12 23:29 +0100
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-12 18:54 -0700
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-13 00:52 -0500
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-04-13 08:39 -0400
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:02 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:07 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-17 16:09 +0100
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:19 +0000
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 18:05 +0000
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-17 15:55 +1300
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 08:48 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-17 03:01 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 10:32 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:32 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 21:33 +1300
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-18 08:55 +0000
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 22:13 +1300
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 21:31 +1300
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 09:35 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 09:49 -0700
Re: New directions in C Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-03-16 10:07 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 10:51 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 10:25 +0000
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-16 11:32 +0000
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-16 13:06 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 05:35 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-16 13:46 +0000
Re: New directions in C Kaz Kylheku <kaz@kylheku.com> - 2015-03-16 17:07 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 10:19 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:37 +1300
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 05:42 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-16 10:55 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 09:41 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-18 08:29 -0700
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-12 18:54 -0700 |
| Message-ID | <87mw2cu719.fsf@kst-u.example.com> |
| In reply to | #59940 |
Bartc <bc@freeuk.com> writes:
> On 12/04/2015 21:03, Keith Thompson wrote:
>> I agree that requiring any positional arguments to follow any named
>> arguments (in calls, not in declarations) is reasonable.
>
> Either you've made a mistake there, or I disagree that it is reasonable.
The former. Any positional arguments should *precede* any named
arguments.
[snip]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-04-13 00:52 -0500 |
| Message-ID | <kdlmialk7ba31o3mls30k1miogcnhdshc1@4ax.com> |
| In reply to | #59938 |
On Sun, 12 Apr 2015 13:03:06 -0700, Keith Thompson <kst-u@mib.org> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: >> On Sat, 11 Apr 2015 12:21:20 -0700, Keith Thompson <kst-u@mib.org> >> wrote: >[...] >>>It's quite possible I've misunderstood. In >>> >>> int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=); >>> >>>both c and d have default values, but only d has a "." in its >>>declaration. What exactly does the "." mean? >> >> That the parameter is named (keyword). IOW, the above would have >> three positional parameters, one of which is mandatory (as it has no >> default value), and three positional parameters, with one being >> mandatory. What I was envisioning was that parameters were either >> positional or named, not both. > >Saying the parameter is "named" doesn't really tell me what that >means. All 6 parameters are "named" in the sense that they have >names: a, b, c, d, e, f. > >I *think* what you mean is that if a parameter is "named", a call >may or may not use the parameter name for the associated argument, >and if it's "positional" then it may not. For example, these call: > > g(1, 2, 3, 4, 5, 6); > g(1); > g(1, 2, 3, .d=4, .e=5, .f=6); > >would be legal, but this: > > g(.a=1, .b=2, .c=3, .d=4, .e=5, .f=5); > >would not. What I don't understand is why you'd want a declaration >to be able to impose this kind of arbitrary restriction on the >caller. > >BTW, though the term "keyword parameters" is common, I suggest >avoiding it in this context, since "keyword" already has a specific >meaning. > >[...] > >> I understand, but I suspect that allowing the caller to decide will >> make for more confusing code if you allowed all parameters to be coded >> either way. > >I disagree. > >In Ada, with which I have a fair amount of experience, all parameters >have names, and the names must be consistent between declaration >and definition. There is no distinction between named and positional >parameters in a declaration; the distinction exists only for calls. > >Any call can use either positional or named notation for any >parameter. It hasn't caused any significant problems that I've seen >-- and it's simpler than what you suggest. It doesn't let library >authors arbitrarily decide what kind of notation callers may use. >It allows, but doesn't require, callers to use named notation for >added clarity. I'm just not sure that could be retrofitted into C. And I have less of an objection to allowing nominally positional parameters to be specified with a name. But if you have three or four common parameters, allowing the 30 rare ones to be specified positionally seems less than useful. But I'm not dogmatic about it - I think named/keyword parameters would be a very useful addition, especially for many of the option-rich APIs. >> OTOH, allowing positional parameters to be specified in >> keyword form is probably no problem (at least not worse than what we >> have now), although the rule should probably be something like not >> allowing any positional parameters after any keyword parameters. > >I agree that requiring any positional arguments to follow any named >arguments (in calls, not in declarations) is reasonable. > >[...] > >> One advantage of the new syntax (defining the parameter in the >> declaration with the preceding dot), is that you can enforce sane >> rules if named parameters are defined. Namely there then has to be a >> name for a named parameter, and you can insist that the names in >> multiple declaration and definitions of the function are consistent. I >> think it also avoids any incompatibilities with existing C code, >> although I'm not sure I see one if you just allow the name of a >> positional parameter to be used, except for the fact that there's no >> current need for those names to be consistent, or supplied at all - >> perhaps the rule is that if you *do* use a name for a positional >> parameter, all the declarations have to match). > >As I said, if I were designing a C-like language with named >argument support from scratch, I'd require all parameters to >be named and named consistently. Grafting this feature onto the >existing language without breaking existing code is more difficult. >I think the simplest approach would be to use the name given in >the most recent visible declaration, while specifying names for all >parameters of standard library functions (and encouraging secondary >standards like POSIX and third-party libraries to do likewise). > >Macros would be a problem. Any standard library function can be >implemented as a macro. That means any call using named arguments >would become invalid -- unless macro call syntax is also updated to >allow named arguments. Macro definitions already specify parameter >names; we'd just need to allow macro invocations to use those names. >This could break some existing code; this: > > MACRO(.name=value) > >is currently valid, and this feature would change its meaning. > >Of course, like any new language feature, introducing it in a new >standard will cause problems for programmers, who won't be able to >use it unless they can guarantee that their code will be used only >with compilers that support it. On the other hand, the same was >true for designators in initializers, which were added in C99 for >much the same reason. I hadn't thought about the macro issues. Still I suspect named/keyword parameters (whatever we decide to call them) haven't a prayer of making it past the C committee, and while I don't think the odd on the C++ side are great, I think they're substantially better there. I am often baffled by what the C (and C++) committees find useful. Some simple, and generally usefully stuff that doesn't break anything, (named breaks and continues for breaking out of nested loops and binary literals*, to name two), gets resoundingly ignored, while we get things like VLAs (which I can certainly see a use case for, but it's somewhat small). C'est la vie. *Really, there was some urgent real world requirements for hex FP literals??
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-04-13 08:39 -0400 |
| Message-ID | <mggdcb$o52$1@dont-email.me> |
| In reply to | #59943 |
On 04/13/2015 01:52 AM, Robert Wessel wrote: ... > *Really, there was some urgent real world requirements for hex FP > literals?? Yes. Note the promise made by the last sentence of 6.4.4.2p3: "For decimal floating constants, and also for hexadecimal floating constants when FLT_RADIX is not a power of 2, the result is either the nearest representable value, or the larger or smaller representable value immediately adjacent to the nearest representable value, chosen in an implementation-defined manner. For hexadecimal floating constants when FLT_RADIX is a power of 2, the result is correctly rounded." "Correctly rounded" is a promise of some considerable value when doing high-precision numerical work (it's of less importance in most practical uses of floating point values that represent measurements, since those seldom strain the precision limits on 'double'). No comparable promise has ever applied to decimal floating point constants, regardless of the value of FLT_RADIX (it obviously could be applied when FLT_RADIX is a power of 10 - but the committee decided not to impose such a requirement). -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2015-03-17 15:02 +0100 |
| Message-ID | <me9c5l$j5p$2@speranza.aioe.org> |
| In reply to | #58283 |
Le 17/03/2015 13:42, David Brown a écrit : > I have no problem with Jacob's extended language - but I think it would > make sense to give it another name. Even "Extended C" would be fine. > He has already made it clear that he thinks the C committee is too slow > and conservative (and I don't think that's an unreasonable position) - > his changes go beyond C to make a new language. I have taken care of staying within STANDARD C (1999). Note that the C standard does NOT forbid extensions. The only thing you should never do is to insert new keywords into the language. Please read the standard before yuo start screaming "It is not C".
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2015-03-17 15:07 +0100 |
| Message-ID | <me9ce8$kgi$1@speranza.aioe.org> |
| In reply to | #58283 |
Le 17/03/2015 13:42, David Brown a écrit : > Promoting ideas here is fine. But this is not a commercial newsgroup, > and promoting a commercial product is not appropriate. Promoting a > free, limited version of a commercial product is more of a grey area, > and is probably okay if it is specific to the topic being discussed. As long as it is GNU it is OK. When somebody starts working against GNU, as I do, and refuses to give years of work to some corporation it is FORBIDDEN, OFF TOPIC, RIDICULOUS, etc. Red Hat Corp is selling the work of hundreds of people that gave their work for free. None of those guys receives a penny from Red Hat Corp. When gcc folks charge US$ 25000 to answer a question for about gcc obviously they are not doing it in a commercial context. :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-17 16:09 +0100 |
| Message-ID | <me9g1e$5og$1@dont-email.me> |
| In reply to | #58292 |
On 17/03/15 15:07, jacob navia wrote: > Le 17/03/2015 13:42, David Brown a écrit : >> Promoting ideas here is fine. But this is not a commercial newsgroup, >> and promoting a commercial product is not appropriate. Promoting a >> free, limited version of a commercial product is more of a grey area, >> and is probably okay if it is specific to the topic being discussed. > > > As long as it is GNU it is OK. When somebody starts working against GNU, > as I do, and refuses to give years of work to some corporation it is > FORBIDDEN, OFF TOPIC, RIDICULOUS, etc. People in this group use a wide variety of compilers. gcc is often used as "the reference compiler", simply because lots of people have it, and those that don't have it can easily get it (for zero cost). It is also a pretty good compiler, and does a reasonable (but not perfect) job of supporting all current C standards. Details of /any/ compiler, gcc or otherwise, is off-topic for the most pedantic group members - others are happy with it for a short threads. More serious compiler-specific help should be directed to other arenas. > > Red Hat Corp is selling the work of hundreds of people that gave their > work for free. None of those guys receives a penny from Red Hat Corp. Now you are /really/ getting off topic! But Red Hat makes money selling the packaging of their systems and tools, and selling support for them. They do an extraordinary amount of work in order to put together their distributions, and almost everything they produce is available under the GPL - even though other distributions are able to simply copy Red Hat's effort and re-sell it (or give it away for free). They are major contributors to a range of packages and parts of a typical Linux system, including the kernel, libraries, and toolchains. Some feel they do /too much/ work here, and dominate particular areas (such as Gnome and systemd). But given that Red Hat is a major force behind the development of gcc and related tools, claiming that Red Hat is "all take and no give" shows a total and complete lack of understanding of how open source development works. > > When gcc folks charge US$ 25000 to answer a question for about gcc > obviously they are not doing it in a commercial context. > I have had many questions answered by gcc developers, none of which have charged me. There are certainly companies (and individuals) happy to sell support contracts for gcc - Red Hat, CodeSourcery (now part of Mentor Graphics), etc., will do that. They provide a service, and charge for it (though not at 25K$ per question). But you'll not get any bills for asking questions on the gcc mailing lists. However, contrary to your beliefs, c.l.c. is not a gcc promoter - details of gcc-specific issues are neither more nor less on-topic than specifics of lcc. In either case, occasional small threads are fine, but we don't want any particular compiler to dominate. > > :-) > I hope you really are as smiley as that - you don't always sound it in your posts!
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-03-21 22:19 +0000 |
| Message-ID | <550ded70.35291203@news.xs4all.nl> |
| In reply to | #58283 |
David Brown <david.brown@hesbynett.no> wrote: > On 16/03/15 18:09, Malcolm McLean wrote: > > On Monday, March 16, 2015 at 3:26:47 PM UTC, David Brown wrote: > >> > >> But like most people here, I would far rather see you be honest and > >> accurate when describing your tools and their licensing, and I would > >> prefer if you dropped your paranoia about a c.l.c. conspiracy against > >> you, your ideas, and your products. > >> > > To be fair, Jacob is sometimes ridiculed. > > (Just to be clear here - the discussion here is only in regard to > on-topic threads about C. Any ridicule or flames for off-topic subjects > is incidental here.) > > I've seen mostly fairly polite, but firm, disagreement with Jacob - > ridicule is, I think, very rare. But I accept Kenny's argument that > language or cultural differences may make a post seem stronger or > insulting, when it was not aimed in that way. For example, it is not > uncommon for Brits to use sarcasm in a light-hearted manner, when other > readers take it more seriously. That would be a reasonable argument, except that: a. he is not the only non-native speaker in this group, but he is the only one who interprets these arguments as "insults"; b. he himself has attempted - to be honest, poorly - to use sarcasm himself, so he at least knows what it is. _His_ attempts at sarcasm are almost always more directly insulting than anyone else's aimed at him. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-16 18:05 +0000 |
| Message-ID | <me75uu$8qh$1@dont-email.me> |
| In reply to | #58204 |
On 16/03/15 14:27, jacob navia wrote: > Le 16/03/2015 11:36, Richard Heathfield a écrit : >> But "insulted"? I think you need to back up that claim if you wish >> people to believe it, because it is a most extraordinary claim - why >> would anyone insult an implementor for implementing C99? > > Mr "teapot", and all the anonymous trolls that were stalking me for years? Were you insulted by the trolls? Sure. (Who hasn't been?) But were you insulted for implementing C99, as you claimed? I doubt it very much. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-17 15:55 +1300 |
| Message-ID | <cmpjcgF5dq2U1@mid.individual.net> |
| In reply to | #58169 |
Richard Heathfield wrote: > If they want the STL, sure they should use C++. The STL is a C++ > library. This is why we have different languages - so that people get > the freedom to make these kinds of choices. Yes, it's true that C++ has > STL and C doesn't, but that doesn't mean that we need to add STL to C. > Rather, it means we get to choose whether we wish to use a language with > STL or a language without it. The pay-off for not having STL is > decreased complexity. Less complexity in the language for sure, but the complexity is still there in the the problem you would use the C++ standard library to solve. I simply don't buy the "decreased complexity" argument. C may be a less complex language, but this inevitably leads to more complex solutions. A recent discussion on reading a file of unknown length into a buffer was a a good illustration of this. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-17 08:48 +0000 |
| Message-ID | <me8pn1$fn1$1@dont-email.me> |
| In reply to | #58264 |
On 17/03/15 02:55, Ian Collins wrote: > Richard Heathfield wrote: > >> If they want the STL, sure they should use C++. The STL is a C++ >> library. This is why we have different languages - so that people get >> the freedom to make these kinds of choices. Yes, it's true that C++ has >> STL and C doesn't, but that doesn't mean that we need to add STL to C. >> Rather, it means we get to choose whether we wish to use a language with >> STL or a language without it. The pay-off for not having STL is >> decreased complexity. > > Less complexity in the language for sure, but the complexity is still > there in the the problem you would use the C++ standard library to solve. That's not necessarily true, but I will grant that it is often true. Thing is, you get the choice. > I simply don't buy the "decreased complexity" argument. C may be a less > complex language, but this inevitably leads to more complex solutions. I *like* complex solutions, as long as it's *my* complexity, not the language's complexity. I like a simple, powerful language that I can use to do big, complicated things in a way that I know will work exactly the way I want it to. Now, obviously not everybody will see things the same way that I do, but *they* can use C++, can't they? > A recent discussion on reading a file of unknown length into a buffer > was a a good illustration of this. Well, personally I don't think reading a file of unknown length into a buffer is all that complicated a task. (And yes, I remember the discussion.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-17 03:01 -0700 |
| Message-ID | <bb41e4d4-2971-4093-839c-01f1f2f7503e@googlegroups.com> |
| In reply to | #58272 |
On Tuesday, March 17, 2015 at 8:48:27 AM UTC, Richard Heathfield wrote: > On 17/03/15 02:55, Ian Collins wrote: > > Well, personally I don't think reading a file of unknown length into a > buffer is all that complicated a task. (And yes, I remember the discussion.) > C doesn't let you find the length of the file, and it forces you to decide your own allocation strategy. So it's one of those things which is easy to do on most platforms if you are specifically targeting that platform. It's simply lock file, query file length, allocate memory, fail on out of memory, read file into buffer, unlock file, return buffer and length to caller. It's hard to write a portable, general-purpose function in pure ANSI C.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-17 10:32 +0000 |
| Message-ID | <me8vqq$54v$1@dont-email.me> |
| In reply to | #58275 |
On 17/03/15 10:01, Malcolm McLean wrote: > On Tuesday, March 17, 2015 at 8:48:27 AM UTC, Richard Heathfield wrote: >> On 17/03/15 02:55, Ian Collins wrote: >> >> Well, personally I don't think reading a file of unknown length into a >> buffer is all that complicated a task. (And yes, I remember the discussion.) >> > C doesn't let you find the length of the file, Oh yes it does. (To be more precise, it lets me find how much data I can read from the file, which amounts to the same thing from my perspective, modulo ferror().) > and it forces you to decide your own > allocation strategy. s/forces/allows/ - it's something I'd *prefer* to decide for myself, and C allows me to do that. That's good, not bad. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-18 01:32 -0700 |
| Message-ID | <f91c654a-4741-4f9c-b334-747c432b9a9b@googlegroups.com> |
| In reply to | #58276 |
On Tuesday, March 17, 2015 at 10:32:58 AM UTC, Richard Heathfield wrote: > On 17/03/15 10:01, Malcolm McLean wrote: > > > > and it forces you to decide your own > > allocation strategy. > > s/forces/allows/ - it's something I'd *prefer* to decide for myself, and > C allows me to do that. That's good, not bad. > But you're not necessarily the programmer who calls the code, and you don't necessarily know the context. On a typical desktop system, a reasonable strategy is to allocate a chunk of memory, then increment by 50% every time the input goes over the limit. That strikes a reasonable balance between number of allocation calls and excess memory usage. But if you're writing for a hosted but non-general purpose computer you might well know the hard limit on allocation size, so it makes sense to code this in, especially if many input files are close to the hard limit, which might often be the case if, for example, they are game levels and the main program is a trivial level loader/ driver. But if the game runs on both PCs and consoles, and for some reason the load routines can't just be rewritten, it's better to have a higher-level "loadfile" interface.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-18 21:33 +1300 |
| Message-ID | <cmsri2FqupfU3@mid.individual.net> |
| In reply to | #58276 |
Richard Heathfield wrote: > On 17/03/15 10:01, Malcolm McLean wrote: >> On Tuesday, March 17, 2015 at 8:48:27 AM UTC, Richard Heathfield wrote: >>> On 17/03/15 02:55, Ian Collins wrote: >>> >>> Well, personally I don't think reading a file of unknown length into a >>> buffer is all that complicated a task. (And yes, I remember the discussion.) >>> >> C doesn't let you find the length of the file, > > Oh yes it does. (To be more precise, it lets me find how much data I can > read from the file, which amounts to the same thing from my perspective, > modulo ferror().) Unless the "file" doesn't have a size, such as a terminal input. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-18 08:55 +0000 |
| Message-ID | <mebeha$ohg$1@dont-email.me> |
| In reply to | #58395 |
On 18/03/15 08:33, Ian Collins wrote: > Richard Heathfield wrote: >> On 17/03/15 10:01, Malcolm McLean wrote: >>> On Tuesday, March 17, 2015 at 8:48:27 AM UTC, Richard Heathfield wrote: >>>> On 17/03/15 02:55, Ian Collins wrote: >>>> >>>> Well, personally I don't think reading a file of unknown length into a >>>> buffer is all that complicated a task. (And yes, I remember the discussion.) >>>> >>> C doesn't let you find the length of the file, >> >> Oh yes it does. (To be more precise, it lets me find how much data I can >> read from the file, which amounts to the same thing from my perspective, >> modulo ferror().) > > Unless the "file" doesn't have a size, such as a terminal input. That's true, but irrelevant. If the application is intended to process terminal input, it makes little sense to me to seek information about how much information will eventually be typed. By its very nature, the data stream is unbounded (and the same applies no matter what language or library one is using). -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-18 22:13 +1300 |
| Message-ID | <cmsttsFqupfU5@mid.individual.net> |
| In reply to | #58398 |
Richard Heathfield wrote: > On 18/03/15 08:33, Ian Collins wrote: >> Richard Heathfield wrote: >>> On 17/03/15 10:01, Malcolm McLean wrote: >>>> On Tuesday, March 17, 2015 at 8:48:27 AM UTC, Richard Heathfield wrote: >>>>> On 17/03/15 02:55, Ian Collins wrote: >>>>> >>>>> Well, personally I don't think reading a file of unknown length into a >>>>> buffer is all that complicated a task. (And yes, I remember the discussion.) >>>>> >>>> C doesn't let you find the length of the file, >>> >>> Oh yes it does. (To be more precise, it lets me find how much data I can >>> read from the file, which amounts to the same thing from my perspective, >>> modulo ferror().) >> >> Unless the "file" doesn't have a size, such as a terminal input. > > That's true, but irrelevant. If the application is intended to process > terminal input, it makes little sense to me to seek information about > how much information will eventually be typed. By its very nature, the > data stream is unbounded (and the same applies no matter what language > or library one is using). That right, but if the language's box of tricks contains standard flexible containers, the solution (and test) complexity is significantly reduced. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-18 21:31 +1300 |
| Message-ID | <cmsrehFqupfU2@mid.individual.net> |
| In reply to | #58272 |
Richard Heathfield wrote: > On 17/03/15 02:55, Ian Collins wrote: >> Richard Heathfield wrote: >> >>> If they want the STL, sure they should use C++. The STL is a C++ >>> library. This is why we have different languages - so that people get >>> the freedom to make these kinds of choices. Yes, it's true that C++ has >>> STL and C doesn't, but that doesn't mean that we need to add STL to C. >>> Rather, it means we get to choose whether we wish to use a language with >>> STL or a language without it. The pay-off for not having STL is >>> decreased complexity. >> >> Less complexity in the language for sure, but the complexity is still >> there in the the problem you would use the C++ standard library to solve. > > That's not necessarily true, but I will grant that it is often true. > Thing is, you get the choice. As you do in C++, only one seldom takes the wheel reinventing path. >> I simply don't buy the "decreased complexity" argument. C may be a less >> complex language, but this inevitably leads to more complex solutions. > > I *like* complex solutions, as long as it's *my* complexity, not the > language's complexity. I like a simple, powerful language that I can use > to do big, complicated things in a way that I know will work exactly the > way I want it to. Now, obviously not everybody will see things the same > way that I do, but *they* can use C++, can't they? From my perspective I don't like the additional testing overhead of a complex solution... The less code I have to write, the fewer tests I have to write, the faster I get the job done and get paid. >> A recent discussion on reading a file of unknown length into a buffer >> was a a good illustration of this. > > Well, personally I don't think reading a file of unknown length into a > buffer is all that complicated a task. (And yes, I remember the discussion.) That depends which language you are using :) -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-16 09:35 -0700 |
| Message-ID | <77729e8b-46d1-4851-9d5f-90c4452e7abb@googlegroups.com> |
| In reply to | #58167 |
W dniu poniedziałek, 16 marca 2015 11:11:06 UTC+1 użytkownik jacob navia napisał: > I have been working with this program the last 20 years. > > I implemented the C99 standard, and was insulted to no end by the > regulars here because "C99 was not portable", the only standard they > would accept was the C89 standard of 1989. > > I have implemented a replica of the STL in plain C. I presented it tothe > committee in Portland. It was rejected after a small discussion of one > hour. People should use C++. > > Here, you are the only one that somehow has said anything with meaning. > But you represent the current view in thisnewsgroup when you say: > > <quote> > such 'directions' (changes) are not in the natural spirit of c, so imo > this IS NOT C,, > thus those are not new directions in c > <end quote> nono, I appericiate/prize your work if youre the man who made lcc-win (I probably even used it (briefly and i dont remember but made some test with it in some winapi progs) and i know it is somewhat known and probably nice compiler, youre solely wrote it? made port to winapi? [if you got a time you coul say a bit more what this work was like] but as you spend 20 yeras on this i spend 15 on deep thinking on c ground rules and 'spirit' (the thing that makes c language and tehnology so special and amazing etc] and here i feel i know what im saying (at least "what i have on my mind") you could call it a set of "additions or improvements in c" but iMO personally those additions break some terrific rules of c spirit and imo are lower level than original c [they are for example worse then my C2 theoretic work, things like acces to the other funstions statics, or e,f,g = a,g,f; general redesign to allow x, y = foo(), adhoc enums, resizable arrays, and other 'weird' and unique stuff of my invention ;o] I am even not sure if my C2 stuff is on a wuality level of original c, I just mean that obtaining the quality level of oryginal c is 'hard' (wonder if i should 'ship' my own C2 solutions into working life.. not sure if i should do that becouse thing is not finished.. but maybe.. if so you could maybe implement some of my solutions and i would geat a plesaure of testing it when work (but as i said i am not sure as to this if they should be shipped or if i just should worm more on this at all, hard decisions and no clue which way is better)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-16 09:49 -0700 |
| Message-ID | <403a1ab1-b0bf-48f7-8b0c-1fe764be124a@googlegroups.com> |
| In reply to | #58167 |
W dniu poniedziałek, 16 marca 2015 11:11:06 UTC+1 użytkownik jacob navia napisał: > > Here, you are the only one that somehow has said anything with meaning. tnx, ye my thoughts on c improvements are valuable (though recently, three month or so im am so sick of programming that i do not do nothing at all) besides youre a bit 'oversensitive' this group is not so bad, i mean it has both kinds of energy bad and good, filter out bad focus on good to discuss/rethink something (that is what im doing)
[toc] | [prev] | [next] | [standalone]
| From | Lőrinczy Zsigmond <zsiga@nospam.for.me> |
|---|---|
| Date | 2015-03-16 10:07 +0100 |
| Message-ID | <me66gf$2v1$1@speranza.aioe.org> |
| In reply to | #58109 |
On 2015-03-14 23:05, jacob navia wrote: > This is the first of a series of messages here I propose to discuss the > developments/enhancements to C in lcc-win. Don't call this C language. Pick a character, a create a new name, eg: C^ or C%
[toc] | [prev] | [next] | [standalone]
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web