Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #9464 > unrolled thread
| Started by | Paul <pchristor@yahoo.co.uk> |
|---|---|
| First post | 2011-08-29 23:26 -0700 |
| Last post | 2011-08-30 16:45 -0700 |
| Articles | 20 on this page of 197 — 20 participants |
Back to article view | Back to comp.lang.c++
bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-29 23:26 -0700
Re: bad alloc Krice <paulkp@mbnet.fi> - 2011-08-30 02:14 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 06:26 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 14:34 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 06:54 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 15:02 +0100
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 15:06 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:20 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 15:31 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:47 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 15:52 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 08:00 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 16:15 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:31 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 18:58 +0100
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 19:18 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 16:17 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-31 00:56 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 17:11 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-31 01:24 +0100
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-08-31 12:33 +1200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 18:38 -0700
Re: bad alloc Noah Roberts <roberts.noah@gmail.com> - 2011-08-30 20:07 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 04:04 -0700
Re: bad alloc Noah Roberts <roberts.noah@gmail.com> - 2011-08-31 09:17 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-31 14:59 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 00:50 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 12:41 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 05:00 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 13:59 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 06:35 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 14:50 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 13:51 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 21:58 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 14:05 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 22:08 +0100
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 03:16 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 04:12 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-02 15:08 +0100
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 03:07 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 04:15 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 11:21 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:46 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 18:58 +0100
Re: bad alloc "Waldek M." <wm@localhost.localdomain> - 2011-08-31 20:58 +0200
Re: bad alloc "io_x" <a@b.c.invalid> - 2011-09-03 10:13 +0200
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:53 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 16:28 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-01 00:49 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-01 04:50 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 03:17 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 04:21 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-01 16:23 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 03:19 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 15:37 -0700
Re: bad alloc Dombo <dombo@disposable.invalid> - 2011-09-04 09:25 +0200
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-01 16:20 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-30 06:54 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:12 -0700
Re: bad alloc Dombo <dombo@disposable.invalid> - 2011-08-30 22:58 +0200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 15:56 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-08-31 09:28 +0000
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 04:20 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-02 14:57 +0000
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 08:35 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 04:25 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-30 03:26 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 05:54 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 14:30 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:00 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 00:37 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 04:26 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-30 07:03 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 07:57 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 16:04 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 08:15 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 16:20 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:37 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-08-30 18:41 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:49 -0700
Re: bad alloc Asger-P <junk@asger-p.dk> - 2011-08-31 10:33 +0200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 04:22 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-30 16:04 -0700
Re: bad alloc Noah Roberts <roberts.noah@gmail.com> - 2011-08-30 20:02 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-30 20:33 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 01:30 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-08-31 09:23 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 04:21 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 04:47 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-31 05:35 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-01 01:08 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 03:56 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 04:18 -0700
Re: bad alloc Dombo <dombo@disposable.invalid> - 2011-09-03 18:37 +0200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-03 13:39 -0700
Re: bad alloc red floyd <no.spam.here@its.invalid> - 2011-09-03 13:45 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-03 13:51 -0700
Re: bad alloc Sjouke Burry <burryNULNULFOUR@PPLLAANNEETT.NNLL> - 2011-09-04 00:14 +0200
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 15:51 -0700
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-09-04 12:15 +1200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-04 05:00 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:13 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 15:45 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-02 15:40 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-02 09:33 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 14:06 -0700
Re: bad alloc "io_x" <a@b.c.invalid> - 2011-09-03 10:12 +0200
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 04:21 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 01:22 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 05:18 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-08-31 06:36 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 09:33 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-01 00:20 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 04:25 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-01 12:51 +0100
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 06:04 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-01 06:26 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-01 16:58 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-01 17:25 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 16:02 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:20 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 19:13 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:39 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 17:26 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:35 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 17:28 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 21:01 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 16:14 -0700
Re: bad alloc "io_x" <a@b.c.invalid> - 2011-09-05 10:31 +0200
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:36 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-06 04:09 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:49 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 17:11 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-07 00:24 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-08-31 09:59 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-31 11:24 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-01 16:29 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-01 16:42 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-01 21:37 -0700
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-09-02 17:45 +1200
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-03 16:20 -0700
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-09-04 12:03 +1200
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-04 10:56 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:50 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-06 00:12 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 03:04 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-07 00:08 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-07 02:33 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-07 04:28 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-06 13:43 +0000
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-06 07:37 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-07 00:11 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-07 04:29 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-07 05:38 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-07 18:17 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-08 00:45 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 06:58 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-06 09:21 -0700
Re: bad alloc "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2011-09-07 09:10 +0200
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-07 04:18 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-07 10:34 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-07 04:00 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-08 12:11 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-08 06:27 -0700
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:52 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-06 17:16 -0700
Re: bad alloc Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-07 02:39 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-07 04:14 -0700
Re: bad alloc Ian Collins <ian-news@hotmail.com> - 2011-09-06 17:00 +1200
Re: bad alloc Miles Bader <miles@gnu.org> - 2011-09-06 14:51 +0900
Re: bad alloc James Kanze <james.kanze@gmail.com> - 2011-09-06 15:55 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-05 18:44 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-07 10:20 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-07 03:40 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-13 17:06 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-13 12:09 -0700
Re: bad alloc "Paul" <pchristor@yahoo.co.uk> - 2011-09-14 00:18 +0100
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-14 15:11 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-14 11:17 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-15 04:17 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-15 06:50 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-15 07:31 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-15 07:59 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-16 00:19 -0700
Re: bad alloc Noah Roberts <roberts.noah@gmail.com> - 2011-09-17 10:13 -0700
Re: bad alloc Goran <goran.pusic@gmail.com> - 2011-09-18 10:07 -0700
Re: bad alloc yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-16 15:41 +0000
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-16 11:26 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-16 15:38 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-17 04:25 -0700
Re: bad alloc Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-01 23:17 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-09-02 04:03 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 04:37 -0700
Re: bad alloc Leigh Johnston <leigh@i42.co.uk> - 2011-09-02 15:15 +0100
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-09-02 07:35 -0700
Re: bad alloc Adam Skutt <askutt@gmail.com> - 2011-08-30 16:06 -0700
Re: bad alloc Paul <pchristor@yahoo.co.uk> - 2011-08-30 16:45 -0700
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-08-31 12:33 +1200 |
| Message-ID | <9c5dqcF5dgU5@mid.individual.net> |
| In reply to | #9528 |
On 08/31/11 12:24 PM, Leigh Johnston wrote: > > You are just being a troll. And you keep feeding it! Get a kill-file, please. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-30 18:38 -0700 |
| Message-ID | <20c65950-b8f6-44b1-85d2-2c77a584268d@i21g2000yqd.googlegroups.com> |
| In reply to | #9528 |
On Aug 31, 1:24 am, Leigh Johnston <le...@i42.co.uk> wrote: > On 31/08/2011 01:11, Paul wrote: > > > > > > > On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: > >> On 31/08/2011 00:17, Paul wrote: > > >>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>> On 30/08/2011 18:58, Leigh Johnston wrote: > > >>>>> On 30/08/2011 18:31, Paul wrote: > >>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>> On 30/08/2011 16:00, Paul wrote: > > >>>>>>>> Bollocks. > >>>>>>>> You have spouted bullshit and now you realise it you are trying to get > >>>>>>>> out of the arguement with some bullshit about noobish guff. > > >>>>>>>> Its you thats noobish saying that the only sane option is to allow a > >>>>>>>> program to crash if an allocation fails, and you know it. > > >>>>>>> I said the following: > > >>>>>>> "The only sane remedy for most cases of allocation failure is to > >>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>> exception." > > >>>>>>> I stand by what I said so I am not trying to "get out of" anything. As > >>>>>>> usual you fail and continue to fail with your bullshit: note the words > >>>>>>> "most cases of" in what I said. > > >>>>>> It's not the only sane remedy. It's the most insane remedy. > > >>>>> In your own deluded, ill-informed opinion. > > >>>>>> Imagine a program that controlled a robot: > >>>>>> One process for each limb, one for the head and one for the central > >>>>>> gyromatic balance system. The robot is in walk mode and you run out of > >>>>>> memory because a screeching parrot flies past. > >>>>>> What is the "sane" option your program should take: > >>>>>> Shut down eye and hearing modules and slow his walking speed? > >>>>>> Just let the program crash and allow the robot to fall over in a heap? > > >>>>> Are you blind as well as dense? I said: > > >>>>> "The only sane remedy for *most cases of* allocation failure is to > >>>>> terminate the application which is what will happen with an uncaught > >>>>> exception." > > >>>>> *most cases of* > > >>>>> If I was designing robot control software than I would design it in such > >>>>> a way that certain individual sub-systems allocate all their required > >>>>> memory up-front so that if some fatal error does occur then the robot > >>>>> can safely come to a stand still and then reboot its systems. > > >>>>>> If you were working on critical systems such as aircraft controls > >>>>>> would you still think that allowing errors to go uncatched is the only > >>>>>> sane remedy? > > >>>>> Critical systems such as aircraft controls will (I assume) allocate all > >>>>> the memory that is needed for all of their operations up-front so the > >>>>> situation of a memory allocation failure during flight will never occur. > > >>>> I actually have real world experience of doing something similar as I > >>>> was on the Telephony Application Call Control team for two different > >>>> smartphones. If the user exhausts their memory running apps Telephony > >>>> would still need to be able to create a call object if there was an > >>>> incoming call so the call objects were created up-front rather than > >>>> on-demand. This may be an over-simplification but you get the idea. > > >>> I can understand a scenario where you might want to reserve some > >>> memory for a critical part of the program. But I don't see many > >>> programs that would be able to predict their memory requirements up > >>> front. Take your phone example, it would be impossible to predict > >>> every possible user scenario and there just wouldn't be enough memory > >>> to create all the objects required for every possible scenario or even > >>> a fractional representation of every possible scenario. > > >> You don't know what you are talking about. > > > Oh yes I do. > > It is quite obvious that you don't > > > A phone has limited memory. You cannot pre-allocate all the objects a > > user *may* require to run all apps on his/her phone. > > Why are you so dense? Where did I say that? I said the Telephony App > could create all the objects it needs up front not other less critical apps. > > > > > video jukebox, photo editor, soundblaster master etc etc. > > Obviously these apps are not critical so wouldn't be required to create > any objects up front. > But according to your programming style, if these apps did not check for allocation errors the phone would crash regularly thus incoming calls could be missed during phone reboots. SO what was the point of preallocating call objects in case of incoming calls?
[toc] | [prev] | [next] | [standalone]
| From | Noah Roberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-08-30 20:07 -0700 |
| Message-ID | <986c0a50-5587-4bd2-85f6-4bc04556456b@a10g2000prn.googlegroups.com> |
| In reply to | #9530 |
On Aug 30, 6:38 pm, Paul <pchris...@yahoo.co.uk> wrote: > On Aug 31, 1:24 am, Leigh Johnston <le...@i42.co.uk> wrote: > > > > > > > > > On 31/08/2011 01:11, Paul wrote: > > > > On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: > > >> On 31/08/2011 00:17, Paul wrote: > > > >>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>> On 30/08/2011 18:58, Leigh Johnston wrote: > > > >>>>> On 30/08/2011 18:31, Paul wrote: > > >>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>>>>> On 30/08/2011 16:00, Paul wrote: > > > >>>>>>>> Bollocks. > > >>>>>>>> You have spouted bullshit and now you realise it you are trying to get > > >>>>>>>> out of the arguement with some bullshit about noobish guff. > > > >>>>>>>> Its you thats noobish saying that the only sane option is to allow a > > >>>>>>>> program to crash if an allocation fails, and you know it. > > > >>>>>>> I said the following: > > > >>>>>>> "The only sane remedy for most cases of allocation failure is to > > >>>>>>> terminate the application which is what will happen with an uncaught > > >>>>>>> exception." > > > >>>>>>> I stand by what I said so I am not trying to "get out of" anything. As > > >>>>>>> usual you fail and continue to fail with your bullshit: note the words > > >>>>>>> "most cases of" in what I said. > > > >>>>>> It's not the only sane remedy. It's the most insane remedy. > > > >>>>> In your own deluded, ill-informed opinion. > > > >>>>>> Imagine a program that controlled a robot: > > >>>>>> One process for each limb, one for the head and one for the central > > >>>>>> gyromatic balance system. The robot is in walk mode and you run out of > > >>>>>> memory because a screeching parrot flies past. > > >>>>>> What is the "sane" option your program should take: > > >>>>>> Shut down eye and hearing modules and slow his walking speed? > > >>>>>> Just let the program crash and allow the robot to fall over in a heap? > > > >>>>> Are you blind as well as dense? I said: > > > >>>>> "The only sane remedy for *most cases of* allocation failure is to > > >>>>> terminate the application which is what will happen with an uncaught > > >>>>> exception." > > > >>>>> *most cases of* > > > >>>>> If I was designing robot control software than I would design it in such > > >>>>> a way that certain individual sub-systems allocate all their required > > >>>>> memory up-front so that if some fatal error does occur then the robot > > >>>>> can safely come to a stand still and then reboot its systems. > > > >>>>>> If you were working on critical systems such as aircraft controls > > >>>>>> would you still think that allowing errors to go uncatched is the only > > >>>>>> sane remedy? > > > >>>>> Critical systems such as aircraft controls will (I assume) allocate all > > >>>>> the memory that is needed for all of their operations up-front so the > > >>>>> situation of a memory allocation failure during flight will never occur. > > > >>>> I actually have real world experience of doing something similar as I > > >>>> was on the Telephony Application Call Control team for two different > > >>>> smartphones. If the user exhausts their memory running apps Telephony > > >>>> would still need to be able to create a call object if there was an > > >>>> incoming call so the call objects were created up-front rather than > > >>>> on-demand. This may be an over-simplification but you get the idea. > > > >>> I can understand a scenario where you might want to reserve some > > >>> memory for a critical part of the program. But I don't see many > > >>> programs that would be able to predict their memory requirements up > > >>> front. Take your phone example, it would be impossible to predict > > >>> every possible user scenario and there just wouldn't be enough memory > > >>> to create all the objects required for every possible scenario or even > > >>> a fractional representation of every possible scenario. > > > >> You don't know what you are talking about. > > > > Oh yes I do. > > > It is quite obvious that you don't > > > > A phone has limited memory. You cannot pre-allocate all the objects a > > > user *may* require to run all apps on his/her phone. > > > Why are you so dense? Where did I say that? I said the Telephony App > > could create all the objects it needs up front not other less critical apps. > > > > video jukebox, photo editor, soundblaster master etc etc. > > > Obviously these apps are not critical so wouldn't be required to create > > any objects up front. > > But according to your programming style, if these apps did not check > for allocation errors the phone would crash regularly thus incoming > calls could be missed during phone reboots. I'm confused now. I thought that was YOUR argument. Is this an example of a self-induced reductio ad absurdum?
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-08-31 04:04 -0700 |
| Message-ID | <638e91f9-099d-4a76-8cca-b61a3e3d820d@y4g2000vbx.googlegroups.com> |
| In reply to | #9532 |
On Aug 31, 4:07 am, Noah Roberts <roberts.n...@gmail.com> wrote: > On Aug 30, 6:38 pm, Paul <pchris...@yahoo.co.uk> wrote: <snip> > > I'm confused now. I thought that was YOUR argument. Is this an > example of a self-induced reductio ad absurdum?- Hide quoted text - > My argument was that bad_alloc exceptions should be handled. I don't see a reason to ignore them when all the mechanics are in place to catch such exceptions and handle them in some appropriate way.
[toc] | [prev] | [next] | [standalone]
| From | Noah Roberts <roberts.noah@gmail.com> |
|---|---|
| Date | 2011-08-31 09:17 -0700 |
| Message-ID | <eec28364-4e01-48af-9038-27bbe76c1282@n35g2000yqf.googlegroups.com> |
| In reply to | #9558 |
On Aug 31, 4:04 am, Paul <pchris...@yahoo.co.uk> wrote: > On Aug 31, 4:07 am, Noah Roberts <roberts.n...@gmail.com> wrote:> On Aug 30, 6:38 pm, Paul <pchris...@yahoo.co.uk> wrote: > <snip> > > > I'm confused now. I thought that was YOUR argument. Is this an > > example of a self-induced reductio ad absurdum?- Hide quoted text - > > My argument was that bad_alloc exceptions should be handled. I don't > see a reason to ignore them when all the mechanics are in place to > catch such exceptions and handle them in some appropriate way. That was surely your thesis, yes, but you repeatedly claimed that those who disagree were writing horrible code that would crash all the time.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-08-31 14:59 +0100 |
| Message-ID | <a_SdnazqJaHUo8PTnZ2dnUVZ8hydnZ2d@giganews.com> |
| In reply to | #9530 |
On 31/08/2011 02:38, Paul wrote: > On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: >> On 31/08/2011 01:11, Paul wrote: >> >> >> >> >> >>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: >>>> On 31/08/2011 00:17, Paul wrote: >> >>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: >> >>>>>>> On 30/08/2011 18:31, Paul wrote: >>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>> On 30/08/2011 16:00, Paul wrote: >> >>>>>>>>>> Bollocks. >>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get >>>>>>>>>> out of the arguement with some bullshit about noobish guff. >> >>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a >>>>>>>>>> program to crash if an allocation fails, and you know it. >> >>>>>>>>> I said the following: >> >>>>>>>>> "The only sane remedy for most cases of allocation failure is to >>>>>>>>> terminate the application which is what will happen with an uncaught >>>>>>>>> exception." >> >>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As >>>>>>>>> usual you fail and continue to fail with your bullshit: note the words >>>>>>>>> "most cases of" in what I said. >> >>>>>>>> It's not the only sane remedy. It's the most insane remedy. >> >>>>>>> In your own deluded, ill-informed opinion. >> >>>>>>>> Imagine a program that controlled a robot: >>>>>>>> One process for each limb, one for the head and one for the central >>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of >>>>>>>> memory because a screeching parrot flies past. >>>>>>>> What is the "sane" option your program should take: >>>>>>>> Shut down eye and hearing modules and slow his walking speed? >>>>>>>> Just let the program crash and allow the robot to fall over in a heap? >> >>>>>>> Are you blind as well as dense? I said: >> >>>>>>> "The only sane remedy for *most cases of* allocation failure is to >>>>>>> terminate the application which is what will happen with an uncaught >>>>>>> exception." >> >>>>>>> *most cases of* >> >>>>>>> If I was designing robot control software than I would design it in such >>>>>>> a way that certain individual sub-systems allocate all their required >>>>>>> memory up-front so that if some fatal error does occur then the robot >>>>>>> can safely come to a stand still and then reboot its systems. >> >>>>>>>> If you were working on critical systems such as aircraft controls >>>>>>>> would you still think that allowing errors to go uncatched is the only >>>>>>>> sane remedy? >> >>>>>>> Critical systems such as aircraft controls will (I assume) allocate all >>>>>>> the memory that is needed for all of their operations up-front so the >>>>>>> situation of a memory allocation failure during flight will never occur. >> >>>>>> I actually have real world experience of doing something similar as I >>>>>> was on the Telephony Application Call Control team for two different >>>>>> smartphones. If the user exhausts their memory running apps Telephony >>>>>> would still need to be able to create a call object if there was an >>>>>> incoming call so the call objects were created up-front rather than >>>>>> on-demand. This may be an over-simplification but you get the idea. >> >>>>> I can understand a scenario where you might want to reserve some >>>>> memory for a critical part of the program. But I don't see many >>>>> programs that would be able to predict their memory requirements up >>>>> front. Take your phone example, it would be impossible to predict >>>>> every possible user scenario and there just wouldn't be enough memory >>>>> to create all the objects required for every possible scenario or even >>>>> a fractional representation of every possible scenario. >> >>>> You don't know what you are talking about. >> >>> Oh yes I do. >> >> It is quite obvious that you don't >> >>> A phone has limited memory. You cannot pre-allocate all the objects a >>> user *may* require to run all apps on his/her phone. >> >> Why are you so dense? Where did I say that? I said the Telephony App >> could create all the objects it needs up front not other less critical apps. >> >> >> >>> video jukebox, photo editor, soundblaster master etc etc. >> >> Obviously these apps are not critical so wouldn't be required to create >> any objects up front. >> > But according to your programming style, if these apps did not check > for allocation errors the phone would crash regularly thus incoming > calls could be missed during phone reboots. > SO what was the point of preallocating call objects in case of > incoming calls? Does a crashing Windows app crash Windows? No. Why would a phone be any different? Try engaging your brain. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-01 00:50 -0700 |
| Message-ID | <f3a07d2d-6d38-45b0-98ce-6c2fe16ec94b@n11g2000yqh.googlegroups.com> |
| In reply to | #9564 |
On Aug 31, 2:59 pm, Leigh Johnston <le...@i42.co.uk> wrote: > On 31/08/2011 02:38, Paul wrote: > > > > > > > On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: > >> On 31/08/2011 01:11, Paul wrote: > > >>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: > >>>> On 31/08/2011 00:17, Paul wrote: > > >>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: > > >>>>>>> On 30/08/2011 18:31, Paul wrote: > >>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>> On 30/08/2011 16:00, Paul wrote: > > >>>>>>>>>> Bollocks. > >>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get > >>>>>>>>>> out of the arguement with some bullshit about noobish guff. > > >>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a > >>>>>>>>>> program to crash if an allocation fails, and you know it. > > >>>>>>>>> I said the following: > > >>>>>>>>> "The only sane remedy for most cases of allocation failure is to > >>>>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>>>> exception." > > >>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As > >>>>>>>>> usual you fail and continue to fail with your bullshit: note the words > >>>>>>>>> "most cases of" in what I said. > > >>>>>>>> It's not the only sane remedy. It's the most insane remedy. > > >>>>>>> In your own deluded, ill-informed opinion. > > >>>>>>>> Imagine a program that controlled a robot: > >>>>>>>> One process for each limb, one for the head and one for the central > >>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of > >>>>>>>> memory because a screeching parrot flies past. > >>>>>>>> What is the "sane" option your program should take: > >>>>>>>> Shut down eye and hearing modules and slow his walking speed? > >>>>>>>> Just let the program crash and allow the robot to fall over in a heap? > > >>>>>>> Are you blind as well as dense? I said: > > >>>>>>> "The only sane remedy for *most cases of* allocation failure is to > >>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>> exception." > > >>>>>>> *most cases of* > > >>>>>>> If I was designing robot control software than I would design it in such > >>>>>>> a way that certain individual sub-systems allocate all their required > >>>>>>> memory up-front so that if some fatal error does occur then the robot > >>>>>>> can safely come to a stand still and then reboot its systems. > > >>>>>>>> If you were working on critical systems such as aircraft controls > >>>>>>>> would you still think that allowing errors to go uncatched is the only > >>>>>>>> sane remedy? > > >>>>>>> Critical systems such as aircraft controls will (I assume) allocate all > >>>>>>> the memory that is needed for all of their operations up-front so the > >>>>>>> situation of a memory allocation failure during flight will never occur. > > >>>>>> I actually have real world experience of doing something similar as I > >>>>>> was on the Telephony Application Call Control team for two different > >>>>>> smartphones. If the user exhausts their memory running apps Telephony > >>>>>> would still need to be able to create a call object if there was an > >>>>>> incoming call so the call objects were created up-front rather than > >>>>>> on-demand. This may be an over-simplification but you get the idea. > > >>>>> I can understand a scenario where you might want to reserve some > >>>>> memory for a critical part of the program. But I don't see many > >>>>> programs that would be able to predict their memory requirements up > >>>>> front. Take your phone example, it would be impossible to predict > >>>>> every possible user scenario and there just wouldn't be enough memory > >>>>> to create all the objects required for every possible scenario or even > >>>>> a fractional representation of every possible scenario. > > >>>> You don't know what you are talking about. > > >>> Oh yes I do. > > >> It is quite obvious that you don't > > >>> A phone has limited memory. You cannot pre-allocate all the objects a > >>> user *may* require to run all apps on his/her phone. > > >> Why are you so dense? Where did I say that? I said the Telephony App > >> could create all the objects it needs up front not other less critical apps. > > >>> video jukebox, photo editor, soundblaster master etc etc. > > >> Obviously these apps are not critical so wouldn't be required to create > >> any objects up front. > > > But according to your programming style, if these apps did not check > > for allocation errors the phone would crash regularly thus incoming > > calls could be missed during phone reboots. > > SO what was the point of preallocating call objects in case of > > incoming calls? > > Does a crashing Windows app crash Windows? No. Why would a phone be > any different? Try engaging your brain. > Why does any app have to crash? Its only crashing because of an incompetent programmer somewhere. There is no point in having robust code when there is code running alongside it that will crash the system at the slightest glimmer of a low memory situation.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-09-01 12:41 +0100 |
| Message-ID | <2-WdnZiSIZ8e8sLTnZ2dnUVZ8qudnZ2d@giganews.com> |
| In reply to | #9584 |
On 01/09/2011 08:50, Paul wrote: > On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: >> On 31/08/2011 02:38, Paul wrote: >> >> >> >> >> >>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: >>>> On 31/08/2011 01:11, Paul wrote: >> >>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>> On 31/08/2011 00:17, Paul wrote: >> >>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: >> >>>>>>>>> On 30/08/2011 18:31, Paul wrote: >>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: >> >>>>>>>>>>>> Bollocks. >>>>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get >>>>>>>>>>>> out of the arguement with some bullshit about noobish guff. >> >>>>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a >>>>>>>>>>>> program to crash if an allocation fails, and you know it. >> >>>>>>>>>>> I said the following: >> >>>>>>>>>>> "The only sane remedy for most cases of allocation failure is to >>>>>>>>>>> terminate the application which is what will happen with an uncaught >>>>>>>>>>> exception." >> >>>>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As >>>>>>>>>>> usual you fail and continue to fail with your bullshit: note the words >>>>>>>>>>> "most cases of" in what I said. >> >>>>>>>>>> It's not the only sane remedy. It's the most insane remedy. >> >>>>>>>>> In your own deluded, ill-informed opinion. >> >>>>>>>>>> Imagine a program that controlled a robot: >>>>>>>>>> One process for each limb, one for the head and one for the central >>>>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of >>>>>>>>>> memory because a screeching parrot flies past. >>>>>>>>>> What is the "sane" option your program should take: >>>>>>>>>> Shut down eye and hearing modules and slow his walking speed? >>>>>>>>>> Just let the program crash and allow the robot to fall over in a heap? >> >>>>>>>>> Are you blind as well as dense? I said: >> >>>>>>>>> "The only sane remedy for *most cases of* allocation failure is to >>>>>>>>> terminate the application which is what will happen with an uncaught >>>>>>>>> exception." >> >>>>>>>>> *most cases of* >> >>>>>>>>> If I was designing robot control software than I would design it in such >>>>>>>>> a way that certain individual sub-systems allocate all their required >>>>>>>>> memory up-front so that if some fatal error does occur then the robot >>>>>>>>> can safely come to a stand still and then reboot its systems. >> >>>>>>>>>> If you were working on critical systems such as aircraft controls >>>>>>>>>> would you still think that allowing errors to go uncatched is the only >>>>>>>>>> sane remedy? >> >>>>>>>>> Critical systems such as aircraft controls will (I assume) allocate all >>>>>>>>> the memory that is needed for all of their operations up-front so the >>>>>>>>> situation of a memory allocation failure during flight will never occur. >> >>>>>>>> I actually have real world experience of doing something similar as I >>>>>>>> was on the Telephony Application Call Control team for two different >>>>>>>> smartphones. If the user exhausts their memory running apps Telephony >>>>>>>> would still need to be able to create a call object if there was an >>>>>>>> incoming call so the call objects were created up-front rather than >>>>>>>> on-demand. This may be an over-simplification but you get the idea. >> >>>>>>> I can understand a scenario where you might want to reserve some >>>>>>> memory for a critical part of the program. But I don't see many >>>>>>> programs that would be able to predict their memory requirements up >>>>>>> front. Take your phone example, it would be impossible to predict >>>>>>> every possible user scenario and there just wouldn't be enough memory >>>>>>> to create all the objects required for every possible scenario or even >>>>>>> a fractional representation of every possible scenario. >> >>>>>> You don't know what you are talking about. >> >>>>> Oh yes I do. >> >>>> It is quite obvious that you don't >> >>>>> A phone has limited memory. You cannot pre-allocate all the objects a >>>>> user *may* require to run all apps on his/her phone. >> >>>> Why are you so dense? Where did I say that? I said the Telephony App >>>> could create all the objects it needs up front not other less critical apps. >> >>>>> video jukebox, photo editor, soundblaster master etc etc. >> >>>> Obviously these apps are not critical so wouldn't be required to create >>>> any objects up front. >> >>> But according to your programming style, if these apps did not check >>> for allocation errors the phone would crash regularly thus incoming >>> calls could be missed during phone reboots. >>> SO what was the point of preallocating call objects in case of >>> incoming calls? >> >> Does a crashing Windows app crash Windows? No. Why would a phone be >> any different? Try engaging your brain. >> > Why does any app have to crash? > Its only crashing because of an incompetent programmer somewhere. > > There is no point in having robust code when there is code running > alongside it that will crash the system at the slightest glimmer of a > low memory situation. Crash the system? Again: Does a crashing Windows app crash Windows? No. Why would a phone be any different? Try engaging your brain. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-01 05:00 -0700 |
| Message-ID | <385a737c-a1e9-49e6-9ca5-a78a34100fbd@s2g2000vby.googlegroups.com> |
| In reply to | #9600 |
On Sep 1, 12:41 pm, Leigh Johnston <le...@i42.co.uk> wrote: > On 01/09/2011 08:50, Paul wrote: > > > > > > > On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >> On 31/08/2011 02:38, Paul wrote: > > >>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: > >>>> On 31/08/2011 01:11, Paul wrote: > > >>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>> On 31/08/2011 00:17, Paul wrote: > > >>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: > > >>>>>>>>> On 30/08/2011 18:31, Paul wrote: > >>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: > > >>>>>>>>>>>> Bollocks. > >>>>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get > >>>>>>>>>>>> out of the arguement with some bullshit about noobish guff. > > >>>>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a > >>>>>>>>>>>> program to crash if an allocation fails, and you know it. > > >>>>>>>>>>> I said the following: > > >>>>>>>>>>> "The only sane remedy for most cases of allocation failure is to > >>>>>>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>>>>>> exception." > > >>>>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As > >>>>>>>>>>> usual you fail and continue to fail with your bullshit: note the words > >>>>>>>>>>> "most cases of" in what I said. > > >>>>>>>>>> It's not the only sane remedy. It's the most insane remedy. > > >>>>>>>>> In your own deluded, ill-informed opinion. > > >>>>>>>>>> Imagine a program that controlled a robot: > >>>>>>>>>> One process for each limb, one for the head and one for the central > >>>>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of > >>>>>>>>>> memory because a screeching parrot flies past. > >>>>>>>>>> What is the "sane" option your program should take: > >>>>>>>>>> Shut down eye and hearing modules and slow his walking speed? > >>>>>>>>>> Just let the program crash and allow the robot to fall over in a heap? > > >>>>>>>>> Are you blind as well as dense? I said: > > >>>>>>>>> "The only sane remedy for *most cases of* allocation failure is to > >>>>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>>>> exception." > > >>>>>>>>> *most cases of* > > >>>>>>>>> If I was designing robot control software than I would design it in such > >>>>>>>>> a way that certain individual sub-systems allocate all their required > >>>>>>>>> memory up-front so that if some fatal error does occur then the robot > >>>>>>>>> can safely come to a stand still and then reboot its systems. > > >>>>>>>>>> If you were working on critical systems such as aircraft controls > >>>>>>>>>> would you still think that allowing errors to go uncatched is the only > >>>>>>>>>> sane remedy? > > >>>>>>>>> Critical systems such as aircraft controls will (I assume) allocate all > >>>>>>>>> the memory that is needed for all of their operations up-front so the > >>>>>>>>> situation of a memory allocation failure during flight will never occur. > > >>>>>>>> I actually have real world experience of doing something similar as I > >>>>>>>> was on the Telephony Application Call Control team for two different > >>>>>>>> smartphones. If the user exhausts their memory running apps Telephony > >>>>>>>> would still need to be able to create a call object if there was an > >>>>>>>> incoming call so the call objects were created up-front rather than > >>>>>>>> on-demand. This may be an over-simplification but you get the idea. > > >>>>>>> I can understand a scenario where you might want to reserve some > >>>>>>> memory for a critical part of the program. But I don't see many > >>>>>>> programs that would be able to predict their memory requirements up > >>>>>>> front. Take your phone example, it would be impossible to predict > >>>>>>> every possible user scenario and there just wouldn't be enough memory > >>>>>>> to create all the objects required for every possible scenario or even > >>>>>>> a fractional representation of every possible scenario. > > >>>>>> You don't know what you are talking about. > > >>>>> Oh yes I do. > > >>>> It is quite obvious that you don't > > >>>>> A phone has limited memory. You cannot pre-allocate all the objects a > >>>>> user *may* require to run all apps on his/her phone. > > >>>> Why are you so dense? Where did I say that? I said the Telephony App > >>>> could create all the objects it needs up front not other less critical apps. > > >>>>> video jukebox, photo editor, soundblaster master etc etc. > > >>>> Obviously these apps are not critical so wouldn't be required to create > >>>> any objects up front. > > >>> But according to your programming style, if these apps did not check > >>> for allocation errors the phone would crash regularly thus incoming > >>> calls could be missed during phone reboots. > >>> SO what was the point of preallocating call objects in case of > >>> incoming calls? > > >> Does a crashing Windows app crash Windows? No. Why would a phone be > >> any different? Try engaging your brain. > > > Why does any app have to crash? > > Its only crashing because of an incompetent programmer somewhere. > > > There is no point in having robust code when there is code running > > alongside it that will crash the system at the slightest glimmer of a > > low memory situation. > > Crash the system? Again: Does a crashing Windows app crash Windows? > No. Why would a phone be any different? Try engaging your brain. > You have no idea what will happen if you don't catch the exception and close the program safely. Many an application has crashed a system or caused a BSOD.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-09-01 13:59 +0100 |
| Message-ID | <rp6dnR4dFohQHMLTnZ2dnUVZ7vqdnZ2d@giganews.com> |
| In reply to | #9604 |
On 01/09/2011 13:00, Paul wrote: > On Sep 1, 12:41 pm, Leigh Johnston<le...@i42.co.uk> wrote: >> On 01/09/2011 08:50, Paul wrote: >> >> >> >> >> >>> On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>> On 31/08/2011 02:38, Paul wrote: >> >>>>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>> On 31/08/2011 01:11, Paul wrote: >> >>>>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>> On 31/08/2011 00:17, Paul wrote: >> >>>>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: >> >>>>>>>>>>> On 30/08/2011 18:31, Paul wrote: >>>>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: >> >>>>>>>>>>>>>> Bollocks. >>>>>>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get >>>>>>>>>>>>>> out of the arguement with some bullshit about noobish guff. >> >>>>>>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a >>>>>>>>>>>>>> program to crash if an allocation fails, and you know it. >> >>>>>>>>>>>>> I said the following: >> >>>>>>>>>>>>> "The only sane remedy for most cases of allocation failure is to >>>>>>>>>>>>> terminate the application which is what will happen with an uncaught >>>>>>>>>>>>> exception." >> >>>>>>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As >>>>>>>>>>>>> usual you fail and continue to fail with your bullshit: note the words >>>>>>>>>>>>> "most cases of" in what I said. >> >>>>>>>>>>>> It's not the only sane remedy. It's the most insane remedy. >> >>>>>>>>>>> In your own deluded, ill-informed opinion. >> >>>>>>>>>>>> Imagine a program that controlled a robot: >>>>>>>>>>>> One process for each limb, one for the head and one for the central >>>>>>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of >>>>>>>>>>>> memory because a screeching parrot flies past. >>>>>>>>>>>> What is the "sane" option your program should take: >>>>>>>>>>>> Shut down eye and hearing modules and slow his walking speed? >>>>>>>>>>>> Just let the program crash and allow the robot to fall over in a heap? >> >>>>>>>>>>> Are you blind as well as dense? I said: >> >>>>>>>>>>> "The only sane remedy for *most cases of* allocation failure is to >>>>>>>>>>> terminate the application which is what will happen with an uncaught >>>>>>>>>>> exception." >> >>>>>>>>>>> *most cases of* >> >>>>>>>>>>> If I was designing robot control software than I would design it in such >>>>>>>>>>> a way that certain individual sub-systems allocate all their required >>>>>>>>>>> memory up-front so that if some fatal error does occur then the robot >>>>>>>>>>> can safely come to a stand still and then reboot its systems. >> >>>>>>>>>>>> If you were working on critical systems such as aircraft controls >>>>>>>>>>>> would you still think that allowing errors to go uncatched is the only >>>>>>>>>>>> sane remedy? >> >>>>>>>>>>> Critical systems such as aircraft controls will (I assume) allocate all >>>>>>>>>>> the memory that is needed for all of their operations up-front so the >>>>>>>>>>> situation of a memory allocation failure during flight will never occur. >> >>>>>>>>>> I actually have real world experience of doing something similar as I >>>>>>>>>> was on the Telephony Application Call Control team for two different >>>>>>>>>> smartphones. If the user exhausts their memory running apps Telephony >>>>>>>>>> would still need to be able to create a call object if there was an >>>>>>>>>> incoming call so the call objects were created up-front rather than >>>>>>>>>> on-demand. This may be an over-simplification but you get the idea. >> >>>>>>>>> I can understand a scenario where you might want to reserve some >>>>>>>>> memory for a critical part of the program. But I don't see many >>>>>>>>> programs that would be able to predict their memory requirements up >>>>>>>>> front. Take your phone example, it would be impossible to predict >>>>>>>>> every possible user scenario and there just wouldn't be enough memory >>>>>>>>> to create all the objects required for every possible scenario or even >>>>>>>>> a fractional representation of every possible scenario. >> >>>>>>>> You don't know what you are talking about. >> >>>>>>> Oh yes I do. >> >>>>>> It is quite obvious that you don't >> >>>>>>> A phone has limited memory. You cannot pre-allocate all the objects a >>>>>>> user *may* require to run all apps on his/her phone. >> >>>>>> Why are you so dense? Where did I say that? I said the Telephony App >>>>>> could create all the objects it needs up front not other less critical apps. >> >>>>>>> video jukebox, photo editor, soundblaster master etc etc. >> >>>>>> Obviously these apps are not critical so wouldn't be required to create >>>>>> any objects up front. >> >>>>> But according to your programming style, if these apps did not check >>>>> for allocation errors the phone would crash regularly thus incoming >>>>> calls could be missed during phone reboots. >>>>> SO what was the point of preallocating call objects in case of >>>>> incoming calls? >> >>>> Does a crashing Windows app crash Windows? No. Why would a phone be >>>> any different? Try engaging your brain. >> >>> Why does any app have to crash? >>> Its only crashing because of an incompetent programmer somewhere. >> >>> There is no point in having robust code when there is code running >>> alongside it that will crash the system at the slightest glimmer of a >>> low memory situation. >> >> Crash the system? Again: Does a crashing Windows app crash Windows? >> No. Why would a phone be any different? Try engaging your brain. >> > You have no idea what will happen if you don't catch the exception and > close the program safely. > Many an application has crashed a system or caused a BSOD. You don't know what you are talking about; for a clue see: http://en.wikipedia.org/wiki/User_space /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-01 06:35 -0700 |
| Message-ID | <430c7d51-3c05-4f1a-b3bd-a0c082e09ca2@q2g2000vbz.googlegroups.com> |
| In reply to | #9606 |
On Sep 1, 1:59 pm, Leigh Johnston <le...@i42.co.uk> wrote: > On 01/09/2011 13:00, Paul wrote: > > > > > > > On Sep 1, 12:41 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >> On 01/09/2011 08:50, Paul wrote: > > >>> On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>> On 31/08/2011 02:38, Paul wrote: > > >>>>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>> On 31/08/2011 01:11, Paul wrote: > > >>>>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>> On 31/08/2011 00:17, Paul wrote: > > >>>>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: > > >>>>>>>>>>> On 30/08/2011 18:31, Paul wrote: > >>>>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: > > >>>>>>>>>>>>>> Bollocks. > >>>>>>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get > >>>>>>>>>>>>>> out of the arguement with some bullshit about noobish guff. > > >>>>>>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a > >>>>>>>>>>>>>> program to crash if an allocation fails, and you know it. > > >>>>>>>>>>>>> I said the following: > > >>>>>>>>>>>>> "The only sane remedy for most cases of allocation failure is to > >>>>>>>>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>>>>>>>> exception." > > >>>>>>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As > >>>>>>>>>>>>> usual you fail and continue to fail with your bullshit: note the words > >>>>>>>>>>>>> "most cases of" in what I said. > > >>>>>>>>>>>> It's not the only sane remedy. It's the most insane remedy. > > >>>>>>>>>>> In your own deluded, ill-informed opinion. > > >>>>>>>>>>>> Imagine a program that controlled a robot: > >>>>>>>>>>>> One process for each limb, one for the head and one for the central > >>>>>>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of > >>>>>>>>>>>> memory because a screeching parrot flies past. > >>>>>>>>>>>> What is the "sane" option your program should take: > >>>>>>>>>>>> Shut down eye and hearing modules and slow his walking speed? > >>>>>>>>>>>> Just let the program crash and allow the robot to fall over in a heap? > > >>>>>>>>>>> Are you blind as well as dense? I said: > > >>>>>>>>>>> "The only sane remedy for *most cases of* allocation failure is to > >>>>>>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>>>>>> exception." > > >>>>>>>>>>> *most cases of* > > >>>>>>>>>>> If I was designing robot control software than I would design it in such > >>>>>>>>>>> a way that certain individual sub-systems allocate all their required > >>>>>>>>>>> memory up-front so that if some fatal error does occur then the robot > >>>>>>>>>>> can safely come to a stand still and then reboot its systems. > > >>>>>>>>>>>> If you were working on critical systems such as aircraft controls > >>>>>>>>>>>> would you still think that allowing errors to go uncatched is the only > >>>>>>>>>>>> sane remedy? > > >>>>>>>>>>> Critical systems such as aircraft controls will (I assume) allocate all > >>>>>>>>>>> the memory that is needed for all of their operations up-front so the > >>>>>>>>>>> situation of a memory allocation failure during flight will never occur. > > >>>>>>>>>> I actually have real world experience of doing something similar as I > >>>>>>>>>> was on the Telephony Application Call Control team for two different > >>>>>>>>>> smartphones. If the user exhausts their memory running apps Telephony > >>>>>>>>>> would still need to be able to create a call object if there was an > >>>>>>>>>> incoming call so the call objects were created up-front rather than > >>>>>>>>>> on-demand. This may be an over-simplification but you get the idea. > > >>>>>>>>> I can understand a scenario where you might want to reserve some > >>>>>>>>> memory for a critical part of the program. But I don't see many > >>>>>>>>> programs that would be able to predict their memory requirements up > >>>>>>>>> front. Take your phone example, it would be impossible to predict > >>>>>>>>> every possible user scenario and there just wouldn't be enough memory > >>>>>>>>> to create all the objects required for every possible scenario or even > >>>>>>>>> a fractional representation of every possible scenario. > > >>>>>>>> You don't know what you are talking about. > > >>>>>>> Oh yes I do. > > >>>>>> It is quite obvious that you don't > > >>>>>>> A phone has limited memory. You cannot pre-allocate all the objects a > >>>>>>> user *may* require to run all apps on his/her phone. > > >>>>>> Why are you so dense? Where did I say that? I said the Telephony App > >>>>>> could create all the objects it needs up front not other less critical apps. > > >>>>>>> video jukebox, photo editor, soundblaster master etc etc. > > >>>>>> Obviously these apps are not critical so wouldn't be required to create > >>>>>> any objects up front. > > >>>>> But according to your programming style, if these apps did not check > >>>>> for allocation errors the phone would crash regularly thus incoming > >>>>> calls could be missed during phone reboots. > >>>>> SO what was the point of preallocating call objects in case of > >>>>> incoming calls? > > >>>> Does a crashing Windows app crash Windows? No. Why would a phone be > >>>> any different? Try engaging your brain. > > >>> Why does any app have to crash? > >>> Its only crashing because of an incompetent programmer somewhere. > > >>> There is no point in having robust code when there is code running > >>> alongside it that will crash the system at the slightest glimmer of a > >>> low memory situation. > > >> Crash the system? Again: Does a crashing Windows app crash Windows? > >> No. Why would a phone be any different? Try engaging your brain. > > > You have no idea what will happen if you don't catch the exception and > > close the program safely. > > Many an application has crashed a system or caused a BSOD. > > You don't know what you are talking about; for a clue see: > > http://en.wikipedia.org/wiki/User_space > This is a crap attempt to justify your support for sloppy programming techniques. If you allow expections to go uncaught you have no control over your program and any other resources it may be using, these resources are not limited to userspace. And since when was C++ unsuitable for kernal mode programming?
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-09-01 14:50 +0100 |
| Message-ID | <XZydnZn9TuM4EMLTnZ2dnUVZ8s-dnZ2d@giganews.com> |
| In reply to | #9609 |
On 01/09/2011 14:35, Paul wrote: > On Sep 1, 1:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: >> On 01/09/2011 13:00, Paul wrote: >> >> >> >> >> >>> On Sep 1, 12:41 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>> On 01/09/2011 08:50, Paul wrote: >> >>>>> On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>> On 31/08/2011 02:38, Paul wrote: >> >>>>>>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>> On 31/08/2011 01:11, Paul wrote: >> >>>>>>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>> On 31/08/2011 00:17, Paul wrote: >> >>>>>>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: >> >>>>>>>>>>>>> On 30/08/2011 18:31, Paul wrote: >>>>>>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: >> >>>>>>>>>>>>>>>> Bollocks. >>>>>>>>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get >>>>>>>>>>>>>>>> out of the arguement with some bullshit about noobish guff. >> >>>>>>>>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a >>>>>>>>>>>>>>>> program to crash if an allocation fails, and you know it. >> >>>>>>>>>>>>>>> I said the following: >> >>>>>>>>>>>>>>> "The only sane remedy for most cases of allocation failure is to >>>>>>>>>>>>>>> terminate the application which is what will happen with an uncaught >>>>>>>>>>>>>>> exception." >> >>>>>>>>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As >>>>>>>>>>>>>>> usual you fail and continue to fail with your bullshit: note the words >>>>>>>>>>>>>>> "most cases of" in what I said. >> >>>>>>>>>>>>>> It's not the only sane remedy. It's the most insane remedy. >> >>>>>>>>>>>>> In your own deluded, ill-informed opinion. >> >>>>>>>>>>>>>> Imagine a program that controlled a robot: >>>>>>>>>>>>>> One process for each limb, one for the head and one for the central >>>>>>>>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of >>>>>>>>>>>>>> memory because a screeching parrot flies past. >>>>>>>>>>>>>> What is the "sane" option your program should take: >>>>>>>>>>>>>> Shut down eye and hearing modules and slow his walking speed? >>>>>>>>>>>>>> Just let the program crash and allow the robot to fall over in a heap? >> >>>>>>>>>>>>> Are you blind as well as dense? I said: >> >>>>>>>>>>>>> "The only sane remedy for *most cases of* allocation failure is to >>>>>>>>>>>>> terminate the application which is what will happen with an uncaught >>>>>>>>>>>>> exception." >> >>>>>>>>>>>>> *most cases of* >> >>>>>>>>>>>>> If I was designing robot control software than I would design it in such >>>>>>>>>>>>> a way that certain individual sub-systems allocate all their required >>>>>>>>>>>>> memory up-front so that if some fatal error does occur then the robot >>>>>>>>>>>>> can safely come to a stand still and then reboot its systems. >> >>>>>>>>>>>>>> If you were working on critical systems such as aircraft controls >>>>>>>>>>>>>> would you still think that allowing errors to go uncatched is the only >>>>>>>>>>>>>> sane remedy? >> >>>>>>>>>>>>> Critical systems such as aircraft controls will (I assume) allocate all >>>>>>>>>>>>> the memory that is needed for all of their operations up-front so the >>>>>>>>>>>>> situation of a memory allocation failure during flight will never occur. >> >>>>>>>>>>>> I actually have real world experience of doing something similar as I >>>>>>>>>>>> was on the Telephony Application Call Control team for two different >>>>>>>>>>>> smartphones. If the user exhausts their memory running apps Telephony >>>>>>>>>>>> would still need to be able to create a call object if there was an >>>>>>>>>>>> incoming call so the call objects were created up-front rather than >>>>>>>>>>>> on-demand. This may be an over-simplification but you get the idea. >> >>>>>>>>>>> I can understand a scenario where you might want to reserve some >>>>>>>>>>> memory for a critical part of the program. But I don't see many >>>>>>>>>>> programs that would be able to predict their memory requirements up >>>>>>>>>>> front. Take your phone example, it would be impossible to predict >>>>>>>>>>> every possible user scenario and there just wouldn't be enough memory >>>>>>>>>>> to create all the objects required for every possible scenario or even >>>>>>>>>>> a fractional representation of every possible scenario. >> >>>>>>>>>> You don't know what you are talking about. >> >>>>>>>>> Oh yes I do. >> >>>>>>>> It is quite obvious that you don't >> >>>>>>>>> A phone has limited memory. You cannot pre-allocate all the objects a >>>>>>>>> user *may* require to run all apps on his/her phone. >> >>>>>>>> Why are you so dense? Where did I say that? I said the Telephony App >>>>>>>> could create all the objects it needs up front not other less critical apps. >> >>>>>>>>> video jukebox, photo editor, soundblaster master etc etc. >> >>>>>>>> Obviously these apps are not critical so wouldn't be required to create >>>>>>>> any objects up front. >> >>>>>>> But according to your programming style, if these apps did not check >>>>>>> for allocation errors the phone would crash regularly thus incoming >>>>>>> calls could be missed during phone reboots. >>>>>>> SO what was the point of preallocating call objects in case of >>>>>>> incoming calls? >> >>>>>> Does a crashing Windows app crash Windows? No. Why would a phone be >>>>>> any different? Try engaging your brain. >> >>>>> Why does any app have to crash? >>>>> Its only crashing because of an incompetent programmer somewhere. >> >>>>> There is no point in having robust code when there is code running >>>>> alongside it that will crash the system at the slightest glimmer of a >>>>> low memory situation. >> >>>> Crash the system? Again: Does a crashing Windows app crash Windows? >>>> No. Why would a phone be any different? Try engaging your brain. >> >>> You have no idea what will happen if you don't catch the exception and >>> close the program safely. >>> Many an application has crashed a system or caused a BSOD. >> >> You don't know what you are talking about; for a clue see: >> >> http://en.wikipedia.org/wiki/User_space >> > > This is a crap attempt to justify your support for sloppy programming > techniques. > If you allow expections to go uncaught you have no control over your > program and any other resources it may be using, these resources are > not limited to userspace. And since when was C++ unsuitable for kernal > mode programming? Again you don't know what you are talking about as you don't appear to know what an "application" is. I will tell you: on most modern platforms an "application" is a program that runs in userland. An application crashing in userland should not "crash the system". C++ is of course suitable for kernel mode programming but we are not talking about kernel mode programming. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-01 13:51 -0700 |
| Message-ID | <85d438ed-a9da-4fd7-be88-3f8c92d49d31@eb1g2000vbb.googlegroups.com> |
| In reply to | #9610 |
On Sep 1, 2:50 pm, Leigh Johnston <le...@i42.co.uk> wrote: > On 01/09/2011 14:35, Paul wrote: > > > > > > > On Sep 1, 1:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >> On 01/09/2011 13:00, Paul wrote: > > >>> On Sep 1, 12:41 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>> On 01/09/2011 08:50, Paul wrote: > > >>>>> On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>> On 31/08/2011 02:38, Paul wrote: > > >>>>>>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>> On 31/08/2011 01:11, Paul wrote: > > >>>>>>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>>> On 31/08/2011 00:17, Paul wrote: > > >>>>>>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: > > >>>>>>>>>>>>> On 30/08/2011 18:31, Paul wrote: > >>>>>>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: > > >>>>>>>>>>>>>>>> Bollocks. > >>>>>>>>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get > >>>>>>>>>>>>>>>> out of the arguement with some bullshit about noobish guff. > > >>>>>>>>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a > >>>>>>>>>>>>>>>> program to crash if an allocation fails, and you know it. > > >>>>>>>>>>>>>>> I said the following: > > >>>>>>>>>>>>>>> "The only sane remedy for most cases of allocation failure is to > >>>>>>>>>>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>>>>>>>>>> exception." > > >>>>>>>>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As > >>>>>>>>>>>>>>> usual you fail and continue to fail with your bullshit: note the words > >>>>>>>>>>>>>>> "most cases of" in what I said. > > >>>>>>>>>>>>>> It's not the only sane remedy. It's the most insane remedy. > > >>>>>>>>>>>>> In your own deluded, ill-informed opinion. > > >>>>>>>>>>>>>> Imagine a program that controlled a robot: > >>>>>>>>>>>>>> One process for each limb, one for the head and one for the central > >>>>>>>>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of > >>>>>>>>>>>>>> memory because a screeching parrot flies past. > >>>>>>>>>>>>>> What is the "sane" option your program should take: > >>>>>>>>>>>>>> Shut down eye and hearing modules and slow his walking speed? > >>>>>>>>>>>>>> Just let the program crash and allow the robot to fall over in a heap? > > >>>>>>>>>>>>> Are you blind as well as dense? I said: > > >>>>>>>>>>>>> "The only sane remedy for *most cases of* allocation failure is to > >>>>>>>>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>>>>>>>> exception." > > >>>>>>>>>>>>> *most cases of* > > >>>>>>>>>>>>> If I was designing robot control software than I would design it in such > >>>>>>>>>>>>> a way that certain individual sub-systems allocate all their required > >>>>>>>>>>>>> memory up-front so that if some fatal error does occur then the robot > >>>>>>>>>>>>> can safely come to a stand still and then reboot its systems. > > >>>>>>>>>>>>>> If you were working on critical systems such as aircraft controls > >>>>>>>>>>>>>> would you still think that allowing errors to go uncatched is the only > >>>>>>>>>>>>>> sane remedy? > > >>>>>>>>>>>>> Critical systems such as aircraft controls will (I assume) allocate all > >>>>>>>>>>>>> the memory that is needed for all of their operations up-front so the > >>>>>>>>>>>>> situation of a memory allocation failure during flight will never occur. > > >>>>>>>>>>>> I actually have real world experience of doing something similar as I > >>>>>>>>>>>> was on the Telephony Application Call Control team for two different > >>>>>>>>>>>> smartphones. If the user exhausts their memory running apps Telephony > >>>>>>>>>>>> would still need to be able to create a call object if there was an > >>>>>>>>>>>> incoming call so the call objects were created up-front rather than > >>>>>>>>>>>> on-demand. This may be an over-simplification but you get the idea. > > >>>>>>>>>>> I can understand a scenario where you might want to reserve some > >>>>>>>>>>> memory for a critical part of the program. But I don't see many > >>>>>>>>>>> programs that would be able to predict their memory requirements up > >>>>>>>>>>> front. Take your phone example, it would be impossible to predict > >>>>>>>>>>> every possible user scenario and there just wouldn't be enough memory > >>>>>>>>>>> to create all the objects required for every possible scenario or even > >>>>>>>>>>> a fractional representation of every possible scenario. > > >>>>>>>>>> You don't know what you are talking about. > > >>>>>>>>> Oh yes I do. > > >>>>>>>> It is quite obvious that you don't > > >>>>>>>>> A phone has limited memory. You cannot pre-allocate all the objects a > >>>>>>>>> user *may* require to run all apps on his/her phone. > > >>>>>>>> Why are you so dense? Where did I say that? I said the Telephony App > >>>>>>>> could create all the objects it needs up front not other less critical apps. > > >>>>>>>>> video jukebox, photo editor, soundblaster master etc etc. > > >>>>>>>> Obviously these apps are not critical so wouldn't be required to create > >>>>>>>> any objects up front. > > >>>>>>> But according to your programming style, if these apps did not check > >>>>>>> for allocation errors the phone would crash regularly thus incoming > >>>>>>> calls could be missed during phone reboots. > >>>>>>> SO what was the point of preallocating call objects in case of > >>>>>>> incoming calls? > > >>>>>> Does a crashing Windows app crash Windows? No. Why would a phone be > >>>>>> any different? Try engaging your brain. > > >>>>> Why does any app have to crash? > >>>>> Its only crashing because of an incompetent programmer somewhere. > > >>>>> There is no point in having robust code when there is code running > >>>>> alongside it that will crash the system at the slightest glimmer of a > >>>>> low memory situation. > > >>>> Crash the system? Again: Does a crashing Windows app crash Windows? > >>>> No. Why would a phone be any different? Try engaging your brain. > > >>> You have no idea what will happen if you don't catch the exception and > >>> close the program safely. > >>> Many an application has crashed a system or caused a BSOD. > > >> You don't know what you are talking about; for a clue see: > > >>http://en.wikipedia.org/wiki/User_space > > > This is a crap attempt to justify your support for sloppy programming > > techniques. > > If you allow expections to go uncaught you have no control over your > > program and any other resources it may be using, these resources are > > not limited to userspace. And since when was C++ unsuitable for kernal > > mode programming? > > Again you don't know what you are talking about as you don't appear to > know what an "application" is. I will tell you: on most modern > platforms an "application" is a program that runs in userland. An > application crashing in userland should not "crash the system". > > C++ is of course suitable for kernel mode programming but we are not > talking about kernel mode programming. > Your vey own words prove how incompetent you are. You say an application "should not" crash the system but in reality you have no clue whether it will crash the sytem or not. We are talking about C++ , we are not talking about C++ *only* in a usermode archetectUER. Your attempt to confine the bounds of this discussion to USERMODE shite are overwhelmingly splattered in bullshit. Get a life and wake up , a C++ program that is *expected* to crash because the programmer is too noob to implement exception handling is a pile of shit and if that's the sort of progams you are producing then they aren't worth the filespace they occupy.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-09-01 21:58 +0100 |
| Message-ID | <QvudneiduNVgbMLTnZ2dnUVZ8rydnZ2d@giganews.com> |
| In reply to | #9620 |
On 01/09/2011 21:51, Paul wrote: [snip] >>>>>> Crash the system? Again: Does a crashing Windows app crash Windows? >>>>>> No. Why would a phone be any different? Try engaging your brain. >> >>>>> You have no idea what will happen if you don't catch the exception and >>>>> close the program safely. >>>>> Many an application has crashed a system or caused a BSOD. >> >>>> You don't know what you are talking about; for a clue see: >> >>>> http://en.wikipedia.org/wiki/User_space >> >>> This is a crap attempt to justify your support for sloppy programming >>> techniques. >>> If you allow expections to go uncaught you have no control over your >>> program and any other resources it may be using, these resources are >>> not limited to userspace. And since when was C++ unsuitable for kernal >>> mode programming? >> >> Again you don't know what you are talking about as you don't appear to >> know what an "application" is. I will tell you: on most modern >> platforms an "application" is a program that runs in userland. An >> application crashing in userland should not "crash the system". >> >> C++ is of course suitable for kernel mode programming but we are not >> talking about kernel mode programming. >> > Your vey own words prove how incompetent you are. > You say an application "should not" crash the system but in reality > you have no clue whether it will crash the sytem or not. > > We are talking about C++ , we are not talking about C++ *only* in a > usermode archetectUER. Your attempt to confine the bounds of this > discussion to USERMODE shite are overwhelmingly splattered in > bullshit. > Get a life and wake up , a C++ program that is *expected* to crash > because the programmer is too noob to implement exception handling is > a pile of shit and if that's the sort of progams you are producing > then they aren't worth the filespace they occupy. Again you show that you are unable to maturely handle losing an argument; oh well that is your problem not mine. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-01 14:05 -0700 |
| Message-ID | <167d8252-1e00-4292-8436-68078dc488e8@o10g2000vby.googlegroups.com> |
| In reply to | #9610 |
On Sep 1, 2:50 pm, Leigh Johnston <le...@i42.co.uk> wrote: > On 01/09/2011 14:35, Paul wrote: > > > > > > > On Sep 1, 1:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >> On 01/09/2011 13:00, Paul wrote: > > >>> On Sep 1, 12:41 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>> On 01/09/2011 08:50, Paul wrote: > > >>>>> On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>> On 31/08/2011 02:38, Paul wrote: > > >>>>>>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>> On 31/08/2011 01:11, Paul wrote: > > >>>>>>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>>> On 31/08/2011 00:17, Paul wrote: > > >>>>>>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: > > >>>>>>>>>>>>> On 30/08/2011 18:31, Paul wrote: > >>>>>>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: > >>>>>>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: > > >>>>>>>>>>>>>>>> Bollocks. > >>>>>>>>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get > >>>>>>>>>>>>>>>> out of the arguement with some bullshit about noobish guff. > > >>>>>>>>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a > >>>>>>>>>>>>>>>> program to crash if an allocation fails, and you know it. > > >>>>>>>>>>>>>>> I said the following: > > >>>>>>>>>>>>>>> "The only sane remedy for most cases of allocation failure is to > >>>>>>>>>>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>>>>>>>>>> exception." > > >>>>>>>>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As > >>>>>>>>>>>>>>> usual you fail and continue to fail with your bullshit: note the words > >>>>>>>>>>>>>>> "most cases of" in what I said. > > >>>>>>>>>>>>>> It's not the only sane remedy. It's the most insane remedy. > > >>>>>>>>>>>>> In your own deluded, ill-informed opinion. > > >>>>>>>>>>>>>> Imagine a program that controlled a robot: > >>>>>>>>>>>>>> One process for each limb, one for the head and one for the central > >>>>>>>>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of > >>>>>>>>>>>>>> memory because a screeching parrot flies past. > >>>>>>>>>>>>>> What is the "sane" option your program should take: > >>>>>>>>>>>>>> Shut down eye and hearing modules and slow his walking speed? > >>>>>>>>>>>>>> Just let the program crash and allow the robot to fall over in a heap? > > >>>>>>>>>>>>> Are you blind as well as dense? I said: > > >>>>>>>>>>>>> "The only sane remedy for *most cases of* allocation failure is to > >>>>>>>>>>>>> terminate the application which is what will happen with an uncaught > >>>>>>>>>>>>> exception." > > >>>>>>>>>>>>> *most cases of* > > >>>>>>>>>>>>> If I was designing robot control software than I would design it in such > >>>>>>>>>>>>> a way that certain individual sub-systems allocate all their required > >>>>>>>>>>>>> memory up-front so that if some fatal error does occur then the robot > >>>>>>>>>>>>> can safely come to a stand still and then reboot its systems. > > >>>>>>>>>>>>>> If you were working on critical systems such as aircraft controls > >>>>>>>>>>>>>> would you still think that allowing errors to go uncatched is the only > >>>>>>>>>>>>>> sane remedy? > > >>>>>>>>>>>>> Critical systems such as aircraft controls will (I assume) allocate all > >>>>>>>>>>>>> the memory that is needed for all of their operations up-front so the > >>>>>>>>>>>>> situation of a memory allocation failure during flight will never occur. > > >>>>>>>>>>>> I actually have real world experience of doing something similar as I > >>>>>>>>>>>> was on the Telephony Application Call Control team for two different > >>>>>>>>>>>> smartphones. If the user exhausts their memory running apps Telephony > >>>>>>>>>>>> would still need to be able to create a call object if there was an > >>>>>>>>>>>> incoming call so the call objects were created up-front rather than > >>>>>>>>>>>> on-demand. This may be an over-simplification but you get the idea. > > >>>>>>>>>>> I can understand a scenario where you might want to reserve some > >>>>>>>>>>> memory for a critical part of the program. But I don't see many > >>>>>>>>>>> programs that would be able to predict their memory requirements up > >>>>>>>>>>> front. Take your phone example, it would be impossible to predict > >>>>>>>>>>> every possible user scenario and there just wouldn't be enough memory > >>>>>>>>>>> to create all the objects required for every possible scenario or even > >>>>>>>>>>> a fractional representation of every possible scenario. > > >>>>>>>>>> You don't know what you are talking about. > > >>>>>>>>> Oh yes I do. > > >>>>>>>> It is quite obvious that you don't > > >>>>>>>>> A phone has limited memory. You cannot pre-allocate all the objects a > >>>>>>>>> user *may* require to run all apps on his/her phone. > > >>>>>>>> Why are you so dense? Where did I say that? I said the Telephony App > >>>>>>>> could create all the objects it needs up front not other less critical apps. > > >>>>>>>>> video jukebox, photo editor, soundblaster master etc etc. > > >>>>>>>> Obviously these apps are not critical so wouldn't be required to create > >>>>>>>> any objects up front. > > >>>>>>> But according to your programming style, if these apps did not check > >>>>>>> for allocation errors the phone would crash regularly thus incoming > >>>>>>> calls could be missed during phone reboots. > >>>>>>> SO what was the point of preallocating call objects in case of > >>>>>>> incoming calls? > > >>>>>> Does a crashing Windows app crash Windows? No. Why would a phone be > >>>>>> any different? Try engaging your brain. > > >>>>> Why does any app have to crash? > >>>>> Its only crashing because of an incompetent programmer somewhere. > > >>>>> There is no point in having robust code when there is code running > >>>>> alongside it that will crash the system at the slightest glimmer of a > >>>>> low memory situation. > > >>>> Crash the system? Again: Does a crashing Windows app crash Windows? > >>>> No. Why would a phone be any different? Try engaging your brain. > > >>> You have no idea what will happen if you don't catch the exception and > >>> close the program safely. > >>> Many an application has crashed a system or caused a BSOD. > > >> You don't know what you are talking about; for a clue see: > > >>http://en.wikipedia.org/wiki/User_space > > > This is a crap attempt to justify your support for sloppy programming > > techniques. > > If you allow expections to go uncaught you have no control over your > > program and any other resources it may be using, these resources are > > not limited to userspace. And since when was C++ unsuitable for kernal > > mode programming? > > Again you don't know what you are talking about as you don't appear to > know what an "application" is. I will tell you: on most modern > platforms an "application" is a program that runs in userland. An > application crashing in userland should not "crash the system". > > C++ is of course suitable for kernel mode programming but we are not > talking about kernel mode programming. > Bollocks, we are taliking about C++ programs in general. ANd even if we were just considering applications that run in some user space on a given OS it is still not guaranteeed what will happen when an application crashes which is probably why you use the term "should not" crash the system. In reality you don't have a clue what will happen.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-09-01 22:08 +0100 |
| Message-ID | <LOSdnYODSPPAacLTnZ2dnUVZ8jCdnZ2d@giganews.com> |
| In reply to | #9622 |
On 01/09/2011 22:05, Paul wrote: > On Sep 1, 2:50 pm, Leigh Johnston<le...@i42.co.uk> wrote: >> On 01/09/2011 14:35, Paul wrote: >> >> >> >> >> >>> On Sep 1, 1:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>> On 01/09/2011 13:00, Paul wrote: >> >>>>> On Sep 1, 12:41 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>> On 01/09/2011 08:50, Paul wrote: >> >>>>>>> On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>> On 31/08/2011 02:38, Paul wrote: >> >>>>>>>>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>> On 31/08/2011 01:11, Paul wrote: >> >>>>>>>>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>>>> On 31/08/2011 00:17, Paul wrote: >> >>>>>>>>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: >> >>>>>>>>>>>>>>> On 30/08/2011 18:31, Paul wrote: >>>>>>>>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: >>>>>>>>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: >> >>>>>>>>>>>>>>>>>> Bollocks. >>>>>>>>>>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get >>>>>>>>>>>>>>>>>> out of the arguement with some bullshit about noobish guff. >> >>>>>>>>>>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a >>>>>>>>>>>>>>>>>> program to crash if an allocation fails, and you know it. >> >>>>>>>>>>>>>>>>> I said the following: >> >>>>>>>>>>>>>>>>> "The only sane remedy for most cases of allocation failure is to >>>>>>>>>>>>>>>>> terminate the application which is what will happen with an uncaught >>>>>>>>>>>>>>>>> exception." >> >>>>>>>>>>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As >>>>>>>>>>>>>>>>> usual you fail and continue to fail with your bullshit: note the words >>>>>>>>>>>>>>>>> "most cases of" in what I said. >> >>>>>>>>>>>>>>>> It's not the only sane remedy. It's the most insane remedy. >> >>>>>>>>>>>>>>> In your own deluded, ill-informed opinion. >> >>>>>>>>>>>>>>>> Imagine a program that controlled a robot: >>>>>>>>>>>>>>>> One process for each limb, one for the head and one for the central >>>>>>>>>>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of >>>>>>>>>>>>>>>> memory because a screeching parrot flies past. >>>>>>>>>>>>>>>> What is the "sane" option your program should take: >>>>>>>>>>>>>>>> Shut down eye and hearing modules and slow his walking speed? >>>>>>>>>>>>>>>> Just let the program crash and allow the robot to fall over in a heap? >> >>>>>>>>>>>>>>> Are you blind as well as dense? I said: >> >>>>>>>>>>>>>>> "The only sane remedy for *most cases of* allocation failure is to >>>>>>>>>>>>>>> terminate the application which is what will happen with an uncaught >>>>>>>>>>>>>>> exception." >> >>>>>>>>>>>>>>> *most cases of* >> >>>>>>>>>>>>>>> If I was designing robot control software than I would design it in such >>>>>>>>>>>>>>> a way that certain individual sub-systems allocate all their required >>>>>>>>>>>>>>> memory up-front so that if some fatal error does occur then the robot >>>>>>>>>>>>>>> can safely come to a stand still and then reboot its systems. >> >>>>>>>>>>>>>>>> If you were working on critical systems such as aircraft controls >>>>>>>>>>>>>>>> would you still think that allowing errors to go uncatched is the only >>>>>>>>>>>>>>>> sane remedy? >> >>>>>>>>>>>>>>> Critical systems such as aircraft controls will (I assume) allocate all >>>>>>>>>>>>>>> the memory that is needed for all of their operations up-front so the >>>>>>>>>>>>>>> situation of a memory allocation failure during flight will never occur. >> >>>>>>>>>>>>>> I actually have real world experience of doing something similar as I >>>>>>>>>>>>>> was on the Telephony Application Call Control team for two different >>>>>>>>>>>>>> smartphones. If the user exhausts their memory running apps Telephony >>>>>>>>>>>>>> would still need to be able to create a call object if there was an >>>>>>>>>>>>>> incoming call so the call objects were created up-front rather than >>>>>>>>>>>>>> on-demand. This may be an over-simplification but you get the idea. >> >>>>>>>>>>>>> I can understand a scenario where you might want to reserve some >>>>>>>>>>>>> memory for a critical part of the program. But I don't see many >>>>>>>>>>>>> programs that would be able to predict their memory requirements up >>>>>>>>>>>>> front. Take your phone example, it would be impossible to predict >>>>>>>>>>>>> every possible user scenario and there just wouldn't be enough memory >>>>>>>>>>>>> to create all the objects required for every possible scenario or even >>>>>>>>>>>>> a fractional representation of every possible scenario. >> >>>>>>>>>>>> You don't know what you are talking about. >> >>>>>>>>>>> Oh yes I do. >> >>>>>>>>>> It is quite obvious that you don't >> >>>>>>>>>>> A phone has limited memory. You cannot pre-allocate all the objects a >>>>>>>>>>> user *may* require to run all apps on his/her phone. >> >>>>>>>>>> Why are you so dense? Where did I say that? I said the Telephony App >>>>>>>>>> could create all the objects it needs up front not other less critical apps. >> >>>>>>>>>>> video jukebox, photo editor, soundblaster master etc etc. >> >>>>>>>>>> Obviously these apps are not critical so wouldn't be required to create >>>>>>>>>> any objects up front. >> >>>>>>>>> But according to your programming style, if these apps did not check >>>>>>>>> for allocation errors the phone would crash regularly thus incoming >>>>>>>>> calls could be missed during phone reboots. >>>>>>>>> SO what was the point of preallocating call objects in case of >>>>>>>>> incoming calls? >> >>>>>>>> Does a crashing Windows app crash Windows? No. Why would a phone be >>>>>>>> any different? Try engaging your brain. >> >>>>>>> Why does any app have to crash? >>>>>>> Its only crashing because of an incompetent programmer somewhere. >> >>>>>>> There is no point in having robust code when there is code running >>>>>>> alongside it that will crash the system at the slightest glimmer of a >>>>>>> low memory situation. >> >>>>>> Crash the system? Again: Does a crashing Windows app crash Windows? >>>>>> No. Why would a phone be any different? Try engaging your brain. >> >>>>> You have no idea what will happen if you don't catch the exception and >>>>> close the program safely. >>>>> Many an application has crashed a system or caused a BSOD. >> >>>> You don't know what you are talking about; for a clue see: >> >>>> http://en.wikipedia.org/wiki/User_space >> >>> This is a crap attempt to justify your support for sloppy programming >>> techniques. >>> If you allow expections to go uncaught you have no control over your >>> program and any other resources it may be using, these resources are >>> not limited to userspace. And since when was C++ unsuitable for kernal >>> mode programming? >> >> Again you don't know what you are talking about as you don't appear to >> know what an "application" is. I will tell you: on most modern >> platforms an "application" is a program that runs in userland. An >> application crashing in userland should not "crash the system". >> >> C++ is of course suitable for kernel mode programming but we are not >> talking about kernel mode programming. >> > Bollocks, we are taliking about C++ programs in general. > > ANd even if we were just considering applications that run in some > user space on a given OS it is still not guaranteeed what will happen > when an application crashes which is probably why you use the term > "should not" crash the system. In reality you don't have a clue what > will happen. Unfortunately this reply is not much better than your other reply which says more or less the same thing but with added vitriol so the answer is the same: you are unable to maturely handle losing an argument which is your problem not mine; heh. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-09-02 03:16 -0700 |
| Message-ID | <31d93030-50fa-4926-abc1-c2daf800356b@er4g2000vbb.googlegroups.com> |
| In reply to | #9622 |
On Sep 1, 10:05 pm, Paul <pchris...@yahoo.co.uk> wrote: > On Sep 1, 2:50 pm, Leigh Johnston <le...@i42.co.uk> wrote: > > On 01/09/2011 14:35, Paul wrote: > > > On Sep 1, 1:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >> On 01/09/2011 13:00, Paul wrote: > > >>> On Sep 1, 12:41 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>> On 01/09/2011 08:50, Paul wrote: > > >>>>> On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>>>> On 31/08/2011 02:38, Paul wrote: > > >>>>>>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>>>>>> On 31/08/2011 01:11, Paul wrote: > > >>>>>>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>>>>>>>> On 31/08/2011 00:17, Paul wrote: > > >>>>>>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>>>>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: > > >>>>>>>>>>>>> On 30/08/2011 18:31, Paul wrote: > > >>>>>>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>>>>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: trim your posts for $DEITY's sake! <chainsaw> > > >>> You have no idea what will happen if you don't catch the exception and > > >>> close the program safely. > > >>> Many an application has crashed a system or caused a BSOD. > > > >> You don't know what you are talking about; for a clue see: > > > >>http://en.wikipedia.org/wiki/User_space > > > > This is a <expletive> attempt to justify your support for sloppy programming > > > techniques. > > > If you allow expections to go uncaught you have no control over your > > > program and any other resources it may be using, these resources are > > > not limited to userspace. And since when was C++ unsuitable for kernal > > > mode programming? by using the term "application" you are implicitly talking about user mode development. Do kernals really call new? Do they throw C++ exceptions? > > Again you don't know what you are talking about as you don't appear to > > know what an "application" is. I will tell you: on most modern > > platforms an "application" is a program that runs in userland. An > > application crashing in userland should not "crash the system". > > > C++ is of course suitable for kernel mode programming but we are not > > talking about kernel mode programming. > > <expletive>, we are taliking about C++ programs in general. I thought you were talkign about "applciations"? In fact the discussion was about applications on phones. Don't sound very kernally to me. > ANd even if we were just considering applications that run in some > user space on a given OS it is still not guaranteeed what will happen > when an application crashes which is probably why you use the term > "should not" crash the system. In reality you don't have a clue what > will happen. in a well written OS a crash in a user mode program will not harm the OS. In this case we are talkign about an exit due to an unhandled exception. From an OS's point of view this pretty well defined behaviour. Likely the user program called abort() which is pretty well a "kill me now!" request. Do your kernal programs call abort()? What happens then?
[toc] | [prev] | [next] | [standalone]
| From | Paul <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-09-02 04:12 -0700 |
| Message-ID | <f5ec964d-9c8b-4adb-81a2-1897ad580439@h6g2000yqe.googlegroups.com> |
| In reply to | #9653 |
On Sep 2, 11:16 am, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > On Sep 1, 10:05 pm, Paul <pchris...@yahoo.co.uk> wrote: > <chainsaw> > > > > >>> You have no idea what will happen if you don't catch the exception and > > > >>> close the program safely. > > > >>> Many an application has crashed a system or caused a BSOD. > > > > >> You don't know what you are talking about; for a clue see: > > > > >>http://en.wikipedia.org/wiki/User_space > > > > > This is a <expletive> attempt to justify your support for sloppy programming > > > > techniques. > > > > If you allow expections to go uncaught you have no control over your > > > > program and any other resources it may be using, these resources are > > > > not limited to userspace. And since when was C++ unsuitable for kernal > > > > mode programming? > > by using the term "application" you are implicitly talking about user > mode development. > > Do kernals really call new? Do they throw C++ exceptions? Dude. An application uses kernal mode modules device drivers etc. Application is just a layer. > > > > Again you don't know what you are talking about as you don't appear to > > > know what an "application" is. I will tell you: on most modern > > > platforms an "application" is a program that runs in userland. An > > > application crashing in userland should not "crash the system". > > > > C++ is of course suitable for kernel mode programming but we are not > > > talking about kernel mode programming. > > > <expletive>, we are taliking about C++ programs in general. > > I thought you were talkign about "applciations"? In fact the > discussion was about applications on phones. Don't sound very kernally > to me. No he started talking about reserving memory for the phones critical systems, then I said what is the point is another program is running alongside it which may crash the system. SO what if that program is an "applicaton" or any other type of program , an application is capable of crashing a system just as a device driver is, because applications use device drivers. > > > ANd even if we were just considering applications that run in some > > user space on a given OS it is still not guaranteeed what will happen > > when an application crashes which is probably why you use the term > > "should not" crash the system. In reality you don't have a clue what > > will happen. > > in a well written OS a crash in a user mode program will not harm the > OS. In this case we are talkign about an exit due to an unhandled > exception. From an OS's point of view this pretty well defined > behaviour. Likely the user program called abort() which is pretty well > a "kill me now!" request. What exactly is....... an exit due to unhandled exception? THe reason from the program exiting is not because of an unhandled exception. An unhandled exception allows the program to run on, the progam doesn't exit until it crashes somewhere down the line after corrupting the whole systems memory and shit. > > Do your kernal programs call abort()? What happens then?- Hide quoted text - > Define abort()
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-09-02 15:08 +0100 |
| Message-ID | <2_adnWpJCP32fv3TnZ2dnUVZ8v2dnZ2d@giganews.com> |
| In reply to | #9657 |
On 02/09/2011 12:12, Paul wrote: > On Sep 2, 11:16 am, Nick Keighley<nick_keighley_nos...@hotmail.com> > wrote: >> >> in a well written OS a crash in a user mode program will not harm the >> OS. In this case we are talkign about an exit due to an unhandled >> exception. From an OS's point of view this pretty well defined >> behaviour. Likely the user program called abort() which is pretty well >> a "kill me now!" request. > > What exactly is....... an exit due to unhandled exception? > > THe reason from the program exiting is not because of an unhandled > exception. An unhandled exception allows the program to run on, the > progam doesn't exit until it crashes somewhere down the line after > corrupting the whole systems memory and shit. Again you don't know what you are talking about. In C++ an unhandled (uncaught) exception will cause the application to terminate; again a gap in C++ knowledge on your part causes you to stubbornly defend a nonsense position causing much noise in the newsgroup. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-09-02 03:07 -0700 |
| Message-ID | <2089b1c8-a0f0-4d52-aa1d-bd72e4957970@gz5g2000vbb.googlegroups.com> |
| In reply to | #9604 |
On Sep 1, 1:00 pm, Paul <pchris...@yahoo.co.uk> wrote: > On Sep 1, 12:41 pm, Leigh Johnston <le...@i42.co.uk> wrote: > > > > > On 01/09/2011 08:50, Paul wrote: > > > > On Aug 31, 2:59 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >> On 31/08/2011 02:38, Paul wrote: > > > >>> On Aug 31, 1:24 am, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>> On 31/08/2011 01:11, Paul wrote: > > > >>>>> On Aug 31, 12:56 am, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>>>> On 31/08/2011 00:17, Paul wrote: > > > >>>>>>> On Aug 30, 7:18 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>>>>>> On 30/08/2011 18:58, Leigh Johnston wrote: > > > >>>>>>>>> On 30/08/2011 18:31, Paul wrote: > > >>>>>>>>>> On Aug 30, 4:15 pm, Leigh Johnston<le...@i42.co.uk> wrote: > > >>>>>>>>>>> On 30/08/2011 16:00, Paul wrote: > > > >>>>>>>>>>>> Bollocks. > > >>>>>>>>>>>> You have spouted bullshit and now you realise it you are trying to get > > >>>>>>>>>>>> out of the arguement with some bullshit about noobish guff. > > > >>>>>>>>>>>> Its you thats noobish saying that the only sane option is to allow a > > >>>>>>>>>>>> program to crash if an allocation fails, and you know it. > > > >>>>>>>>>>> I said the following: > > > >>>>>>>>>>> "The only sane remedy for most cases of allocation failure is to > > >>>>>>>>>>> terminate the application which is what will happen with an uncaught > > >>>>>>>>>>> exception." > > > >>>>>>>>>>> I stand by what I said so I am not trying to "get out of" anything. As > > >>>>>>>>>>> usual you fail and continue to fail with your bullshit: note the words > > >>>>>>>>>>> "most cases of" in what I said. > > > >>>>>>>>>> It's not the only sane remedy. It's the most insane remedy. > > > >>>>>>>>> In your own deluded, ill-informed opinion. > > > >>>>>>>>>> Imagine a program that controlled a robot: > > >>>>>>>>>> One process for each limb, one for the head and one for the central > > >>>>>>>>>> gyromatic balance system. The robot is in walk mode and you run out of > > >>>>>>>>>> memory because a screeching parrot flies past. > > >>>>>>>>>> What is the "sane" option your program should take: > > >>>>>>>>>> Shut down eye and hearing modules and slow his walking speed? > > >>>>>>>>>> Just let the program crash and allow the robot to fall over in a heap? > > > >>>>>>>>> Are you blind as well as dense? I said: > > > >>>>>>>>> "The only sane remedy for *most cases of* allocation failure is to > > >>>>>>>>> terminate the application which is what will happen with an uncaught > > >>>>>>>>> exception." > > > >>>>>>>>> *most cases of* > > > >>>>>>>>> If I was designing robot control software than I would design it in such > > >>>>>>>>> a way that certain individual sub-systems allocate all their required > > >>>>>>>>> memory up-front so that if some fatal error does occur then the robot > > >>>>>>>>> can safely come to a stand still and then reboot its systems. > > > >>>>>>>>>> If you were working on critical systems such as aircraft controls > > >>>>>>>>>> would you still think that allowing errors to go uncatched is the only > > >>>>>>>>>> sane remedy? > > > >>>>>>>>> Critical systems such as aircraft controls will (I assume) allocate all > > >>>>>>>>> the memory that is needed for all of their operations up-front so the > > >>>>>>>>> situation of a memory allocation failure during flight will never occur. > > > >>>>>>>> I actually have real world experience of doing something similar as I > > >>>>>>>> was on the Telephony Application Call Control team for two different > > >>>>>>>> smartphones. If the user exhausts their memory running apps Telephony > > >>>>>>>> would still need to be able to create a call object if there was an > > >>>>>>>> incoming call so the call objects were created up-front rather than > > >>>>>>>> on-demand. This may be an over-simplification but you get the idea. > > > >>>>>>> I can understand a scenario where you might want to reserve some > > >>>>>>> memory for a critical part of the program. But I don't see many > > >>>>>>> programs that would be able to predict their memory requirements up > > >>>>>>> front. Take your phone example, it would be impossible to predict > > >>>>>>> every possible user scenario and there just wouldn't be enough memory > > >>>>>>> to create all the objects required for every possible scenario or even > > >>>>>>> a fractional representation of every possible scenario. > > > >>>>>> You don't know what you are talking about. > > > >>>>> Oh yes I do. > > > >>>> It is quite obvious that you don't > > > >>>>> A phone has limited memory. You cannot pre-allocate all the objects a > > >>>>> user *may* require to run all apps on his/her phone. > > > >>>> Why are you so dense? Where did I say that? I said the Telephony App > > >>>> could create all the objects it needs up front not other less critical apps. > > > >>>>> video jukebox, photo editor, soundblaster master etc etc. > > > >>>> Obviously these apps are not critical so wouldn't be required to create > > >>>> any objects up front. > > > >>> But according to your programming style, if these apps did not check > > >>> for allocation errors the phone would crash regularly thus incoming > > >>> calls could be missed during phone reboots. > > >>> SO what was the point of preallocating call objects in case of > > >>> incoming calls? > > > >> Does a crashing Windows app crash Windows? No. Why would a phone be > > >> any different? Try engaging your brain. > > > > Why does any app have to crash? > > > Its only crashing because of an incompetent programmer somewhere. > > > > There is no point in having robust code when there is code running > > > alongside it that will crash the system at the slightest glimmer of a > > > low memory situation. > > > Crash the system? Again: Does a crashing Windows app crash Windows? > > No. Why would a phone be any different? Try engaging your brain. > > You have no idea what will happen if you don't catch the exception and > close the program safely. > Many an application has crashed a system or caused a BSOD.- not since Windows NT even Microsoft started writing proper Oss after that
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c++
csiph-web