Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #9464 > unrolled thread

bad alloc

Back to article view | Back to comp.lang.c++

Contents

  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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10  Next page →

#9547

Hi Paul

Please, please, please, please, please, please
delete some of all that unneeded quotation it is so much
waste of time all the scrolling...

P.s. You are of course not the only one.

Thanks in advance
Best regards
Asger-P

[toc] | [prev] | [next] | [standalone]

#9555

On Aug 31, 9:33 am, Asger-P <j...@asger-p.dk> wrote:
> Hi Paul
>
> Please, please, please, please, please, please
> delete some of all that unneeded quotation it is so much
> waste of time all the scrolling...
>
> P.s. You are of course not the only one.
>
Ok sorry. New interfase was hiding it from me.

[toc] | [prev] | [next] | [standalone]

#9520

On Aug 30, 6:26 am, Goran <goran.pu...@gmail.com> wrote:
> There's a school of thought that says that allocation failure should
> simply terminate everything. This is based on the notion that, once
> there's no memory, world has ended for the code anyhow. This notion is
> false in a significant amount of cases (and is not in the spirit of C
> or C++; if it were, malloc or new would terminate()). Why is notion
> wrong? Because normally, code goes like this: work, work, allocate
> some resources, work (with those), free those, allocate more, work,
> allocate, work, free, free etc. That is, for many-a-code-path, there's
> a "hill climb" where resources are allocated while working "up", and
> they are deallocated, all or at least a significant part, while going
> "down" (e.g. perhaps calculation result is kept allocated. So once
> code hits a brick wall going up, there's a big chance there will be
> plenty of breathing room once it comes down (due to all those
> freeing). IOW, there's no __immediate need__ to die. Go down, clean up
> behind you and you'll be fine. It's kinda better to go back and say "I
> couldn't do X due to OOM" is kinda better than dying at the spot,
> wouldn't you say?

For most code, on most platforms, the two will be one and the same.
The OS cleans up most resources when a process dies, and most process
have no choice but to die.

Straightforward C++ on most implementations will deallocate memory as
it goes, so when the application runs out of memory, there won't be
anything to free up: retrying the operation will cause the code to
fail in the same place.  Making more memory available requires
rewriting the code to avoid unnecessarily holding on to resources that
it no longer needs.

Even when there's memory to free up, writing an exception handler that
actually safely runs under an out-of-memory condition is impressively
difficult.  In some situations, it may not be possible to do what you
want, and it may not be possible to do anything at all.  Moreover, you
may not have any way to detect these conditions while your code is
running. Your only recourse may be to crash and crash hard.

Even when you can safely write the exception handler, it also means
your code must have a fairly strong exception guarantee so that you
can retry the failed operation.  This is difficult to do and may not
possible, either.

If you can do all three of those things, then yes, you can attempt to
retry.  The number of applications where this is possible is quite
small; the number of applications where this is prudent is even
smaller still.  Otherwise, your only option is death in some fashion.
At this point, "immediate death" vs. "deferred death" may very well be
irrelevant.

In some languages, such as Java, you have no choice in the matter, as
you're not promised you'll be told about the allocation fail in such a
way that can enable a retry.  Heck, you're not even promised you will
fail in such a way you can cleanup after yourself.

As a result of all this, the correct school of thought is your third
school:
> Finally, there's a school of thought that says that allocations should
> not be checked at all.

Properly written, exception-safe C++ code will do the right thing when
std::bad_alloc is thrown, and most C++ code cannot sensibly handle
std::bad_alloc.  As a result, the automatic behavior, which is to let
the exception propagate up to main() and terminate the program there,
is the correct behavior for the overwhelming majority of C++
applications.  As programmers, we win anytime the automatic behavior
is the correct behavior.

More importantly, this advice sensibly applies to a bevy of other
programming languages with exception handling semantics similiar to C+
+ (e.g., Python, Java, C#) so it's sensible programming advice beyond
mere C++.

Adam

[toc] | [prev] | [next] | [standalone]

#9531

On Aug 30, 4:04 pm, Adam Skutt <ask...@gmail.com> wrote:

> Properly written, exception-safe C++ code will do the right thing when
> std::bad_alloc is thrown, and most C++ code cannot sensibly handle
> std::bad_alloc.  As a result, the automatic behavior, which is to let
> the exception propagate up to main() and terminate the program there,
> is the correct behavior for the overwhelming majority of C++
> applications.  As programmers, we win anytime the automatic behavior
> is the correct behavior.
>

What if you're within a try block well before main in the call stack?
What if the catch for that block attempts to do something like save
what the user's working on, or do some other seemingly reasonable
attempt at something that seems reasonable?

A lot of people will catch std::exception.  I don't see a big problem
with this but I do see potential in what you're talking about to cause
problems with that.  If you get a bad_alloc and then attempt to do
something like write to disk or whatnot as a response to that
exception, you may get the same problem again only now you're writing
to disk, something that's inherently unreversible from the program's
point of view.  This could result in corruption of important user data
in some cases.

[toc] | [prev] | [next] | [standalone]

#9534

On Aug 30, 11:02 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> On Aug 30, 4:04 pm, Adam Skutt <ask...@gmail.com> wrote:
>
> > Properly written, exception-safe C++ code will do the right thing when
> > std::bad_alloc is thrown, and most C++ code cannot sensibly handle
> > std::bad_alloc.  As a result, the automatic behavior, which is to let
> > the exception propagate up to main() and terminate the program there,
> > is the correct behavior for the overwhelming majority of C++
> > applications.  As programmers, we win anytime the automatic behavior
> > is the correct behavior.
>
> What if you're within a try block well before main in the call stack?

Doesn't change anything and why would it?

> What if the catch for that block attempts to do something like save
> what the user's working on, or do some other seemingly reasonable
> attempt at something that seems reasonable?

It will almost certainly fail.  But that's OK, what that could happen
anyway.  Consider entry due to another exception, std::bad_alloc being
thrown somehow during the write-out process.  You're stuck with the
exact same result: the attempt to save the state fails.

If anything, this is why catch blocks (especially for root exceptions)
shouldn't try to do much at all.    In many cases, the exception lacks
the information to determine what behaviors are safe after the
exception has occurred. Determining what behavior is safe is often
quite difficult.  std::bad_alloc is not unique in this regard.

>
> A lot of people will catch std::exception.  I don't see a big problem
> with this but I do see potential in what you're talking about to cause
> problems with that.  If you get a bad_alloc and then attempt to do
> something like write to disk or whatnot as a response to that
> exception, you may get the same problem again only now you're writing
> to disk, something that's inherently unreversible from the program's
> point of view.  This could result in corruption of important user data
> in some cases.

Who's to say I wasn't already in the process of writing to disk when
bad_alloc was initially raised?  The argument 'catch blocks can have
side effects too' is not an argument against letting bad_alloc bubble
up.

Adam

[toc] | [prev] | [next] | [standalone]

#9546

On Aug 31, 5:33 am, Adam Skutt <ask...@gmail.com> wrote:
> On Aug 30, 11:02 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>
> > On Aug 30, 4:04 pm, Adam Skutt <ask...@gmail.com> wrote:
>
> > > Properly written, exception-safe C++ code will do the right thing when
> > > std::bad_alloc is thrown, and most C++ code cannot sensibly handle
> > > std::bad_alloc.  As a result, the automatic behavior, which is to let
> > > the exception propagate up to main() and terminate the program there,
> > > is the correct behavior for the overwhelming majority of C++
> > > applications.  As programmers, we win anytime the automatic behavior
> > > is the correct behavior.
>
> > What if you're within a try block well before main in the call stack?
>
> Doesn't change anything and why would it?
>
> > What if the catch for that block attempts to do something like save
> > what the user's working on, or do some other seemingly reasonable
> > attempt at something that seems reasonable?
>
> It will almost certainly fail.  But that's OK, what that could happen
> anyway.  Consider entry due to another exception, std::bad_alloc being
> thrown somehow during the write-out process.  You're stuck with the
> exact same result: the attempt to save the state fails.

Why would bad_alloc be thrown while writing to disk? Guess: because
writing is made in such a way as to modify program state. Doesn't seem
all that logical.

(Repeating myself) there's two factors that play:

1. walking down the stack upon OOM (or other exception) normally frees
resources.
2. top-level error is not a place to do anything resource-sensitive,
exactly due to OOM possibility.

It's not as complicated as you make it out to be. Going "nice" in case
of OOM might not be worth it in all cases, but is not an and-all
response to all concerns.

Goran.

[toc] | [prev] | [next] | [standalone]

#9549

In article <c8b2f277-891c-4f40-a895-6cd78145e031@33g2000yqu.googlegroups.com>,
Goran  <goran.pusic@gmail.com> wrote:
>On Aug 31, 5:33 am, Adam Skutt <ask...@gmail.com> wrote:
>> On Aug 30, 11:02 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>>
>> > On Aug 30, 4:04 pm, Adam Skutt <ask...@gmail.com> wrote:
>>
>> > > Properly written, exception-safe C++ code will do the right thing when
>> > > std::bad_alloc is thrown, and most C++ code cannot sensibly handle
>> > > std::bad_alloc.  As a result, the automatic behavior, which is to let
>> > > the exception propagate up to main() and terminate the program there,
>> > > is the correct behavior for the overwhelming majority of C++
>> > > applications.  As programmers, we win anytime the automatic behavior
>> > > is the correct behavior.
>>
>> > What if you're within a try block well before main in the call stack?
>>
>> Doesn't change anything and why would it?
>>
>> > What if the catch for that block attempts to do something like save
>> > what the user's working on, or do some other seemingly reasonable
>> > attempt at something that seems reasonable?
>>
>> It will almost certainly fail.  But that's OK, what that could happen
>> anyway.  Consider entry due to another exception, std::bad_alloc being
>> thrown somehow during the write-out process.  You're stuck with the
>> exact same result: the attempt to save the state fails.
>
>Why would bad_alloc be thrown while writing to disk? Guess: because
>writing is made in such a way as to modify program state. Doesn't seem
>all that logical.
>
>(Repeating myself) there's two factors that play:
>
>1. walking down the stack upon OOM (or other exception) normally frees
>resources.
>2. top-level error is not a place to do anything resource-sensitive,
>exactly due to OOM possibility.
>
>It's not as complicated as you make it out to be. Going "nice" in case
>of OOM might not be worth it in all cases, but is not an and-all
>response to all concerns.

I absolutely agree with Goran and disagree that terminate on OOM is
*always* the best approach.  There may be programs where it is the
best approach but it is far from always the case.

A concrete example:

Network server using a standard pattern of one listener/producer and
multiple worker/consumer threads.  The listener receives and job
request and hands done the processing of the job to one of the worker
thread.   

It is a very much possible that processing one particular job might
actually require too much memory for the system.  The correct thing to
do in that case is to stop processing this one oversized job,  release
all the resources acquired to process this job, mark it as error and
continue processing further jobs.

Since this is a persistent server than needs to be on and alive 24/7,
it would be totally innapropriate to permanently terminate the server.
Even if there was an additional monitoring process that restart the
server if it dies, this would not be a good thing because you would
loose current progress in the currently running worker threads and
would also kill current external client connections.  

Yan

[toc] | [prev] | [next] | [standalone]

#9556

On Aug 31, 5:23 am, yatremblay@bel1lin202.(none) (Yannick Tremblay)
wrote:
> In article <c8b2f277-891c-4f40-a895-6cd78145e...@33g2000yqu.googlegroups.com>,
>
>
>
>
>
>
>
>
>
> Goran  <goran.pu...@gmail.com> wrote:
> >On Aug 31, 5:33 am, Adam Skutt <ask...@gmail.com> wrote:
> >> On Aug 30, 11:02 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>
> >> > On Aug 30, 4:04 pm, Adam Skutt <ask...@gmail.com> wrote:
>
> >> > > Properly written, exception-safe C++ code will do the right thing when
> >> > > std::bad_alloc is thrown, and most C++ code cannot sensibly handle
> >> > > std::bad_alloc.  As a result, the automatic behavior, which is to let
> >> > > the exception propagate up to main() and terminate the program there,
> >> > > is the correct behavior for the overwhelming majority of C++
> >> > > applications.  As programmers, we win anytime the automatic behavior
> >> > > is the correct behavior.
>
> >> > What if you're within a try block well before main in the call stack?
>
> >> Doesn't change anything and why would it?
>
> >> > What if the catch for that block attempts to do something like save
> >> > what the user's working on, or do some other seemingly reasonable
> >> > attempt at something that seems reasonable?
>
> >> It will almost certainly fail.  But that's OK, what that could happen
> >> anyway.  Consider entry due to another exception, std::bad_alloc being
> >> thrown somehow during the write-out process.  You're stuck with the
> >> exact same result: the attempt to save the state fails.
>
> >Why would bad_alloc be thrown while writing to disk? Guess: because
> >writing is made in such a way as to modify program state. Doesn't seem
> >all that logical.
>
> >(Repeating myself) there's two factors that play:
>
> >1. walking down the stack upon OOM (or other exception) normally frees
> >resources.
> >2. top-level error is not a place to do anything resource-sensitive,
> >exactly due to OOM possibility.
>
> >It's not as complicated as you make it out to be. Going "nice" in case
> >of OOM might not be worth it in all cases, but is not an and-all
> >response to all concerns.
>
> I absolutely agree with Goran and disagree that terminate on OOM is
> *always* the best approach.  There may be programs where it is the
> best approach but it is far from always the case.
>
> A concrete example:
>
> Network server using a standard pattern of one listener/producer and
> multiple worker/consumer threads.  The listener receives and job
> request and hands done the processing of the job to one of the worker
> thread.  
>
> It is a very much possible that processing one particular job might
> actually require too much memory for the system.  The correct thing to
> do in that case is to stop processing this one oversized job,  release
> all the resources acquired to process this job, mark it as error and
> continue processing further jobs.
>
> Since this is a persistent server than needs to be on and alive 24/7,
> it would be totally innapropriate to permanently terminate the server.
> Even if there was an additional monitoring process that restart the
> server if it dies, this would not be a good thing because you would
> loose current progress in the currently running worker threads and
> would also kill current external client connections.  
>
> Yan

[toc] | [prev] | [next] | [standalone]

#9560

On Aug 31, 5:23 am, yatremblay@bel1lin202.(none) (Yannick Tremblay)
wrote:
> In article <c8b2f277-891c-4f40-a895-6cd78145e...@33g2000yqu.googlegroups.com>,
> Goran  <goran.pu...@gmail.com> wrote:
> >On Aug 31, 5:33 am, Adam Skutt <ask...@gmail.com> wrote:
> >> On Aug 30, 11:02 pm, Noah Roberts <roberts.n...@gmail.com> wrote:
>
> >> > On Aug 30, 4:04 pm, Adam Skutt <ask...@gmail.com> wrote:
>
> >> > > Properly written, exception-safe C++ code will do the right thing when
> >> > > std::bad_alloc is thrown, and most C++ code cannot sensibly handle
> >> > > std::bad_alloc.  As a result, the automatic behavior, which is to let
> >> > > the exception propagate up to main() and terminate the program there,
> >> > > is the correct behavior for the overwhelming majority of C++
> >> > > applications.  As programmers, we win anytime the automatic behavior
> >> > > is the correct behavior.
>
> >> > What if you're within a try block well before main in the call stack?
>
> >> Doesn't change anything and why would it?
>
> >> > What if the catch for that block attempts to do something like save
> >> > what the user's working on, or do some other seemingly reasonable
> >> > attempt at something that seems reasonable?
>
> >> It will almost certainly fail.  But that's OK, what that could happen
> >> anyway.  Consider entry due to another exception, std::bad_alloc being
> >> thrown somehow during the write-out process.  You're stuck with the
> >> exact same result: the attempt to save the state fails.
>
> >Why would bad_alloc be thrown while writing to disk? Guess: because
> >writing is made in such a way as to modify program state. Doesn't seem
> >all that logical.
>
> >(Repeating myself) there's two factors that play:
>
> >1. walking down the stack upon OOM (or other exception) normally frees
> >resources.
> >2. top-level error is not a place to do anything resource-sensitive,
> >exactly due to OOM possibility.
>
> >It's not as complicated as you make it out to be. Going "nice" in case
> >of OOM might not be worth it in all cases, but is not an and-all
> >response to all concerns.
>
> I absolutely agree with Goran and disagree that terminate on OOM is
> *always* the best approach.  There may be programs where it is the
> best approach but it is far from always the case.
>
> A concrete example:
>
> Network server using a standard pattern of one listener/producer and
> multiple worker/consumer threads.  The listener receives and job
> request and hands done the processing of the job to one of the worker
> thread.  
>
> It is a very much possible that processing one particular job might
> actually require too much memory for the system.  The correct thing to
> do in that case is to stop processing this one oversized job,  release
> all the resources acquired to process this job, mark it as error and
> continue processing further jobs.

If it's possible to stop processing a job safely and recover, sure.
Marking the job as an error might require allocating memory, so you
have to avoid that.  This is more difficult that it sounds, and
requires code that is explicitly written to ensure that it is
possible.  Screw that code up, and you'll almost certainly end up in a
deadlock situation or with a zombie worker thread, at which point you
will be restarting the process anyway!

Anyway, while you're in the process of attempting to cancel the
oversized job, many other jobs will fail (possibly all of them) since
they can no longer allocate memory either. In the meantime, all your I/
O connections will be frozen since there's no more memory for copying
data from your clients.  Best case: a transient slow down.  Worst
case: internal state becomes corrupted, forcing you to close some
(again, maybe all) of the connections anyway, or the clients
disconnect for you because you took to long to respond.  All of your I/
O code must be able to properly handle an OOM condition as well.  This
too, requires careful design and code you must write yourself.

So no, it's not a given that attempting to fix the problem is any
better.  Heap fragmentation may mean that you're prolonging the
inevitable and that you'll just endlessly spin canceling jobs and
trying to free memory.  In a multithreaded application, by the time
you've actually freed the memory, the damage may already have been
done.

> Since this is a persistent server than needs to be on and alive 24/7,
> it would be totally innapropriate to permanently terminate the server.

No, it wouldn't.  If you need high reliability, then you need
redundancy.  If you have redundancy, then lost of an individual unit
is normally not a big deal.  Cleaning staff have the disturbing habit
of knocking out power cables to servers, after all.

> Even if there was an additional monitoring process that restart the
> server if it dies, this would not be a good thing because you would
> loose current progress in the currently running worker threads and
> would also kill current external client connections.  

This can happen anyway, so your solution must simply be prepared to
deal with this eventuality.  Making your code handle memory allocation
failure gracefully does not save you from the cleaning staff.  If your
system can handle the cleaning staff, then it can handle memory
allocation failure terminating a process, too.

I don't know why people think it's interesting to talk about super
reliable software but neglect super reliable hardware too.  It's
impossible to make hardware that never fails (pesky physics) so why
would I ever bother writing software that never fails?  Software that
never crashes is useless if the cleaning staff kicks out the power
cable every night.

Adam

[toc] | [prev] | [next] | [standalone]

#9562

On Aug 31, 12:47 pm, Adam Skutt <ask...@gmail.com> wrote:
> On Aug 31, 5:23 am, yatremblay@bel1lin202.(none) (Yannick Tremblay)
> wrote:
<snip>
>
> I don't know why people think it's interesting to talk about super
> reliable software but neglect super reliable hardware too.  It's
> impossible to make hardware that never fails (pesky physics) so why
> would I ever bother writing software that never fails?  Software that
> never crashes is useless if the cleaning staff kicks out the power
> cable every night.
>
So attempting to deliver robust software is a waste of time because
some cleaner may switch of the machine at the wall?
The amazing thing about this post is that you're serious.

[toc] | [prev] | [next] | [standalone]

#9586

On Aug 31, 12:47 pm, Adam Skutt <ask...@gmail.com> wrote:

<snip>

> I don't know why people think it's interesting to talk about super
> reliable software but neglect super reliable hardware too.

http://en.wikipedia.org/wiki/NonStop

> It's
> impossible to make hardware that never fails (pesky physics) so why
> would I ever bother writing software that never fails?  Software that
> never crashes is useless if the cleaning staff kicks out the power
> cable every night.

so protect the power socket. Are server farms really this vulnerable?
Life support equipment? Fly-by-wire? Telephone excahnges?
The world is not a desk top.

[toc] | [prev] | [next] | [standalone]

#9598

On Sep 1, 4:08 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Aug 31, 12:47 pm, Adam Skutt <ask...@gmail.com> wrote:
>
> <snip>
>
> > I don't know why people think it's interesting to talk about super
> > reliable software but neglect super reliable hardware too.
>
> http://en.wikipedia.org/wiki/NonStop
>

Does not neglect the hardware!  Plus, the wikipedia page says you can
write programs for NonStop OS that terminate.  Please read your
references before citing them.  NonStop just provides a defined
mechanism, as part of the operating system, for providing the sorts of
redundancy I mentioned you need.

> so protect the power socket. Are server farms really this vulnerable?

The recent issues with Amazon EC2 would suggest yes.

> Life support equipment? Fly-by-wire? Telephone excahnges?
> The world is not a desk top.

All support software that crashes.  In life/safety-critical systems,
it's often preferable to crash immediately (fail-fast) whenever /any/
abnormal situation is encountered, because you can restart to a known
state much faster than you can fix the program, and you get a
deterministic response to all crashes.

Adams

[toc] | [prev] | [next] | [standalone]

#9659

On Sep 1, 11:56 am, Adam Skutt <ask...@gmail.com> wrote:
> On Sep 1, 4:08 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
>
> > On Aug 31, 12:47 pm, Adam Skutt <ask...@gmail.com> wrote:
>
> > <snip>
>
> > > I don't know why people think it's interesting to talk about super
> > > reliable software but neglect super reliable hardware too.
>
> >http://en.wikipedia.org/wiki/NonStop
>
> Does not neglect the hardware!  

rather my point...

so not everyone neglects the hardware do they?


> Plus, the wikipedia page says you can
> write programs for NonStop OS that terminate.

lost me. Surely most programs (except maybe OSs) are expected to
terminate sometime.

  Please read your
> references before citing them.


I did. I think you misunderstood my pojnt

> NonStop just provides a defined
> mechanism, as part of the operating system, for providing the sorts of
> redundancy I mentioned you need.

riight...

> > so protect the power socket. Are server farms really this vulnerable?
>
> The recent issues with Amazon EC2 would suggest yes.
>
> > Life support equipment? Fly-by-wire? Telephone excahnges?
> > The world is not a desk top.
>
> All support software that crashes.

not too often one would hope... A crash in a pace maker sounds like a
bad idea.

> In life/safety-critical systems,
> it's often preferable to crash immediately (fail-fast) whenever /any/
> abnormal situation is encountered, because you can restart to a known
> state much faster than you can fix the program, and you get a
> deterministic response to all crashes.

I tend to take this approach on important stuff and the hardware is
often duplicated

[toc] | [prev] | [next] | [standalone]

#9696

Op 02-Sep-11 13:18, Nick Keighley schreef:
> On Sep 1, 11:56 am, Adam Skutt<ask...@gmail.com>  wrote:

>> Plus, the wikipedia page says you can
>> write programs for NonStop OS that terminate.
>
> lost me. Surely most programs (except maybe OSs) are expected to
> terminate sometime.

On embedded systems it is quite likely that the program is intended to 
run for eternity (or at least until the power is lost).

[toc] | [prev] | [next] | [standalone]

#9700

On Sep 3, 5:37 pm, Dombo <do...@disposable.invalid> wrote:
> Op 02-Sep-11 13:18, Nick Keighley schreef:
>
> > On Sep 1, 11:56 am, Adam Skutt<ask...@gmail.com>  wrote:
> >> Plus, the wikipedia page says you can
> >> write programs for NonStop OS that terminate.
>
> > lost me. Surely most programs (except maybe OSs) are expected to
> > terminate sometime.
>
> On embedded systems it is quite likely that the program is intended to
> run for eternity (or at least until the power is lost).

If we are all to be perfectly honest about C++ for embeded systems.
Does anyone actually use C++? I did some searching on the web to find
out what compilers exist for EC++ and there are a few. I don't know if
any of them support exceptions because EC++ has fewer features and one
of the features not featured in EC++ is exceptions.

[toc] | [prev] | [next] | [standalone]

#9701

On 9/3/2011 1:39 PM, Paul wrote:
> On Sep 3, 5:37 pm, Dombo<do...@disposable.invalid>  wrote:
>> Op 02-Sep-11 13:18, Nick Keighley schreef:
>>
>>> On Sep 1, 11:56 am, Adam Skutt<ask...@gmail.com>    wrote:
>>>> Plus, the wikipedia page says you can
>>>> write programs for NonStop OS that terminate.
>>
>>> lost me. Surely most programs (except maybe OSs) are expected to
>>> terminate sometime.
>>
>> On embedded systems it is quite likely that the program is intended to
>> run for eternity (or at least until the power is lost).
>
> If we are all to be perfectly honest about C++ for embeded systems.
> Does anyone actually use C++? I did some searching on the web to find
> out what compilers exist for EC++ and there are a few. I don't know if
> any of them support exceptions because EC++ has fewer features and one
> of the features not featured in EC++ is exceptions.
>

Yes.   We had a missile avionics system written in C++.

[toc] | [prev] | [next] | [standalone]

#9702

On Sep 3, 9:45 pm, red floyd <no.spam.h...@its.invalid> wrote:
> On 9/3/2011 1:39 PM, Paul wrote:
>
>
>
>
>
> > On Sep 3, 5:37 pm, Dombo<do...@disposable.invalid>  wrote:
> >> Op 02-Sep-11 13:18, Nick Keighley schreef:
>
> >>> On Sep 1, 11:56 am, Adam Skutt<ask...@gmail.com>    wrote:
> >>>> Plus, the wikipedia page says you can
> >>>> write programs for NonStop OS that terminate.
>
> >>> lost me. Surely most programs (except maybe OSs) are expected to
> >>> terminate sometime.
>
> >> On embedded systems it is quite likely that the program is intended to
> >> run for eternity (or at least until the power is lost).
>
> > If we are all to be perfectly honest about C++ for embeded systems.
> > Does anyone actually use C++? I did some searching on the web to find
> > out what compilers exist for EC++ and there are a few. I don't know if
> > any of them support exceptions because EC++ has fewer features and one
> > of the features not featured in EC++ is exceptions.
>
> Yes.   We had a missile avionics system written in C++.- Hide quoted text -
>
Well its kinda obvious how that program will terminate :)

[toc] | [prev] | [next] | [standalone]

#9716

red floyd wrote:
> On 9/3/2011 1:39 PM, Paul wrote:
>> On Sep 3, 5:37 pm, Dombo<do...@disposable.invalid>  wrote:
>>> Op 02-Sep-11 13:18, Nick Keighley schreef:
>>>
>>>> On Sep 1, 11:56 am, Adam Skutt<ask...@gmail.com>    wrote:
>>>>> Plus, the wikipedia page says you can
>>>>> write programs for NonStop OS that terminate.
>>>> lost me. Surely most programs (except maybe OSs) are expected to
>>>> terminate sometime.
>>> On embedded systems it is quite likely that the program is intended to
>>> run for eternity (or at least until the power is lost).
>> If we are all to be perfectly honest about C++ for embeded systems.
>> Does anyone actually use C++? I did some searching on the web to find
>> out what compilers exist for EC++ and there are a few. I don't know if
>> any of them support exceptions because EC++ has fewer features and one
>> of the features not featured in EC++ is exceptions.
>>
> 
> Yes.   We had a missile avionics system written in C++.
> 
Now you tell us. All those "unexplained" blow-ups.

[toc] | [prev] | [next] | [standalone]

#9712

On Sep 3, 9:39 pm, Paul <pchris...@yahoo.co.uk> wrote:
> On Sep 3, 5:37 pm, Dombo <do...@disposable.invalid> wrote:

> If we are all to be perfectly honest about C++ for embeded systems.
> Does anyone actually use C++?

It depends on what you mean by "embedded".  I've certainly used
C++ in embedded systems, and it is my impression that for large
scale embedded systems (telephone routing, air traffic control,
etc.), it is widespread, with Ada being the only other language
used.

> I did some searching on the web to find
> out what compilers exist for EC++ and there are a few.

Many embedded systems use standard C++, not EC++.

> I don't know if
> any of them support exceptions because EC++ has fewer features and one
> of the features not featured in EC++ is exceptions.

In practice, the EC++ compilers are often C++ compilers as well,
with various compiler options to choose which C++ features are
active (and added to EC++).

"Embedded" covers such a large domain that it is difficult to
speak about it generally.  I've worked on locomotive brake
systems that fit in 2K of PROM, without any disk or OS, and I've
worked on telephone routing systems with more than a million
lines of code, running under Unix.  Both are "embedded systems",
but the constraints are radically different.

--
James Kanze

[toc] | [prev] | [next] | [standalone]

#9718

On 09/ 4/11 10:51 AM, James Kanze wrote:
> On Sep 3, 9:39 pm, Paul<pchris...@yahoo.co.uk>  wrote:
>> On Sep 3, 5:37 pm, Dombo<do...@disposable.invalid>  wrote:
>
>> If we are all to be perfectly honest about C++ for embeded systems.
>> Does anyone actually use C++?
>
> It depends on what you mean by "embedded".  I've certainly used
> C++ in embedded systems, and it is my impression that for large
> scale embedded systems (telephone routing, air traffic control,
> etc.), it is widespread, with Ada being the only other language
> used.

That's my impression as well.  C is still the dominant language for 
embedded systems.  Even where C is still used, the teams I have worked 
with are keen to step up to C++.

>> I did some searching on the web to find
>> out what compilers exist for EC++ and there are a few.
>
> Many embedded systems use standard C++, not EC++.

That's right, EC++ was an abomination that should never have been let 
loose on the world.

>> I don't know if
>> any of them support exceptions because EC++ has fewer features and one
>> of the features not featured in EC++ is exceptions.
>
> In practice, the EC++ compilers are often C++ compilers as well,
> with various compiler options to choose which C++ features are
> active (and added to EC++).
>
> "Embedded" covers such a large domain that it is difficult to
> speak about it generally.  I've worked on locomotive brake
> systems that fit in 2K of PROM, without any disk or OS, and I've
> worked on telephone routing systems with more than a million
> lines of code, running under Unix.  Both are "embedded systems",
> but the constraints are radically different.

Ditto, my past "Embedded" projects range from single chip 8 bit micros 
through to large layer 3 switches, which run as a Linux cluster!  On 
bigger systems, just like traditional servers, more than one programming 
language is used.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10  Next page →

Back to top | Article view | comp.lang.c++

csiph-web