«

On Sep 1, 8:49*am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Aug 31, 12:28*am, Paul <pchris...@yahoo.co.uk> wrote:
>
> > On Aug 30, 3:02*pm, Leigh Johnston <le...@i42.co.uk> wrote:
> > > On 30/08/2011 14:54, Paul wrote:
> > > > On Aug 30, 2:34 pm, Leigh Johnston<le...@i42.co.uk> *wrote:
> > > >> On 30/08/2011 14:26, Paul wrote:
>
> <snip>
>
> > > >>> I think that pre-STL it was pretty much standard practise to check
> > > >>> for memory allocation failures for example:
>
> > > >>> float* m1 = new float[16];
> > > >>> if(!m1){
> > > >>> //output an exit msg.
> > > >>> exit();
> > > >>> }
>
> which is exactly what not handling a bad_alloc exception would do...
>
> <snip>
>
> > > >> Rule of thumb for C++ exception aware code: liberally sprinkle throws
> > > >> but have very few try/catches.
>
> > > > What is the point in having throws if you're not going to catch them?
>
> > > Again your lack of experience is showing.
>
> > How does this address the question...What is the point of a throw if
> > [it's] not being caught?
>
> to invoke destructors. Go and look up RAII.

And what good would invoking any destructor do?
Your program is about to crash you want to call destructors but not
catch the exception? That doesn't make any sense.

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:
>
> >>>>>>>>>>>> *******s.
> >>>>>>>>>>>> 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 toallow 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 isto
> >>>>>>>>>>> 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 ina heap?
>
> >>>>>>>>> Are you blind as well as dense? I said:
>
> >>>>>>>>> "The only sane remedy for *most cases of* allocation failure isto
> >>>>>>>>> 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 therobot
> >>>>>>>>> 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 similaras 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 wasan
> >>>>>>>> incoming call so the call objects were created up-front rather than
> >>>>>>>> on-demand. *This may be an over-simplification but you get theidea.
>
> >>>>>>> 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 oreven
> >>>>>>> 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 objectsa
> >>>>> 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 phonebe
> >> 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.

On Sep 1, 7:51*am, Leigh Johnston <le...@i42.co.uk> wrote:
> On 01/09/2011 12:25, Adam Skutt wrote:
>
> > On Sep 1, 3:20 am, Goran<goran.pu...@gmail.com> *wrote:
> >> I don't think so. Your thinking is pretty much that any exception
> >> should lead to a termination.
>
> > Given that's the default behavior, it's a damn good starting
> > assumption!
>
> Nonsense; C++ exceptions are not just for unrecoverable fatal errors;

And I've never said otherwise. It doesn't change the fact that if you
raise an exception, the default behavior of the program will be to
terminate unless you explicitly take action to prevent it, i.e., write
a catch handler. Since that's the default, it's perfectly reasonable
to assume the proper response to an arbitrary exception X is to
terminate, especially absent directions on how to properly handle the
exception!

There are plenty of exception handling schemes, and languages that
implement them, that provide other behavior such as forcing the
programmer to explicitly handle some or all exceptions. C++ doesn't
use them, and I don't believe it doesn't use them by accident.

> if that were the case we wouldn't need try/catch or even exceptions as we
> would just call abort() instead.

However, even if exceptions were for unrecoverable fatal errors, this
doesn't ipso facto follow. Even abort() has a mechanism (albeit a
crude one) for performing processing after it is called.

Adam

On Sep 1, 1:25*pm, Adam Skutt <ask...@gmail.com> wrote:
> On Sep 1, 3:20*am, Goran <goran.pu...@gmail.com> wrote:
>
> > On Aug 31, 6:33*pm, Adam Skutt <ask...@gmail.com> wrote:
>
> > > > Say that you want to save. If your file stream is already there, and
> > > > given that saving is logically a "const" operation,
>
> > > It is not logically a "const" operation and never will be one. *The
> > > very notion is absurd. *How can I/O be const?
>
> > Please note the word "logically". If you already have a stream and
> > data to save, saving itself __does not__ change program state.
> > Successful save might e.g. change the state of the "dirty" bit, if
> > there's one.
>
> So you're resolved to contradict yourself in the same paragraph now?
> You're simply factually wrong: doing I/O always involves a change in
> the state of the process, period. *If it doesn't, then the Haskell
> folk have a lot of explaining to do.

Please explain how e.g.

write(f, some_char_ptr, strlen(some_char_ptr));

change program state. Or fprintf(...), for that matter (all sorts of
conversions possible there).

> > I know. Functionality that informs the operator about failures, like
> > logging functions, in a well-designed system, __are__ no-throw
> > operations.
>
> Funny, the people who've actually written C++ logging APIs sure as
> hell don't seem to agree with you.

But they are not in the business of writing nothrow code, nor they
shouldn't be. They are in the business of writing rich infrastructure
for logging. That's bound to have all sorts of failure points.

