Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #3254 > unrolled thread
| Started by | boltar2003@boltar.world |
|---|---|
| First post | 2011-05-05 09:37 +0000 |
| Last post | 2011-05-11 03:43 -0700 |
| Articles | 20 on this page of 241 — 42 participants |
Back to article view | Back to comp.lang.c
Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:37 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 02:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? China Blue Veins <chine.bleu@yahoo.com> - 2011-05-05 04:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-05 11:58 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-06 03:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 00:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:18 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-06 02:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-05 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-05-05 15:40 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-05 21:17 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Datesfat Chicks <datesfat.chicks@gmail.com> - 2011-05-05 18:45 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 09:58 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 10:16 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Richard Kettlewell <rjk@greenend.org.uk> - 2011-05-06 11:28 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:34 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 13:03 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 14:32 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-07 16:27 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 16:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-08 06:19 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-08 17:18 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 09:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:34 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 10:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-11 08:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-11 15:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-12 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:23 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:01 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 12:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-07 18:15 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-08 15:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 09:32 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-08 10:46 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 21:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 09:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:24 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 15:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 15:15 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 19:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-07 20:26 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 21:06 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:27 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-05 20:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-06 02:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 19:27 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-18 19:54 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 02:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Marco Parrone <marco@marcoparrone.com> - 2011-05-06 17:32 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 08:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 21:46 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 00:28 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 09:01 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 06:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-07 22:52 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 01:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 09:37 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Willem <willem@toad.stack.nl> - 2011-05-08 10:44 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 07:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-09 11:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 13:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 07:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:38 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 07:44 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-09 21:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 13:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 14:19 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 15:05 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 10:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 19:04 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-14 11:13 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-09 23:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:06 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-10 00:11 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 11:17 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-10 07:10 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-10 13:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:48 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:54 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-05-12 05:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 00:44 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 23:21 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 07:08 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:48 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:03 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 10:12 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-11 21:23 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-12 09:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:35 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 06:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-12 14:36 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-12 22:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-11 11:47 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 08:07 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-10 21:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-11 02:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-11 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:42 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-15 00:23 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-14 22:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-16 04:19 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-16 08:40 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-16 17:53 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-16 21:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 09:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 10:20 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-17 15:00 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? pacman@kosh.dhis.org (Alan Curry) - 2011-05-17 20:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 14:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-17 16:23 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-17 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 01:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-18 01:29 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-18 04:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ben Pfaff <blp@cs.stanford.edu> - 2011-05-17 16:47 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-17 17:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-23 21:57 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-23 21:57 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:45 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-24 11:43 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-24 10:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Sherm Pendley <sherm.pendley@gmail.com> - 2011-05-11 11:11 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 16:22 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 21:25 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Seebs <usenet-nospam@seebs.net> - 2011-05-10 17:28 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-09 17:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 12:20 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 03:53 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-10 20:18 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 04:42 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 09:12 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-10 03:21 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-10 10:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 08:12 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? pete <pfiland@mindspring.com> - 2011-05-10 09:39 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 12:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Ian Collins <ian-news@hotmail.com> - 2011-05-11 08:12 +1200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-10 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-10 19:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-11 07:41 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-11 19:51 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-11 12:45 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-10 07:50 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-10 11:04 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 09:27 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-08 22:50 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:18 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:49 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 20:05 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-08 13:44 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:22 -0700
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 17:05 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 14:07 -0400
Re: Avoiding recursive stack overflow in C? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-15 22:49 +0100
Re: Avoiding recursive stack overflow in C? James Kuyper <jameskuyper@verizon.net> - 2011-05-15 21:08 -0400
Re: Avoiding recursive stack overflow in C? Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-05-16 11:10 +0100
Re: Avoiding recursive stack overflow in C? Ilya Zakharevich <nospam-abuse@ilyaz.org> - 2011-05-16 08:04 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-07 19:11 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2011-05-08 10:16 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-09 09:03 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-06 08:59 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 03:01 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 07:13 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-06 09:02 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-06 15:41 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 02:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-07 16:17 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 10:08 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:20 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 14:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-05-07 14:31 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 22:49 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:22 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 10:24 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-07 17:32 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 11:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 10:57 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-08 08:09 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Shao Miller <sha0.miller@gmail.com> - 2011-05-07 21:35 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-08 23:31 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 00:26 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-09 08:39 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-09 09:03 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-09 10:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-09 17:52 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Herbert Rosenau" <os2guy@pc-rosenau.de> - 2011-05-10 11:20 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-08 17:59 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-09 09:01 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-07 20:41 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 12:48 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:01 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-05-08 13:10 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 19:51 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 22:21 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? gazelle@shell.xmission.com (Kenny McCormack) - 2011-06-04 12:54 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-04 12:59 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? ImpalerCore <jadill33@gmail.com> - 2011-06-07 06:30 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Michael Press <rubrum@pacbell.net> - 2011-06-10 21:56 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-05-07 13:53 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 15:16 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 23:42 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Keith Thompson <kst-u@mib.org> - 2011-05-07 19:37 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 07:17 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? "io_x" <a@b.c.invalid> - 2011-05-08 09:24 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:36 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:29 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-08 00:28 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-07 23:06 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-08 07:30 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-08 15:51 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-14 13:33 +0300
Re: Avoiding recursive stack overflow in C on Unix/Linux? Barry Margolin <barmar@alum.mit.edu> - 2011-05-14 11:08 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-14 15:53 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM> - 2011-05-10 22:14 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:08 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nobody <nobody@nowhere.com> - 2011-05-08 08:15 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:43 -0700
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
| From | "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-05-24 10:58 -0700 |
| Message-ID | <d2f2fc3a-0405-4bef-b251-fa46e4adcc75@f15g2000yqe.googlegroups.com> |
| In reply to | #4686 |
On May 24, 5:43 am, Rainer Weikusat <rweiku...@mssgmbh.com> wrote: > "robertwess...@yahoo.com" <robertwess...@yahoo.com> writes: > > [...] > > >>> I don't know whether this completely avoids the worst-case N**2 > >>> behavior or not, but it should make it less likely to happen > >>> accidentally. > > >> Nope, reduces the constant, that's all. If the median is selected > >> from 3 random (i.e. unpredicatable to an attacker) elements, then > >> the worst case behaviour can not be forced, and you would average > >> to the theoretical average. But then you have to secure information > >> about your (P)RNG state. > > > And producing large quantities of good random numbers with low > > overhead is much harder than the problem you wanted to solve in the > > first place. > > In theory. In practice, all this takes is linking with OpenSSL, > assuming that some source of good randomness will always be available/ > nobody except the person who wrote the code will ever bother to check > it with that much detail (especially, since the chances that anyone who > is at least remoteley superior insofar job positions go both > understands the issue and cares about it in absence of a pending > customer lawsuit are extremly slim) and then go on a happy, four week > holiday somewhere in the sun with the pleasant conviction that an > inherently wrong solution for some problem can always be turned > into something which gives a 'good enough' appearance of working for > all practical purposes by making the implementation complicated > enough to hide its deficiencies. Open SSL (or whichever crypto library is handy on your platform) will fairly easy produce a stream of high quality random bits. It will, however, have very high overhead. So much so that I’d expect a straight Heapsort to be faster, which would be simpler than the Quicksort implementation (just counting the sort part of the code). Poor quality “random” numbers are much easier to generate. Your point about an apparently good enough (which all too often equates to "no demonstrated fatal flaws"), but cheap, solution frequently satisfying the bosses, is of course, a general truth.
[toc] | [prev] | [next] | [standalone]
| From | Sherm Pendley <sherm.pendley@gmail.com> |
|---|---|
| Date | 2011-05-11 11:11 -0400 |
| Message-ID | <87boz9uvaw.fsf@sherm.shermpendley.com> |
| In reply to | #3690 |
Michael Press <rubrum@pacbell.net> writes: > I cannot see myself ever calling bsearch(3). I will > call qsort(3). Note the existence of qsort_r. > Sometimes I'll write an insertion sort with binary > search. Sometimes I'll write a heapsort. This stuff > is not hard. It may not be hard, but it *is* boring and well-covered ground. I'd rather spend my time on wheels that haven't yet been invented. :-) sherm--
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-11 19:48 -0700 |
| Message-ID | <rubrum-107C14.19482811052011@news.albasani.net> |
| In reply to | #3756 |
In article <87boz9uvaw.fsf@sherm.shermpendley.com>, Sherm Pendley <sherm.pendley@gmail.com> wrote: > Michael Press <rubrum@pacbell.net> writes: > > > I cannot see myself ever calling bsearch(3). I will > > call qsort(3). Note the existence of qsort_r. > > Sometimes I'll write an insertion sort with binary > > search. Sometimes I'll write a heapsort. This stuff > > is not hard. > > It may not be hard, but it *is* boring and well-covered > ground. I'd rather spend my time on wheels that haven't > yet been invented. :-) I am easily amused. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-09 16:22 -0700 |
| Message-ID | <ln1v07o3wc.fsf@nuthaus.mib.org> |
| In reply to | #3648 |
Måns Rullgård <mans@mansr.com> writes:
> Joshua Maurice <joshuamaurice@gmail.com> writes:
>> On May 9, 3:05 pm, Michael Press <rub...@pacbell.net> wrote:
>>> There are good reasons to write it oneself. When I want
>>> a binary search I simply write it on the fly; and embed
>>> whatever I want to do with the search result right there.
>>>
>>> It takes as long or longer to write the interfaces to a
>>> library binary search as it does to write one that does
>>> exactly what I want.
>>
>> I politely disagree, and I must express my extreme disbelief at this
>> statement that you can write a good correct binary search algorithm
>> faster than you can use C++ std::map, or C++ std::lower_bound, et al.
>
> A binary search is roughly 10 lines of code. Writing one really doesn't
> take long.
In "Programming Pearls", Jon Bentley writes:
While the first binary search was published in 1946, the first
binary search that works correctly for all values of n did not
appear until 1962.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-09 21:25 -0700 |
| Message-ID | <rubrum-A5C291.21254709052011@news.albasani.net> |
| In reply to | #3653 |
In article <ln1v07o3wc.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> wrote: > Måns Rullgård <mans@mansr.com> writes: > > Joshua Maurice <joshuamaurice@gmail.com> writes: > >> On May 9, 3:05 pm, Michael Press <rub...@pacbell.net> wrote: > >>> There are good reasons to write it oneself. When I want > >>> a binary search I simply write it on the fly; and embed > >>> whatever I want to do with the search result right there. > >>> > >>> It takes as long or longer to write the interfaces to a > >>> library binary search as it does to write one that does > >>> exactly what I want. > >> > >> I politely disagree, and I must express my extreme disbelief at this > >> statement that you can write a good correct binary search algorithm > >> faster than you can use C++ std::map, or C++ std::lower_bound, et al. > > > > A binary search is roughly 10 lines of code. Writing one really doesn't > > take long. > > In "Programming Pearls", Jon Bentley writes: > > While the first binary search was published in 1946, the first > binary search that works correctly for all values of n did not > appear until 1962. I've had sixteen years to get it right too. I feel sorry for those without the confidence to write their own binary search. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-10 17:28 +0000 |
| Message-ID | <slrnishl8g.v9t.usenet-nospam@guild.seebs.net> |
| In reply to | #3659 |
On 2011-05-10, Michael Press <rubrum@pacbell.net> wrote: > I feel sorry for those without the confidence > to write their own binary search. I am pretty typo-prone. I'd rather not take any more chances than I have to. :) -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-09 17:11 -0700 |
| Message-ID | <rubrum-B22B70.17115409052011@news.albasani.net> |
| In reply to | #3647 |
In article <2f33e674-b127-4c35-89b5-dcbf564f3aab@h36g2000pro.googlegroups.com>, Joshua Maurice <joshuamaurice@gmail.com> wrote: > On May 9, 3:05 pm, Michael Press <rub...@pacbell.net> wrote: > > There are good reasons to write it oneself. When I want > > a binary search I simply write it on the fly; and embed > > whatever I want to do with the search result right there. > > > > It takes as long or longer to write the interfaces to a > > library binary search as it does to write one that does > > exactly what I want. > > I politely disagree, and I must express my extreme disbelief at this > statement that you can write a good correct binary search algorithm > faster than you can use C++ std::map, or C++ std::lower_bound, et al. Does the library write your compare routine and unit test it for me? Does the library routine inline the code that examines the return and executed the action dependent on the return value? Does the library return a value in exactly the form I want? -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-10 12:20 +1200 |
| Message-ID | <92reltF51pU8@mid.individual.net> |
| In reply to | #3655 |
On 05/10/11 12:11 PM, Michael Press wrote: > In article > <2f33e674-b127-4c35-89b5-dcbf564f3aab@h36g2000pro.googlegroups.com>, > Joshua Maurice<joshuamaurice@gmail.com> wrote: > >> On May 9, 3:05 pm, Michael Press<rub...@pacbell.net> wrote: >>> There are good reasons to write it oneself. When I want >>> a binary search I simply write it on the fly; and embed >>> whatever I want to do with the search result right there. >>> >>> It takes as long or longer to write the interfaces to a >>> library binary search as it does to write one that does >>> exactly what I want. >> >> I politely disagree, and I must express my extreme disbelief at this >> statement that you can write a good correct binary search algorithm >> faster than you can use C++ std::map, or C++ std::lower_bound, et al. > > Does the library write your compare routine > and unit test it for me? If it has to be written, you have to write and test the compare routine whether you use a library for the search or not. > Does the library > routine inline the code that examines the > return and executed the action dependent on > the return value? That's the compiler's job, not the library's. > Does the library return > a value in exactly the form I want? How many forms of true and false are there? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-05-10 03:53 -0400 |
| Message-ID | <4DC8EEED.139F@mindspring.com> |
| In reply to | #3656 |
Ian Collins wrote: > > On 05/10/11 12:11 PM, Michael Press wrote: > > In article > > <2f33e674-b127-4c35-89b5-dcbf564f3aab@h36g2000pro.googlegroups.com>, > > Joshua Maurice<joshuamaurice@gmail.com> wrote: > > > >> On May 9, 3:05 pm, Michael Press<rub...@pacbell.net> wrote: > >>> There are good reasons to write it oneself. When I want > >>> a binary search I simply write it on the fly; and embed > >>> whatever I want to do with the search result right there. > >>> > >>> It takes as long or longer to write the interfaces to a > >>> library binary search as it does to write one that does > >>> exactly what I want. > >> > >> I politely disagree, > >> and I must express my extreme disbelief at this > >> statement that you can write a good correct binary search algorithm > >> faster than you can use C++ std::map, > >> or C++ std::lower_bound, et al. I can write a good binary search algorithm faster than I can use C++ std::map, or C++ std::lower_bound, et al, because I don't know C++. > > Does the library write your compare routine > > and unit test it for me? > > If it has to be written, > you have to write and test the compare routine > whether you use a library for the search or not. > > > Does the library > > routine inline the code that examines the > > return and executed the action dependent on > > the return value? > > That's the compiler's job, not the library's. > > > Does the library return > > a value in exactly the form I want? > > How many forms of true and false are there? bsearch either returns NULL or returns a pointer to an element of an array. It is also possible to want a binary search which returns a pointer to the first occurance in the array or to want a binary search which returns a pointer to the last occurance in the array. -- pete
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-10 20:18 +1200 |
| Message-ID | <92salqFggcU1@mid.individual.net> |
| In reply to | #3670 |
On 05/10/11 07:53 PM, pete wrote: > Ian Collins wrote: >> >> On 05/10/11 12:11 PM, Michael Press wrote: >> >>> Does the library return >>> a value in exactly the form I want? >> >> How many forms of true and false are there? > > bsearch either > returns NULL or > returns a pointer to an element of an array. > > It is also possible to want a binary search > which returns a pointer to the first occurance in the array > or to want a binary search > which returns a pointer to the last occurance in the array. All of those are supplied by the C++ standard library (plus the option of returning the range of matching elements). -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-05-10 04:42 -0400 |
| Message-ID | <4DC8FA8D.7E98@mindspring.com> |
| In reply to | #3671 |
Ian Collins wrote:
>
> On 05/10/11 07:53 PM, pete wrote:
> > Ian Collins wrote:
> >>
> >> On 05/10/11 12:11 PM, Michael Press wrote:
> >>
> >>> Does the library return
> >>> a value in exactly the form I want?
> >>
> >> How many forms of true and false are there?
> >
> > bsearch either
> > returns NULL or
> > returns a pointer to an element of an array.
> >
> > It is also possible to want a binary search
> > which returns a pointer to the first occurance in the array
> > or to want a binary search
> > which returns a pointer to the last occurance in the array.
>
> All of those are supplied by the C++ standard library (plus the option
> of returning the range of matching elements).
I can still write them in less time than it takes me to learn C++.
/* BEGIN lo_hisearch.c */
#include <stddef.h>
struct lo_hi {
void *lo;
void *hi;
};
struct lo_hi lo_hisearch(const void *key, const void *base,
size_t nmemb, size_t size,
int (*compar)(const void *, const void *));
void *losearch(const void *key, const void *base,
size_t nmemb, size_t size,
int (*compar)(const void *, const void *));
void *hisearch(const void *key, const void *base,
size_t nmemb, size_t size,
int (*compar)(const void *, const void *));
struct lo_hi
lo_hisearch(const void *key, const void *base,
size_t nmemb, size_t size,
int (*compar)(const void *, const void *))
{
struct lo_hi found;
found.lo = losearch(key, base, nmemb, size, compar);
found.hi = hisearch(key, base, nmemb, size, compar);
return found;
}
void *
losearch(const void *key, const void *base,
size_t nmemb, size_t size,
int (*compar)(const void *, const void *))
{
int comp;
size_t low, middle, high;
const void *found = NULL;
if (nmemb != 0) {
const char *const array = base;
low = 0;
high = nmemb;
do {
nmemb = high - low;
middle = nmemb / 2 + low;
base = middle * size + array;
comp = compar(key, base);
if (comp > 0) {
low = middle;
} else {
high = middle;
if (comp == 0) {
found = base;
}
}
} while (nmemb != 1);
}
return (void *)found;
}
void *
hisearch(const void *key, const void *base,
size_t nmemb, size_t size,
int (*compar)(const void *, const void *))
{
int comp;
size_t low, middle, high;
const void *found = NULL;
if (nmemb != 0) {
const char *const array = base;
low = 0;
high = nmemb;
do {
nmemb = high - low;
middle = nmemb / 2 + low;
base = middle * size + array;
comp = compar(key, base);
if (0 > comp) {
high = middle;
} else {
low = middle;
if (comp == 0) {
found = base;
}
}
} while (nmemb != 1);
}
return (void *)found;
}
/* END lo_hisearch.c */
--
pete
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-10 09:12 +0000 |
| Message-ID | <iqavik$u84$1@speranza.aioe.org> |
| In reply to | #3673 |
On Tue, 10 May 2011 04:42:53 -0400 pete <pfiland@mindspring.com> wrote: >> All of those are supplied by the C++ standard library (plus the option >> of returning the range of matching elements). > >I can still write them in less time than it takes me to learn C++. Perhaps you should learn C++. While it seems to be the case that the standards committee doesn't seem to know when to leave well enough alone and seem to want to turn it into the largest, most unwieldy language the world has yet seen by adding language "features" that should really be left in libraries, some of its basic functionality is very useful. I'd rather not have to go back to function pointers in structures to mimic OO again or have endless function return value error checks instead of just throwing exceptions. B2003
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-05-10 03:21 -0700 |
| Message-ID | <45a2d888-6c81-4303-83f6-932d4c7ebc25@p7g2000yqh.googlegroups.com> |
| In reply to | #3674 |
On May 10, 12:12 pm, boltar2...@boltar.world wrote: > On Tue, 10 May 2011 04:42:53 -0400 > > >I can still write them in less time than it takes me to learn C++. > > Perhaps you should learn C++. > I abandoned C++. I haven't written any new code in it for years. There were many reasons. Mainly, I'd been getting more and more sceptical about object-oriented design. Quite a lot of people have now come round to this view. But the standard template library was a factor. The problem is you end up writing copy constructors and overloading comparators for too many, trivial objects. Then the syntax isn't nice and readable. It also generated incomprehensible error messages when something failed - that's probably been fixed now, but it was a major nuisance at the time. Then there were too many ways of doing things - the correct way, passing a controlled sequence, worked, but it was too difficult to get people to use it consistently. A data structure isn't just a way of storing information, it's also an interface by which parts of the program talk to each other, if you've got plain arrays and STL vectors and arrays of objects and arrays of object pointers all holding similar data, then integration becomes very difficult.
[toc] | [prev] | [next] | [standalone]
| From | boltar2003@boltar.world |
|---|---|
| Date | 2011-05-10 10:53 +0000 |
| Message-ID | <iqb5fh$dv9$1@speranza.aioe.org> |
| In reply to | #3676 |
On Tue, 10 May 2011 03:21:04 -0700 (PDT) Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >There were many reasons. Mainly, I'd been getting more and more >sceptical about object-oriented design. Quite a lot of people have now It can lead to overblown , overdesigned programs certainly. But it has its uses. Its just that some coders brought up on OO seem to think it should be used for everything and don't stop to consider whether its appropriate for certain tasks. Also the current fad of design patterns has a lot to answer for - many new coders don't think about how to solve a problem from the ground up, they just try and solve it by plugging together the patterns they know in a lego brick style. >factor. The problem is you end up writing copy constructors and >overloading comparators for too many, trivial objects. Then the syntax True, but I think the latest version of C++ has fixed the constructor issue - if you don't provide the constructors for your child class it defaults to using the parent class versions. A godsend if you want to inherit from something like std::string without having to have a 50 line long class definition to make it work properly. B2003
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-10 08:12 -0700 |
| Message-ID | <6c0448b5-07c4-4bfb-9bb9-267db677a470@l18g2000yql.googlegroups.com> |
| In reply to | #3676 |
On May 10, 12:21 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > On May 10, 12:12 pm, boltar2...@boltar.world wrote:> On Tue, 10 May 2011 04:42:53 -0400 > > > >I can still write them in less time than it takes me to learn C++. > > > Perhaps you should learn C++. > > I abandoned C++. I haven't written any new code in it for years. > Where C provides a programmer with ample rope to hang himself, C++ provides a firing-squad, blindfold and last-cigarette. It requires quite a lot of attention both to detail _and_ the big picture. If you loose sight of the big picture or lack the discipline to stick to it, C ++ programs get get very messy, very fast. If used properly, however, it's a very potent tool to write amazing software and frankly, i like the language for the same reason i like C: It does what i tell it to without being a nagging mother-in-law. STL is one of the reasosns for that. I don't have to mess around to get all the details of various container-classes right, but i can concentrate on the problem at hand instead. > There were many reasons. Mainly, I'd been getting more and more > sceptical about object-oriented design. Quite a lot of people have now > come round to this view. No single programming "paradigm" is a panacea and will suite everyone, but to quote B. Stroustrup himself: The major cause of complaints is C+ + undoubted success. As someone remarked: There are only two kinds of programming languages: those people always bitch about and those nobody uses. <snip>
[toc] | [prev] | [next] | [standalone]
| From | pete <pfiland@mindspring.com> |
|---|---|
| Date | 2011-05-10 09:39 -0400 |
| Message-ID | <4DC9401F.497A@mindspring.com> |
| In reply to | #3674 |
boltar2003@boltar.world wrote: > > On Tue, 10 May 2011 04:42:53 -0400 > pete <pfiland@mindspring.com> wrote: > >I can still write them in less time than it takes me to learn C++. > > Perhaps you should learn C++. I don't program professionally anymore. C code is just a hobby for me. Writing C code is what I do instead of crossword puzzles. Learning a new language just seems like work to me. > While it seems to be the case that the standards > committee doesn't seem to know when to leave well enough > alone and seem to want to turn it into the largest, > most unwieldy language the world has yet > seen by adding language "features" > that should really be left in libraries, > some of its basic functionality is very useful. > I'd rather not have to go back to function pointers > in structures to mimic OO again or have endless > function return value error checks > instead of just throwing exceptions. Like yourself with C++, I'm unenthusiastic about future changes to C. -- pete
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-10 12:51 -0700 |
| Message-ID | <rubrum-01D59C.12510510052011@news.albasani.net> |
| In reply to | #3656 |
In article <92reltF51pU8@mid.individual.net>, Ian Collins <ian-news@hotmail.com> wrote: > On 05/10/11 12:11 PM, Michael Press wrote: > > In article > > <2f33e674-b127-4c35-89b5-dcbf564f3aab@h36g2000pro.googlegroups.com>, > > Joshua Maurice<joshuamaurice@gmail.com> wrote: > > > >> On May 9, 3:05 pm, Michael Press<rub...@pacbell.net> wrote: > >>> There are good reasons to write it oneself. When I want > >>> a binary search I simply write it on the fly; and embed > >>> whatever I want to do with the search result right there. > >>> > >>> It takes as long or longer to write the interfaces to a > >>> library binary search as it does to write one that does > >>> exactly what I want. > >> > >> I politely disagree, and I must express my extreme disbelief at this > >> statement that you can write a good correct binary search algorithm > >> faster than you can use C++ std::map, or C++ std::lower_bound, et al. > > > > Does the library write your compare routine > > and unit test it for me? > > If it has to be written, you have to write and test the compare routine > whether you use a library for the search or not. Or embed it in the binary search code. It's typically one line. > > Does the library > > routine inline the code that examines the > > return and executed the action dependent on > > the return value? > > That's the compiler's job, not the library's. No. You missed the point. What do you do with the result of the binary search? That too can be embedded in the binary search routine. > > Does the library return > > a value in exactly the form I want? > > How many forms of true and false are there? Binary search does not refer to the return value---the return is not binary valued. There are different purposes for a binary search, and different ways to use the result. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-11 08:12 +1200 |
| Message-ID | <92tkh8F51qU3@mid.individual.net> |
| In reply to | #3691 |
On 05/11/11 07:51 AM, Michael Press wrote: > In article<92reltF51pU8@mid.individual.net>, > Ian Collins<ian-news@hotmail.com> wrote: > >> On 05/10/11 12:11 PM, Michael Press wrote: >>> In article >>> <2f33e674-b127-4c35-89b5-dcbf564f3aab@h36g2000pro.googlegroups.com>, >>> Joshua Maurice<joshuamaurice@gmail.com> wrote: >>> >>>> On May 9, 3:05 pm, Michael Press<rub...@pacbell.net> wrote: >>>>> There are good reasons to write it oneself. When I want >>>>> a binary search I simply write it on the fly; and embed >>>>> whatever I want to do with the search result right there. >>>>> >>>>> It takes as long or longer to write the interfaces to a >>>>> library binary search as it does to write one that does >>>>> exactly what I want. >>>> >>>> I politely disagree, and I must express my extreme disbelief at this >>>> statement that you can write a good correct binary search algorithm >>>> faster than you can use C++ std::map, or C++ std::lower_bound, et al. >>> >>> Does the library write your compare routine >>> and unit test it for me? >> >> If it has to be written, you have to write and test the compare routine >> whether you use a library for the search or not. > > Or embed it in the binary search code. > It's typically one line. Which is what the C++ search functions do. >>> Does the library >>> routine inline the code that examines the >>> return and executed the action dependent on >>> the return value? >> >> That's the compiler's job, not the library's. > > No. You missed the point. What do you do with > the result of the binary search? That too can > be embedded in the binary search routine. Doesn't the search have to complete before it has a result? >>> Does the library return >>> a value in exactly the form I want? >> >> How many forms of true and false are there? > > Binary search does not refer to the return value---the > return is not binary valued. There are different > purposes for a binary search, and different ways to use > the result. Indeed, I was hung up on binary_search, the C++ library also includes upper and lower bounds as well as equal range search functions. It is better design to decouple the algorithm from the result processing. If nothing else, it gives you a reusable algorithm. Better still if this can be done with little or no overhead. Overhead is often seen as a blocker in C, but it isn't in C++ which is one reason C++ has an algorithms library and C doesn't. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-05-10 15:16 -0700 |
| Message-ID | <4f51c719-c42d-4b71-afdb-659cc1ac7407@k15g2000pri.googlegroups.com> |
| In reply to | #3695 |
On May 10, 1:12 pm, Ian Collins <ian-n...@hotmail.com> wrote: > It is better design to decouple the algorithm from the result > processing. If nothing else, it gives you a reusable algorithm. Better > still if this can be done with little or no overhead. Overhead is often > seen as a blocker in C, but it isn't in C++ which is one reason C++ has > an algorithms library and C doesn't. I'm not sure I'd put it that way. It's just that in C++, you can write low-level reusable algorithms which do not carry overhead compared to hand rolling, such as a binary search, as opposed to C where you cannot (barring macros and god do I hope that no one uses macros for that purpose). Templates are a wonderful thing (as hacky and unwieldy as they are).
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-10 19:43 -0700 |
| Message-ID | <rubrum-201D28.19432210052011@news.albasani.net> |
| In reply to | #3695 |
In article <92tkh8F51qU3@mid.individual.net>, Ian Collins <ian-news@hotmail.com> wrote: > On 05/11/11 07:51 AM, Michael Press wrote: > > In article<92reltF51pU8@mid.individual.net>, > > Ian Collins<ian-news@hotmail.com> wrote: > > > >> On 05/10/11 12:11 PM, Michael Press wrote: > >>> In article > >>> <2f33e674-b127-4c35-89b5-dcbf564f3aab@h36g2000pro.googlegroups.com>, > >>> Joshua Maurice<joshuamaurice@gmail.com> wrote: > >>> > >>>> On May 9, 3:05 pm, Michael Press<rub...@pacbell.net> wrote: > >>>>> There are good reasons to write it oneself. When I want > >>>>> a binary search I simply write it on the fly; and embed > >>>>> whatever I want to do with the search result right there. > >>>>> > >>>>> It takes as long or longer to write the interfaces to a > >>>>> library binary search as it does to write one that does > >>>>> exactly what I want. > >>>> > >>>> I politely disagree, and I must express my extreme disbelief at this > >>>> statement that you can write a good correct binary search algorithm > >>>> faster than you can use C++ std::map, or C++ std::lower_bound, et al. > >>> > >>> Does the library write your compare routine > >>> and unit test it for me? > >> > >> If it has to be written, you have to write and test the compare routine > >> whether you use a library for the search or not. > > > > Or embed it in the binary search code. > > It's typically one line. > > Which is what the C++ search functions do. _You_ must _write_ the callback routine, or am I mistaken here? It's true in C. > >>> Does the library > >>> routine inline the code that examines the > >>> return and executed the action dependent on > >>> the return value? > >> > >> That's the compiler's job, not the library's. > > > > No. You missed the point. What do you do with > > the result of the binary search? That too can > > be embedded in the binary search routine. > > Doesn't the search have to complete before it has a result? The result is present _in_ the binary search code that I just wrote out. I can put the search result action _in_ the binary search code. I am beginning to think you think I am trying to write a replacement for the library routine, despite everything I have said that implies otherwise. > >>> Does the library return > >>> a value in exactly the form I want? > >> > >> How many forms of true and false are there? > > > > Binary search does not refer to the return value---the > > return is not binary valued. There are different > > purposes for a binary search, and different ways to use > > the result. > > Indeed, I was hung up on binary_search, the C++ library also includes > upper and lower bounds as well as equal range search functions. > > It is better design to decouple the algorithm from the result > processing. If nothing else, it gives you a reusable algorithm. Better > still if this can be done with little or no overhead. Overhead is often > seen as a blocker in C, but it isn't in C++ which is one reason C++ has > an algorithms library and C doesn't. Despite all its advantages I remain uninterested in C++. -- Michael Press
[toc] | [prev] | [next] | [standalone]
Page 8 of 13 — ← Prev page 1 … 6 7 [8] 9 10 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web