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 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-04-10 02:06 -0700 |
| Message-ID | <f7a5c20f-b33f-4d25-bb1b-4ed9083f045b@googlegroups.com> |
| In reply to | #59865 |
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);
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-10 10:21 +0100 |
| Message-ID | <mg84ku$onh$1@dont-email.me> |
| In reply to | #59868 |
On 10/04/2015 10:06, Malcolm McLean 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);
There's a small problem with using "=" here. If you have an actual
object in scope called "population", then you don't know if want to
assign false to that, and pass that value, or just pass false without
changing that object.
(Also 'stdev' is as annoying an abbreviation as 'adr' is for 'address'.
They both need the extra 'd'.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-10 10:31 +0100 |
| Message-ID | <mg8575$qne$1@dont-email.me> |
| In reply to | #59868 |
On 10/04/15 10:06, Malcolm McLean 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.
Obviously you enjoy typing. :-)
>
> double stdev(double *x, int N, bool population = true)
Did you mean to write "stddev" ? That would make more sense.
> {
> /* do sample or population deviation depending on flag */
> }
>
> /* call for population */
> stdev(everyone, 7000000000);
A machine with enough room for 7E9 doubles in RAM? Nice. When you're
done with it, just pass it across, would you? But please note that:
stddev(everyone, 7000000000, 0);
isn't much more work (three extra characters, two if you're feeling
parsimonious), and it saves changing the language.
>
> /* compulsory named argument for non-default */
> stdev(sample, 50, population = false);
I'd prefer:
stddev(sample, 50, 0);
which is considerably shorter. Or, if you're into wordy:
stddev(sample, 50, false);
which is still shorter.
> /* permitted if you insist */
> stdev(population = true, x = sample, N = 50);
If you like typing that much, you could do this:
stddev::population = true;
stddev::x = sample;
stddev::N = 50;
stddev::calc;
stdio::outdata = stddev::result;
stdio::write;
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-10 11:26 +0100 |
| Message-ID | <mg88eu$5pt$1@dont-email.me> |
| In reply to | #59870 |
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); 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. It can also save typing, and become self-documenting, in calls like this: initwindow(width:640, height:480); instead of: initwindow(640, 480); which, because bare constants are undesirable, really demands to be written as: #define window_with 640 #define window_height 480 initwindow(window_width, window_height); (Because macro names have file scope, you need to use longer identifiers. Parameter keyword names have a narrower scope and a known context so can be shorter.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-10 11:53 +0100 |
| Message-ID | <mg8a1d$b3u$1@dont-email.me> |
| In reply to | #59871 |
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. > > 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! -- 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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-10 12:22 +0100 |
| Message-ID | <mg8bna$h09$1@dont-email.me> |
| In reply to | #59872 |
On 10/04/2015 11:53, Richard Heathfield wrote: > On 10/04/15 11:26, Bartc wrote: >> 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. No, you just have to change the entire library! And there's the little matter of having to define and initialise the struct somewhere. (And the reader having to deal with such disjointed bits of code.) (MS likes to use such structs extensively in their Windows APIs. But because I had the temerity to call these APIs from my own language, I had to painstakingly construct an exactly compatible struct each time I came across a new one. And it was still a PITA to use. I think that's why I switched over to using the C runtime library for many things. Function calls on the same machine, however, are more standardised and are easier to call from a different language.) >> initwindow(width:640, height:480); >> >> instead of: >> >> initwindow(640, 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! No, initwindow allows different sizes of window. But if you only intend to use a fixed size in your use of it, then normal C obliges you to pass the dimensions. Then, if there are several calls to initwindow(), it makes sense to use macros. My example wasn't about defaults either, but if defaults were used, and they happened to be (640,480) or you made it that way because it's in one of your libraries, then you could actually write: initwindow(); and get the default size. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-10 12:46 +0100 |
| Message-ID | <mg8d56$lu5$1@dont-email.me> |
| In reply to | #59873 |
On 10/04/15 12:22, Bartc wrote: > On 10/04/2015 11:53, Richard Heathfield wrote: >> On 10/04/15 11:26, Bartc wrote: > >>> 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. > > No, you just have to change the entire library! Which is easier, changing the library or changing the language? And when the library interface is palpably unusable, changing it is actually a good idea. > And there's the little > matter of having to define and initialise the struct somewhere. (And the > reader having to deal with such disjointed bits of code.) That is indeed a little matter. > (MS likes to use such structs extensively in their Windows APIs. But > because I had the temerity to call these APIs from my own language, I > had to painstakingly construct an exactly compatible struct each time I > came across a new one. And it was still a PITA to use. I think that's > why I switched over to using the C runtime library for many things. Okay, so you don't like that way of moving data around. Personally, I think it makes a lot of sense. In fact, despite the fact that I think MS should just crawl under a stone and expire quietly, I reckon the Windows API (while far from perfect) is actually very, very good and I quite enjoy programming for it. > > Function calls on the same machine, however, are more standardised and > are easier to call from a different language.) > >>> initwindow(width:640, height:480); >>> >>> instead of: >>> >>> initwindow(640, 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! > > No, initwindow allows different sizes of window. But if you only intend > to use a fixed size in your use of it, then normal C obliges you to pass > the dimensions. Fine, so in that very limited circumstance you use some identifiers. I don't see the problem. > Then, if there are several calls to initwindow(), it makes sense to use > macros. I still think it makes more sense to use objects (in the C sense of the word, of course), but sure, macros if they float your boat. Try upper case, though, for convention's sake. Conventions do actually have value. > > My example wasn't about defaults either, but if defaults were used, and > they happened to be (640,480) or you made it that way because it's in > one of your libraries, then you could actually write: > > initwindow(); > > and get the default size. If they happen to be, sure. But what are the odds of that? It's more likely that they're that way because you programmed them that way, in which case you have control over initwindow(), in which case why not just accept 0 (or, perhaps, -1) as meaning "use the default size"? There are so many easy ways to do this that don't involve adding a whole level of complexity to the C language. -- 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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-10 13:46 +0100 |
| Message-ID | <mg8gl3$3h2$1@dont-email.me> |
| In reply to | #59874 |
On 10/04/2015 12:46, Richard Heathfield wrote: > On 10/04/15 12:22, Bartc wrote: >> My example wasn't about defaults either, but if defaults were used, and >> they happened to be (640,480) or you made it that way because it's in >> one of your libraries, then you could actually write: >> >> initwindow(); >> >> and get the default size. > > > If they happen to be, sure. But what are the odds of that? It's more > likely that they're that way because you programmed them that way, in > which case you have control over initwindow(), in which case why not > just accept 0 (or, perhaps, -1) as meaning "use the default size"? Because then it means doing this: fn(0,0,0,0); or: fn(-1,-1,-1,-1); or: fn(USE_DEFAULT, USE_DEFAULT, USE_DEFAULT, USE_DEFAULT); assuming all default codes are the same. (It's just a shame the actual name of the function you're calling is now hidden in the noise.) > There are so many easy ways to do this that don't involve adding a whole > level of complexity to the C language. Actually keyword and default parameters are one of the simpler things to add, and can be done in a way that doesn't affect existing code. I use both quite a lot elsewhere, but probably default parameters more. Keyword parameters are used more for functions with many related options (creating graphics or geometry for example). Default parameters are useful also when you need to add an extra parameter to a function that is already used in a thousand places. You just declare a default value for it, which also makes it optional. Then those existing thousand calls don't need changing; they will just silently push an extra value, usually 0. (And if you then decide you don't need it after all, you can take it out and can still leave those calls alone. But existing code will need recompiling, as it would do anyway.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-04-10 13:51 +0100 |
| Message-ID | <mg8guf$4li$1@dont-email.me> |
| In reply to | #59878 |
On 10/04/15 13:46, Bartc wrote: > On 10/04/2015 12:46, Richard Heathfield wrote: <snip> >> There are so many easy ways to do this that don't involve adding a whole >> level of complexity to the C language. > > Actually keyword and default parameters are one of the simpler things to > add, and can be done in a way that doesn't affect existing code. At this point, I see no alternative but to hand you over to Richard Bos. And may God have mercy on your soul. -- 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 | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-04-10 18:54 +0000 |
| Message-ID | <NfUvSn.QL5.GQ7VD@gmail.com> |
| In reply to | #59873 |
On Fri, Apr 10, 2015 at 12:22:05PM +0100, Bartc wrote:
> On 10/04/2015 11:53, Richard Heathfield wrote:
> >On 10/04/15 11:26, Bartc wrote:
>
> >>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.
>
> No, you just have to change the entire library! And there's the little
> matter of having to define and initialise the struct somewhere. (And the
> reader having to deal with such disjointed bits of code.)
>
> (MS likes to use such structs extensively in their Windows APIs. But
> because I had the temerity to call these APIs from my own language, I
> had to painstakingly construct an exactly compatible struct each time I
> came across a new one. And it was still a PITA to use. I think that's
> why I switched over to using the C runtime library for many things.
>
> Function calls on the same machine, however, are more standardised and
> are easier to call from a different language.)
>
> >>initwindow(width:640, height:480);
> >>
> >>instead of:
> >>
> >>initwindow(640, 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!
>
> No, initwindow allows different sizes of window. But if you only intend
> to use a fixed size in your use of it, then normal C obliges you to pass
> the dimensions.
>
> Then, if there are several calls to initwindow(), it makes sense to use
> macros.
>
> My example wasn't about defaults either, but if defaults were used, and
> they happened to be (640,480) or you made it that way because it's in
> one of your libraries, then you could actually write:
>
> initwindow();
>
> and get the default size.
Christ. That's what descriptors are for.
How about initwindow(params), where params is a structure pointer
describing the window parameters. One of the things about wimp
interfaces is that there are generally a zillion little things to
set or tune. I would go mad if I was required to use functions
expecting tens of function arguments, which is why in my own code I
have settled on a parameters structure containing all of the flags and
whatnot required to set up the module instance. My avl tree module
has the following parameters structure:
struct avl_params {
str_ing file;
avl_compare compare;
void * ctxt;
avl_ptr start_size;
avl_ptr max_nr_nodes;
u32 xpn_factor; +
u32 nr_bulk;
u32 sleep_interval; +
u32 spin_max; +
u32 nr_pauses; +
u8 prefer_readers; +
u8 prefer_writers; +
u8 allow_dups;
u8 mt_safe;
u8 mt_update;
u8 load_file;
u8 save_file;
u8 map_file;
u8 tlm_record;
tlm_rowctr tlm_nr_drows;
rwlock_params lock; /* See rwlock.h. */
mem_pool_params pool; /* See mem_pool.h */
obj_id_ptr id; /* See obj_id.h */
};
Granted that a handful of the top-level parameters are duplicates
(marked with a +) of items found in rwlock and mem_pool parameters
structures, but that is only a convenience for people who might be
confused by nested structures. I have a trivial 'avl_params_init'
macro that sets sane defaults, and that's that. The prototype for
avl_open() is nothing more than "avl * avl_open(avl_params *)". The
principle of module design implicit here is extended to the full API,
so I have an avl_op structure which is passed to the avl_operation()
function:
struct avl_op {
u8 code;
u8 status;
u16 reserved;
AVL_KEY key;
AVL_KEY item;
u64 latency;
avl_ptr tree_size;
avl_tlm * tlm;
};
This structure also has its own avl_op_init macro. And so forth. One
of the side-effects of this arrangement is that there is next to no
copying occuring. Code making use of avl tree primitives (probe,
update, insert, delete) declare the avl_op structure on their stack,
its elements are filled out and then it's pointer is passed to the
function(s) doing the work. This arrangement has the properties of
intrinsic efficiency and simplicity.
Now consider the notion of functions with default arguments in this
scenario. First you must define the function such that it will accept
all of the above structure elements individually AND you require that
the language is modified to fill in elements that you do not
explicitly include in the function call. PLUS you must identify the
function arguments that you do use by prefixing them with their
identifier. I suppose the compiler can define a structure for you and
hide the details of its allocation and initialization to avoid the
cost of pushing each individual function argument on the stack, but so
what. It is still ugly.
Furthermore, I suspect your default function arguments will be be
program wide for any given module, rather than specific to a module
instance, which limits their utility considerably. So while I am not
exactly pleased to find myself in agreement with Mr. Heathfield, I
must say that this suggestion is a Bad Idea. The general technique
as illustrated above is more than adequate to obviate the need for
functions with more than two or three arguments, and that is a 'win'.
Regards,
Steve Thompson
--
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-10 13:11 -0700 |
| Message-ID | <c5a0090f-04a0-45a4-a588-b0650e7e0e50@googlegroups.com> |
| In reply to | #59885 |
W dniu piątek, 10 kwietnia 2015 21:23:09 UTC+2 użytkownik Steve Thompson napisał:
> On Fri, Apr 10, 2015 at 12:22:05PM +0100, Bartc wrote:
> > On 10/04/2015 11:53, Richard Heathfield wrote:
> > >On 10/04/15 11:26, Bartc wrote:
> >
> > >>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.
> >
> > No, you just have to change the entire library! And there's the little
> > matter of having to define and initialise the struct somewhere. (And the
> > reader having to deal with such disjointed bits of code.)
> >
> > (MS likes to use such structs extensively in their Windows APIs. But
> > because I had the temerity to call these APIs from my own language, I
> > had to painstakingly construct an exactly compatible struct each time I
> > came across a new one. And it was still a PITA to use. I think that's
> > why I switched over to using the C runtime library for many things.
> >
> > Function calls on the same machine, however, are more standardised and
> > are easier to call from a different language.)
> >
> > >>initwindow(width:640, height:480);
> > >>
> > >>instead of:
> > >>
> > >>initwindow(640, 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!
> >
> > No, initwindow allows different sizes of window. But if you only intend
> > to use a fixed size in your use of it, then normal C obliges you to pass
> > the dimensions.
> >
> > Then, if there are several calls to initwindow(), it makes sense to use
> > macros.
> >
> > My example wasn't about defaults either, but if defaults were used, and
> > they happened to be (640,480) or you made it that way because it's in
> > one of your libraries, then you could actually write:
> >
> > initwindow();
> >
> > and get the default size.
>
> Christ. That's what descriptors are for.
>
> How about initwindow(params), where params is a structure pointer
> describing the window parameters. One of the things about wimp
> interfaces is that there are generally a zillion little things to
> set or tune. I would go mad if I was required to use functions
> expecting tens of function arguments, which is why in my own code I
> have settled on a parameters structure containing all of the flags and
> whatnot required to set up the module instance. My avl tree module
> has the following parameters structure:
>
> struct avl_params {
> str_ing file;
> avl_compare compare;
> void * ctxt;
> avl_ptr start_size;
> avl_ptr max_nr_nodes;
> u32 xpn_factor; +
> u32 nr_bulk;
> u32 sleep_interval; +
> u32 spin_max; +
> u32 nr_pauses; +
> u8 prefer_readers; +
> u8 prefer_writers; +
> u8 allow_dups;
> u8 mt_safe;
> u8 mt_update;
> u8 load_file;
> u8 save_file;
> u8 map_file;
> u8 tlm_record;
> tlm_rowctr tlm_nr_drows;
> rwlock_params lock; /* See rwlock.h. */
> mem_pool_params pool; /* See mem_pool.h */
> obj_id_ptr id; /* See obj_id.h */
> };
>
>
> Granted that a handful of the top-level parameters are duplicates
> (marked with a +) of items found in rwlock and mem_pool parameters
> structures, but that is only a convenience for people who might be
> confused by nested structures. I have a trivial 'avl_params_init'
> macro that sets sane defaults, and that's that. The prototype for
> avl_open() is nothing more than "avl * avl_open(avl_params *)". The
> principle of module design implicit here is extended to the full API,
> so I have an avl_op structure which is passed to the avl_operation()
> function:
>
> struct avl_op {
> u8 code;
> u8 status;
> u16 reserved;
> AVL_KEY key;
> AVL_KEY item;
> u64 latency;
> avl_ptr tree_size;
> avl_tlm * tlm;
> };
>
> This structure also has its own avl_op_init macro. And so forth. One
> of the side-effects of this arrangement is that there is next to no
> copying occuring. Code making use of avl tree primitives (probe,
> update, insert, delete) declare the avl_op structure on their stack,
> its elements are filled out and then it's pointer is passed to the
> function(s) doing the work. This arrangement has the properties of
> intrinsic efficiency and simplicity.
>
> Now consider the notion of functions with default arguments in this
> scenario. First you must define the function such that it will accept
> all of the above structure elements individually AND you require that
> the language is modified to fill in elements that you do not
> explicitly include in the function call. PLUS you must identify the
> function arguments that you do use by prefixing them with their
> identifier. I suppose the compiler can define a structure for you and
> hide the details of its allocation and initialization to avoid the
> cost of pushing each individual function argument on the stack, but so
> what. It is still ugly.
>
> Furthermore, I suspect your default function arguments will be be
> program wide for any given module, rather than specific to a module
> instance, which limits their utility considerably. So while I am not
> exactly pleased to find myself in agreement with Mr. Heathfield, I
> must say that this suggestion is a Bad Idea. The general technique
> as illustrated above is more than adequate to obviate the need for
> functions with more than two or three arguments, and that is a 'win'.
>
>
I am personally not sure if using such structures 9filling then passing etc
(as winapi also do, - is a good option
(probably not)
If i use such api i dislike it
>
> Regards,
>
> Steve Thompson
>
> --
> "If I had a nickel for every time some idiot called me about a
> computer problem that turned out to be user error, I would be able to
> retire and spend the rest of my days cultivating clues in my backyard
> hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-10 14:10 -0700 |
| Message-ID | <62511557-4ae9-4c60-a6b0-1601bf4f4dc8@googlegroups.com> |
| In reply to | #59886 |
W dniu piątek, 10 kwietnia 2015 22:11:22 UTC+2 użytkownik fir napisał: > W dniu piątek, 10 kwietnia 2015 21:23:09 UTC+2 użytkownik Steve Thompson napisał: > > > > I am personally not sure if using such structures 9filling then passing etc > (as winapi also do, - is a good option > (probably not) > > If i use such api i dislike it > ps i got not to much thoughts on this becouse i never yet wrote an api that needs many different arguments.. used a couple of them but to say if it can be donne better would have to design one (hard to belive it cannot be done better though) dont know, im not sure for example if given method with structure means creating structure on caller side then passing it where it is used (copied) by api,, think if other way, i mean holding structure instance on api side then returning pointer to it to the caller to use it would not be a bit cleaner
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-04-11 17:46 +0000 |
| Message-ID | <3GOwe7.hEH.iQ1ao@gmail.com> |
| In reply to | #59886 |
On Fri, Apr 10, 2015 at 01:11:07PM -0700, fir wrote: > W dniu piątek, 10 kwietnia 2015 21:23:09 UTC+2 użytkownik Steve Thompson napisał: > > > > I am personally not sure if using such structures 9filling then passing etc > (as winapi also do, - is a good option > (probably not) > > If i use such api i dislike it What is the alternative? In my example the avl_open() function would require 25+ function arguments, which is clearly unreasonable. It might be possible to write a number of 'configuration' functions which could be called individually to set various options and only do the allocation and configuration of various bits at the time the first key is inserted, but that would be a hell of a lot more work. The scheme I suggest is additonally future proof. New features may be added transparently, or I might change the rwlock algorithm (and indeed I have a couple of variants undergoing testing) etc. without requiring that I update API usage all over the place in application code. Regards, Steve Thompson -- "If I had a nickel for every time some idiot called me about a computer problem that turned out to be user error, I would be able to retire and spend the rest of my days cultivating clues in my backyard hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-11 23:38 +0100 |
| Message-ID | <mgc7ni$h8s$1@dont-email.me> |
| In reply to | #59885 |
On 10/04/2015 19:54, Steve Thompson wrote: > On Fri, Apr 10, 2015 at 12:22:05PM +0100, Bartc wrote: >> My example wasn't about defaults either, but if defaults were used, and >> they happened to be (640,480) or you made it that way because it's in >> one of your libraries, then you could actually write: >> >> initwindow(); >> >> and get the default size. > > Christ. That's what descriptors are for. > > How about initwindow(params), where params is a structure pointer > describing the window parameters. One of the things about wimp > interfaces is that there are generally a zillion little things to > set or tune. I would go mad if I was required to use functions > expecting tens of function arguments, which is why in my own code I > have settled on a parameters structure containing all of the flags and > whatnot required to set up the module instance. My avl tree module > has the following parameters structure: Nothing stops you doing that. And no-one is holding a gun to your head saying you /must/ use keyword params. I've used keyword params in a dynamic language where /one/ param might be a 'dict' type containing the multitudinous options, and where you could override one of those options without affecting the default set. For use in C, there /already/ exist functions with a dozen or more parameters (I'm only familiar with Win32); this scheme can be superimposed on such functions. But, given a function drawimage() which: * Draws an image I * Into window W (default: screen) * At W position X,Y (default: top left or centred) * At scale SX,SY or at single fixed aspect scale SX (default: 1.0, 1.0) * Start position in I: IX,IY (default top left) * Size of I to draw: (W,H) (default: entire image) * Plus a dozen other options etc etc then /I/ would go mad if I had to painstakingly fill in a form - sorry a struct - just before every call! Most of the time you just want to do: drawimage(I); // centred on screen drawimage(W,I); // top left in W and sometimes: drawimage(W,I,scale:2) // double size > Now consider the notion of functions with default arguments in this > scenario. First you must define the function such that it will accept > all of the above structure elements individually AND you require that That would be silly. You wouldn't define /dozens/ of parameters like that. I suppose the compiler can define a structure for you and > hide the details of its allocation and initialization to avoid the > cost of pushing each individual function argument on the stack, but so > what. It is still ugly. What's the cost of writing arguments to a struct in memory? And the caller having to access those via a pointer? (And with some platforms, many arguments are passed via registers; that is awkward when using structs.) Anyway for many of these kinds of functions (CreateWindowEx for example), they are not going to be called millions of times per second. > Furthermore, I suspect your default function arguments will be be > program wide for any given module, Most defaults are going to be NULL or zero, no matter what the module. Even if not zero, functions can often use zero to signal that a more elaborate default is being requested (for example, which depends on the value of other arguments, which is harder to express directly). rather than specific to a module > instance, which limits their utility considerably. So while I am not > exactly pleased to find myself in agreement with Mr. Heathfield, I > must say that this suggestion is a Bad Idea. The general technique > as illustrated above is more than adequate to obviate the need for > functions with more than two or three arguments, and that is a 'win'. I use that technique too. In fact I've demonstrated that above, where both I and W are likely to be handles (pointers in C) to the relevant descriptors. Perhaps you're misunderstanding how keyword params and defaults are likely to be used. It will not be used so that I and W can be expanded into their 28 and 46 respective elements to create a new set of functions that start with 74 parameters plus all the rest! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-11 16:35 -0700 |
| Message-ID | <e9d56724-b188-4c9a-84cf-e7f9e75dee28@googlegroups.com> |
| In reply to | #59919 |
W dniu niedziela, 12 kwietnia 2015 00:38:46 UTC+2 użytkownik Bart napisał: > On 10/04/2015 19:54, Steve Thompson wrote: > > On Fri, Apr 10, 2015 at 12:22:05PM +0100, Bartc wrote: > > >> My example wasn't about defaults either, but if defaults were used, and > >> they happened to be (640,480) or you made it that way because it's in > >> one of your libraries, then you could actually write: > >> > >> initwindow(); > >> > >> and get the default size. > > > > Christ. That's what descriptors are for. > > > > How about initwindow(params), where params is a structure pointer > > describing the window parameters. One of the things about wimp > > interfaces is that there are generally a zillion little things to > > set or tune. I would go mad if I was required to use functions > > expecting tens of function arguments, which is why in my own code I > > have settled on a parameters structure containing all of the flags and > > whatnot required to set up the module instance. My avl tree module > > has the following parameters structure: > > Nothing stops you doing that. And no-one is holding a gun to your head > saying you /must/ use keyword params. > > I've used keyword params in a dynamic language where /one/ param might > be a 'dict' type containing the multitudinous options, and where you > could override one of those options without affecting the default set. > > For use in C, there /already/ exist functions with a dozen or more > parameters (I'm only familiar with Win32); this scheme can be > superimposed on such functions. > > But, given a function drawimage() which: > > * Draws an image I > * Into window W (default: screen) > * At W position X,Y (default: top left or centred) > * At scale SX,SY or at single fixed aspect scale SX (default: 1.0, 1.0) > * Start position in I: IX,IY (default top left) > * Size of I to draw: (W,H) (default: entire image) > * Plus a dozen other options etc etc > > then /I/ would go mad if I had to painstakingly fill in a form - sorry a > struct - just before every call! > > Most of the time you just want to do: > > drawimage(I); // centred on screen > drawimage(W,I); // top left in W > > and sometimes: > > drawimage(W,I,scale:2) // double size > this is good example, (I got such routine in my library (draw sprite from textura atlas at screen in given pos zoom and rotation) even default sipmle call has a lot of params (seven if im not wrong) probably more extensive version could have few more (though i dont have that) so what with that. IMO as all thore parameters are meaningfull (and 'variable') there is not a problem to pass them each time as they are, though probably some could be 'cached' in some way how? for me it seem natural to giva a couple of (function) headers (more natural then default args in c++ way, as i said such default args are only a wrapper and imo is not quite clean) what other options? - global "temporary*" state with some api to manipulate it(such like opengl do) - seem not to much good for me, not so much bad but also not so much good imo [not sure] (*by temporary i mean shallow stack or only something like "1-element stack"-state) - structore defined on caller side and pass a pointer to it - not sure, it all depends on how to do it probably, but not necessary good - structure defined on api side, (and accessed by something like handle) for some moment it seem lika a better option for me though I am also not sure - other options? (probably some mix of 2 and 3, it is both sides of the structures with settings could work in some way) > > Now consider the notion of functions with default arguments in this > > scenario. First you must define the function such that it will accept > > all of the above structure elements individually AND you require that > > That would be silly. You wouldn't define /dozens/ of parameters like that. > > I suppose the compiler can define a structure for you and > > hide the details of its allocation and initialization to avoid the > > cost of pushing each individual function argument on the stack, but so > > what. It is still ugly. > > What's the cost of writing arguments to a struct in memory? And the > caller having to access those via a pointer? (And with some platforms, > many arguments are passed via registers; that is awkward when using > structs.) > > Anyway for many of these kinds of functions (CreateWindowEx for > example), they are not going to be called millions of times per second. > > > Furthermore, I suspect your default function arguments will be be > > program wide for any given module, > > Most defaults are going to be NULL or zero, no matter what the module. > Even if not zero, functions can often use zero to signal that a more > elaborate default is being requested (for example, which depends on the > value of other arguments, which is harder to express directly). > > rather than specific to a module > > instance, which limits their utility considerably. So while I am not > > exactly pleased to find myself in agreement with Mr. Heathfield, I > > must say that this suggestion is a Bad Idea. The general technique > > as illustrated above is more than adequate to obviate the need for > > functions with more than two or three arguments, and that is a 'win'. > > I use that technique too. In fact I've demonstrated that above, where > both I and W are likely to be handles (pointers in C) to the relevant > descriptors. > > Perhaps you're misunderstanding how keyword params and defaults are > likely to be used. It will not be used so that I and W can be expanded > into their 28 and 46 respective elements to create a new set of > functions that start with 74 parameters plus all the rest! > > -- > Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-11 17:19 -0700 |
| Message-ID | <bdbff49f-a858-462b-95c3-9bd0d2949c81@googlegroups.com> |
| In reply to | #59920 |
W dniu niedziela, 12 kwietnia 2015 01:35:44 UTC+2 użytkownik fir napisał: > W dniu niedziela, 12 kwietnia 2015 00:38:46 UTC+2 użytkownik Bart napisał: > > On 10/04/2015 19:54, Steve Thompson wrote: > > > On Fri, Apr 10, 2015 at 12:22:05PM +0100, Bartc wrote: > > > > >> My example wasn't about defaults either, but if defaults were used, and > > >> they happened to be (640,480) or you made it that way because it's in > > >> one of your libraries, then you could actually write: > > >> > > >> initwindow(); > > >> > > >> and get the default size. > > > > > > Christ. That's what descriptors are for. > > > > > > How about initwindow(params), where params is a structure pointer > > > describing the window parameters. One of the things about wimp > > > interfaces is that there are generally a zillion little things to > > > set or tune. I would go mad if I was required to use functions > > > expecting tens of function arguments, which is why in my own code I > > > have settled on a parameters structure containing all of the flags and > > > whatnot required to set up the module instance. My avl tree module > > > has the following parameters structure: > > > > Nothing stops you doing that. And no-one is holding a gun to your head > > saying you /must/ use keyword params. > > > > I've used keyword params in a dynamic language where /one/ param might > > be a 'dict' type containing the multitudinous options, and where you > > could override one of those options without affecting the default set. > > > > For use in C, there /already/ exist functions with a dozen or more > > parameters (I'm only familiar with Win32); this scheme can be > > superimposed on such functions. > > > > But, given a function drawimage() which: > > > > * Draws an image I > > * Into window W (default: screen) > > * At W position X,Y (default: top left or centred) > > * At scale SX,SY or at single fixed aspect scale SX (default: 1.0, 1.0) > > * Start position in I: IX,IY (default top left) > > * Size of I to draw: (W,H) (default: entire image) > > * Plus a dozen other options etc etc > > > > then /I/ would go mad if I had to painstakingly fill in a form - sorry a > > struct - just before every call! > > > > Most of the time you just want to do: > > > > drawimage(I); // centred on screen > > drawimage(W,I); // top left in W > > > > and sometimes: > > > > drawimage(W,I,scale:2) // double size > > > > this is good example, (I got such routine in my library (draw sprite from textura atlas at screen in given pos zoom and rotation) even default sipmle call has a lot of params (seven > if im not wrong) probably more extensive version could have few more (though i dont have that) > > so what with that. IMO as all thore parameters are meaningfull (and 'variable') there is not a problem to pass them each time as they are, > though probably some could be 'cached' in some way > > how? for me it seem natural to giva a couple > of (function) headers (more natural then default args in c++ way, as i said such default args are only a wrapper and imo is not quite clean) > > what other options? > - global "temporary*" state with some api to manipulate it(such like opengl do) - seem not to much good for me, not so much bad but also not so much good imo [not sure] > (*by temporary i mean shallow stack or only > something like "1-element stack"-state) > - structore defined on caller side and pass a pointer to it - not sure, it all depends on how to do it probably, but not necessary good > - structure defined on api side, (and accessed > by something like handle) for some moment it seem lika a better option for me though I am also not sure > - other options? > > (probably some mix of 2 and 3, it is both sides of the structures with settings could work in some way) > ps some interesting thig here is that such structure in some sense could have 'not decided' storage, i mean not (said) caller side, not calee side either - this is interesting case (first time i see such thing)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-12 00:54 -0700 |
| Message-ID | <148f137a-4bae-439d-97da-1e4280c09310@googlegroups.com> |
| In reply to | #59922 |
W dniu niedziela, 12 kwietnia 2015 02:19:22 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 12 kwietnia 2015 01:35:44 UTC+2 użytkownik fir napisał:
> > W dniu niedziela, 12 kwietnia 2015 00:38:46 UTC+2 użytkownik Bart napisał:
> > > On 10/04/2015 19:54, Steve Thompson wrote:
> > > > On Fri, Apr 10, 2015 at 12:22:05PM +0100, Bartc wrote:
> > >
> > > >> My example wasn't about defaults either, but if defaults were used, and
> > > >> they happened to be (640,480) or you made it that way because it's in
> > > >> one of your libraries, then you could actually write:
> > > >>
> > > >> initwindow();
> > > >>
> > > >> and get the default size.
> > > >
> > > > Christ. That's what descriptors are for.
> > > >
> > > > How about initwindow(params), where params is a structure pointer
> > > > describing the window parameters. One of the things about wimp
> > > > interfaces is that there are generally a zillion little things to
> > > > set or tune. I would go mad if I was required to use functions
> > > > expecting tens of function arguments, which is why in my own code I
> > > > have settled on a parameters structure containing all of the flags and
> > > > whatnot required to set up the module instance. My avl tree module
> > > > has the following parameters structure:
> > >
> > > Nothing stops you doing that. And no-one is holding a gun to your head
> > > saying you /must/ use keyword params.
> > >
> > > I've used keyword params in a dynamic language where /one/ param might
> > > be a 'dict' type containing the multitudinous options, and where you
> > > could override one of those options without affecting the default set.
> > >
> > > For use in C, there /already/ exist functions with a dozen or more
> > > parameters (I'm only familiar with Win32); this scheme can be
> > > superimposed on such functions.
> > >
> > > But, given a function drawimage() which:
> > >
> > > * Draws an image I
> > > * Into window W (default: screen)
> > > * At W position X,Y (default: top left or centred)
> > > * At scale SX,SY or at single fixed aspect scale SX (default: 1.0, 1.0)
> > > * Start position in I: IX,IY (default top left)
> > > * Size of I to draw: (W,H) (default: entire image)
> > > * Plus a dozen other options etc etc
> > >
> > > then /I/ would go mad if I had to painstakingly fill in a form - sorry a
> > > struct - just before every call!
> > >
> > > Most of the time you just want to do:
> > >
> > > drawimage(I); // centred on screen
> > > drawimage(W,I); // top left in W
> > >
> > > and sometimes:
> > >
> > > drawimage(W,I,scale:2) // double size
> > >
> >
> > this is good example, (I got such routine in my library (draw sprite from textura atlas at screen in given pos zoom and rotation) even default sipmle call has a lot of params (seven
> > if im not wrong) probably more extensive version could have few more (though i dont have that)
> >
> > so what with that. IMO as all thore parameters are meaningfull (and 'variable') there is not a problem to pass them each time as they are,
> > though probably some could be 'cached' in some way
> >
> > how? for me it seem natural to giva a couple
> > of (function) headers (more natural then default args in c++ way, as i said such default args are only a wrapper and imo is not quite clean)
> >
> > what other options?
> > - global "temporary*" state with some api to manipulate it(such like opengl do) - seem not to much good for me, not so much bad but also not so much good imo [not sure]
> > (*by temporary i mean shallow stack or only
> > something like "1-element stack"-state)
> > - structore defined on caller side and pass a pointer to it - not sure, it all depends on how to do it probably, but not necessary good
> > - structure defined on api side, (and accessed
> > by something like handle) for some moment it seem lika a better option for me though I am also not sure
> > - other options?
> >
> > (probably some mix of 2 and 3, it is both sides of the structures with settings could work in some way)
> >
>
> ps some interesting thig here is that such structure in some sense could have 'not decided' storage, i mean not (said) caller side, not calee side either - this is interesting case (first time i see such thing)
(add)
i mean something like that
//Sprite fir = NewSprite ((atlas)"atlas.png", (posx)0 , (posy)0, (width)100, (height)100);
Sprite fir = NewSprite( (atlas)"atlas.png", (rect) (0,0,100,100) );
Sprite fir=NewSprite("atlas.png",0,0,100,100);
DrawSprite(fir, (where) (320, 200), (rotation) 0.0, (zoom) 1.0 )
there are at least three ways of 'baking' parameters here (bake all nine in one, bake
five in one, bake five and bake four in two etc)
(in such illustration it seem that bake structures should lay on caller side)
packing it all provides some disadvantages though (for example three separate calls instead of one - this is worse, though
it could be minimalised as those baking calls could be just asignments to structure
(with an option of adhoc creating stryucture
in the argument place it could be used both
as a divided on 2 lines and in 1 line
Sprite fir = {"atlas.png", {0,0,100,100}};
SpritePosition fir_pos
= {where (320, 200), angle 0.0, zoom 1.0 }; //named fields in initialisers
DrawSprite(fir, fir_pos );
or
DrawSprite(sprite {"atlas.png", {0,0,100,100}}, {where (320, 200), angle 0.0, zoom 1.0 };
bit strange looking but maybe there is some sense in this
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-12 01:29 -0700 |
| Message-ID | <ff30d992-acce-4fea-a7ea-7cb98cbf9393@googlegroups.com> |
| In reply to | #59929 |
W dniu niedziela, 12 kwietnia 2015 09:54:27 UTC+2 użytkownik fir napisał:
> W dniu niedziela, 12 kwietnia 2015 02:19:22 UTC+2 użytkownik fir napisał:
> > W dniu niedziela, 12 kwietnia 2015 01:35:44 UTC+2 użytkownik fir napisał:
> > > W dniu niedziela, 12 kwietnia 2015 00:38:46 UTC+2 użytkownik Bart napisał:
> > > > On 10/04/2015 19:54, Steve Thompson wrote:
> > > > > On Fri, Apr 10, 2015 at 12:22:05PM +0100, Bartc wrote:
> > > >
> > > > >> My example wasn't about defaults either, but if defaults were used, and
> > > > >> they happened to be (640,480) or you made it that way because it's in
> > > > >> one of your libraries, then you could actually write:
> > > > >>
> > > > >> initwindow();
> > > > >>
> > > > >> and get the default size.
> > > > >
> > > > > Christ. That's what descriptors are for.
> > > > >
> > > > > How about initwindow(params), where params is a structure pointer
> > > > > describing the window parameters. One of the things about wimp
> > > > > interfaces is that there are generally a zillion little things to
> > > > > set or tune. I would go mad if I was required to use functions
> > > > > expecting tens of function arguments, which is why in my own code I
> > > > > have settled on a parameters structure containing all of the flags and
> > > > > whatnot required to set up the module instance. My avl tree module
> > > > > has the following parameters structure:
> > > >
> > > > Nothing stops you doing that. And no-one is holding a gun to your head
> > > > saying you /must/ use keyword params.
> > > >
> > > > I've used keyword params in a dynamic language where /one/ param might
> > > > be a 'dict' type containing the multitudinous options, and where you
> > > > could override one of those options without affecting the default set.
> > > >
> > > > For use in C, there /already/ exist functions with a dozen or more
> > > > parameters (I'm only familiar with Win32); this scheme can be
> > > > superimposed on such functions.
> > > >
> > > > But, given a function drawimage() which:
> > > >
> > > > * Draws an image I
> > > > * Into window W (default: screen)
> > > > * At W position X,Y (default: top left or centred)
> > > > * At scale SX,SY or at single fixed aspect scale SX (default: 1.0, 1.0)
> > > > * Start position in I: IX,IY (default top left)
> > > > * Size of I to draw: (W,H) (default: entire image)
> > > > * Plus a dozen other options etc etc
> > > >
> > > > then /I/ would go mad if I had to painstakingly fill in a form - sorry a
> > > > struct - just before every call!
> > > >
> > > > Most of the time you just want to do:
> > > >
> > > > drawimage(I); // centred on screen
> > > > drawimage(W,I); // top left in W
> > > >
> > > > and sometimes:
> > > >
> > > > drawimage(W,I,scale:2) // double size
> > > >
> > >
> > > this is good example, (I got such routine in my library (draw sprite from textura atlas at screen in given pos zoom and rotation) even default sipmle call has a lot of params (seven
> > > if im not wrong) probably more extensive version could have few more (though i dont have that)
> > >
> > > so what with that. IMO as all thore parameters are meaningfull (and 'variable') there is not a problem to pass them each time as they are,
> > > though probably some could be 'cached' in some way
> > >
> > > how? for me it seem natural to giva a couple
> > > of (function) headers (more natural then default args in c++ way, as i said such default args are only a wrapper and imo is not quite clean)
> > >
> > > what other options?
> > > - global "temporary*" state with some api to manipulate it(such like opengl do) - seem not to much good for me, not so much bad but also not so much good imo [not sure]
> > > (*by temporary i mean shallow stack or only
> > > something like "1-element stack"-state)
> > > - structore defined on caller side and pass a pointer to it - not sure, it all depends on how to do it probably, but not necessary good
> > > - structure defined on api side, (and accessed
> > > by something like handle) for some moment it seem lika a better option for me though I am also not sure
> > > - other options?
> > >
> > > (probably some mix of 2 and 3, it is both sides of the structures with settings could work in some way)
> > >
> >
> > ps some interesting thig here is that such structure in some sense could have 'not decided' storage, i mean not (said) caller side, not calee side either - this is interesting case (first time i see such thing)
>
>
> (add)
>
>
> i mean something like that
>
> //Sprite fir = NewSprite ((atlas)"atlas.png", (posx)0 , (posy)0, (width)100, (height)100);
>
> Sprite fir = NewSprite( (atlas)"atlas.png", (rect) (0,0,100,100) );
>
> Sprite fir=NewSprite("atlas.png",0,0,100,100);
>
> DrawSprite(fir, (where) (320, 200), (rotation) 0.0, (zoom) 1.0 )
>
> there are at least three ways of 'baking' parameters here (bake all nine in one, bake
> five in one, bake five and bake four in two etc)
>
> (in such illustration it seem that bake structures should lay on caller side)
>
> packing it all provides some disadvantages though (for example three separate calls instead of one - this is worse, though
> it could be minimalised as those baking calls could be just asignments to structure
> (with an option of adhoc creating stryucture
> in the argument place it could be used both
> as a divided on 2 lines and in 1 line
>
> Sprite fir = {"atlas.png", {0,0,100,100}};
> SpritePosition fir_pos
> = {where (320, 200), angle 0.0, zoom 1.0 }; //named fields in initialisers
> DrawSprite(fir, fir_pos );
>
> or
>
> DrawSprite(sprite {"atlas.png", {0,0,100,100}}, {where (320, 200), angle 0.0, zoom 1.0 };
>
> bit strange looking but maybe there is some sense in this
ps what is a clue (central point) of this (or about)->
the point is that arg groups should be sorta 'automaticaly' baked
so there one could bake it without touching
foo definition
foo(1,2,3,4,5,6,7,8,9,10);
P p = {1,2,3,4,5,6,7,8,9,10};
foo((P) p);
R r = {1,2,3,4,5};
S s = {6,7,8,9,10};
foo((R) r, (S) s);
at least that seems so something like that here
--
Paul Desmond - Take Ten (Full Album)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-04-11 17:32 -0700 |
| Message-ID | <92b76a23-b2ee-4057-9433-d4539ad22cd7@googlegroups.com> |
| In reply to | #59920 |
> > this is good example, (I got such routine in my library (draw sprite from textura atlas at screen in given pos zoom and rotation) even default sipmle call has a lot of params (seven > if im not wrong) wrong, ut has nine if not eleven
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2015-04-11 23:33 +0000 |
| Message-ID | <DKGWbi.Di2.WxZUh@gmail.com> |
| In reply to | #59919 |
On Sat, Apr 11, 2015 at 11:38:28PM +0100, Bartc wrote: > On 10/04/2015 19:54, Steve Thompson wrote: > >On Fri, Apr 10, 2015 at 12:22:05PM +0100, Bartc wrote: > > >>My example wasn't about defaults either, but if defaults were used, and > >>they happened to be (640,480) or you made it that way because it's in > >>one of your libraries, then you could actually write: > >> > >> initwindow(); > >> > >>and get the default size. > > > >Christ. That's what descriptors are for. > > > >How about initwindow(params), where params is a structure pointer > >describing the window parameters. One of the things about wimp > >interfaces is that there are generally a zillion little things to > >set or tune. I would go mad if I was required to use functions > >expecting tens of function arguments, which is why in my own code I > >have settled on a parameters structure containing all of the flags and > >whatnot required to set up the module instance. My avl tree module > >has the following parameters structure: > > Nothing stops you doing that. And no-one is holding a gun to your head > saying you /must/ use keyword params. A good thing too, or I might have to jujitsu/kung-fu/karate the offending firearm and then use it on the perpetrators lower extremities. > I've used keyword params in a dynamic language where /one/ param might > be a 'dict' type containing the multitudinous options, and where you > could override one of those options without affecting the default set. > > For use in C, there /already/ exist functions with a dozen or more > parameters (I'm only familiar with Win32); this scheme can be > superimposed on such functions. I'm sure there are plenty of examples of such usage. My position is merely that it does not have to be that way, and that descriptors represent an efficient solution. I'm not rabidly passionate about my choice, and I was mainly influenced by the SCSI protocol. I have decided to use the scheme I propose as a standard interface in my own code, and so far it is working out well in every instance I have used it. > But, given a function drawimage() which: > > * Draws an image I > * Into window W (default: screen) > * At W position X,Y (default: top left or centred) > * At scale SX,SY or at single fixed aspect scale SX (default: 1.0, 1.0) > * Start position in I: IX,IY (default top left) > * Size of I to draw: (W,H) (default: entire image) > * Plus a dozen other options etc etc > > then /I/ would go mad if I had to painstakingly fill in a form - sorry a > struct - just before every call! Well, you don't actually have to do that. If you were using my scheme you'd only have something like the following: img_desc i; ... imagedesc_init(win, &i); i.bm = image; i.scalex = 0.5; i.scaley = 0.5; drawimage(&i); or some sensible variation appropriate to your API's capabilities. > Most of the time you just want to do: > > drawimage(I); // centred on screen > drawimage(W,I); // top left in W > > and sometimes: > > drawimage(W,I,scale:2) // double size Which can in fact be supported with macros. > >Now consider the notion of functions with default arguments in this > >scenario. First you must define the function such that it will accept > >all of the above structure elements individually AND you require that > > That would be silly. You wouldn't define /dozens/ of parameters like that. But a dozen function parameters is ok? > I suppose the compiler can define a structure for you and > >hide the details of its allocation and initialization to avoid the > >cost of pushing each individual function argument on the stack, but so > >what. It is still ugly. > > What's the cost of writing arguments to a struct in memory? And the > caller having to access those via a pointer? (And with some platforms, > many arguments are passed via registers; that is awkward when using > structs.) Pretty much the same cost as writing them to the stack, but as your function parameters will often be associated with variables on the stack anyhow, your function call requires a second copy of each. This may be acceptable if you are paranoid, but otherwise it will use twice as much stack. If I am not mistaken, typical ABIs reserve a small number of registers for passing function parameters and put everything in excess on the stack. x86-64 reserves five GP registers for function parameters, but x86-32 uses none. Arm reserves four. > Anyway for many of these kinds of functions (CreateWindowEx for > example), they are not going to be called millions of times per second. That is true. However, looking at a function call does not necessarily tell you what the parameters signify, particularly if they are constants. With a structure where elements are assigned it is immediately obvious what is being done, all things being equal. > >Furthermore, I suspect your default function arguments will be be > >program wide for any given module, > > Most defaults are going to be NULL or zero, no matter what the module. > Even if not zero, functions can often use zero to signal that a more > elaborate default is being requested (for example, which depends on the > value of other arguments, which is harder to express directly). It depends. If there are a bunch of flags your rule may not be true. > rather than specific to a module > >instance, which limits their utility considerably. So while I am not > >exactly pleased to find myself in agreement with Mr. Heathfield, I > >must say that this suggestion is a Bad Idea. The general technique > >as illustrated above is more than adequate to obviate the need for > >functions with more than two or three arguments, and that is a 'win'. > > I use that technique too. In fact I've demonstrated that above, where > both I and W are likely to be handles (pointers in C) to the relevant > descriptors. > > Perhaps you're misunderstanding how keyword params and defaults are > likely to be used. It will not be used so that I and W can be expanded > into their 28 and 46 respective elements to create a new set of > functions that start with 74 parameters plus all the rest! I don't think I am misunderstanding; I simply don't see the sense in it. Your approach is similar to the GCC extension that allows partial structure initialization by naming the elements as they appear in the static initializer. I don't think that is terribly helpful either, but it seems more useful than what you appear to be proposing. I will revisit some of your earlier arguments and see if I have missed anything important. Regards, Steve Thompson -- "If I had a nickel for every time some idiot called me about a computer problem that turned out to be user error, I would be able to retire and spend the rest of my days cultivating clues in my backyard hillside garden." -- MysteryDog in 24hoursupport.helpdesk.
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web