> > Now, if functionality fails, and logging fails, tough. You think you
> > can do better? I think you can't. I think that terminating/restarting
> > the process might be a way out, but __only__ for some software and
> > some situations, and that percentage of those is smaller than what you
> > make it out to be.
>
> I think it's a way out for all applications, and as your reliability
> needs go up, your odds of terminating at any sort of failure go up
> substantially as well. *The safest way to proceed after a normal
> condition is to restart from a known state, and the safest way to do
> that is to restart the process, possibly even the whole computer.
> This is what many life-critical and safety-critical systems do.
>
> > It might, but given the nature of e.g. logging, it is of course my
> > task to ensure these conversions are a no-throw (or better yet, actual
> > no-fail) operations. I believe that
> > 1. conversions are rare
>
> Then you're hopelessly ignorant.

Surely you meant: "In presence of a compelling argument, kids often go
for on insults?"

>
> > 2. if they exist, it s the task of the logging to make it a no-throw
> > (or better yet, actual no-fail) operation. See how exception::what is
> > "const"? That's not by accident.
>
> I'd love to see a generalized algorithm for removing freestore
> allocations from programs, but I'm quite confident you will not be
> providing it.

I never, not once, claimed that there should be such a thing. I have
no idea why you are fixating on this.

> > That requires that code knows what is likely to fail.
>
> No it doesn't, it only requires it to know what is an expensive
> operation that is undesirable to repeat. *That's reasonably easy most
> of the time.
>
> > Erm...
>
> > web_response << "Welcome " some_person.diplay_name() << "!";
>
> > class person
> > {
> > * string display_name() { if (culture == "en") return first_name +
> > last_name; ... };
>
> > };
>
> > I don't know how __you__ write your code, but I have transient peaks
> > all the time.
>
> What "transient peaks"? *

See that temporary string produced by operator+? There's one. And they
are __everywhere__.

> That's not even C++ and there's not enough
> context to see what the hell you're talking about.

Yes, there is, but you are reduced to being argumentative.

> I don't see any
> memory there that could be freed by an OOM handler to enable the
> operation to be retried. *

I never, not once said that operation should be retried. I never, not
once, said that OOM handler should try to free any memory. Go back and
check it out.

> You have to show the presence of allocated
> memory that is not necessary to complete whatever computation you're
> attempting.

I don't have to show that, because I never, in any way, shape or form,
implied that I wanted to complete attempted computation. On the
contrary, I claimed in my first post, that operation should be rolled
back and that it is __likely__ that said rollback (stack unwind) will
have freed some resources. See that image processing that failed? The
thing is, because it was expensive, there's a massive chance it has
been allocating for a while, failed somewhere in the middle, likely
while trying to allocate quite a chunk off the heap. When bad_alloc
was thrown, all that was freed. When catch was reached, chances are,
there's plenty of heap. And you want do kill the process. Yeah, that's
some way to go.

> > I don't think so. Your thinking is pretty much that any exception
> > should lead to a termination.
>
> Given that's the default behavior, it's a damn good starting
> assumption!

If you rely on terminate(), you lose useful error info that was in
exception object (well, should be, at least; I suspect that's not how
you write your exceptions). Not nice. And, bar C++, no language
runtime terminates e.g. a console program by a hard terminate.

> > If that was thinking of language
> > designers, then a catch would be a no-return block, and if it weren't,
> > implementers would push designers to make it so. None of that is true
> > nor is happening.
>
> If it weren't the thinking of language developers, they'd follow the
> exception handling semantics of Eiffel and similar languages.
>
> You know, I never much liked Don Quixote when I read it in school, so
> I think I have no interest in conversing with you further, Mr.
> Quixote.

Shame. It's a good book. Not related to this though.

Goran.

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:
>
> >>>>>>>>>>>>>> *******s.
> >>>>>>>>>>>>>> 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 anuncaught
> >>>>>>>>>>>>> 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 designit 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 appsTelephony
> >>>>>>>>>> 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 ratherthan
> >>>>>>>>>> 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?

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:
>
> >>>>>>>>>>>>>>>> *******s.
> >>>>>>>>>>>>>>>> You have spouted bullshit and now you realise it you aretrying 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 anuncaught
> >>>>>>>>>>>>> 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 thenthe 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 uncatchedis 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 willnever 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 therewas an
> >>>>>>>>>>>> incoming call so the call objects were created up-front rather than
> >>>>>>>>>>>> on-demand. *This may be an over-simplification but you getthe 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 tocreate
> >>>>>>>> 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 ofa
> >>>>> 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 **** and if that's the sort of progams you are producing
then they aren't worth the filespace they occupy.

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:
>
> >>>>>>>>>>>>>>>> *******s.
> >>>>>>>>>>>>>>>> You have spouted bullshit and now you realise it you aretrying 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 anuncaught
> >>>>>>>>>>>>> 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 thenthe 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 uncatchedis 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 willnever 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 therewas an
> >>>>>>>>>>>> incoming call so the call objects were created up-front rather than
> >>>>>>>>>>>> on-demand. *This may be an over-simplification but you getthe 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 tocreate
> >>>>>>>> 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 ofa
> >>>>> 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.
>
*******s, 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.

