Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #58109 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2015-03-14 23:05 +0100 |
| Last post | 2015-03-18 08:29 -0700 |
| Articles | 20 on this page of 233 — 30 participants |
Back to article view | Back to comp.lang.c
New directions in C jacob navia <jacob@spamsink.net> - 2015-03-14 23:05 +0100
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-15 13:08 +1300
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 14:49 +0100
Re: New directions in C Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-04-07 10:03 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 01:36 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 02:07 -0700
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 11:10 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 10:36 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 11:43 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 11:01 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 13:11 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 12:51 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 06:11 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 13:37 +0000
Re: New directions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 13:44 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 15:23 +0100
Re: New directions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 15:07 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 10:24 -0700
Re: New directions in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-16 19:36 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 16:19 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-16 15:51 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 20:41 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:23 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:34 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:37 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:48 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:52 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 16:05 +0100
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-17 18:58 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-17 12:15 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-17 12:31 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 16:13 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-17 09:50 -0700
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 17:59 +0100
Re: New directions in C Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 17:16 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 18:24 +0100
Re: New directions in C Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 17:46 +0000
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 18:02 +0000
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-17 18:58 +0000
Re: New directions in C fmassei@gmail.com - 2015-03-17 13:04 -0700
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:17 -0700
Re: New directions in C Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-18 14:58 +0000
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-17 11:38 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-03-17 22:59 -0400
Re: New directions in C jacob navia <jacob@jacob.remcomp.fr> - 2015-03-18 09:05 +0100
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-03-18 08:56 -0400
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-18 10:27 +0100
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-17 09:35 -0700
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 17:44 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:11 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:14 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 05:24 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:50 +1300
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 07:21 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-17 01:50 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 21:22 +1300
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:55 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 22:08 +1300
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 07:01 -0700
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-03-16 08:27 -0400
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 13:31 +0100
Re: New directions in C Martin Shobe <martin.shobe@yahoo.com> - 2015-03-16 09:47 -0500
Re: New directions in C Kaz Kylheku <kaz@kylheku.com> - 2015-03-16 17:16 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:15 +0000
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-03-23 12:41 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 10:20 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-16 12:54 +0100
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-16 09:30 -0700
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-03-16 13:14 -0400
Jacob (Was: New directions in C) gazelle@shell.xmission.com (Kenny McCormack) - 2015-03-16 18:07 +0000
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 15:27 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-16 16:26 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 10:09 -0700
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-03-16 11:14 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-17 13:42 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 14:59 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:27 +0100
Re: New directions in C Johannes Bauer <dfnsonfsduifb@gmx.de> - 2015-03-17 15:34 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 16:18 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:35 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 01:23 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-22 11:00 +0000
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-29 16:56 +0000
Re: New directions in C asetofsymbols@gmail.com - 2015-03-29 10:04 -0700
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 10:56 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-29 19:30 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 12:25 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-29 20:46 +0100
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-29 21:46 +0000
Re: New directions in C Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:43 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 00:33 +0200
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-06 23:13 +0000
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-07 15:46 +1200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 01:37 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-07 21:08 +1200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 02:52 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-07 11:09 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 13:18 +0200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 13:03 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 06:16 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 16:18 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-07 07:37 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 23:31 +0200
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-07 22:40 -0400
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-08 16:57 +1200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 09:14 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 01:52 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-08 21:36 +1200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 02:51 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-04-08 22:23 +1200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 13:14 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 04:27 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 14:29 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 06:01 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 15:21 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 06:44 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 16:50 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 08:19 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-08 10:55 -0700
Re: New directions in C asetofsymbols@gmail.com - 2015-04-08 22:27 -0700
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-08 11:13 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 21:27 +0200
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-08 13:12 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 09:34 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-09 00:59 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 12:31 +0200
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-09 08:41 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-08 22:48 +0100
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-08 19:03 -0500
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 10:01 +0200
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-09 09:50 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-09 01:18 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-08 12:32 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-08 08:49 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 06:15 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-10 23:18 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-10 23:50 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-11 15:02 +0200
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-11 06:44 -0700
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-12 16:53 +0200
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-11 10:01 -0500
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-11 09:23 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-11 13:53 -0400
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-12 02:08 -0500
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-12 03:02 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-12 17:07 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-13 01:59 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-13 08:13 -0400
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-13 06:50 -0700
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-11 11:57 -0400
Re: New directions in C Richard Damon <Richard@Damon-Family.org> - 2015-04-08 08:36 -0400
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-08 15:01 +0200
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-07 04:58 -0500
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-07 11:16 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-04-07 13:30 +0200
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-07 12:03 +0100
Re: New directions in C Morris Dovey <mrdovey@iedu.com> - 2015-04-07 11:32 -0500
Re: New directions in C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-07 17:12 +0000
Re: New directions in C jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 19:41 +0200
Re: New directions in C Kaz Kylheku <kaz@kylheku.com> - 2015-03-29 18:21 +0000
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-29 21:29 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-29 14:26 -0700
Re: New directions in C Les Cargill <lcargill99@comcast.com> - 2015-03-29 19:10 -0500
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-30 09:48 +0000
Re: New directions in C jacob navia <jacob@jacob.remcomp.fr> - 2015-03-30 13:14 +0200
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-04-06 12:39 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-29 10:53 -0700
Re: New directions in C Michael Angelo Ravera <maravera@prodigy.net> - 2015-04-09 18:17 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 01:08 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 17:44 -0700
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-10 02:06 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 10:21 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 10:31 +0100
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 11:26 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 11:53 +0100
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 12:22 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 12:46 +0100
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-10 13:46 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 13:51 +0100
Re: New directions in C Steve Thompson <stevet810@gmail.com> - 2015-04-10 18:54 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 13:11 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 14:10 -0700
Re: New directions in C Steve Thompson <stevet810@gmail.com> - 2015-04-11 17:46 +0000
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-11 23:38 +0100
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 16:35 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 17:19 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-12 00:54 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-12 01:29 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-11 17:32 -0700
Re: New directions in C Steve Thompson <stevet810@gmail.com> - 2015-04-11 23:33 +0000
Re: New directions in C Reinhardt Behm <rbehm@hushmail.com> - 2015-04-10 09:23 -0300
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-04-10 13:31 +0100
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-10 13:29 -0500
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-04-10 12:12 -0700
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-10 13:46 -0700
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-10 18:30 -0500
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-11 12:21 -0700
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-12 01:01 -0500
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-12 13:03 -0700
Re: New directions in C Bartc <bc@freeuk.com> - 2015-04-12 23:29 +0100
Re: New directions in C Keith Thompson <kst-u@mib.org> - 2015-04-12 18:54 -0700
Re: New directions in C Robert Wessel <robertwessel2@yahoo.com> - 2015-04-13 00:52 -0500
Re: New directions in C James Kuyper <jameskuyper@verizon.net> - 2015-04-13 08:39 -0400
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:02 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-17 15:07 +0100
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-17 16:09 +0100
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-21 22:19 +0000
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 18:05 +0000
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-17 15:55 +1300
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 08:48 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-17 03:01 -0700
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 10:32 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 01:32 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 21:33 +1300
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-18 08:55 +0000
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 22:13 +1300
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-18 21:31 +1300
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 09:35 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 09:49 -0700
Re: New directions in C Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-03-16 10:07 +0100
Re: New directions in C jacob navia <jacob@spamsink.net> - 2015-03-16 10:51 +0100
Re: New directions in C Richard Heathfield <rjh@cpax.org.uk> - 2015-03-16 10:25 +0000
Re: New directions in C Bartc <bc@freeuk.com> - 2015-03-16 11:32 +0000
Re: New directions in C David Brown <david.brown@hesbynett.no> - 2015-03-16 13:06 +0100
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 05:35 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-16 13:46 +0000
Re: New directions in C Kaz Kylheku <kaz@kylheku.com> - 2015-03-16 17:07 +0000
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 10:19 -0700
Re: New directions in C Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:37 +1300
Re: New directions in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 05:42 -0700
Re: New directions in C raltbos@xs4all.nl (Richard Bos) - 2015-03-16 10:55 +0000
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-16 09:41 -0700
Re: New directions in C fir <profesor.fir@gmail.com> - 2015-03-18 08:29 -0700
Page 1 of 12 [1] 2 3 … 12 Next page →
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2015-03-14 23:05 +0100 |
| Subject | New directions in C |
| Message-ID | <me2bbi$5n9$1@speranza.aioe.org> |
This is the first of a series of messages here I propose to discuss the developments/enhancements to C in lcc-win. 1.1 Motivation The development of the C++ language has had an adverse effect in the development of C. Since C++ was designed as the “better C”, C was (and is) presented as the example of “how not to do things”, even if both languages retained a large common base. All development of C as an independent language has ceased and C has been relegated to the past. The need for a simple and efficient language persists however, and C is the language of choice for many systems running today and many new ones. The objective of this proposal is to correct certain missing features of C like its string library and the lack of a container library with a few improvements that have been part of many computer languages since a long time without introducing any new complexity or performance loss. The main conceptual difference between C and C++ is the object orientation. C is not object oriented, and it will never be so. This does not preclude the development of C as a language. Many programming tasks can be expressed without any need for object orientation, and in fact in many programming tasks the object orientation is purely artificial, imposed by external factors and not emerging naturally from the analysis of the application itself. This document then, proposes the development of several enhancements to the language, mostly compatible with their C++ counterparts. The main aim is to make C programming easier, more secure and more flexible than it is now. Each addition is justified by the improvements it brings, and possible uses and mis-uses are discussed. All this developments are implemented using the lcc-win compiler system (Available from http://www.cs.virginia.edu/~lcc-win32). These are not just proposals but a reference implementation exists, and it is widely distributed since several years. 1.2 Overview The main propositions developed here are: 1. Operator overloading 2. Garbage Collection 3. Generic functions 4. Default function arguments 5. References All this propositions have as a goal increasing the level of abstraction used by C programmers without unduly increasing the complexity of the implementation. All this enhancements have added only about 2 000 lines of code to the original code of the lcc-win32 compiler. This is extremely small, and proves that apparently difficult extensions can be inserted into an existing compiler without much effort. Each enhancement can be viewed separately, but their strength is only visible when they all work together. The first part of this documents details the specifications for the proposed changes, the second describes applications for them in the form of a string library and a container library. There you see how these enhancements work, and how they could be used to implement a good standard library for C.
[toc] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-15 13:08 +1300 |
| Message-ID | <cmk0sdFlu63U1@mid.individual.net> |
| In reply to | #58109 |
jacob navia wrote: > This is the first of a series of messages here I propose to discuss the > developments/enhancements to C in lcc-win. > > 1.1 Motivation > The development of the C++ language has had an adverse effect in the > development of C. That's certainly a contentions claim. C and C++ have evolved and they tend to fill different niches. > Since C++ was designed as the “better C”, C was (and is) presented as > the example of “how not to do things”, even if both languages retained a > large common base. All development of C as an independent language has > ceased and C has been relegated to the past. Ditto. Both the C and C++ standards were revised, with a number of similar additions, in the same year. > The need for a simple and efficient language persists however, and C is > the language of choice for many systems running today and many new ones. > The objective of this proposal is to correct certain missing features of > C like its string library and the lack of a container > library with a few improvements that have been part of many computer > languages since a long time without introducing any new complexity or > performance loss. > > The main conceptual difference between C and C++ is the object > orientation. C is not object oriented, and it will never be so. Neither is C++. Sure C++ supports object oriented programming, but it isn't exclusively and OO language. This is abundantly clear from the fact that the majority of the C++ standard library isn't oriented programming. > This > does not preclude the development of C as a language. Many programming > tasks can be expressed without any need for object orientation, > and in fact in many programming tasks the object orientation is purely > artificial, imposed by external factors and not emerging naturally from > the analysis of the application itself. That is a flaw of an application's design, not the language used to implement it. Using OO as a reason not to use C++ is a flawed argument. > This document then, proposes the development of several enhancements to > the language, mostly compatible with their C++ counterparts. The main > aim is to make C programming easier, more secure and more flexible than > it is now. Each addition is justified by the improvements it brings, and > possible uses and mis-uses are discussed. It appears all of them are available now (using a more natural syntax) with the appropriate subset of C++. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2015-03-17 14:49 +0100 |
| Message-ID | <me9bct$5rh$1@news.albasani.net> |
| In reply to | #58116 |
On 15.03.2015 01:08, Ian Collins wrote: > It appears all of them are available now (using a more natural syntax) > with the appropriate subset of C++. Heretic! If Jacob would use C++, he couldn't reinvent the wheel using C! Next thing you know someone will tell him that the STL exists. SCNR, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>
[toc] | [prev] | [next] | [standalone]
| From | Anand Hariharan <mailto.anand.hariharan@gmail.com> |
|---|---|
| Date | 2015-04-07 10:03 -0700 |
| Message-ID | <0560dc28-dae7-40a6-840c-48c931bddcea@googlegroups.com> |
| In reply to | #58116 |
On Saturday, March 14, 2015 at 7:08:54 PM UTC-5, Ian Collins wrote: > jacob navia wrote: (...) > > Since C++ was designed as the "better C", C was (and is) presented as > > the example of "how not to do things", even if both languages retained a > > large common base. All development of C as an independent language has > > ceased and C has been relegated to the past. > > Ditto. Both the C and C++ standards were revised, with a number of > similar additions, in the same year. > With namespaces, it is far easier to expand C++'s library without needing to introduce new keywords. The 2003 C++ standard was entirely TR1 library extensions being incorporated into the standard library. On the contrary, the best C can do is reserve names starting with identifiers or str or such. There is considerable inertia in adding functionality to C even if it is library-only. Ad-hoc implementing data structures such as linked lists gets tiresome after a while -- specially when the code-base written by multiple people with different styles, gets into maintenance mode. A new language is highly unlikely to gain traction unless it has the blessing of a big corporation such as Sun/Oracle or Microsoft. - Anand
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-16 01:36 -0700 |
| Message-ID | <ce6c22f4-fea6-4ef2-a3d3-b6fa2a1ca7f9@googlegroups.com> |
| In reply to | #58109 |
such 'directions' (changes) are not in the natural spirit of c, so imo this IS NOT C,, thus those are not new directions in c (at least i wouldnt call it like that[!]) sadle even comitee changes may go this wrng way, comitee is more conservative (hopefully) but imo probably they are conservative to only some percent of c spirit - and thus sadly probably they also warp a bit
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-16 02:07 -0700 |
| Message-ID | <5661d082-b964-4d03-9b19-6d874e69f7f7@googlegroups.com> |
| In reply to | #58163 |
anyway if you re creator/maintainer (?) of lcc-win (somewhat known compiler i think) congratulations, [Could you maybe say a bit more on this? (on lcc and lcc-win)]
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2015-03-16 11:10 +0100 |
| Message-ID | <me6a74$cij$2@speranza.aioe.org> |
| In reply to | #58164 |
I have been working with this program the last 20 years. I implemented the C99 standard, and was insulted to no end by the regulars here because "C99 was not portable", the only standard they would accept was the C89 standard of 1989. I have implemented a replica of the STL in plain C. I presented it tothe committee in Portland. It was rejected after a small discussion of one hour. People should use C++. Here, you are the only one that somehow has said anything with meaning. But you represent the current view in thisnewsgroup when you say: <quote> such 'directions' (changes) are not in the natural spirit of c, so imo this IS NOT C,, thus those are not new directions in c <end quote>
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-16 10:36 +0000 |
| Message-ID | <me6bm8$q49$1@dont-email.me> |
| In reply to | #58167 |
On 16/03/15 10:10, jacob navia wrote: > > I have been working with this program the last 20 years. > > I implemented the C99 standard, and was insulted to no end by the > regulars here because "C99 was not portable", the only standard they > would accept was the C89 standard of 1989. I am on record as being less than enthusiastic about C99. I will cheerfully go on record as being less than enthusiastic about C11. I think C99 remains less portable than C90. Are there any C11 implementations yet? I don't know. 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? > I have implemented a replica of the STL in plain C. I presented it tothe > committee in Portland. It was rejected after a small discussion of one > hour. People should use C++. 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. <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 | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2015-03-16 11:43 +0100 |
| Message-ID | <me6c50$hbp$1@speranza.aioe.org> |
| In reply to | #58169 |
Le 16/03/2015 11:36, Richard Heathfield a écrit : > > 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. > A language without a STL forces you to reimplement linked lists for each application you want, or rewrite my implementation if you want. That is why there are thousands of different implementations of linked lists in every C program and thousands of different and incompatible libraries. The interface I proposed is just that: an interface. If you do not like the standard implementation of your compiler vendor you can write your own, keeping the interface and maybe improving it for you, etc. Your own implementation would be compatibme with other implementations if you keep the interface. But the committee declared that it is more important for the language to start implementing a parallel programming standard.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-16 11:01 +0000 |
| Message-ID | <me6d4k$vn4$1@dont-email.me> |
| In reply to | #58173 |
On 16/03/15 10:43, jacob navia wrote: <snip> > A language without a STL forces you to reimplement linked lists for each > application you want, That's one way to put it. Another way to put it is that C doesn't force us to think about linked lists in a particular way. Rather, we can design the interface to fit in with the way we prefer to think about linked lists. And we might make the same choice every time, or we might choose on a case-by-case basis. That's not a constraint. That's freedom. <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 | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2015-03-16 13:11 +0100 |
| Message-ID | <me6h9v$u5g$1@speranza.aioe.org> |
| In reply to | #58176 |
Le 16/03/2015 12:01, Richard Heathfield a écrit : > On 16/03/15 10:43, jacob navia wrote: > > <snip> > >> A language without a STL forces you to reimplement linked lists for each >> application you want, > > That's one way to put it. Another way to put it is that C doesn't force > us to think about linked lists in a particular way. Note that you DO NOT HAVE TO THINK ABOUT LINKED LIST IN ANY PARTICULAR WAY EITHER WHEN USING THE CCL! The CCL is an INTERFACE for linked lists and says NOTHING ABOUT THE IMPLEMENTATION! > Rather, we can > design the interface to fit in with the way we prefer to think about > linked lists. You can do that with the CCL too! > And we might make the same choice every time, or we might > choose on a case-by-case basis. That's not a constraint. That's freedom. > The CCL doesn't constrain you in ANY way. You keep your freedom to think about linked lists as you want. But the INTERFACE to the rest of the software is standard, so YOUR way ofthinking about linked lists is compatible with your library that you got from XYZ and is compatible with all other implementations.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-16 12:51 +0000 |
| Message-ID | <me6ji6$ok7$1@dont-email.me> |
| In reply to | #58181 |
On 16/03/15 12:11, jacob navia wrote: > Le 16/03/2015 12:01, Richard Heathfield a écrit : >> On 16/03/15 10:43, jacob navia wrote: >> >> <snip> >> >>> A language without a STL forces you to reimplement linked lists for each >>> application you want, >> >> That's one way to put it. Another way to put it is that C doesn't force >> us to think about linked lists in a particular way. > > Note that you DO NOT HAVE TO THINK ABOUT LINKED LIST IN ANY PARTICULAR > WAY EITHER WHEN USING THE CCL! There's no need to shout. When we implement a linked list (or whatever ADT it might be), we specify an interface, and that interface then constrains our user-programmers. > > The CCL is an INTERFACE for linked lists and says NOTHING ABOUT THE > IMPLEMENTATION! Sure, but it specifies the interface, and that nails you to a particular interface. Let's consider a simpler example: strings. (Presumably we are talking about stretchy strings here, not necessarily just simple C strings.) How many different interfaces can we think of for strings? First decision: will our strings be legitimate C strings (null-terminated), or counted, or both? (All these choices have advantages and disadvantages, and the Right Choice may depend on the application.) Second decision: will the type be opaque or transparent? This will have a major impact on usage. Some people prefer type opacity, and other people prefer type transparency. Third decision: resource acquisition and initialisation. Do we combine these two, or do we make them separate? Off-hand, I can't think of a good reason to separate them, but just maybe there's a reason I haven't thought of. Fourth decision: error-handling - always a bug-bear for libraries. Do we return an error code for every function? That's a good way to do it, but it makes get_length() fiddly to use. Or do we pass in a pointer to an error status object? That's another good way to do it, but it's always, always fiddly. I'll stop there, because I hope I've made my point. *All* of these decisions will have an impact on interface design, and so, no doubt, will others. There is rarely One Right Way to do these things, and so any generic library will colour the way in which we have to think about lists via the way the library author decides to design the interface. >> Rather, we can >> design the interface to fit in with the way we prefer to think about >> linked lists. > > You can do that with the CCL too! Ah, I didn't realise we could re-design the interface... > >> And we might make the same choice every time, or we might >> choose on a case-by-case basis. That's not a constraint. That's freedom. >> > > The CCL doesn't constrain you in ANY way. You keep your freedom to think > about linked lists as you want. But the INTERFACE to the rest of the > software is standard, ...and it seems that, after all, we can't. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-16 06:11 -0700 |
| Message-ID | <4f9b1fc3-6390-4882-9fb8-8f0c9441d720@googlegroups.com> |
| In reply to | #58191 |
On Monday, March 16, 2015 at 12:51:10 PM UTC, Richard Heathfield wrote: > > Let's consider a simpler example: strings. (Presumably we are talking > about stretchy strings here, not necessarily just simple C strings.) How > many different interfaces can we think of for strings? > > First decision: will our strings be legitimate C strings > (null-terminated), or counted, or both? (All these choices have > advantages and disadvantages, and the Right Choice may depend on the > application.) > > Second decision: will the type be opaque or transparent? This will have > a major impact on usage. Some people prefer type opacity, and other > people prefer type transparency. > > Third decision: resource acquisition and initialisation. Do we combine > these two, or do we make them separate? Off-hand, I can't think of a > good reason to separate them, but just maybe there's a reason I haven't > thought of. > > Fourth decision: error-handling - always a bug-bear for libraries. Do we > return an error code for every function? That's a good way to do it, but > it makes get_length() fiddly to use. Or do we pass in a pointer to an > error status object? That's another good way to do it, but it's always, > always fiddly. > > I'll stop there, because I hope I've made my point. *All* of these > decisions will have an impact on interface design, and so, no doubt, > will others. There is rarely One Right Way to do these things, and so > any generic library will colour the way in which we have to think about > lists via the way the library author decides to design the interface. > But for 95% at least of programs that use strings but are not limited in any way by their string handling facilities, we just need a format for strings. Store them as ASCIIZ arrays, utf-8, using a w_char or a short or an int. Use EBCDIC, a linked list of characters, anything, we just don't care, as long as we have a format in which we can pass the message "Hello Fred" and display it in some Fred-readable way.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-03-16 13:37 +0000 |
| Message-ID | <me6ma8$4qo$1@dont-email.me> |
| In reply to | #58193 |
On 16/03/15 13:11, Malcolm McLean wrote: > On Monday, March 16, 2015 at 12:51:10 PM UTC, Richard Heathfield wrote: >> <snip> >> >> I'll stop there, because I hope I've made my point. *All* of these >> decisions will have an impact on interface design, and so, no doubt, >> will others. There is rarely One Right Way to do these things, and so >> any generic library will colour the way in which we have to think about >> lists via the way the library author decides to design the interface. >> > But for 95% at least of programs that use strings but are not limited in any > way by their string handling facilities, we just need a format for strings. You're missing the point. We're talking about ADT interface design, and how the decisions we make about usage colour the way in which we specify the interface. Strings are just a very simple example of an ADT candidate. But the same arguments apply to dictionaries, bags, queues, priority queues, graphs... whatever. We're not just talking about Hello World. -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-03-16 13:44 +0000 |
| Message-ID | <878uexm4ys.fsf@bsb.me.uk> |
| In reply to | #58181 |
jacob navia <jacob@spamsink.net> writes: > Le 16/03/2015 12:01, Richard Heathfield a écrit : >> On 16/03/15 10:43, jacob navia wrote: >> >> <snip> >> >>> A language without a STL forces you to reimplement linked lists for each >>> application you want, >> >> That's one way to put it. Another way to put it is that C doesn't force >> us to think about linked lists in a particular way. > > Note that you DO NOT HAVE TO THINK ABOUT LINKED LIST IN ANY PARTICULAR > WAY EITHER WHEN USING THE CCL! > > The CCL is an INTERFACE for linked lists and says NOTHING ABOUT THE > IMPLEMENTATION! If that is literally true, then it's shame because there are some things about the implementation that are useful to know. For example, C++ containers have specified complexity bound on the cost of the various operations. This does not say a lot about the implementation, but it's more than nothing. >> Rather, we can >> design the interface to fit in with the way we prefer to think about >> linked lists. > > You can do that with the CCL too! > >> And we might make the same choice every time, or we might >> choose on a case-by-case basis. That's not a constraint. That's freedom. > > The CCL doesn't constrain you in ANY way. You keep your freedom to > think about linked lists as you want. I don't see how this is possible -- the interface *is* a constraint and sometimes a non-trivial one. Your interface constrains the access to those function that you provide. For example, how do I insert an element into a list at a position determined by some condition? (The obvious example being to insert an element so as to preserve some kind of ordering.) It looked clunky using your list interface, but I might have missed the right functions to use. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2015-03-16 15:23 +0100 |
| Message-ID | <me6p0o$i78$1@speranza.aioe.org> |
| In reply to | #58197 |
Le 16/03/2015 14:44, Ben Bacarisse a écrit : > If that is literally true, then it's shame because there are some things > about the implementation that are useful to know. For example, C++ > containers have specified complexity bound on the cost of the various > operations. This does not say a lot about the implementation, but it's > more than nothing. Obviously each implementation could document that. The CCL by itself doesn't preclude ANY option so as to give you the maximum flexibility
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-03-16 15:07 +0000 |
| Message-ID | <87zj7dj807.fsf@bsb.me.uk> |
| In reply to | #58202 |
jacob navia <jacob@spamsink.net> writes: > Le 16/03/2015 14:44, Ben Bacarisse a écrit : >> If that is literally true, then it's shame because there are some things >> about the implementation that are useful to know. For example, C++ >> containers have specified complexity bound on the cost of the various >> operations. This does not say a lot about the implementation, but it's >> more than nothing. > > Obviously each implementation could document that. The CCL by itself > doesn't preclude ANY option so as to give you the maximum flexibility That means I could write an application that uses CCL arrays and discover that some target systems have an O(n) indexing operation operation. That could sink the design. I'd want to have some minimal guarantees first. I don't see the harm in saying that indexing must be O(1) in time (possibly amortised). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-16 10:24 -0700 |
| Message-ID | <3a9cddf6-f235-4ccc-abf8-f81e3f3d8d28@googlegroups.com> |
| In reply to | #58208 |
On Monday, March 16, 2015 at 3:07:44 PM UTC, Ben Bacarisse wrote: > jacob navia <jacob@spamsink.net> writes: > > That means I could write an application that uses CCL arrays and > discover that some target systems have an O(n) indexing operation > operation. That could sink the design. I'd want to have some minimal > guarantees first. I don't see the harm in saying that indexing must be > O(1) in time (possibly amortised). > What if array access is O(log log N) dues to some extremely clever algorithm that keeps small arrays in caches and farms out huge ones to disk?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-03-16 19:36 +0000 |
| Message-ID | <87oanska3x.fsf@bsb.me.uk> |
| In reply to | #58226 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, March 16, 2015 at 3:07:44 PM UTC, Ben Bacarisse wrote: >> jacob navia <jacob@spamsink.net> writes: >> >> That means I could write an application that uses CCL arrays and >> discover that some target systems have an O(n) indexing operation >> operation. That could sink the design. I'd want to have some minimal >> guarantees first. I don't see the harm in saying that indexing must be >> O(1) in time (possibly amortised). >> > What if array access is O(log log N) dues to some extremely clever algorithm that > keeps small arrays in caches and farms out huge ones to disk? What of it? It would not non-conforming but in a way that probably wouldn't matter to anyone. And a conforming implementation may have a shockingly slow O(1) "vector" type whose performance would matter to almost everyone. Neither case would make me prefer to have *no* complexity specified. Would you? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-16 16:19 -0700 |
| Message-ID | <9e74beba-2850-44ed-9291-c471c10ca7cc@googlegroups.com> |
| In reply to | #58242 |
On Monday, March 16, 2015 at 7:36:59 PM UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > On Monday, March 16, 2015 at 3:07:44 PM UTC, Ben Bacarisse wrote: > >> jacob navia <jacob@spamsink.net> writes: > >> > >> That means I could write an application that uses CCL arrays and > >> discover that some target systems have an O(n) indexing operation > >> operation. That could sink the design. I'd want to have some minimal > >> guarantees first. I don't see the harm in saying that indexing must be > >> O(1) in time (possibly amortised). > >> > > What if array access is O(log log N) dues to some extremely clever > > algorithm that keeps small arrays in caches and farms out huge ones > > to disk? > > What of it? It would not non-conforming but in a way that probably > wouldn't matter to anyone. And a conforming implementation may have a > shockingly slow O(1) "vector" type whose performance would matter to > almost everyone. Neither case would make me prefer to have *no* > complexity specified. Would you? > By demanding O constant random access, you're more or less constraining the array type to be wrapper over an in-memory buffer. To be fair you also said "amortised" which gives a little leeway. But there's not much point having a wrapper over a memory buffer. You can just as easily access the buffer directly. The usual reason for the wrapper is to allow the internals to change. But if the internals change, the access time is likely to change, in practice probably to logarithmic time.
[toc] | [prev] | [next] | [standalone]
Page 1 of 12 [1] 2 3 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web