Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.unix.programmer > #306 > unrolled thread
| Started by | boltar2003@boltar.world |
|---|---|
| First post | 2011-05-05 09:37 +0000 |
| Last post | 2011-05-05 12:18 -0700 |
| Articles | 20 on this page of 270 — 46 participants |
Back to article view | Back to comp.unix.programmer
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? Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-05 13:40 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 13:52 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Azazel <azazel@remove.azazel.net> - 2011-05-05 09:22 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? boltar2003@boltar.world - 2011-05-05 14:41 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Azazel <azazel@remove.azazel.net> - 2011-05-05 10:30 -0500
Re: Avoiding recursive stack overflow in C on Unix/Linux? scott@slp53.sl.home (Scott Lurndal) - 2011-05-07 23:23 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-05 18:55 +0200
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-05 11:58 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-06 14:36 +0200
RLIMIT_STACK (was: Avoiding recursive stack overflow in C on Unix/Linux?) Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-10 14:19 +0100
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 08:28 +0200
Re: RLIMIT_STACK scott@slp53.sl.home (Scott Lurndal) - 2011-05-11 16:18 +0000
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 18:37 +0200
Re: RLIMIT_STACK scott@slp53.sl.home (Scott Lurndal) - 2011-05-11 19:53 +0000
Re: RLIMIT_STACK Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2011-05-11 17:43 +0100
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 20:03 +0200
Re: RLIMIT_STACK Xavier Roche <xroche@free.fr.NOSPAM.invalid> - 2011-05-11 20:20 +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? Noob <root@127.0.0.1> - 2011-06-01 15:19 +0200
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? Michael Press <rubrum@pacbell.net> - 2011-05-07 21:02 -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? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 10:29 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-06 03:04 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? James Kuyper <jameskuyper@verizon.net> - 2011-05-06 06:33 -0400
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-06 12:04 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-07 04:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-07 13:07 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-07 21:13 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Måns Rullgård <mans@mansr.com> - 2011-05-08 10:46 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? David Schwartz <davids@webmaster.com> - 2011-05-08 05:11 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? Golden California Girls <gldncagrls@aol.com.mil> - 2011-05-07 08:59 -0700
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? Nicolas George <nicolas$george@salle-s.org> - 2011-05-11 21:07 +0000
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? "Ersek, Laszlo" <lacos@caesar.elte.hu> - 2011-05-15 18:21 +0200
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? Nicolas George <nicolas$george@salle-s.org> - 2011-05-16 16:58 +0000
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? Michael Press <rubrum@pacbell.net> - 2011-05-07 23:27 -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? 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? Nobody <nobody@nowhere.com> - 2011-05-08 08:37 +0100
Re: Avoiding recursive stack overflow in C on Unix/Linux? Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2011-05-08 11:13 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-09 15:46 -0700
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? boltar2003@boltar.world - 2011-05-10 08:30 +0000
Re: Avoiding recursive stack overflow in C on Unix/Linux? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-05-11 03:43 -0700
Re: Avoiding recursive stack overflow in C on Unix/Linux? William Ahern <william@wilbur.25thandClement.com> - 2011-05-05 12:18 -0700
Page 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-10 20:18 +1200 |
| Message-ID | <92salqFggcU1@mid.individual.net> |
| In reply to | #470 |
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 | #471 |
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 | #473 |
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 | #474 |
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 | #476 |
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 | #476 |
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 | #474 |
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 | #465 |
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 | #484 |
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 | #486 |
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 | #486 |
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]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-11 07:41 -0400 |
| Message-ID | <iqdslv$86n$1@dont-email.me> |
| In reply to | #493 |
On 05/10/2011 10:43 PM, Michael Press wrote: > 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: ... >>>> 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. You don't always need to write a callback; one may already be available. For each of the binary search function templates (lower_bound, upper_bound, equal_range, and binary_search) there is an overload which requires no comparison function object. That overload uses '<' to perform the comparison. This works for any element type which is: a) a built-in type for which '<' is already provided b) a C++ standard library class for which operator<() is already provided c) a user-defined class for which you have already overload operator<() for some other purpose, so there's no additional cost to also using it in the binary search. But you're right, in general: you do need to write a comparison function; the most reasonable way to do it is write one that is an operator<() overload, taking advantage of the feature described above. That's not always feasible. I recently had a need for a sequence of elements which was simultaneously sorted by two different fields; the sort order was required to be the same for both fields. Insertions of elements for which that requirement could not be met was disallowed. For that purpose, I needed two different comparison functions, one for each field. Only one of them could be operator<(); the other would have to be a separate comparison function. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Michael Press <rubrum@pacbell.net> |
|---|---|
| Date | 2011-05-11 19:51 -0700 |
| Message-ID | <rubrum-B8A30C.19512711052011@news.albasani.net> |
| In reply to | #520 |
In article <iqdslv$86n$1@dont-email.me>, James Kuyper <jameskuyper@verizon.net> wrote: > On 05/10/2011 10:43 PM, Michael Press wrote: > > 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: > ... > >>>> 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. > > You don't always need to write a callback; one may already be available. > For each of the binary search function templates (lower_bound, > upper_bound, equal_range, and binary_search) there is an overload which > requires no comparison function object. That overload uses '<' to > perform the comparison. This works for any element type which is: > a) a built-in type for which '<' is already provided > b) a C++ standard library class for which operator<() is already provided > c) a user-defined class for which you have already overload operator<() > for some other purpose, so there's no additional cost to also using it > in the binary search. > > But you're right, in general: you do need to write a comparison > function; the most reasonable way to do it is write one that is an > operator<() overload, taking advantage of the feature described above. > > That's not always feasible. I recently had a need for a sequence of > elements which was simultaneously sorted by two different fields; the > sort order was required to be the same for both fields. Insertions of > elements for which that requirement could not be met was disallowed. For > that purpose, I needed two different comparison functions, one for each > field. Only one of them could be operator<(); the other would have to be > a separate comparison function. Right. Sometimes it is simpler to write a dedicated routine. -- Michael Press
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-05-11 12:45 +0100 |
| Message-ID | <878vudtq8n.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #486 |
Ian Collins <ian-news@hotmail.com> writes:
[ binary search ]
> It is better design to decouple the algorithm from the result
> processing. If nothing else, it gives you a reusable algorithm.
The algorithm is something abstract and as such, inherently reusable
(although the practical usefulness of an algorithm may be limited
outside the problem situation it was intended to help with): Provided
you need to write code which has to search for something in a sorted
array, you can use the reusable 'binary search' algorithm instead of
inventing your own searching algorithm ('binary search' is a really
bad example here because it is so absolutely trivial to implement). It
is also possible to create a reusable implementation of an algorithm,
which amounts to exchanging the problem of implementing the algorithm
for the problem of dealing with an external dependency whose exact
behaviour cannot be determined by inspecting the source code of a
particular program alone, whose exact behaviour may change independently
of the code of the the programs using it, whose implementation isn't
necessarily particularly well-suited for solving the specific problem
at hand and whose implementation may now (or at any time in future)
contain errors independent of the source code of any program using it.
In nutshell, the means such a
program-using-the-reusable-implementation-of-a-reusable algorithm can
possibly/ probably be written faster but it becomes harder to debug
and maintain in exchange for that. Except if the functionality gained
in this way is non-trivial, this is usually a bad tradeoff since
debugging and maintaining code is generally more difficult and
time-consuming than writing it.
I recently spent roughly a complete work day trying to 'decrypt'
Ulrich Drepperts custom macro orgies inside glibc in order to
determine what code is actually being executed by a program which
failed inside the getpsnam library routine before I was able to
identify the actual problem and what was causing it and fix that which
provides a nice example of the maintenance problem I wrote about in
the first paragraph. And I'd wager a bet that a majority of
'developers' won't even contemplate to try to determine why some
seemingly correct code fails inside a library call but just stack
workaround onto workaround in order to mitigate the practical
consequences whenever the reliability problems caused by the actual
error happens to reach them (and this is bound to be much less often
than the problem affecting a user of the code in some significant
way).
> Better still if this can be done with little or no overhead.
Computers are really fast nowadays and avoiding the inherent overhead
of 'the most general "optimized" solution we were able to find'
usually turns 'performance problems' into non-issues: Only heavy users
of insanely huge and complex third-party libraries are still affected
by that (this is a somewhat hyperbolic statement with a true core).
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-10 07:50 -0700 |
| Message-ID | <56eb5eae-f200-4445-9ab3-3579e0a17a5e@q32g2000yqn.googlegroups.com> |
| In reply to | #456 |
On May 10, 12:05 am, Michael Press <rub...@pacbell.net> wrote: > In article > <cdc2bce7-4168-4bad-92b7-fdaa78e55...@b19g2000yqg.googlegroups.com>, > "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: > > > > > > > > > > > On May 9, 1:30 pm, boltar2...@boltar.world wrote: > > > On Sun, 8 May 2011 07:23:46 -0700 (PDT) > > > "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: > > > > >> In a place where you can catch the error and terminate cleanly. > > > > >> One of the major problems with C is that you cannot reliably handle > > > >> stack overflows, unless you roll your own stack. > > > > >Exactly. And since implementing a stack mechanism with all the > > > >goodities and niceties a demanding programmer wants, is in the range > > > >of Computer Science 101, it's rather superfluous as a language > > > >element. > > > > Best not to mention that to the STL fanboys on comp.lang.c++ ;) > > > STL is a library, not a language element. A superbly useful library at > > that. That's exactly where stuff like lists, queues, stack and what > > have SHOULD be implemented. After all, it's no use inventing the wheel > > all over again every time you need one. > > There are good reasons to write it oneself. Oh sure... Please... It was merely an observations that there are good reasons to have libs like BOOST and STL, too. Not some kind of fatwa prohibiting this, that or the other. If you feel you're better off rolling your own, then you should. > 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. If that's the best solution for you... Who am i to protest?
[toc] | [prev] | [next] | [standalone]
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Date | 2011-05-10 11:04 +0100 |
| Message-ID | <871v06lvmm.fsf@sapphire.mobileactivedefense.com> |
| In reply to | #455 |
"Kleuskes & Moos" <kleuske@xs4all.nl> writes: > On May 9, 1:30 pm, boltar2...@boltar.world wrote: >> On Sun, 8 May 2011 07:23:46 -0700 (PDT) >> "Kleuskes & Moos" <kleu...@xs4all.nl> wrote: >> >> In a place where you can catch the error and terminate cleanly. >> >> >> One of the major problems with C is that you cannot reliably handle >> >> stack overflows, unless you roll your own stack. >> >> >Exactly. And since implementing a stack mechanism with all the >> >goodities and niceties a demanding programmer wants, is in the range >> >of Computer Science 101, it's rather superfluous as a language >> >element. >> >> Best not to mention that to the STL fanboys on comp.lang.c++ ;) > > STL is a library, not a language element. A superbly useful library at > that. That's exactly where stuff like lists, queues, stack and what > have SHOULD be implemented. After all, it's no use inventing the wheel > all over again every time you need one. Funny as it may seem, but that's what people who construct vehicles actually often do: They design different types of wheels for different types of vehicles and actually even construct new types of wheels in order to improve the designs of existing of wheels. But they don't usually claim that they invented the basic design because they also created an implementation of it. It takes a programmer-turned-math-geek to be so out of touch with reality to not notice that this analogy is nowhere near being accurate and to also avoid noticing that a one-size-fits-all-wheel simply doesn't exist while - at the same time - claiming to have invented something comparable to 'the wheel' when all he has actually done is create another implementation of an algorithm which has been well-known for thirty years or so and was usually the topic of some kind of undergraduate course. Given these glaring deficiencies in judgement and the completely ludicrous self-assessment, such a person is not one one can expect to give sensible advice to others.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-08 09:27 -0400 |
| Message-ID | <iq65n6$g8v$1@dont-email.me> |
| In reply to | #417 |
On 05/08/2011 04:26 AM, Kleuskes & Moos wrote: > On May 8, 4:52�am, James Kuyper <jameskuy...@verizon.net> wrote: >> On 05/07/2011 09:35 AM, Kleuskes & Moos wrote: >> >>> On May 7, 3:01 pm, James Kuyper <jameskuy...@verizon.net> wrote: >>>> On 05/07/2011 03:28 AM, Kleuskes & Moos wrote: ... >> Nor any portable way to cap non-recursive function calls that overflow >> the stack, either. > > Of course there is. Do not make the call-tree big enough to do that, > and if there's no recursion involved, it's rather easy to derive a max > stack size and put it in your hardware requirements. Imposing a hardware requirement is what makes that solution non-portable. It's not a bad solution; but it cannot be ported to a machine that doesn't meet those requirements. Some mechanism for determining, within your program, whether a given function call would require more stack than is currently available would make it possible to write code which at least fails gracefully on such hardware, instead of simply aborting (or worse). > So, basically, you're saying, since your cannot avoid it absolutely > anyway, all advice is useless, and it's OK to use tail-recursion to > skip through a 2 Mb file. Ok. No, I'm saying that any precautions you need to take to make recursion safe necessarily limit the portability of your code; the same is true of making non-recursive function calls safe; it's just a little easier to take the appropriate precautions with non-recursive code. As long as you take those precautions, and consider the associated limitations on the portability of your code acceptable, there's no other reason to avoid recursion. And, where it's appropriate, there can be strong reasons to favor a recursive approach. ... > You're like a mechanic telling me how brakes are useless since they > cannot guarantee that you won't run into anything, anyway. Even when > applying the brakes, you can still run over a pedestrian or a 20-ton > truck, so basically brakes are useless. No, you should not confuse non-portable with useless. ... >> 1. The lack of any portable way for a C code to avoid making a function >> call that requires more stack space than is currently available; there's >> not even a portable way to recover from the fact that such a call was >> made, which would be a markedly inferior solution to this problem. >> Handling a SIGSEGV is indeed an example of such an inferior solution, >> but it's not mandated by the C standard. > > Nope, it's mandated by the POSIX standard instead. But i'm getting > curious, pray describe the superior solution you have in mind. I haven't come up with an alternative that is easy to use. The simplest approach I can think of, from the point of view of the implementor, would be two constructs. I would call them standard library functions, and using function-call syntax might be the appropriate way to specify them in the standard, but they must be implemented in such a way that they can always be called safely, regardless of how little stack there is left. One function determines how much memory is currently available for objects with automatic storage duration (if the exact amount is hard to determine, it may instead return a guaranteed minimum amount). The second function takes a function pointer as an argument, and reports the amount of memory required for objects with automatic storage duration needed to call that function. It would not include the memory needed by function calls within the pointed-at function; avoiding stack overflow due to those calls would be the responsibility of the function that directly performs them. There's a number of reasons why this simple approach would be inadequate for C: VLAs and objects with automatic storage duration defined inside conditionally executed blocks are the two biggest problems I can see; I'm sure there are others. However, a C-like language without those features could implement such constructs. It might be possible to implement some variant of this idea in C itself. The key advantage of this idea, over SIGSEGV, is that it allows a program to avoid the problem, rather than merely react to the problem after it has already happened. Understand: I am not advocating the creation of such a mechanism; my main point is that the problem that such a mechanism would solve, exists whether or not the program in question uses recursion. You shouldn't avoid recursion just because that problem is a little harder to deal with in recursive code than in non-recursive code. ... >> 2. You made a comment about me relying on SIGSEGV; I don't, and I >> explained why I can't; but this is only a side issue, not directly >> relevant to the first point. > > Ok. So you have different ways of dealing with a stack-overflow. Again > i'm curious how you do that. Portably, since you've stressed the > importance of that quality in your software. I can't - because neither C, nor any other language that I'm familiar with, has portable methods to avoid stack overflow. I use non-portable methods that are probably not too different from yours. They basically amount to making sure that it works on every machine I have available to test it on, and hoping that it works elsewhere. While my software is required to be available to the public, the only machines it absolutely must run on are machines operated by my own company, and I have development machines I can test my code on that are (supposed to be) configured identically to the production machines. But if a user is having trouble porting my code to their machine, and is willing to give me access to that machine for testing, I would certainly be glad to fix the problem. I have anecdotal evidence suggesting that most users don't bother; many of them simply make the fix themselves, without even bothering to complain about it. I found a bug last year when we first ported our code to a 64-bit CentOS machine, and when I announced my bug fix, three users wrote to tell me they'd already noticed the problem and fixed it in their own copies of the code, without bothering to tell me about the bug. ... > So your point applies, and i can't guarantee that a single function- > call won't crash the system. Mission impossible? Mission > irresponsable? > > What alternatives do you have? None - which is the substance of my complaint. >> It doesn't even matter whether or not >> it uses a stack to provide that memory, or some other mechanism, such as >> activation records. > > I'm getting curious again, what sort of killer-functioncall did you > have in mind? Something which allocates a 2Gb array on stack and > passes it around by value? If that's the case, your design stinks. No, just a function that requires more total stack space than is available; it doesn't all have to be allocated in a single object. Virtual memory makes such a limit harder to exceed, but not all systems have virtual memory. On some small machines, it could take a whole lot less than 2GB to exceed that limit. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-08 08:04 -0700 |
| Message-ID | <eee7408c-f3c8-45c0-8509-0b399db9b810@w24g2000yqb.googlegroups.com> |
| In reply to | #426 |
On May 8, 3:27 pm, James Kuyper <jameskuy...@verizon.net> wrote: > On 05/08/2011 04:26 AM, Kleuskes & Moos wrote: > > > On May 8, 4:52 am, James Kuyper <jameskuy...@verizon.net> wrote: > >> On 05/07/2011 09:35 AM, Kleuskes & Moos wrote: > > >>> On May 7, 3:01 pm, James Kuyper <jameskuy...@verizon.net> wrote: > >>>> On 05/07/2011 03:28 AM, Kleuskes & Moos wrote: > ... > >> Nor any portable way to cap non-recursive function calls that overflow > >> the stack, either. > > > Of course there is. Do not make the call-tree big enough to do that, > > and if there's no recursion involved, it's rather easy to derive a max > > stack size and put it in your hardware requirements. > > Imposing a hardware requirement is what makes that solution > non-portable. That may be true, but still, there's no way around it. At leats your requrements should include a fair estimate of memory needed to run the program. Besides, no software, however portable, will run on all systems. The differences are simply too big. So wether you want to or not, hardware requirements are a fact of life. > It's not a bad solution; but it cannot be ported to a > machine that doesn't meet those requirements. Nope. That's the basic meaning of hardware requirements. > Some mechanism for determining, within your program, whether a given >function call would require more stack than is currently available would > make it possible to write code which at least fails gracefully on such > hardware, instead of simply aborting (or worse). Some mechanism of checking RAM size and seeing wether or not that meets the minimum requirements is much simpler. Then it's up to the programmer to halt the program or inform the user that he's on his own and the programmer can't guarantee safe execution. > > So, basically, you're saying, since your cannot avoid it absolutely > > anyway, all advice is useless, and it's OK to use tail-recursion to > > skip through a 2 Mb file. Ok. > > No, I'm saying that any precautions you need to take to make recursion > safe necessarily limit the portability of your code; the same is true of > making non-recursive function calls safe; it's just a little easier to > take the appropriate precautions with non-recursive code. As long as you > take those precautions, and consider the associated limitations on the > portability of your code acceptable, there's no other reason to avoid > recursion. And, where it's appropriate, there can be strong reasons to > favor a recursive approach. Still curious what "precautions" you are talking about, after first telling me there's no safe and portable way. So please expound. > > You're like a mechanic telling me how brakes are useless since they > > cannot guarantee that you won't run into anything, anyway. Even when > > applying the brakes, you can still run over a pedestrian or a 20-ton > > truck, so basically brakes are useless. > > No, you should not confuse non-portable with useless. Oh, trust me... I don't. Some of the most useful software i ever wrote was totally and utterly non-portable. In a software design-sense, that is. It even required a custom processor to run in the first place. > >> 1. The lack of any portable way for a C code to avoid making a function > >> call that requires more stack space than is currently available; there's > >> not even a portable way to recover from the fact that such a call was > >> made, which would be a markedly inferior solution to this problem. > >> Handling a SIGSEGV is indeed an example of such an inferior solution, > >> but it's not mandated by the C standard. > > > Nope, it's mandated by the POSIX standard instead. But i'm getting > > curious, pray describe the superior solution you have in mind. > > I haven't come up with an alternative that is easy to use. > The simplest approach I can think of, from the point of view of the > implementor, would be two constructs. I would call them standard library > functions, and using function-call syntax might be the appropriate way > to specify them in the standard, but they must be implemented in such a > way that they can always be called safely, regardless of how little > stack there is left. If you're out of stack, you can't call anything, for lack of stack- space to hold a return address. But still, you could reserve some space for an "emergency stack". > One function determines how much memory is > currently available for objects with automatic storage duration (if the > exact amount is hard to determine, it may instead return a guaranteed > minimum amount). Ok. > The second function takes a function pointer as an argument, and reports > the amount of memory required for objects with automatic storage > duration needed to call that function. It would not include the memory > needed by function calls within the pointed-at function; avoiding stack > overflow due to those calls would be the responsibility of the function > that directly performs them. > > There's a number of reasons why this simple approach would be inadequate > for C: VLAs and objects with automatic storage duration defined inside > conditionally executed blocks are the two biggest problems I can see; > I'm sure there are others. However, a C-like language without those > features could implement such constructs. It might be possible to > implement some variant of this idea in C itself. It might. > The key advantage of this idea, over SIGSEGV, is that it allows a > program to avoid the problem, rather than merely react to the problem > after it has already happened. Tja... It seems to me such a solution would have a few problems. First off, on many systems the amount of memory available to automatic variables variable itself. Secondly it would introduce a shitload of overhead, since before calling any function a check must be made. And that's apart from problems you already mentioned. > Understand: I am not advocating the creation of such a mechanism; my > main point is that the problem that such a mechanism would solve, exists > whether or not the program in question uses recursion. You shouldn't > avoid recursion just because that problem is a little harder to deal > with in recursive code than in non-recursive code. No. You should avoid it because it's fundamentally unsafe, unless you and your customers are prepared to live with the consequences. In the latter case, and this is quite frequent, recurse the hell out of your system if it makes your software easier to read and maintain. As i mentioned earlier, it _is_ the saving grace of recursion. > >> 2. You made a comment about me relying on SIGSEGV; I don't, and I > >> explained why I can't; but this is only a side issue, not directly > >> relevant to the first point. > > > Ok. So you have different ways of dealing with a stack-overflow. Again > > i'm curious how you do that. Portably, since you've stressed the > > importance of that quality in your software. > > I can't - because neither C, nor any other language that I'm familiar > with, has portable methods to avoid stack overflow. I use non-portable > methods that are probably not too different from yours. They basically > amount to making sure that it works on every machine I have available to > test it on, and hoping that it works elsewhere. Ok. I'm specialized i software where "hoping it doesn't crash" just does not cut it. People get killed that way (no joke). > While my software is required to be available to the public, the only > machines it absolutely must run on are machines operated by my own > company, and I have development machines I can test my code on that are > (supposed to be) configured identically to the production machines. > But if a user is having trouble porting my code to their machine, and is > willing to give me access to that machine for testing, I would certainly > be glad to fix the problem. I have anecdotal evidence suggesting that > most users don't bother; many of them simply make the fix themselves, > without even bothering to complain about it. I found a bug last year > when we first ported our code to a 64-bit CentOS machine, and when I > announced my bug fix, three users wrote to tell me they'd already > noticed the problem and fixed it in their own copies of the code, > without bothering to tell me about the bug. Perhaps they thought you already knew about it. In many applications a crashing program isn't the end of the world, and customers just shrug and try again. That is also my expirience. > > So your point applies, and i can't guarantee that a single function- > > call won't crash the system. Mission impossible? Mission > > irresponsable? > > > What alternatives do you have? > > None - which is the substance of my complaint. Ok. In that case, try to avoid recursion, if at all possible, especially if you suspect you stack might me overrun. Your customers do not mind a crash every now and then, mine do and consider it a matter of life and death or at least a substantial amount of cash. They don't come complaining to me, but their lawyers start complaining to my boss. > >> It doesn't even matter whether or not > >> it uses a stack to provide that memory, or some other mechanism, such as > >> activation records. > > > I'm getting curious again, what sort of killer-functioncall did you > > have in mind? Something which allocates a 2Gb array on stack and > > passes it around by value? If that's the case, your design stinks. > > No, just a function that requires more total stack space than is > available; it doesn't all have to be allocated in a single object. > Virtual memory makes such a limit harder to exceed, but not all systems > have virtual memory. On some small machines, it could take a whole lot > less than 2GB to exceed that limit. True. So take heed that does not happen.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-08 22:50 -0400 |
| Message-ID | <iq7kpu$ph5$1@dont-email.me> |
| In reply to | #428 |
On 05/08/2011 11:04 AM, Kleuskes & Moos wrote: > On May 8, 3:27�pm, James Kuyper <jameskuy...@verizon.net> wrote: ... >> whether or not the program in question uses recursion. You shouldn't >> avoid recursion just because that problem is a little harder to deal >> with in recursive code than in non-recursive code. > > No. You should avoid it because it's fundamentally unsafe, I guess we'll just have to agree to disagree on that point; I don't wee either of us making any progress in convincing the other. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "Kleuskes & Moos" <kleuske@xs4all.nl> |
|---|---|
| Date | 2011-05-09 00:18 -0700 |
| Message-ID | <086cf53d-11ff-4d0b-8fd5-4b1d70b767ac@28g2000yqu.googlegroups.com> |
| In reply to | #442 |
On May 9, 4:50 am, James Kuyper <jameskuy...@verizon.net> wrote: > On 05/08/2011 11:04 AM, Kleuskes & Moos wrote: > > > On May 8, 3:27 pm, James Kuyper <jameskuy...@verizon.net> wrote: > ... > >> whether or not the program in question uses recursion. You shouldn't > >> avoid recursion just because that problem is a little harder to deal > >> with in recursive code than in non-recursive code. > > > No. You should avoid it because it's fundamentally unsafe, > > I guess we'll just have to agree to disagree on that point; I don't wee > either of us making any progress in convincing the other. That's a sensible outcome. It was a pleasure exchanging views with you.
[toc] | [prev] | [next] | [standalone]
Page 10 of 14 — ← Prev page 1 … 8 9 [10] 11 12 … 14 Next page →
Back to top | Article view | comp.unix.programmer
csiph-web