On Aug 30, 2:34 pm, Leigh Johnston <le...@i42.co.uk> wrote:
> On 30/08/2011 14:26, Paul wrote:

[...]
> The only sane remedy for most cases of allocation failure is to
> terminate the application which is what will happen with an uncaught
> exception.

That's probably true for most applications, but not all. And
even if you do terminate the application, you might want some
sort of clean-up involved. Most of the applications I've worked
on have replaced the new_handler, so it calls exit(), rather
than aborting (and thus, destructors of static variables are
called, along with any functions registered with atexit).
Alternatively, a single try/catch in main can be used.

> Rule of thumb for C++ exception aware code: liberally sprinkle
> throws but have very few try/catches.

Agreed. Even if you have to continue when out of memory occurs
(e.g. because it can occur because a user request is too
complex), you'll still catch bad_alloc at a very high level, and
abort the request. Except (as I'm sure you know), catching
bad_alloc isn't always reliable. If the "request" which causes
you to run out of memory is a result of trying to grow the
stack, for example, there's no system on which you can catch it,
and on some widespread systems, the system will tell you that
there is still memory when there isn't, and then crash the
program when it tries to access that memory.

--
James Kanze

On Sep 1, 8:49 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Aug 31, 12:28 am, Paul <pchris...@yahoo.co.uk> wrote:

[...]
> > How does this address the question...What is the point of a throw if
> > [it's] not being caught?

> to invoke destructors. Go and look up RAII.

If you don't catch the exception, it's unspecified (or
implementation defined, I forget which) whether destructors are
called or not.

--
James Kanze

On Aug 31, 11:24*am, Adam Skutt <ask...@gmail.com> wrote:
> On Aug 31, 12:59*pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> > I would hazard a guess that a fair share of programs could reasonably
> > attempt to recover from an OOM because they will free memory when they
> > start freeing the stack.
>
> No, that doesn't guarantee you a thing, especially if your goal is to
> retry the operation you failed in the first place. *You'll simply
> reallocate the same amount of memory, again, and fail in the same
> place, again. *The OOM handler must go out of its way to ensure
> additional memory gets freed if a retry is desirable (generally, if
> anything other than termination is desirable).

Again, I don't think anyone is suggesting a naive retry of a failed
job on OOM. We're suggesting logging the error first, and possibly
more sophisticated schemes of retry.

[...]

> > Also, to be pedantic, those OSs have an
> > option to turn off overcommit.
>
> Turning off overcommit doesn't ensure your process stays alive. *Even
> when it does, you may have traded the survival of your process for the
> loss of the whole system.
>
> > It's an unfortunate reality due to the
> > fork-exec bug in POSIX (fork as the only process creation is the bug),
> > but we deal with what we have.
>
> fork()/exec() is not the primary reason for overcommit support in
> Linux and other operating systems. *Overcommit comes about because
> many application do use allocation strategies that ask for more memory
> from the operating system then they ever use. *fork()/exec() is really
> a corner case.

Interesting. I've tried to google for more information on this topic,
but there's not much I can find offhand about the actual initial
motivations for overcommit, and the current motivations for leaving
overcommit in.

Furthermore, the current situation is even more broken than I thought.
It seems there's no good way to limit (virtual) memory usage on a per-
user basis in Linux (and presumably other unix-like OSes (?)). Thus,
your options are 1- overcommit and the OOM killer on a relatively
random process, or 2- no overcommit and an OOM failure return code or
exception from malloc et al in a relatively random process. This is
completely broken. I often wonder how such states can persist for so
long. It's not just me, right? Other people do see how this is broken,
right? Why is no one fixing this? It can't be that hard to implement
per-user limits.

With this in mind, I give slightly more credence to your approach, or
at least I'm more open minded as my approach has significant
limitations as well.

> > Why? Again, see the earlier reference to fallacious reasoning. You
> > must always assume that there's 0 bytes available, both before and
> > after any std::bad_alloc errors.
>
> No, that does not follow at all. You need to consider the goal of the
> exception handler: succeed no matter what state the application is in
> vs. the goals of the rest of the program: succeed only if possible.
> The latter means no memory allocation.

Why do you claim that those are their goals? Has a stakeholder ever
given you such requirements?

> > Agreed. I don't mean to gloss over the difficulty. You have to abandon
> > basically all portable code at this point and use the system APIs,
> > like POSIX write. Annoying, but doable.
>
> And a non-starter, especially for a C++ newsgroup!

The distinction is that you were discussing strategies for other
languages, which is why I rightly noted that it's irrelevant to the
conversation and the newsgroup. I will now perhaps acknowledge that
you were trying to shed some light on the current situation by
referencing how other languages do it (in an omitted quote). I was
possibly incorrect for jumping to "off topic".

However, in the above quote, I talked about using non-portable
mechanisms to achieve some degree of reliability, which is relevant to
C++ and this newsgroup. This newsgroup is not purely C++ standard -
that's comp.std.c++. This newsgroup does have a strong bias towards
portable programming, but if the only reasonable solution is to use
POSIX or win32 APIs, then it is appropriate to suggest that here.