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 244 — 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 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-18 00:45 +0000
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 raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:14 +0000
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-15 09:12 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-15 07:33 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-16 22:03 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-17 04:00 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-18 17:26 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-19 09:46 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:38 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:16 +0000
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 Robert Wessel <robertwessel2@yahoo.com> - 2015-04-14 02:44 -0500
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 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2015-04-10 09:23 -0300 |
| Message-ID | <mg8fa4$td3$2@dont-email.me> |
| In reply to | #59872 |
Richard Heathfield wrote: > On 10/04/15 11:26, Bartc wrote: >> On 10/04/2015 10:31, Richard Heathfield wrote: >>> On 10/04/15 10:06, Malcolm McLean wrote: >> >>>> I'd fold default and named arguments together. >>> >>> Obviously you enjoy typing. :-) >> >>>> stdev(population = true, x = sample, N = 50); >>> >>> If you like typing that much, you could do this: >> .... >> >> Actually it can save typing, as you can do this: >> >> callfn(file:f); >> >> instead of: >> >> callfn(0, 0, 0, NULL, 1, 0, 1, 1, f, NULL); > > That's crying out to be made a struct pointer argument, which reduces it > to: > > callfn(f, NULL); > > without changing the language. That example is not language problem but a design problem. A function that needs that many parameters, even if hidden in some struct (the MS way of creating unusable APIs) shows lack of clear design. > >> >> But the real advantage is not having to count along to see if you've put >> the f in the right place. Not only writing it, but also reading it to >> see what exactly is being passed. > > See above. > >> >> It can also save typing, and become self-documenting, in calls like this: >> >> initwindow(width:640, height:480); >> >> instead of: >> >> initwindow(640, 480); > > That doesn't really save typing as such, does it? As for > self-documentation, how about initwindowxy(640, 480); ? > >> >> which, because bare constants are undesirable, really demands to be >> written as: >> >> #define window_with 640 > > I think you may have caught the 'drop d' virus from Malcolm. > >> #define window_height 480 >> >> initwindow(window_width, window_height); > > I don't see why these are macros. Surely, if you're going to have a > fixed size for the window's width and height, initwindow will already > know these sizes. So you can save even more typing, again without having > to change the language, because you don't have to pass any arguments at > all! > -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-10 13:31 +0100 |
| Message-ID | <mg8fou$vrt$1@dont-email.me> |
| In reply to | #59876 |
On 10/04/15 13:23, Reinhardt Behm wrote: > Richard Heathfield wrote: > >> On 10/04/15 11:26, Bartc wrote: <snip> >>> Actually it can save typing, as you can do this: >>> >>> callfn(file:f); >>> >>> instead of: >>> >>> callfn(0, 0, 0, NULL, 1, 0, 1, 1, f, NULL); >> >> That's crying out to be made a struct pointer argument, which reduces it >> to: >> >> callfn(f, NULL); >> >> without changing the language. > > That example is not language problem but a design problem. A function that > needs that many parameters, even if hidden in some struct (the MS way of > creating unusable APIs) shows lack of clear design. I agree that the example suggests a poor design, but I'm not so sure I agree that a function that needs a lot of information to do its job is *necessarily* a poorly-designed function. It might be, of course, but it may simply be that that's the nature of the problem. The usual way of simplifying a complicated function is to re-factor it so that it calls several simpler functions. These simpler functions, however, will between them still need all the information that the more complicated function needed, and so there is no real win in terms of information-passing. Yes, you could re-design your program so that the complicated function (with its need for a plethora of data, either via many parameters or via a struct pointer) isn't needed after all, but that is likely to be at the cost of smearing the complications over the rest of the code base, which isn't necessarily an improvement. <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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-04-10 13:29 -0500 |
| Message-ID | <0f5gia1o9m21r551bjmvep53keoj2oed6e@4ax.com> |
| In reply to | #59868 |
On Fri, 10 Apr 2015 02:06:54 -0700 (PDT), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:
>On Friday, April 10, 2015 at 2:17:44 AM UTC+1, Michael Angelo Ravera wrote:
>>
>> I would wholesale adopt C++'s syntax for some things (like default arguments). I would like a
>> new syntax for "sparse" or "named" arguments. This currently isn't available either in C or C++.
>>
>I'd fold default and named arguments together.
>
>double stdev(double *x, int N, bool population = true)
>{
> /* do sample or population deviation depending on flag */
>}
>
>/* call for population */
>stdev(everyone, 7000000000);
>
>/* compulsory named argument for non-default */
>stdev(sample, 50, population = false);
>
>/* permitted if you insist */
>stdev(population = true, x = sample, N = 50);
I think this was discussed in these parts a few months ago. I was
suggesting something more like:
int f(int a, int b=5, int c=6; int .d=1, int .e=2);
Which would have three positional parameters, with the latter two
optional, and two keyword parameters.
Which could be called with:
f(1)
f(1, 2)
f(1, .e=9)
f(1, 2, 3, .e=8)
f(1, 3, .d=6)
etc.
You could also have mandatory keyword parameters with something like:
int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=);
Where the f= keyword parameter is mandatory.
(And that was based on other ideas in the thread.)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-10 12:12 -0700 |
| Message-ID | <38bc3119-b264-4052-9546-c79c7c55aa68@googlegroups.com> |
| In reply to | #59883 |
W dniu piątek, 10 kwietnia 2015 20:29:05 UTC+2 użytkownik robert...@yahoo.com napisał:
> On Fri, 10 Apr 2015 02:06:54 -0700 (PDT), Malcolm McLean
> <malcolm.mclean5@btinternet.com> wrote:
>
> >On Friday, April 10, 2015 at 2:17:44 AM UTC+1, Michael Angelo Ravera wrote:
> >>
> >> I would wholesale adopt C++'s syntax for some things (like default arguments). I would like a
> >> new syntax for "sparse" or "named" arguments. This currently isn't available either in C or C++.
> >>
> >I'd fold default and named arguments together.
> >
> >double stdev(double *x, int N, bool population = true)
> >{
> > /* do sample or population deviation depending on flag */
> >}
> >
> >/* call for population */
> >stdev(everyone, 7000000000);
> >
> >/* compulsory named argument for non-default */
> >stdev(sample, 50, population = false);
> >
> >/* permitted if you insist */
> >stdev(population = true, x = sample, N = 50);
>
>
> I think this was discussed in these parts a few months ago. I was
> suggesting something more like:
>
> int f(int a, int b=5, int c=6; int .d=1, int .e=2);
>
> Which would have three positional parameters, with the latter two
> optional, and two keyword parameters.
>
> Which could be called with:
>
> f(1)
> f(1, 2)
> f(1, .e=9)
> f(1, 2, 3, .e=8)
> f(1, 3, .d=6)
>
> etc.
>
> You could also have mandatory keyword parameters with something like:
>
> int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=);
>
> Where the f= keyword parameter is mandatory.
>
> (And that was based on other ideas in the thread.)
this was all heavy discussed already
(no to much clear conclusions do appear imo)
imo the conclusion (of mayself maybe)
was nming parameters 1) seem usefull
2) but styllistically it all looks a but like
viusal basic or delphi etc (those long syntax with plenty of ='s, this all possible permutations of called arguments, etc)
probably a bit better (and easier to adopt to c style) look would have the syntax without =
memset(destination d, source s)
?
also not sure if all permutations shpuld be
allowed or at least treated equall (this brings both some good and some bad)
(this one limited form carries the most valuable thing here it is annotative values,
the other ones related to permutations/wariations are somewhat minor and somewhat more dangerous too)
3) the default args as they are done in c++
are a bit out of binary spirit of c imo
[so as to me right now i would limit myself
to considering the first more safer form, with no wariations of args - may be considered later)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-10 13:46 -0700 |
| Message-ID | <878udzvhij.fsf@kst-u.example.com> |
| In reply to | #59883 |
Robert Wessel <robertwessel2@yahoo.com> writes:
[...]
> I think this was discussed in these parts a few months ago. I was
> suggesting something more like:
>
> int f(int a, int b=5, int c=6; int .d=1, int .e=2);
>
> Which would have three positional parameters, with the latter two
> optional, and two keyword parameters.
>
> Which could be called with:
>
> f(1)
> f(1, 2)
> f(1, .e=9)
> f(1, 2, 3, .e=8)
> f(1, 3, .d=6)
>
> etc.
>
> You could also have mandatory keyword parameters with something like:
>
> int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=);
>
> Where the f= keyword parameter is mandatory.
>
> (And that was based on other ideas in the thread.)
In your design, using parameter names in argument lists (I hesitate
to refer to them as "keywords", because that already means something)
may be mandatory, optional, or forbidden, depending on how the
prototype is written.
I'd prefer to leave that choice up to the caller. Letting a function
declaration impose constraints on callers just seems unnecessary.
I'd suggest something a bit simpler:
int f(int a, int b=5, int c=6);
Any of the arguments may be passed with or without a parameter name.
A caller *must* pass a value for `a` explicitly, because it has no
default value. A call using pure positional notation is always
permitted. In a call, all named arguments (if any) must follow
all positional arguments (if any).
Valid calls would include:
f(40) /* Equivalent to f(40, 5, 6) */
f(40, 50, 60) /* Calls below are equivalent to this one */
f(40, 50, .c = 60);
f(40, .c = 60)
f(.a = 40, .b = 50, .c = 60)
f(.c = 60, .b = 50, .a = 40)
There's still the problem of defining canonical names for parameters;
currently parameter names in prototypes are ignored, and may be omitted.
I think we'd still have to permit prototypes without parameter names for
backward compatibility. Given:
int f(int, int, int);
you just couldn't use names in arguments.
Presumably the default value expressions would have to be constant, and
would have to be convertible to the parameter type. For example, this:
void foo(int n = 1.5);
would be legal (but silly), and equivalent to:
void foo(int n = 1);
This is somewhat inspired by the way Ada does default parameters, though
with different syntax. I haven't looked closely at how C++ does this;
if C adds this functionality, it probably shouldn't be *too* different
from C++.
--
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-10 18:30 -0500 |
| Message-ID | <ldmgiaheloq56tng7heu5m55ub9epfuo3t@4ax.com> |
| In reply to | #59887 |
On Fri, 10 Apr 2015 13:46:12 -0700, Keith Thompson <kst-u@mib.org> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: >[...] >> I think this was discussed in these parts a few months ago. I was >> suggesting something more like: >> >> int f(int a, int b=5, int c=6; int .d=1, int .e=2); >> >> Which would have three positional parameters, with the latter two >> optional, and two keyword parameters. >> >> Which could be called with: >> >> f(1) >> f(1, 2) >> f(1, .e=9) >> f(1, 2, 3, .e=8) >> f(1, 3, .d=6) >> >> etc. >> >> You could also have mandatory keyword parameters with something like: >> >> int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=); >> >> Where the f= keyword parameter is mandatory. >> >> (And that was based on other ideas in the thread.) > >In your design, using parameter names in argument lists (I hesitate >to refer to them as "keywords", because that already means something) >may be mandatory, optional, or forbidden, depending on how the >prototype is written. > >I'd prefer to leave that choice up to the caller. Letting a function >declaration impose constraints on callers just seems unnecessary. I think you're reading a bit too much into that - a parameter is mandatory if it doesn't have a default value. As a note, it might be best to omit the equal sign for the named parameter if no default value exists (so just "int .f"). >I'd suggest something a bit simpler: > > int f(int a, int b=5, int c=6); > >Any of the arguments may be passed with or without a parameter name. >A caller *must* pass a value for `a` explicitly, because it has no >default value. A call using pure positional notation is always >permitted. In a call, all named arguments (if any) must follow >all positional arguments (if any). > >Valid calls would include: > > f(40) /* Equivalent to f(40, 5, 6) */ > f(40, 50, 60) /* Calls below are equivalent to this one */ > f(40, 50, .c = 60); > f(40, .c = 60) > f(.a = 40, .b = 50, .c = 60) > f(.c = 60, .b = 50, .a = 40) I'm not sure that you'd really want the flexibility to make parameters optionally named (I think the distinction is useful), but conceptually I'd have no huge objection. There are some corner cases where you might specify the second of three parameters with a keyword, which raises the issue of whether or not you could then specify the third parameter positionally. >There's still the problem of defining canonical names for parameters; >currently parameter names in prototypes are ignored, and may be omitted. >I think we'd still have to permit prototypes without parameter names for >backward compatibility. Given: > > int f(int, int, int); > >you just couldn't use names in arguments. Using the new syntax makes the specification of the parameter names explicit, rather than implicit. And the above would be treated just as it is now. >Presumably the default value expressions would have to be constant, and >would have to be convertible to the parameter type. For example, this: > > void foo(int n = 1.5); > >would be legal (but silly), and equivalent to: > > void foo(int n = 1); > >This is somewhat inspired by the way Ada does default parameters, though >with different syntax. I haven't looked closely at how C++ does this; >if C adds this functionality, it probably shouldn't be *too* different >from C++. The specification of the defaults follows C++'s. The dots in the declaration and the syntax for the names would be new.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-11 12:21 -0700 |
| Message-ID | <874momv5cf.fsf@kst-u.example.com> |
| In reply to | #59895 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Fri, 10 Apr 2015 13:46:12 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>[...]
>>> I think this was discussed in these parts a few months ago. I was
>>> suggesting something more like:
>>>
>>> int f(int a, int b=5, int c=6; int .d=1, int .e=2);
>>>
>>> Which would have three positional parameters, with the latter two
>>> optional, and two keyword parameters.
>>>
>>> Which could be called with:
>>>
>>> f(1)
>>> f(1, 2)
>>> f(1, .e=9)
>>> f(1, 2, 3, .e=8)
>>> f(1, 3, .d=6)
>>>
>>> etc.
>>>
>>> You could also have mandatory keyword parameters with something like:
>>>
>>> int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=);
>>>
>>> Where the f= keyword parameter is mandatory.
>>>
>>> (And that was based on other ideas in the thread.)
>>
>>In your design, using parameter names in argument lists (I hesitate
>>to refer to them as "keywords", because that already means something)
>>may be mandatory, optional, or forbidden, depending on how the
>>prototype is written.
>>
>>I'd prefer to leave that choice up to the caller. Letting a function
>>declaration impose constraints on callers just seems unnecessary.
>
>
> I think you're reading a bit too much into that - a parameter is
> mandatory if it doesn't have a default value.
>
> As a note, it might be best to omit the equal sign for the named
> parameter if no default value exists (so just "int .f").
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?
In a function call, there are (potentially) two choices for each
parameter: whether to specify it, and whether to use its name. I think
we agree that specifying it is mandatory if it doesn't have a default
value, optional if it does. In the model I'm suggesting, using its name
(`.c = 42` vs. just `42`) should be left entirely at the discretion of
the caller, assuming the declaration provides a name.
>>I'd suggest something a bit simpler:
>>
>> int f(int a, int b=5, int c=6);
>>
>>Any of the arguments may be passed with or without a parameter name.
>>A caller *must* pass a value for `a` explicitly, because it has no
>>default value. A call using pure positional notation is always
>>permitted. In a call, all named arguments (if any) must follow
>>all positional arguments (if any).
>>
>>Valid calls would include:
>>
>> f(40) /* Equivalent to f(40, 5, 6) */
>> f(40, 50, 60) /* Calls below are equivalent to this one */
>> f(40, 50, .c = 60);
>> f(40, .c = 60)
>> f(.a = 40, .b = 50, .c = 60)
>> f(.c = 60, .b = 50, .a = 40)
>
>
> I'm not sure that you'd really want the flexibility to make parameters
> optionally named (I think the distinction is useful), but conceptually
> I'd have no huge objection. There are some corner cases where you
> might specify the second of three parameters with a keyword, which
> raises the issue of whether or not you could then specify the third
> parameter positionally.
Sure, you could define rigorous rules that determine what something like
func(10, .param = 20, 30)
means and when it's permitted. The 30 could apply to the 3rd parameter,
to the next parameter that hasn't already been specified, or to the
parameter following `param`. It's not obvious to me that any of those
choices is the best. My own preference is just not to allow that.
>>There's still the problem of defining canonical names for parameters;
>>currently parameter names in prototypes are ignored, and may be omitted.
>>I think we'd still have to permit prototypes without parameter names for
>>backward compatibility. Given:
>>
>> int f(int, int, int);
>>
>>you just couldn't use names in arguments.
>
>
> Using the new syntax makes the specification of the parameter names
> explicit, rather than implicit. And the above would be treated just
> as it is now.
If I were designing a C-like language from scratch, names for parameters
would be mandatory and would have to be consistent across all
definitions and declarations. But there's too much code that declares
functions without naming their parameters for that to be practical.
[...]
--
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-12 01:01 -0500 |
| Message-ID | <0d1kia1ggu3n0e1mbunhdfjv5rr5r328a0@4ax.com> |
| In reply to | #59915 |
On Sat, 11 Apr 2015 12:21:20 -0700, Keith Thompson <kst-u@mib.org> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: >> On Fri, 10 Apr 2015 13:46:12 -0700, Keith Thompson <kst-u@mib.org> >> wrote: >>>Robert Wessel <robertwessel2@yahoo.com> writes: >>>[...] >>>> I think this was discussed in these parts a few months ago. I was >>>> suggesting something more like: >>>> >>>> int f(int a, int b=5, int c=6; int .d=1, int .e=2); >>>> >>>> Which would have three positional parameters, with the latter two >>>> optional, and two keyword parameters. >>>> >>>> Which could be called with: >>>> >>>> f(1) >>>> f(1, 2) >>>> f(1, .e=9) >>>> f(1, 2, 3, .e=8) >>>> f(1, 3, .d=6) >>>> >>>> etc. >>>> >>>> You could also have mandatory keyword parameters with something like: >>>> >>>> int g(int a, int b=5, int c=6; int .d=1, int .e=2, int .f=); >>>> >>>> Where the f= keyword parameter is mandatory. >>>> >>>> (And that was based on other ideas in the thread.) >>> >>>In your design, using parameter names in argument lists (I hesitate >>>to refer to them as "keywords", because that already means something) >>>may be mandatory, optional, or forbidden, depending on how the >>>prototype is written. >>> >>>I'd prefer to leave that choice up to the caller. Letting a function >>>declaration impose constraints on callers just seems unnecessary. >> >> >> I think you're reading a bit too much into that - a parameter is >> mandatory if it doesn't have a default value. >> >> As a note, it might be best to omit the equal sign for the named >> parameter if no default value exists (so just "int .f"). > >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. >In a function call, there are (potentially) two choices for each >parameter: whether to specify it, and whether to use its name. I think >we agree that specifying it is mandatory if it doesn't have a default >value, optional if it does. In the model I'm suggesting, using its name >(`.c = 42` vs. just `42`) should be left entirely at the discretion of >the caller, assuming the declaration provides a name. 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. 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'd suggest something a bit simpler: >>> >>> int f(int a, int b=5, int c=6); >>> >>>Any of the arguments may be passed with or without a parameter name. >>>A caller *must* pass a value for `a` explicitly, because it has no >>>default value. A call using pure positional notation is always >>>permitted. In a call, all named arguments (if any) must follow >>>all positional arguments (if any). >>> >>>Valid calls would include: >>> >>> f(40) /* Equivalent to f(40, 5, 6) */ >>> f(40, 50, 60) /* Calls below are equivalent to this one */ >>> f(40, 50, .c = 60); >>> f(40, .c = 60) >>> f(.a = 40, .b = 50, .c = 60) >>> f(.c = 60, .b = 50, .a = 40) >> >> >> I'm not sure that you'd really want the flexibility to make parameters >> optionally named (I think the distinction is useful), but conceptually >> I'd have no huge objection. There are some corner cases where you >> might specify the second of three parameters with a keyword, which >> raises the issue of whether or not you could then specify the third >> parameter positionally. > >Sure, you could define rigorous rules that determine what something like > func(10, .param = 20, 30) >means and when it's permitted. The 30 could apply to the 3rd parameter, >to the next parameter that hasn't already been specified, or to the >parameter following `param`. It's not obvious to me that any of those >choices is the best. My own preference is just not to allow that. Yes. >>>There's still the problem of defining canonical names for parameters; >>>currently parameter names in prototypes are ignored, and may be omitted. >>>I think we'd still have to permit prototypes without parameter names for >>>backward compatibility. Given: >>> >>> int f(int, int, int); >>> >>>you just couldn't use names in arguments. >> >> >> Using the new syntax makes the specification of the parameter names >> explicit, rather than implicit. And the above would be treated just >> as it is now. > >If I were designing a C-like language from scratch, names for parameters >would be mandatory and would have to be consistent across all >definitions and declarations. But there's too much code that declares >functions without naming their parameters for that to be practical. 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).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-12 13:03 -0700 |
| Message-ID | <87vbh1t8qt.fsf@kst-u.example.com> |
| In reply to | #59926 |
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.
> 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.
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-12 23:29 +0100 |
| Message-ID | <mgerho$ain$1@dont-email.me> |
| In reply to | #59938 |
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. Usually you'd have the positional arguments first, as these are more likely to be the ones you usually have to pass anyway, and less likely to have defaults, and therefore the ones that you will be more familiar with in terms of position. Followed by the keyword arguments. The other way around, how will you know which positional parameter comes after the last keyword one you used? Some advantages of using keyword params is not having to be bothered about their order, and being able to change order or insert new ones without affecting existing calls. And take this example: void testfn(int data, int a=0, int b=0, int c=0, int d=0); data is always passed; a, b, c, d are optional arguments. A typical call might be: testfn(data, b:100); the keyword arguments follow the fixed ones. But try it the other way around: testfn(b:100, ...?); You can't pass data as positional any more, as it doesn't immediately follow b; it doesn't follow any other parameter. You can only pass it as a keyword argument. -- Bartc
[toc] | [prev] | [next] | [standalone]
| 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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-04-14 02:44 -0500 |
| Message-ID | <1ogpia15bhktme6r35j80es7bn44vc34k5@4ax.com> |
| In reply to | #59964 |
On Mon, 13 Apr 2015 08:39:31 -0400, James Kuyper <jameskuyper@verizon.net> wrote: >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). Wouldn't it have been simpler to just impose a "correctly rounded" requirement on decimal FP literals? It might slow down the parsing of those a fair bit, but that seems a minimal issue. The straight-forward method (while slow) is pretty trivial.
[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]
Page 11 of 13 — ← Prev page 1 … 9 10 [11] 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web