Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: C++ Memory Management Question

Reply
Thread Tools

Re: C++ Memory Management Question

 
 
Nick Keighley
Guest
Posts: n/a
 
      01-10-2012
On Jan 2, 2:32*pm, Leigh Johnston <(E-Mail Removed)> wrote:
> On 02/01/2012 11:26, Paul <pchrist wrote:
> > "Leigh Johnston"<(E-Mail Removed)> *wrote in message
> >news:(E-Mail Removed) m...
> >> On 01/01/2012 19:36, Paul<pchrist wrote:
> >>> "Leigh Johnston"<(E-Mail Removed)> * wrote in message
> >>>news:wuqdnZzxuYoWM53SnZ2dnUVZ8iCdnZ2d@giganews. com...
> >>>> On 01/01/2012 14:39, Victor Bazarov wrote:
> >>>>> On 1/1/2012 2:25 AM, Goran wrote:
> >>>>>> On Dec 31 2011, 7:04 pm, Victor Bazarov<(E-Mail Removed)>
> >>>>>> wrote:



<snip>

> >>> I do agree with Carlo that profession programmes should exit
> >>> gracefully , if possible. True it may not always be possible
> >>> as there may be times when a complete system crash is inevitable,
> >>> but a program should at least *try* to save work or recover
> >>> under low memory conditions.


agreed

> >> That is fine if "save work" or "recover" do not allocate memory otherwise
> >> they may also suffer a memory allocation failure. *Aborting the program
> >> (what you call "crashing") on allocation failure is perfectly acceptable
> >> for a subset of all possible programs and this is what will happen if you
> >> don't handle (catch) allocation failure exceptions such as
> >>> std::bad_alloc.


ok

> > This is not what I meant by crashing, I said a system crash ,
> > that is the OS
> > encountering a unrecoverable and critical error.


it's quite clear in context what "program crash" means.

> > You are speaking about
> > aborting a program , a program just dying whenever it encounters an
> > exception..

>
> This thread is not about unrecoverable or critical OS errors; it is
> about memory allocation failures.
>
> Even if an OS provided a mechanism to determine available memory what
> guarantee would there be that the amount of available memory reported by
> such a function would be the same as the amount of available memory when
> the allocation request is actually made?


If you have some control over what is running on the machine it makes
sense. I work in "semi-embedded" environments where the program has a
dedicated machine. We know what's runnig on the machine so we're less
likely to be surprised by memory suddenly vanishing. If the machine
runs out of memory it's usually our fault.

In these circumstances it makes sense to keep an eye on available
memory. particularly when doing memory expensive tasks.

> Are you suggesting that one should check available memory before calling
> any function that may allocate memory? *This is of course absurd.


yes

> Are you suggesting that in C++ one should only use the no-throw version
> of 'new' and check every allocation request at the site of the request
> and report an error and "save work" or "recover"? *This is of course absurd.


fairly silly, as many news are small and available memory is large
 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      01-10-2012
On Jan 2, 10:55*pm, Leigh Johnston <(E-Mail Removed)> wrote:
> On 02/01/2012 22:24, Paul <pchrist wrote:
> > "Leigh Johnston"<(E-Mail Removed)> *wrote in message
> >news:(E-Mail Removed) m...
> >> On 02/01/2012 15:54, Paul<pchrist wrote:
> >>> "Leigh Johnston"<(E-Mail Removed)> * wrote in message
> >>>news:166dnXvy0p2XXZzSnZ2dnUVZ8sadnZ2d@giganews. com...


> >>>> Are you suggesting that in C++ one should only use the no-throw version
> >>>> of
> >>>> 'new' and check every allocation request at the site of the request and
> >>>> report an error and "save work" or "recover"? *This is of course absurd.

>
> >>> Why is it absurd to check each allocation for a failure?

>
> >> If you knew how to properly use C++ exception handling you would not be
> >> asking that question. *You need to learn about RAII and such; I recommend
> >> you read a decent C++ book which should cover this (and it is not the
> >> first time I have made this recommendation to you).

>
> > Allowing the program to terminate is not what I would call properly using
> > C++ EH.
> > What is the point in RAII freeing up memory, with stack created object
> > destructors, if the program is going to terminate anyway?
> > Apparently you dont use C++ EH because you simply allow the program to
> > terminate and catch no exceptions [...]


of course DTORs can do other things besides just freeing memory.

<snip>

 
Reply With Quote
 
 
 
 
BCFD36
Guest
Posts: n/a
 
      01-11-2012
On 1/10/12 12:47 AM, Nick Keighley wrote:
> On Jan 2, 2:32 pm, Leigh Johnston<(E-Mail Removed)> wrote:

[lots of stuff deleted]


>
>> Are you suggesting that in C++ one should only use the no-throw version
>> of 'new' and check every allocation request at the site of the request
>> and report an error and "save work" or "recover"? This is of course absurd.

>
> fairly silly, as many news are small and available memory is large


I am working on a satellite program. You know, one of those things that
orbit the earth. It was decreed long ago (decades) that
malloc/calloc/new/etc. would not be used on these systems. Ever, for any
reason.

I can see the wisdom in this. It is not like you have easy access to a
power-on reset button if this thing decides to crash a year or 5 years
or 10 years after launch, or to some kind of a crash-dump.

And you can't just add new memory, but I'd like to be on the team that
got the assignment to do it if it had to be done.

--
Dave Scruggs

 
Reply With Quote
 
Carlo Milanesi
Guest
Posts: n/a
 
      01-13-2012
On 9 Gen, 18:41, yatremblay@bel1lin202.(none) (Yannick Tremblay)
wrote:
> In article <4f00ee2d$0$6836$(E-Mail Removed)>,CarloMil anesi*<(E-Mail Removed)> wrote:
>
> Most of the time, the std::bad_alloc will be thrown because the
> allocation attempt was too large so the error message should work.
> However, it might happen that even attempting to print the error
> message later will fail.


Usually, when a std::bad_alloc exception is raised, the unrolling of
the stack causes the deallocation of some other memory, and therefore,
even if the "new" causing the exception was asking for just a couple
of bytes, when the exception is catched probably enough memory is
available to display an error message.
Therefore most business or consumer application developers shouldn't
care about the possibility that the error handling procedure cannot
properly run beacuse of low memory conditions.
However, if there is such a concern, the error handling subsystem
should create at program startup all the objects that it will need.
--
Carlo Milanesi
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Project management / bug management Floris van Haaster ASP .Net 3 09-23-2005 08:36 PM
queue management with "application failure management" pouet Java 2 07-30-2004 09:59 PM
CatOS web management or CiscoView management ? Martin Bilgrav Cisco 1 12-20-2003 01:49 PM
perl memory management - does @array = () free the memory? Matt Oefinger Perl Misc 0 06-25-2003 09:11 PM



Advertisments