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 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-18 01:17 -0700 |
| Message-ID | <be41b0af-1759-47b6-99dc-062f60fe3d61@googlegroups.com> |
| In reply to | #58327 |
On Tuesday, March 17, 2015 at 5:16:16 PM UTC, Greg Martin wrote: > On 2015-03-17, jacob navia <jacob@spamsink.net> wrote: > > I skimmed the documentation and it looks like you've put a lot of effort > into it. > > Why do you feel it needs to be standardized as part of C? > It's the kind of thing that's a lot more useful as a standard. Back in the early days of C++, virtually everyone rolled their own string class. Of course you can concatenate strings more effectively in C++ than in C, there was a case for the classes. But you couldn't really use one in serious code, unless you were the configuration manager and defined a string format for the entire codebase, simply because strings need to be a part of the standard language.
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg.at.softsprocket@dot.com> |
|---|---|
| Date | 2015-03-18 14:58 +0000 |
| Message-ID | <uogOw.38449$pp5.11527@fx29.iad> |
| In reply to | #58391 |
On 2015-03-18, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Tuesday, March 17, 2015 at 5:16:16 PM UTC, Greg Martin wrote: >> On 2015-03-17, jacob navia <jacob@spamsink.net> wrote: >> >> I skimmed the documentation and it looks like you've put a lot of effort >> into it. >> >> Why do you feel it needs to be standardized as part of C? >> > It's the kind of thing that's a lot more useful as a standard. > I don't see that. A lot of people use the containers in glib. It's a successful library and they have been using it a long time. Many of us have our own container libraries and aren't looking for something else. Introducing a new syntax can be of value but for a new library to be meaningful, in a language where libraries are easily used and commonly available, it needs to be pretty fundamental. Threads have been brought up as an example of something that an attempt was made to bring into the standard. I understand the desire to standardize but am reminded of a joke, I think football is a great game but it would be greatly improved if they played it on ice and used sticks and perhaps a small rubber disk instead of a ball. > Back in the early days of C++, virtually everyone rolled their own > string class. Of course you can concatenate strings more effectively > in C++ than in C, there was a case for the classes. But you couldn't > really use one in serious code, unless you were the configuration > manager and defined a string format for the entire codebase, > simply because strings need to be a part of the standard language. > Well, string is a fundamental type and C strings could certainly be improved on; I would suggest your example can be used as a counter to an argument about adding containers to the standard library. -- http://www.softsprocket.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-17 11:38 -0700 |
| Message-ID | <87iodzzcxz.fsf@kst-u.example.com> |
| In reply to | #58323 |
jacob navia <jacob@spamsink.net> writes:
[...]
> http://code.google.com/p/ccl/
In case you haven't heard, you'll need to migrate it elsewhere.
http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-03-17 22:59 -0400 |
| Message-ID | <sS5Ow.65920$Op6.1408@fx16.iad> |
| In reply to | #58323 |
On 3/17/15 12:59 PM, jacob navia wrote: > Le 17/03/2015 17:50, fir a écrit : >> critiques repeat some banal and not >> to much interesting critique > > Well, that is the problem. Nobody of the critics has read the CCL > documentation and from that, told me why something would not work, or is > wrong TECHNICALLY. > > All I read is that "C++ has that already" or whatever, general political > statements that do not have any technical content. > > For instance, the CCL implements the observer pattern (as discussed in > the "Design Patterns" seminal book), what is NOT implemented in the C++ > STL. > > The CCL was started when C++ did NOT have hash tables. I proposed a hash > table implementation from the start. > > None of the critics refers to that, or to the design documents or to the > FREELY AVAILABLE CODE! > > http://code.google.com/p/ccl/ > > Because (contrary to lcc) the C containers library is available with > full source code, using ANSI C 89 as the base language. And NO it is NOT > GPL, you can do WHATEVER YOU WANT WITH THE CODE, even sell it if you > feel like it. Jacob, I don't consider myself as a "critic" of you, and have looked at your proposal, though only somewhat briefly. My first impression on reading it was that someone was trying to do a "cfront" version of the STL in C. I see a lot of "vtables" being setup to provide an object oriented version of a number of standard containers. I become particularly confused at your surprise that it wasn't looked favorably, since you began this thread with the comment: The main conceptual difference between C and C++ is the object orientation. C is not object oriented, and it will never be so. And then seem surprised that the committee didn't like someone writing a "C++ Style" library and asking for it to be standardized. I will say that I disagree with your thesis that C will never be object oriented, Your CCL shows that it is quite possible to write "Object Oriented" code in C, what C lacks is direct support for cooked into the language. A second issue that I saw was that is seemed that some of the interfaces seemed overly complex to implement. The biggest one was the Memory Manager object. You request that ALL such objects implement 4 functions, equivalents to malloc, free, realloc, and calloc. One big question is why are you requiring calloc()? As a built in library, calloc make sense as the implementation may have a specially quick way to zero memory, and thus could use this. As to requiring the user to provide one if they want to provide their own memory manager is an anti-pattern, as the user will need to use "standard library" interfaces to do the clear, while the standard library might be able to do something faster. I would make sense to skip the calloc member, and just use the malloc for all allocations. (If calloc does provide some significant speed advantage, then the library has the option to replace calls to the malloc function followed by a clear, after determining that you are using the built in malloc with a call to calloc. The second question is why have both malloc and realloc and members. Once you have required realloc in the table, malloc is unneeded as any call to malloc can become a realloc with a null pointer for the old object (many libraries implement malloc this way). The presence of this sort of stuff gives me the impression that the library doesn't live within what I consider the "Spirit of C", (Which is what I consider the big difference between C and C++), that C is a "lite" language where a simple statement generates simple code that can be expected to run fast. That you REALLY don't pay for what you don't use. (C++ treats this as an ideal, but often sacrifices it) Typically in C, when you iterate through a linked list, the iteration is just a couple of machine instructions long, as are most other basic operations on the container (unless they include operations like balancing a tree or inserting into the middle of a contiguous buffer, that inherently). My feeling (which may be wrong) is that CCL isn't going to be quite that efficient in processing containers as it wants to make the containers "generic".
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-03-18 09:05 +0100 |
| Message-ID | <mebbjg$vus$1@speranza.aioe.org> |
| In reply to | #58376 |
Le 18/03/2015 03:59, Richard Damon a écrit : > One big question is why are you requiring calloc()? As a built in > library, calloc make sense as the implementation may have a specially > quick way to zero memory, and thus could use this. As to requiring the > user to provide one if they want to provide their own memory manager is > an anti-pattern, as the user will need to use "standard library" > interfaces to do the clear, while the standard library might be able to > do something faster. I would make sense to skip the calloc member, and > just use the malloc for all allocations. (If calloc does provide some > significant speed advantage, then the library has the option to replace > calls to the malloc function followed by a clear, after determining that > you are using the built in malloc with a call to calloc. Well, many operatinng systemshave an option for allocating zero cleared memory. That, and the fact that you can always use memset of the memory block after calling calloc it is not a great deal to implement. On the other hand it DOES complexify the interface... I am not 100% sure you are wrong or you are right. I hesitate.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-03-18 08:56 -0400 |
| Message-ID | <WBeOw.65017$yX2.36204@fx18.iad> |
| In reply to | #58388 |
On 3/18/15 4:05 AM, jacob navia wrote: > Le 18/03/2015 03:59, Richard Damon a écrit : >> One big question is why are you requiring calloc()? As a built in >> library, calloc make sense as the implementation may have a specially >> quick way to zero memory, and thus could use this. As to requiring the >> user to provide one if they want to provide their own memory manager is >> an anti-pattern, as the user will need to use "standard library" >> interfaces to do the clear, while the standard library might be able to >> do something faster. I would make sense to skip the calloc member, and >> just use the malloc for all allocations. (If calloc does provide some >> significant speed advantage, then the library has the option to replace >> calls to the malloc function followed by a clear, after determining that >> you are using the built in malloc with a call to calloc. > > Well, many operatinng systemshave an option for allocating zero cleared > memory. That, and the fact that you can always use memset of the memory > block after calling calloc it is not a great deal to implement. > > On the other hand it DOES complexify the interface... I am not 100% sure > you are wrong or you are right. I hesitate. Yes, as I said, there are good reason for the standard to provide such a function to the user, as the standard library can do the job a lot better than the user (like the one that you mention, although it does often have the limitation that the returned block must be the only object on the given memory page). It does NOT make sense to ask the user to provide such an operation unless you really don't expect the user to provide a custom allocator, as when he does, then he no longer has the option to use that type of trick. Simplifying the interface can be helpful. In fact, if you either wrap realloc or know that it will return NULL on a call with size of 0, you can replace you entire "Memory Manager" structure with a single pointer to function, calling it with a NULL pointer for initial allocation or 0 size when all done with the memory, using both if needing to resize a block.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-18 10:27 +0100 |
| Message-ID | <mebgcl$un7$1@dont-email.me> |
| In reply to | #58376 |
On 18/03/15 03:59, Richard Damon wrote: > On 3/17/15 12:59 PM, jacob navia wrote: >> Le 17/03/2015 17:50, fir a écrit : >>> critiques repeat some banal and not >>> to much interesting critique >> >> Well, that is the problem. Nobody of the critics has read the CCL >> documentation and from that, told me why something would not work, or is >> wrong TECHNICALLY. >> >> All I read is that "C++ has that already" or whatever, general political >> statements that do not have any technical content. >> >> For instance, the CCL implements the observer pattern (as discussed in >> the "Design Patterns" seminal book), what is NOT implemented in the C++ >> STL. >> >> The CCL was started when C++ did NOT have hash tables. I proposed a hash >> table implementation from the start. >> >> None of the critics refers to that, or to the design documents or to the >> FREELY AVAILABLE CODE! >> >> http://code.google.com/p/ccl/ >> >> Because (contrary to lcc) the C containers library is available with >> full source code, using ANSI C 89 as the base language. And NO it is NOT >> GPL, you can do WHATEVER YOU WANT WITH THE CODE, even sell it if you >> feel like it. > > > Jacob, > I don't consider myself as a "critic" of you, and have looked at your > proposal, though only somewhat briefly. My first impression on reading > it was that someone was trying to do a "cfront" version of the STL in C. > I see a lot of "vtables" being setup to provide an object oriented > version of a number of standard containers. > > I become particularly confused at your surprise that it wasn't looked > favorably, since you began this thread with the comment: > > The main conceptual difference between C and C++ is the object > orientation. C is not object oriented, and it will never be so. > > And then seem surprised that the committee didn't like someone writing a > "C++ Style" library and asking for it to be standardized. > > I will say that I disagree with your thesis that C will never be object > oriented, Your CCL shows that it is quite possible to write "Object > Oriented" code in C, what C lacks is direct support for cooked into the > language. > "Object oriented" is a style of programming, not a feature of a programming language. A particular programming language may make it easy or efficient to implement OOP (as C++ does), and it may strongly encourage it (as Smalltalk does, where almost everything is an object). But it is perfectly possible, and sometimes very useful, to write object oriented code in C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-03-17 09:35 -0700 |
| Message-ID | <87r3snzio3.fsf@kst-u.example.com> |
| In reply to | #58297 |
Johannes Bauer <dfnsonfsduifb@gmx.de> writes:
> On 16.03.2015 20:41, jacob navia wrote:
>> Because if you use the ccl and the ccl is recognized by the language,
>
> Which it never will.
>
>> the idea behind the CCL and that is hy I spent 2 years implementing it
>
> That's not an "idea". It's like saying "The idea behind my castle built
> of Emmentaler cheese is that I've spent 2 years collecting cheese and
> hot gluing it together".
He didn't say that the "idea" behind CCI is that he spent 2 years
implementing it. You quoted him out of context to make it appear that
way. Anyone interested in what jacob actually said should read the
parent article.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Johannes Bauer <dfnsonfsduifb@gmx.de> |
|---|---|
| Date | 2015-03-17 17:44 +0100 |
| Message-ID | <me9lll$q0m$1@news.albasani.net> |
| In reply to | #58319 |
On 17.03.2015 17:35, Keith Thompson wrote: >> That's not an "idea". It's like saying "The idea behind my castle built >> of Emmentaler cheese is that I've spent 2 years collecting cheese and >> hot gluing it together". > > He didn't say that the "idea" behind CCI is that he spent 2 years > implementing it. You quoted him out of context to make it appear that > way. Anyone interested in what jacob actually said should read the > parent article. Yes, you are correct. I apologize for this, I honestly read him wrong. All mockery aside but I didn't mean to mislead anyone. Thank you for your correction. Cheers, 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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-18 01:11 -0700 |
| Message-ID | <373e0ea4-cf6b-407d-a847-5e7345385d43@googlegroups.com> |
| In reply to | #58297 |
On Tuesday, March 17, 2015 at 2:24:00 PM UTC, Johannes Bauer wrote: > On 16.03.2015 20:41, jacob navia wrote: > > > and 5000 dollars for a trip to Portland to present it to the committee. > > Where they completely tore it apart. And you could have gotten the same > result $5000 cheaper if you would just take criticism seriously. > No, they rejected it as an addition to the standard library. That doesn't mean they felt the work was bad or that they weren't interested in using it themselves, just that it wasn't right for the standard as things stood in 2014.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-03-21 22:14 +0000 |
| Message-ID | <550dec0b.34933828@news.xs4all.nl> |
| In reply to | #58243 |
jacob navia <jacob@spamsink.net> wrote: > Le 16/03/2015 16:51, Richard Bos a écrit : > > If not, I currently fail to see the advantage. I can choose to implement > > my own linked list using my own interface, or I can implement my own > > linked list using_your_ interface. Please tell me why I'd choose the > > latter over the former. > > Because if you use the ccl and the ccl is recognized by the language, > your implementation would be compatible with ALL other list implementations! Erm... no. Not beyond the most trivial of lists - in which case you might as well use Bob Stout's Snippets and not have to implement a new one just to be compatible with your interface. > We would have a STANDARD way of interfacing with linked lists. And what if my linked list needs to do something the average linked list doesn't? Ok, maybe not that common for linked lists... but for trees? I've written red-black trees and triple-t trees, and let me tell you, a "STANDARD" way of interfacing with the one would not have worked with the other. Not usefully, anyway. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-16 05:24 -0700 |
| Message-ID | <fdcf969a-2734-43f3-88ca-017da06d8463@googlegroups.com> |
| In reply to | #58176 |
On Monday, March 16, 2015 at 11:01:31 AM UTC, Richard Heathfield wrote: > On 16/03/15 10:43, jacob navia wrote: > > > 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. > It's easier to write a linked in C from scratch than to use a library written by someone else. So it's OK for a mid level or better programmer, to whom linked lists are second nature. For a beginner, it good for learning how linked lists work, but there's the disadvantage that you might introduce a bug in deleting a doubly-linked node. There's also the disadvantage that it's not possible to easily move between a linked list and another strategy for storing a list of objects. However that's more theoretical than practical - in reality it's unusual to replace one C++ stl container with another, and for the transition to go completely smoothly. Normally the algorithm will need substantial rewriting to get the advantage of the new data structure, and the gains from being able to leave a few iterators as they are will be minimal.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-17 16:50 +1300 |
| Message-ID | <cmpmj9F5dq2U4@mid.individual.net> |
| In reply to | #58185 |
Malcolm McLean wrote: > There's also the disadvantage that it's not possible to easily move between a linked list > and another strategy for storing a list of objects. However that's more theoretical > than practical - in reality it's unusual to replace one C++ stl container with another, > and for the transition to go completely smoothly. Normally the algorithm will need > substantial rewriting to get the advantage of the new data structure, and the gains from > being able to leave a few iterators as they are will be minimal. That isn't really true. Most algorithms (both standard and user written) in C++ use iterators to access containers. This means more often than not all that is required to change from one container to another is to change a coupe of typedefs. The use of iterators is one of the powerful features of the C++ standard library algorithms: they can be used with any container as well as plain old arrays. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2015-03-17 07:21 +0100 |
| Message-ID | <me8h51$i4p$1@speranza.aioe.org> |
| In reply to | #58267 |
Le 17/03/2015 04:50, Ian Collins a écrit : > The use of iterators is one of the powerful features of the C++ standard > library algorithms: they can be used with any container as well as plain > old arrays. That is why the CCL proposes iterators too.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-17 01:50 -0700 |
| Message-ID | <fee40481-8bee-4440-9b93-265688feb51e@googlegroups.com> |
| In reply to | #58267 |
On Tuesday, March 17, 2015 at 3:50:10 AM UTC, Ian Collins wrote: > Malcolm McLean wrote: > > > There's also the disadvantage that it's not possible to easily > > move between a linked list and another strategy for storing a > > list of objects. However that's more theoretical > > than practical - in reality it's unusual to replace one C++ > > stl container with another, and for the transition to go completely > > smoothly. Normally the algorithm will need substantial rewriting to > > get the advantage of the new data structure, and the gains from > > being able to leave a few iterators as they are will be minimal. > > That isn't really true. Most algorithms (both standard and user > written) in C++ use iterators to access containers. This means more > often than not all that is required to change from one container to > another is to change a coupe of typedefs. The use of iterators is one > of the powerful features of the C++ standard library algorithms: they > can be used with any container as well as plain old arrays. > Trivial algorithms typically step through a sequence from first to last applying some sort of transform to each element. So of course you can write to take a begin() / end() iterator. But more complex algorithms generally can't do that. Either you take an iterator, do one pass through, and put the data into your own format, or you require the input to be either a graph (a structure with specified quick links between specified data items), or a multi-dimensional array (so we need a quick operation to extend in the x or the y direction). The problem with fancy languages is that ultimately all they usually do is reformat data with "Russian doll" programming. But writing little bridge functions to specify your complex signal as N reals, N imaginary rather than N (real + imaginary) and so on isn't usually where the program or the programmer spends his time.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-18 21:22 +1300 |
| Message-ID | <cmsqupFqupfU1@mid.individual.net> |
| In reply to | #58273 |
Malcolm McLean wrote: > On Tuesday, March 17, 2015 at 3:50:10 AM UTC, Ian Collins wrote: >> Malcolm McLean wrote: >> >>> There's also the disadvantage that it's not possible to easily >>> move between a linked list and another strategy for storing a >>> list of objects. However that's more theoretical >>> than practical - in reality it's unusual to replace one C++ >>> stl container with another, and for the transition to go completely >>> smoothly. Normally the algorithm will need substantial rewriting to >>> get the advantage of the new data structure, and the gains from >>> being able to leave a few iterators as they are will be minimal. >> >> That isn't really true. Most algorithms (both standard and user >> written) in C++ use iterators to access containers. This means more >> often than not all that is required to change from one container to >> another is to change a coupe of typedefs. The use of iterators is one >> of the powerful features of the C++ standard library algorithms: they >> can be used with any container as well as plain old arrays. >> > Trivial algorithms typically step through a sequence from first to > last applying some sort of transform to each element. So of course > you can write to take a begin() / end() iterator. > But more complex algorithms generally can't do that. Either you take > an iterator, do one pass through, and put the data into your own > format, or you require the input to be either a graph (a structure with > specified quick links between specified data items), or a multi-dimensional > array (so we need a quick operation to extend in the x or the y > direction). > > The problem with fancy languages is that ultimately all they usually > do is reformat data with "Russian doll" programming. But writing little > bridge functions to specify your complex signal as N reals, N imaginary > rather than N (real + imaginary) and so on isn't usually where the > program or the programmer spends his time. What relevance does any of the above have to your original statement and my reply? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-18 01:55 -0700 |
| Message-ID | <db038a8d-9338-4a38-95c3-1f3f784bcd38@googlegroups.com> |
| In reply to | #58392 |
On Wednesday, March 18, 2015 at 8:22:58 AM UTC, Ian Collins wrote: > Malcolm McLean wrote: > > On Tuesday, March 17, 2015 at 3:50:10 AM UTC, Ian Collins wrote: > >> Malcolm McLean wrote: > >> > >>> There's also the disadvantage that it's not possible to easily > >>> move between a linked list and another strategy for storing a > >>> list of objects. However that's more theoretical > >>> than practical - in reality it's unusual to replace one C++ > >>> stl container with another, and for the transition to go completely > >>> smoothly. Normally the algorithm will need substantial rewriting to > >>> get the advantage of the new data structure, and the gains from > >>> being able to leave a few iterators as they are will be minimal. > >> > >> That isn't really true. Most algorithms (both standard and user > >> written) in C++ use iterators to access containers. This means more > >> often than not all that is required to change from one container to > >> another is to change a coupe of typedefs. The use of iterators is one > >> of the powerful features of the C++ standard library algorithms: they > >> can be used with any container as well as plain old arrays. > >> > > Trivial algorithms typically step through a sequence from first to > > last applying some sort of transform to each element. So of course > > you can write to take a begin() / end() iterator. > > But more complex algorithms generally can't do that. Either you take > > an iterator, do one pass through, and put the data into your own > > format, or you require the input to be either a graph (a structure with > > specified quick links between specified data items), or a multi-dimensional > > array (so we need a quick operation to extend in the x or the y > > direction). > > > > The problem with fancy languages is that ultimately all they usually > > do is reformat data with "Russian doll" programming. But writing little > > bridge functions to specify your complex signal as N reals, N imaginary > > rather than N (real + imaginary) and so on isn't usually where the > > program or the programmer spends his time. > > What relevance does any of the above have to your original statement and > my reply? > I'm denying that most algorithms use iterators to access containers. It depends what you mean by that, of course, it some ways it's true. Sorting is clearly an algorithm and C++ sort() takes two iterators. But it's not true in other senses.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-18 22:08 +1300 |
| Message-ID | <cmstk4FqupfU4@mid.individual.net> |
| In reply to | #58399 |
Malcolm McLean wrote: > On Wednesday, March 18, 2015 at 8:22:58 AM UTC, Ian Collins wrote: >> Malcolm McLean wrote: >>> On Tuesday, March 17, 2015 at 3:50:10 AM UTC, Ian Collins wrote: >>>> Malcolm McLean wrote: >>>> >>>>> There's also the disadvantage that it's not possible to easily >>>>> move between a linked list and another strategy for storing a >>>>> list of objects. However that's more theoretical >>>>> than practical - in reality it's unusual to replace one C++ >>>>> stl container with another, and for the transition to go completely >>>>> smoothly. Normally the algorithm will need substantial rewriting to >>>>> get the advantage of the new data structure, and the gains from >>>>> being able to leave a few iterators as they are will be minimal. >>>> >>>> That isn't really true. Most algorithms (both standard and user >>>> written) in C++ use iterators to access containers. This means more >>>> often than not all that is required to change from one container to >>>> another is to change a coupe of typedefs. The use of iterators is one >>>> of the powerful features of the C++ standard library algorithms: they >>>> can be used with any container as well as plain old arrays. >>>> >>> Trivial algorithms typically step through a sequence from first to >>> last applying some sort of transform to each element. So of course >>> you can write to take a begin() / end() iterator. >>> But more complex algorithms generally can't do that. Either you take >>> an iterator, do one pass through, and put the data into your own >>> format, or you require the input to be either a graph (a structure with >>> specified quick links between specified data items), or a multi-dimensional >>> array (so we need a quick operation to extend in the x or the y >>> direction). >>> >>> The problem with fancy languages is that ultimately all they usually >>> do is reformat data with "Russian doll" programming. But writing little >>> bridge functions to specify your complex signal as N reals, N imaginary >>> rather than N (real + imaginary) and so on isn't usually where the >>> program or the programmer spends his time. >> >> What relevance does any of the above have to your original statement and >> my reply? >> > I'm denying that most algorithms use iterators to access containers. > It depends what you mean by that, of course, it some ways it's true. > Sorting is clearly an algorithm and C++ sort() takes two iterators. > But it's not true in other senses. From what sample set to you draw that conclusion? Within the code bases I currently have access to, most do. I see plenty of finds, transforms, set operations, conditional moves and removes along with the occasional sort. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-18 07:01 -0700 |
| Message-ID | <f4c2e851-80ac-4f70-83e6-367fa02209ae@googlegroups.com> |
| In reply to | #58400 |
On Wednesday, March 18, 2015 at 9:08:28 AM UTC, Ian Collins wrote: > Malcolm McLean wrote: > > > I'm denying that most algorithms use iterators to access containers. > > It depends what you mean by that, of course, it some ways it's true. > > Sorting is clearly an algorithm and C++ sort() takes two iterators. > > But it's not true in other senses. > > From what sample set to you draw that conclusion? > > Within the code bases I currently have access to, most do. I see plenty > of finds, transforms, set operations, conditional moves and removes > along with the occasional sort. > Algorithms I write. They fall into several classes, not an exhaustive list, but basically the kind of stuff I do. 1) Function minimisation, root finding, derivative taking, geometry, and so on. Usually take a few reals and maybe the function itself as parameters. 2) Matrix operations. Take an NxN 2D array of doubles. Might also take a container say of 3D points to apply the matrix to. 3) Statistical code. Usually take a set or sets of doubles, often are basically matrix operations in disguise. 4) Algorithms that operate on signals (a sampled wave). Usually rather processor intensive and take arrays. 5) Algorithms that operate on raster images. 6) Algorithms that either operate on graphs or reduce to graph problems. A few of these you can sensibly write using iterators to controlled sequences, for example observations you want to apply a statistical analysis to. But generally that won't be helpful - you could define the rows of an image you are performing edge detection on as members of one container and the pixels as members of each "row" container, if you absolutely insist, but that would be pretty stupid, you're either going to perform a single pass to put the code into a memory-mapped raster, or it's going to be very fiddly and inefficient.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-03-16 08:27 -0400 |
| Message-ID | <me6i68$jdd$1@dont-email.me> |
| In reply to | #58176 |
On 03/16/2015 07:01 AM, Richard Heathfield wrote: ... > 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. ... Neither does C++. Just because the C++ standard library includes some potentially useful templates doesn't force you to use them. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web