kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:

>Andy Koenig had an article concerning this problem in a recent issue of
>C++ Reports.  While I don't totally agree with part of his conclusion
>(that there is nothing fundamentally wrong with the situation), his
>presentation of reality was right on line: you cannot reliably do
>anything about running out of memory.  This *IS* a reality; there is no
>point in the C++ standards committee trying to change it.  (Requiring
>support of e.g. infinite recursion would simply mean that there will
>never be a conforming implementation.)

I disagree with this.

In a multi-tasking environment, you can write a new handler that
displays a message to the user that the system is out of memory with
an abort and retry option telling the user to close other applications
and retry.

Secondly, it is possible to more robustly handle out of memory
conditions.  At application startup, you allocate an "emergency" pool
of memory.  When the first out-of-memory condition occurs, you throw
the bad_alloc exception, but first release the emergency pool so that
the program has enough memory to do cleanup while handling the
exception.



---
Robert Mashlan  R2M Software  rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>In a multi-tasking environment, you can write a new handler that
>displays a message to the user that the system is out of memory with
>an abort and retry option telling the user to close other applications
>and retry.

This is assuming your multi-tasking environment can display a message
box in such circumstances.  The act of displaying a message box may
require memory allocation.

For instance in a non-unicode application under NT, all strings are
duplicated and converted to unicode when passed to the OS.  If
displaying a message box requires allocation of memory and we have
none, then it's a bit difficult to pop up a message box.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David Bradley wrote:
>
> >In a multi-tasking environment, you can write a new handler that
> >displays a message to the user that the system is out of memory with
> >an abort and retry option telling the user to close other applications
> >and retry.
>
> This is assuming your multi-tasking environment can display a message
> box in such circumstances.  The act of displaying a message box may
> require memory allocation.
>
> For instance in a non-unicode application under NT, all strings are
> duplicated and converted to unicode when passed to the OS.  If
> displaying a message box requires allocation of memory and we have
> none, then it's a bit difficult to pop up a message box.

Then do what David said as a second idea, pre-allocate some emergency
memory, and free it just before you try to display the message box. This
pre-flight strategy is also useful for insuring a user can save after
modifying a file. I would rather software not let me edit a file if
there may not be enough memory to save my changes afterwards! (or at
least warn me of the fact *before* I make changes).

The issues seem to get more complex in multi-tasking environments, since
the emergency memory you freed may get immediately taken by another
process. If the OS allowed private pools of memory in a process (and
would use them if the global pool was full), then these private pools
could have the emergency memory allocated in them.

I believe it is reasonable for software to handle out-of-memory
situations with the minimum of inconvenience to the user. This means the
program doesn't just quit immediately. Most often, it can simply abort
the current command and go back to waiting for more user commands.

--
Chelly Green | chelly@eden.com | C++ - http://www.eden.com/~chelly


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <325a9ed7.346252925@news>, davidb@datalytics.com (David Bradley) wrote:
>>In a multi-tasking environment, you can write a new handler that
>>displays a message to the user that the system is out of memory with
>>an abort and retry option telling the user to close other applications
>>and retry.
>
>This is assuming your multi-tasking environment can display a message
>box in such circumstances.  The act of displaying a message box may
>require memory allocation.
>
>For instance in a non-unicode application under NT, all strings are
>duplicated and converted to unicode when passed to the OS.  If
>displaying a message box requires allocation of memory and we have
>none, then it's a bit difficult to pop up a message box.
>
Fortunately Microsoft thought of that and guarantee that, with the appropriate
combination of flags, a message box can always be displayed regardless of
available memory, although the length of the text may be limited.

There are many viable schemes to handle out of memory conditions that do not
involve aborting the application. Perhaps you have cached some data calculated
or read earlier and can discard it when memory is low, perhaps you have a
garbage collector that may be called, or maybe you can use a slower or
otherwise poorer, but less memory hungry algorithm (such as certain compilers
I could name with the infuriating habit of doing less optimisation when memory
is low).

--
Duncan Booth                                             duncan@rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
http://ourworld.compuserve.com/homepages/D_Booth


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

David Bradley wrote:
>
> >In a multi-tasking environment, you can write a new handler that
> >displays a message to the user that the system is out of memory with
> >an abort and retry option telling the user to close other applications
> >and retry.
>
> This is assuming your multi-tasking environment can display a message
> box in such circumstances.  The act of displaying a message box may
> require memory allocation.
>
> For instance in a non-unicode application under NT, all strings are
> duplicated and converted to unicode when passed to the OS.  If
> displaying a message box requires allocation of memory and we have
> none, then it's a bit difficult to pop up a message box.

Then do what David said as a second idea, pre-allocate some emergency
memory, and free it just before you try to display the message box. This
pre-flight strategy is also useful for insuring a user can save after
modifying a file. I would rather software not let me edit a file if
there may not be enough memory to save my changes afterwards! (or at
least warn me of the fact *before* I make changes).

The issues seem to get more complex in multi-tasking environments, since
the emergency memory you freed may get immediately taken by another
process. If the OS allowed private pools of memory in a process (and
would use them if the global pool was full), then these private pools
could have the emergency memory allocated in them.

I believe it is reasonable for software to handle out-of-memory
situations with the minimum of inconvenience to the user. This means the
program doesn't just quit immediately. Most often, it can simply abort
the current command and go back to waiting for more user commands.

--
Chelly Green | chelly@eden.com | C++ - http://www.eden.com/~chelly


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Robert Mashlan <rmashlan@r2m.com> wrote:
>Secondly, it is possible to more robustly handle out of memory
>conditions.  At application startup, you allocate an "emergency" pool
>of memory.  When the first out-of-memory condition occurs, you throw
>the bad_alloc exception, but first release the emergency pool so that
>the program has enough memory to do cleanup while handling the
>exception.

Hmm... I don't know how robust this is.  What if the emergency pool is
somehow swapped out of the physical memory and onto disk?  Freeing
this memory has virtually no effect.  I don't know how OS's
"typically" handle swapping, though; I guess that if they do it on a
per-process basis, this would usually work.

Still, that leaves the question of how much memory to reserve.  If
every application takes that extra "emergency" reserve, then the
system will run out of memory much earlier than it should.  If the
applications don't reserve enough memory to show the messages you
described (to throw up a dialog, whatever), then the problem is
compounded (two out-of-memory failures instead of one).

I think that the only way to safely handle such a situation is really
at the operating system level.  Certainly, there are plenty of ways to
improve application handling of such failures; however, I doubt that
any amount of good programming (in C++ or any language) can make a
program robust if the OS isn't robust (unfortunately, I have yet to
work with an OS that meets my standards of robustness).
--
David A. Cuthbert
dacut@ugcs.caltech.edu
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Chelly Green <chelly@eden.com> wrote:

>Then do what David said as a second idea, pre-allocate some emergency
>memory, and free it just before you try to display the message box. This
>pre-flight strategy is also useful for insuring a user can save after
>modifying a file. I would rather software not let me edit a file if
>there may not be enough memory to save my changes afterwards! (or at
>least warn me of the fact *before* I make changes).

But there is no guarentee that the memory you free you'll be able to
get back.  If you have another app that is eating up memory it may
swallow the freed memory before your app does.

As others have stated most modern OS's warn the user when memory
resources are limitted.  That's fine but there is no guarentee that
the user will do anything about it or that things may be so sluggish
and resources consumed so fast that the user is unable to address the
problem in time.

This is the reason that DB Engines and the like preallocate all the
memory they are going to use and handle things themselves.  That's
fine for a server app that running on a standalone machine.  Not very
practicle for applications that have to live with other apps.
--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

duncan@rcp.co.uk (Duncan Booth) wrote:

>Fortunately Microsoft thought of that and guarantee that, with the appropriate
>combination of flags, a message box can always be displayed regardless of
>available memory, although the length of the text may be limited.

That's true.  But I wonder how other OS's handle it.

>There are many viable schemes to handle out of memory conditions that do not
>involve aborting the application. Perhaps you have cached some data calculated
>or read earlier and can discard it when memory is low, perhaps you have a
>garbage collector that may be called, or maybe you can use a slower or
>otherwise poorer, but less memory hungry algorithm (such as certain compilers
>I could name with the infuriating habit of doing less optimisation when memory
>is low).

The problem is that in a multitasking environment you may not be able
to do anything that will free up memory.  Every byte you free goes to
another process, that it may not be your application that has created
this situation.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
[Discussion of whether progs should just shut down on "out of memory"
conditions]
>Surely
>your compiler doesn't wait until you ask it to finish, nor do you have
>to shut down the system for it to terminate.

My compiler (Visual C++ 4.1) runs within the Microsoft MSDEV
development environment.  If it starts to run low on memory, it warns
me, and suggests I close other apps to make sure it doesn't run out.
If it were to run out, I would want the compilation thread to shut
down *after* telling me why it failed, but I wouldn't want MSDEV to
shut down -- especially if it did so without saving any work in
progress.

Speaking genericly: In some cases, if a program is performing a
modification when a request for more memory cannot be fulfilled, it
may be impossible to save the current data because it is in an
inconsistent state.  I would hope that _set_new_handler called a
routine that told the user (via dialog or whatever) something like the
following:

 I am unable to allocate the memory I need to complete the current

 operation.  Please close some other applications so I can continue.
 If I cancel the current operation, it may leave your data in an
 inconsistent state.

 (button) OK, I've closed some programs, please continue
 (button) Cancel the current operation anyway, even if it may damage
  my data.

If the current operation is non-modifying, a similar dialog without
the damage warnings should appear.  If there is an impossible request
-- an attempt to allocate more memory than the system has, for example
-- an alternative approach to displaying the problem may be necessary.

Now, during initial startup, if a program is unable to allocate even
the most basic things -- such as space for the above dialogs -- a
different, terminating message is appropriate.  In that case, there's
no risk of damaging user data.

>What would you suggest that a compiler do in an out-of-memory condition?

Tell me about it.  It might even ask me to close other stuff so it can
try again or even continue.

>Even today, with the extensive use of client-server architecture, most
>applications are run to do a single, finite job, and terminate when
>finished.

I don't think we are advocating a position that would not allow this
to happen, but the core classes of a language should be robust enough
to allow me to write the apps that don't follow this model and do have
more robust handling.  I certainly wouldn't want my OS to shut down on
an out of memory condition...

>With regards to the exceptions (the server itself, and most
>non-commercial software, including the systems I work on), what do you
>do when the stack overflows?

The Windows 32-bit OS (95 or NT) throws a "structured exception,"
which I convert into a regular exception and catch in a catch block
somewhere along the way.  That at least allows me to shut down
gracefully in most cases, and often just keep going, with only the
current action failing.  My understanding is that the stack in 32-bit
Windows code is dynamically allocated in 4k blocks, so closing other
apps may in fact free up the space I need for more stack space, or I
might even be able to free up some memory for more stack space myself.

Very occasionally, one does have to panic, as the cleanup operations
can fail for the same reasons the original ones did.  In those rare
cases, you are going to have trouble, but those are rarer than the
initial failures if you write your cleanup code right.

>For those who think that they are writing
>software to "higher quality of standards than others", read Andy
>Koenig's article.

Where was this article?  I for one would like to read it.

Andrew Bell
andrewb@graphsoft.com abell@mindspring.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <53eg2l$q2d@news.xs4all.nl> Drinie@xs4all.NL (Rinie Kervel)
writes:

|> In <325a9ed7.346252925@news>, davidb@datalytics.com (David Bradley) writes:

|> >>In a multi-tasking environment, you can write a new handler that
|> >>displays a message to the user that the system is out of memory with
|> >>an abort and retry option telling the user to close other applications
|> >>and retry.

|> >For instance in a non-unicode application under NT, all strings are
|> >duplicated and converted to unicode when passed to the OS.  If
|> >displaying a message box requires allocation of memory and we have
|> >none, then it's a bit difficult to pop up a message box.

|> Can't speak for NT (being a developer of Warehouse Management Software
|> under OS/2), but using a modern OS you can only run out of memory
|> when all VIRTUAL memory is used (that is RAM + disk!).

Not at all.  This is only true for single user systems.  On most
systems, there will be a user limit, and often, a built in rule that
only privileged users can get the last 10% or so.

|> In this case the OS displays the message box (swapper.dat is full).

|> The whole argument seems contrived in a virtual memory environment.
|> The only time we run out of memory (continuoes running WMS servers) is
|> memory leakage. Here the OS is signaling low memory so a normal
|> shutdown of the applications can be done.

Yes and no.  I've run out of memory with 200 MB virtual memory.  My own
process didn't use very much, but once you have a lot of system
processes running in the background...  (INN was the culprit in my
particular case.)  As it happens, on my system, there is a demon process
which leaks memory, so if I forget to reboot it for more than a month or
so...  And of course, if there are other users, you don't know what they
are doing.

|> So far we haven't been able to out new/malloc OS/2 in normal applications.
|> It is therefore hardly worth checking if memory allocation fails.

You don't have to use too much memory.  It is sufficient that there is a
process anywhere on you machine that does, and you may have to cope with
the problem.  As Andy Koenig's article points out, you probably cannot
cope in a way that is guaranteed to work, but IMHO, this is no excuse
for not doing what you can.  (On most OS's, the cases that you cannot
handle will be singificantly rarer than those you can.)  "Coping"
depends on the application: if the program executes a single command and
terminates (about 99% of the programs on my system), then aborting with
an error message is sufficient.  If the program is interactive and
accumulating user data (e.g.: an editor), you had best devise a
strategy to minimize lossage, even for the cases you cannot cope with.
(Such a strategy doesn't exepmt you from having 0 lossage when you can
cope, nor for adopting additional strategies to try and minimize the
cases where you cannot cope.  Thus, for example, under Unix, where
memory is never returned to the system except on program termination, a
good editor will start by recursing deeply to get a reasonable stack,
and will impose artificial limits on expression complexity to avoid
overflowing the stack that it knows it has gotten.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <325AE560.269@eden.com> Chelly Green <chelly@eden.com> writes:

|> Then do what David said as a second idea, pre-allocate some emergency
|> memory, and free it just before you try to display the message box. This
|> pre-flight strategy is also useful for insuring a user can save after
|> modifying a file. I would rather software not let me edit a file if
|> there may not be enough memory to save my changes afterwards! (or at
|> least warn me of the fact *before* I make changes).

|> The issues seem to get more complex in multi-tasking environments, since
|> the emergency memory you freed may get immediately taken by another
|> process. If the OS allowed private pools of memory in a process (and
|> would use them if the global pool was full), then these private pools
|> could have the emergency memory allocated in them.

I imagine that most malloc/operator new handle internally a private pool
of memory, if only for performance reasons.  This would make returning
the memory to the OS somewhat difficult; I suspect that most
implementations take the easy way out, and don't bother.  (This is
certainly the case for every Unix implementation I've seen.  But Unix
makes returning freed memory particularly difficult.)

|> I believe it is reasonable for software to handle out-of-memory
|> situations with the minimum of inconvenience to the user. This means the
|> program doesn't just quit immediately. Most often, it can simply abort
|> the current command and go back to waiting for more user commands.

I agree here.  Except that the program which runs out of memory
typically will *be* the current command, whence my comment that most
often, it can simply abort with an error message.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

The short form of this post:
 Many (if not most) programs do not deal well with out of memory.
 For no applications is this acceptable. (IMHO)

 This does not mean that its OK for the C++ standard to endorse
 this behavior, and in fact make it impossible to create well
 behaved applications.

 For some applications, printing "out of memory" and exiting, is
 an entirely appropriate way to deal with the problem.
 For other applications, it is not acceptable to exit.


 (I have included a bunch of quoted text on the end of this post
 in case anyone missed the previous posts. My news site has been really
 unreliable lately - I had to find these articles on some other site)

Arguments follow:


 [James Kanze]
 >  What would you suggest that a compiler do in an out-of-memory condition?
 If its a command line compiler, it should print "out of memory" and exit.
 If its a GUI based compiler, it should print a diagnostic (if possible),
 abort the compile, and *NOT EXIT*.

Apparently we are talking about two different 'application spaces'.
 First, there is the type of application, like a command line
 compiler.
 The best it can do with out-of-memory errors is the same thing
 it does with other "fatal" errors, print a diagnostic and quit.
 This is a "doit and exit" type program, a tool - generally non
 interactive.
My original post neglected to address this first type of application.

 On the other hand, you have applications like word processors,
 paint programs, spreadsheets, databases, etc...
 For this type of application, it is *not* acceptable to print a
 diagnostic and exit.


 [James Kanze]
 >  With regards to the exceptions (the server itself, and most
 >  non-commercial software, including the systems I work on), what do you
 >  do when the stack overflows?  For those who think that they are writing
 >  software to "higher quality of standards than others", read Andy

 My stack doesn't overflow.
 The OS guarantees me at least a certain amount of stack as part of starting
 the application.
 I do not have recursive functions which are allowed to recurse indefinitely.
 (Well I might, but I consider it a bug, which will be fixed when found).
 I have measured the amount of stack the application uses.
 The only things that affect stack usage are:
  Function calls (recursive or otherwise)
  Local variables
  Processor interrupts.

 Most importantly: Other apps cannot 'steal' your stack space, like they can
 steal your heap space.
 The first 2 items, the application writer has full control over.
 For the 3rd item, its up to the OS to guarantee that its not going
 to put many processor state frames on an applications stack.
 This is generally true.
 (Yes I deal with 'allocated' vs. 'committed' stack space. The OS may
 allocate 500meg of address space for your stack, but until its 'committed',
 you have no guarantee that you can use it).


 [David Bradley]
 >  Consider the situation where some other app has sucked all available
 >  memory and left you with nothing.  You have nothing to free up, what
 >  do you do?  Even if you are able to free up memory there is nothing
 >  guarding against the OS handing it over to the other application
 >  rather than giving it back to you.

 I have considered it.
 In fact, I have test programs which do exactly this.

 I have tested *every* memory allocation failure path in my application.
 It recovers from each and every one appropriately.
 In all cases (except where it can't get enough even to start properly),
 it does *not* exit. It prints a diagnostic (if there is enough memory to do
 so) and continues. This is possible because for most apps, when they are just
 sitting there processing mouse events and paint messages, do not need to
 allocate memory.

 (BTW, I never suggested keeping a rainy-day fund chunk of memory to free
 in the case of low memory - I think that is a bad idea for exactly the reason
 you state above, and other reasons too).


 It is worth noting that there are some OS's which deal with low memory better
 than others.

 In some versions of UNIX which I have tested, "malloc()" never fails.
 If your system has 500Meg of virtual memory, an application is allowed
 to allocate 1gig or more. If the application attempts to access more of
that memory
 than the system has, the OS kills the app - end of story.

 On the other hand, there are OS's which deal with memory a little better.
 The AmigaOS for example. An unprotected (non-virtual too) multitasking OS.
 I have a test program which allocates *all* the memory it can, down to the
 last byte.
 The OS does *not* crash. It can't do everything its supposed to do - like
 move a window, or even refresh properly, but it does not crash. Once the
memory
 is freed (the test program frees its memory and exits after a
predetermined timeout),
 the OS recovers and continues normally.
 On an OS like this it is entirely possible to write a stable application
which
 will not crash or exit due to low memory.


 >  From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
 >  Subject: Re: can't use STL in commercial applications
 >  Date: 8 Oct 1996 14:52:21 GMT
 >
 >  In article <5343b0$83o@handupme.avid.com> joe@vixa.voyager.net (joe)
 >  writes:
 >
 >  |> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
 >
 >  |> >It's worth noting, too, that the only exception that most of the
 >  |> >standard library can throw is bad_alloc.  For many commercial
 >  |> >applications, simply aborting in the case of insufficient memory
may be
 >  |> >acceptable.  In such cases, replace the new_handler to abort, and
don't
 >  |> >use exceptions in your own code, and you should be OK.
 >
 >  |> Is this a commonly held belief amount the C++ committee members?
(shudder)
 >
 >  I have no idea.  I believe that it is a generally held believe amongst
 >  people who write application software, depending, of course, on the
 >  application.
 >
 >  |> Some of us application writers apparently write to higher standards
than others.
 >
 >  |> We here at my company feel that the only ligitimate time for the app
to exit is:
 >  |>      o The user asked us to.
 >  |>      o The OS asked us to (for example, when the OS is shutting down).
 >
 >  |> The only time its acceptable to exit because of out-of-memory is
when the app
 >  |> is just starting up - but then nothing else can be done. (Of course
this never
 >  |> actually happens).
 >
 >  This depends on the application.  I think you have forgotten what is
 >  probably the most important case where many applications exit: they have
 >  either finished their job, or are incapable of finishing it.  Surely
 >  your compiler doesn't wait until you ask it to finish, nor do you have
 >  to shut down the system for it to terminate.  The compiler terminates
 >  either because it has finished compiling the code, or because it
 >  discovers that it is incapable of doing so, either because of errors in
 >  the code or a lack of resources.
 >
 >  What would you suggest that a compiler do in an out-of-memory condition?
 >
 >  Even today, with the extensive use of client-server architecture, most
 >  applications are run to do a single, finite job, and terminate when
 >  finished.  IMHO, this should even be the case in most client-server
 >  applications: the server simply starts the correct process to execute
 >  the command, and then waits for it to finish (or more likely doesn't
 >  wait, depending on the application).
 >
 >  With regards to the exceptions (the server itself, and most
 >  non-commercial software, including the systems I work on), what do you
 >  do when the stack overflows?  For those who think that they are writing
 >  software to "higher quality of standards than others", read Andy
 >  Koenig's article.  As far as I can see, the only way to really attain a
 >  high quality standard is to write your own OS and compiler.  Now, try
 >  and sell that extra cost to the customer.  (Actually, I think it could
 >  be done under some of the better Unix implementations.  But it would
 >  still require some support from the compiler.)
 >  --
 >  James Kanze         Tel.: (+33) 88 14 49 00        email:
kanze@gabi-soft.fr
 >  GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg,
France
 >  Conseils,    tudes et r   alisations en logiciel orient    objet --
 >                  -- A la recherche d'une activit    dans une region
francophone
 >
 >
 >
 >  [ comp.std.c++ is moderated.  To submit articles: try just posting with
     ]
 >  [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu
     ]
 >  [ FAQ:
http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
 >  [ Policy:
http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
 >  [ Comments? mailto:std-c++-request@ncar.ucar.edu
     ]
 >  ::::::::::::::
 >  8704
 >  ::::::::::::::
 >  ge
 >  ge
 >  From: davidb@datalytics.com (David Bradley)
 >  Newsgroups: comp.std.c++
 >  Subject: Re: can't use STL in commercial applications
 >  Date: 8 Oct 1996 14:52:28 GMT
 >  Organization: Datalytics Inc.
 >  Lines: 23
 >  Approved: clamage@eng.sun.com (comp.std.c++)
 >  Message-ID: <325f484d.324098979@news>
 >  27115732@slsvhkt.lts.sel.alcatel.de> <5343b0$83o@handupme.avid.com>
 >  27115732@slsvhkt.lts.sel.alcatel.de> <5343b0$83o@handupme.avid.com>
 >  NNTP-Posting-Host: taumet.eng.sun.com
 >  Mime-Version: 1.0
 >  Content-Type: text/plain; charset=us-ascii
 >  Content-Transfer-Encoding: 7bit
 >  X-NNTP-Posting-Host: 204.62.224.67
 >  X-Newsreader: Forte Agent .99f/32.299
 >  Content-Length: 678
 >  Originator: clamage@taumet
 >
 >  joe@vixa.voyager.net (joe) wrote:
 >
 >  >The only time its accecptable to exit because of out-of-memory is when
the app
 >  >is just starting up - but then nothing else can be done. (Of course
this never
 >  >actually happens).
 >
 >  Consider the situation where some other app has sucked all available
 >  memory and left you with nothing.  You have nothing to free up, what
 >  do you do?  Even if you are able to free up memory there is nothing
 >  guarding against the OS handing it over to the other application
 >  rather than giving it back to you.
 >
 >  --------------------------------------------
 >  David Bradley         davidb@datalytics.com
 >  Software Engineer
 >  Datalytics, Inc.      http://www.datalytics.com
 >
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

andrewb@graphsoft.com (Andrew C. Bell) writes:

> >For those who think that they are writing
> >software to "higher quality of standards than others", read Andy
> >Koenig's article.

"When Memory Runs Low", C++ Report, June 1996.  This is by far the best
summary I've seen concerning the problems of handling (and even
detecting) insufficient memory conditions.

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

davidb@datalytics.com (David Bradley) wrote:

>But there is no guarentee that the memory you free you'll be able to
>get back.  If you have another app that is eating up memory it may
>swallow the freed memory before your app does.

I think that is implementation dependent.  On every heap implemenation
that I've seen, the application requests memory from the operating
system as the heap grows larger, however, it doesn't give the memory
back when it shrinks.  Therefore, with this kind of implementation
the situation you describe can't happen.


rm


---
Robert Mashlan  R2M Software  rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5343b0$83o@handupme.avid.com>, joe@vixa.voyager.net (joe) writes:
|> Some of us application writers apparently write to higher standards than others.
|>
|> We here at my company feel that the only ligitimate time for the app to exit is:
|>  o The user asked us to.
|>  o The OS asked us to (for example, when the OS is shutting down).
|>
|> The only time its accecptable to exit because of out-of-memory is when the app
|> is just starting up - but then nothing else can be done. (Of course this never
|> actually happens).

Cool!  Uhhh.  I work on a compiler.  What do I do when it uses up all 256
meg of virtual storage on a machine in the middle of something?  There's
just NO MORE memory there.

And yes, it happens, though usually on smaller machines.
--

- Bill Seurer     ID Tools and Compiler Development      IBM Rochester, MN
  Business: BillSeurer@vnet.ibm.com               Home: BillSeurer@aol.com
  WWW:  http://members.aol.com/BillSeurer
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

David A. Cuthbert wrote:
>
> Robert Mashlan <rmashlan@r2m.com> wrote:
> >Secondly, it is possible to more robustly handle out of memory
> >conditions.  At application startup, you allocate an "emergency" pool
> >of memory.  When the first out-of-memory condition occurs, you throw
> >the bad_alloc exception, but first release the emergency pool so that
> >the program has enough memory to do cleanup while handling the
> >exception.
>
> Hmm... I don't know how robust this is.  What if the emergency pool is
> somehow swapped out of the physical memory and onto disk?  Freeing
> this memory has virtually no effect.  I don't know how OS's
> "typically" handle swapping, though; I guess that if they do it on a
> per-process basis, this would usually work.

I'd say that swapping is transparent; it really means that you don't
have to care, and every valid program in 100% RAM will work the same
with pagination, but possibly really slower.

The MacOS has some functions to handle that: HoldMemory garanty that the
memory won't be switched to disk, for example.

The part of the system that handle switching run at interrupt level, it
means that it can't allocate any memory so it works fine in low-mem
conditions.

So I really don't see the problem: freeing the memory will have the same
effect as if it were in phisical RAM; allocation of more memory will be
possible and the new memory will be switched to RAM; some not very
oftenly used (read, written) mem will be switched to disk.

> Still, that leaves the question of how much memory to reserve.  If
> every application takes that extra "emergency" reserve, then the
> system will run out of memory much earlier than it should.  If the
> applications don't reserve enough memory to show the messages you
> described (to throw up a dialog, whatever), then the problem is
> compounded (two out-of-memory failures instead of one).

I would say that 50-200 KB would be sufficient; Photoshop could chose
400 KB because it's only used on machines having more than 20 MB of RAM;
a small text editor using 500 KB - 1 MB of RAM would choose 50 KB.

What I mean is that to draw a dialog and then to save doesn't take much
memory compared with the normal mem used.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <KANZE.96Oct10144848@slsviyt.lts.sel.alcatel.de>, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
>In article <53eg2l$q2d@news.xs4all.nl> Drinie@xs4all.NL (Rinie Kervel)
>writes:
>
>|> In <325a9ed7.346252925@news>, davidb@datalytics.com (David Bradley) writes:
>
>|> >>In a multi-tasking environment, you can write a new handler that
>|> >>displays a message to the user that the system is out of memory with
>|> >>an abort and retry option telling the user to close other applications
>|> >>and retry.
>
>
>|> Can't speak for NT (being a developer of Warehouse Management Software
>|> under OS/2), but using a modern OS you can only run out of memory
>|> when all VIRTUAL memory is used (that is RAM + disk!).
>
>Not at all.  This is only true for single user systems.  On most
>systems, there will be a user limit, and often, a built in rule that
>only privileged users can get the last 10% or so.
>
>Yes and no.  I've run out of memory with 200 MB virtual memory.  My own
>process didn't use very much, but once you have a lot of system
>processes running in the background...  (INN was the culprit in my
>particular case.)  As it happens, on my system, there is a demon process
>which leaks memory, so if I forget to reboot it for more than a month or
>so...  And of course, if there are other users, you don't know what they
>are doing.
>
The OS/2 example can be easily converted to multi user systems:
Programs for the user use a resource (virtual memory) and a maximum usage
is allowed. Now if the user approaches that limit (say 4 MB is left, or 5%),
the OS! should display a dialog box stating the problem. As you stated the
program cannot know who is using all that memory, but perhaps the user can.
He/She then has time to choose what program to abort, or simply close some
editor windows etc... This is just like handling disk quota's etc..
Of course with this scheme it is perfectly legal to abort the program when all
memory has been depleted, as the user could have corrected the problem.

Rinie






[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze US/ESC 60/3/141 #40763 wrote:
[snip]
> In the meantime, your statement that one cannot use STL in a
> commercial application is only partially true.  Most compilers have a
> switch which will turn off support for exceptions; use this, and there > is no problem.
>
> It's worth noting, too, that the only exception that most of the
> standard library can throw is bad_alloc.  For many commercial
> applications, simply aborting in the case of insufficient memory may
> be acceptable.

Don't be silly.
What platform do you code for?
On the Mac, if I opened one too many documents, the program aborted and
I lost all my unsaved work, I'd want to find the person responsible and
throttle him (or her). There has to be a way of recovering from running
out of memory other than aborting.

> In such cases, replace the new_handler to abort, and don't
> use exceptions in your own code, and you should be OK.

O, so I don't use one of the most useful language features since C
(except for the basic OOP methodology and perhaps templates). Thank you
for that.

Regards,
    Michael Hudson

Please don't email this address - it's not mine.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:


>It's worth noting, too, that the only exception that most of the
>standard library can throw is bad_alloc.  For many commercial
>applications, simply aborting in the case of insufficient memory may be
>acceptable.  In such cases, replace the new_handler to abort, and don't
>use exceptions in your own code, and you should be OK.

Is this a commonly held belief amoung the C++ committe members? (shudder)


Some of us application writers apparently write to higher standards than others.

We here at my company feel that the only ligitimate time for the app to exit is:
 o The user asked us to.
 o The OS asked us to (for example, when the OS is shutting down).

The only time its accecptable to exit because of out-of-memory is when the app
is just starting up - but then nothing else can be done. (Of course this never
actually happens).






[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <3253F9C5.4786@nowhere.com> Michael Hudson
<sorry.no.email@nowhere.com> writes:

|> James Kanze US/ESC 60/3/141 #40763 wrote:
|> [snip]
|> > In the meantime, your statement that one cannot use STL in a
|> > commercial application is only partially true.  Most compilers have a
|> > switch which will turn off support for exceptions; use this, and there > is no problem.
|> >
|> > It's worth noting, too, that the only exception that most of the
|> > standard library can throw is bad_alloc.  For many commercial
|> > applications, simply aborting in the case of insufficient memory may
|> > be acceptable.

|> Don't be silly.
|> What platform do you code for?
|> On the Mac, if I opened one too many documents, the program aborted and
|> I lost all my unsaved work, I'd want to find the person responsible and
|> throttle him (or her). There has to be a way of recovering from running
|> out of memory other than aborting.

You'll note that I said: "many commerical applications".  Not all, and I
qualified it with "commercial".  In practice, most C/C++ will abort in
some cases of insufficient memory, and you cannot do anything about it.
(Stack overflow is a typical example.)

Andy Koenig had an article concerning this problem in a recent issue of
C++ Reports.  While I don't totally agree with part of his conclusion
(that there is nothing fundamentally wrong with the situation), his
presentation of reality was right on line: you cannot reliably do
anything about running out of memory.  This *IS* a reality; there is no
point in the C++ standards committee trying to change it.  (Requiring
support of e.g. infinite recursion would simply mean that there will
never be a conforming implementation.)

I would go even further and say that it is not even the responsibility
of the C++ committee to try and improve it.  The majority of developpers
seem perfectly happy with the current situation, so any attempt by a
standards committee to regulate otherwise would promptly be ignored.
Educate the programmers, and even without a standard requiring it,
quality of implementation will solve the problem.

Back to what the programmer should do in such cases: in the case of an
editor, for example, I would definitly try and manage my own memory.
Although I cannot do much about stack overflow, I can certainly overload
new_handler to spill part of my edited text to disk, free up the
corresponding memory, and return.  Although I wouldn't swear to it, I
think that the editor I most often use does this.  (I seems like it
does; sometimes, I have close to 100 buffers active, and it has never
core dumped nor thrown me out because of insufficient memory.  On the
other hand, the systems I run on generally have between 150 and 200
Megabytes virtual memory, so maybe I've just never hit the limit.)

Editors are, IMHO, exceptional in terms of commercial applications.
Most commercial applications will do whatever they have to do, and
terminate.  In such cases, there is often no way they can continue in
the absense of memory anyway.

|> > In such cases, replace the new_handler to abort, and don't
|> > use exceptions in your own code, and you should be OK.

|> O, so I don't use one of the most useful language features since C
|> (except for the basic OOP methodology and perhaps templates). Thank you
|> for that.

Which useful feature?  If you are referring to exceptions, I don't use
them, because, until now, I haven't found them particularly useful.  One
of their most notable characteristic is their ability to leave the
internal data in an inconsistent state.  Given the choice between
exceptions and the STL (and this is the current choice!), I'll choose
exceptions any day.  (Of course, I really would like to have the freedom
to use both.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

joe@vixa.voyager.net (joe) wrote:

>The only time its accecptable to exit because of out-of-memory is when the app
>is just starting up - but then nothing else can be done. (Of course this never
>actually happens).

Consider the situation where some other app has sucked all available
memory and left you with nothing.  You have nothing to free up, what
do you do?  Even if you are able to free up memory there is nothing
guarding against the OS handing it over to the other application
rather than giving it back to you.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <5343b0$83o@handupme.avid.com> joe@vixa.voyager.net (joe)
writes:

|> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:

|> >It's worth noting, too, that the only exception that most of the
|> >standard library can throw is bad_alloc.  For many commercial
|> >applications, simply aborting in the case of insufficient memory may be
|> >acceptable.  In such cases, replace the new_handler to abort, and don't
|> >use exceptions in your own code, and you should be OK.

|> Is this a commonly held belief amoung the C++ committe members? (shudder)

I have no idea.  I believe that it is a generally held believe amongst
people who write application software, depending, of course, on the
application.

|> Some of us application writers apparently write to higher standards than others.

|> We here at my company feel that the only ligitimate time for the app to exit is:
|>  o The user asked us to.
|>  o The OS asked us to (for example, when the OS is shutting down).

|> The only time its accecptable to exit because of out-of-memory is when the app
|> is just starting up - but then nothing else can be done. (Of course this never
|> actually happens).

This depends on the application.  I think you have forgotten what is
probably the most important case where many applications exit: they have
either finished their job, or are incapable of finishing it.  Surely
your compiler doesn't wait until you ask it to finish, nor do you have
to shut down the system for it to terminate.  The compiler terminates
either because it has finished compiling the code, or because it
discovers that it is incapable of doing so, either because of errors in
the code or a lack of resources.

What would you suggest that a compiler do in an out-of-memory condition?

Even today, with the extensive use of client-server architecture, most
applications are run to do a single, finite job, and terminate when
finished.  IMHO, this should even be the case in most client-server
applications: the server simply starts the correct process to execute
the command, and then waits for it to finish (or more likely doesn't
wait, depending on the application).

With regards to the exceptions (the server itself, and most
non-commercial software, including the systems I work on), what do you
do when the stack overflows?  For those who think that they are writing
software to "higher quality of standards than others", read Andy
Koenig's article.  As far as I can see, the only way to really attain a
high quality standard is to write your own OS and compiler.  Now, try
and sell that extra cost to the customer.  (Actually, I think it could
be done under some of the better Unix implementations.  But it would
still require some support from the compiler.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In <325a9ed7.346252925@news>, davidb@datalytics.com (David Bradley) writes:
>
>>In a multi-tasking environment, you can write a new handler that
>>displays a message to the user that the system is out of memory with
>>an abort and retry option telling the user to close other applications
>>and retry.
>
>For instance in a non-unicode application under NT, all strings are
>duplicated and converted to unicode when passed to the OS.  If
>displaying a message box requires allocation of memory and we have
>none, then it's a bit difficult to pop up a message box.
>

Can't speak for NT (being a developer of Warehouse Management Software
under OS/2), but using a modern OS you can only run out of memory
when all VIRTUAL memory is used (that is RAM + disk!).

In this case the OS displays the message box (swapper.dat is full).

The whole argument seems contrived in a virtual memory environment.
The only time we run out of memory (continuoes running WMS servers) is
memory leakage. Here the OS is signaling low memory so a normal
shutdown of the applications can be done.

So far we haven't been able to out new/malloc OS/2 in normal applications.
It is therefore hardly worth checking if memory allocation fails.

Rinie
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <324a9655.2318988@news.ma.ultranet.com>
phalpern@truffle.ma.ultranet.com (Pablo Halpern) writes:

|> kanze@gabi-soft.fr (J. Kanze) wrote:

|> >The HP implementation of vector simply ignores the exception, and at
|> >present, there is nothing in the standard that says what it should do.

|> Is that because they are still working on the wording or because they
|> have made a concious decision to leave this unspecified.

Obviously, I cannot read the committee members minds.  But if it were a
conscious decision, I would expect to see words to that effect in the
draft.  There aren't, and so I suppose that it is most likely just one
of those things on their to do list.

|> It seems to me
|> that leaving it unspecified or implementation-specified is inadequate.
|> (Although certain parts of the behavior could be
|> implementation-specified, IMHO the standard should say at least enough
|> about the subject to assure that resource leaks can be prevented. It
|> should probably say more than just that.) I have some ideas on wording,
|> if anybody cares.

I don't think that anyone on the committee would think that leaving it
undefined, unspecified, or implementation specified is the ideal
solution.  I do have some fear that the committee will find that there
is not enough time to specify it correction, and feel forced to specify
it as undefined behavior in order to meet the deadline.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <32480337.4FF1@cds.duke.edu>,
Max TenEyck Woodbury  <mtew@cds.duke.edu> wrote:
>J. Kanze wrote:
>>
>> Willy Wood <ofile@aquanet.co.il> writes:
>>
>> > >BUT the real problem comes from the fact, that STL doesn't HANDLE
>> > >exceptions in any way. That simply means every STL object is
>> > >undefined after an exception if even if the exception comes from
>> > >the elements of the container.
>> > >So vector<string> is something that may result in undefined
>> > >behavior. I can't event destroy the vector or free its memory.
>> >
>> > If a library does not handle an exception and NEEDS to, then it
>> > quite simply contains a bug !
>> >
>> > Post a concrete example if you have one.
>>
>> Let's try vector< string >:
>>
>>                 vector< string >      vs( 100 , string( "Some text" ) ) ;
>>
>> Now think of what happens if memory runs out on the 50th copy of string,
>> and operator new throws bad_alloc.
>>
>> The HP implementation of vector simply ignores the exception, and at
>> present, there is nothing in the standard that says what it should do.
>> Of course, ignoring the exception means that the 49 strings already
>> constructed will not be destructed, so you have a monsterous memory leak
>> (in a system where, apparently, memory is tight).  There is also no way
>> for the user to avoid this problem.
>>
>
>Does it ignore the exception or does it expect the exception to invoke
>the vector destructor and leaves the deallocation problem to the
>destructor?  (I'm being lazy.  My machine is mostly tied up at the
>moment and searching the STL code for the vector destructor would
>take a looong time at the moment.)
>
It doesn't matter what any STL code does.
The STANDARD in the current fashion says NOTHING about that what
simply means that the behavior is UNDEFINED. And that means, that
a standard library is absolutely correct, if it results in a
memory leak.

That's exacly what i mean with "can't use the standard STL in
commercial appilcations" and why I think exception
handling MUST be part of STL in the standard library.

--
Nico                             address: BREDEX GmbH, Nicolai Josuttis
email:   nico@bredex.de                   Fallersleber-Tor-Wall 23
phone:   +49 531 24330-0                  D-38100 Braunschweig
fax:     +49 531 24330-99                 Germany
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kanze@gabi-soft.fr (J. Kanze) wrote:

>The HP implementation of vector simply ignores the exception, and at
>present, there is nothing in the standard that says what it should do.

Is that because they are still working on the wording or because they
have made a concious decision to leave this unspecified. It seems to me
that leaving it unspecified or implementation-specified is inadequate.
(Although certain parts of the behavior could be
implementation-specified, IMHO the standard should say at least enough
about the subject to assure that resource leaks can be prevented. It
should probably say more than just that.) I have some ideas on wording,
if anybody cares.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent
those of my employer.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <199609261027.MAA05810@bredex.bredex.de> Nico Josuttis
<nico@bredex.de> writes:

    [Concerning exceptions thrown from user code invoked by STL...]
|> It doesn't matter what any STL code does.
|> The STANDARD in the current fashion says NOTHING about that what
|> simply means that the behavior is UNDEFINED. And that means, that
|> a standard library is absolutely correct, if it results in a
|> memory leak.

I'm not sure that this is the only interpretation.  One could equally
argue that the standard poses no constraints with regards to exceptions
in user code, so the implementation had better handle them all
correctly.

|> That's exacly what i mean with "can't use the standard STL in
|> commercial appilcations" and why I think exception
|> handling MUST be part of STL in the standard library.

There are two distinct issues:

1. IMHO, the standard must address this issue, and specify what happens
in the case of an exception.  I can perfectly conceive of some
situations resulting in undefined behavior (an exception from a
destructor, for example).

2. Once the standard defines what should be done, the vendors must
implement it.  I can imagine that one of the reasons why vendors like
Rogue Wave are so slow about correcting this obvious weakness is that
they are waiting to see what ISO will require, so as to not be
incompatible.

In the meantime, your statement that one cannot use STL in a commercial
application is only partially true.  Most compilers have a switch which
will turn off support for exceptions; use this, and there is no problem.

It's worth noting, too, that the only exception that most of the
standard library can throw is bad_alloc.  For many commercial
applications, simply aborting in the case of insufficient memory may be
acceptable.  In such cases, replace the new_handler to abort, and don't
use exceptions in your own code, and you should be OK.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Willy Wood <ofile@aquanet.co.il> writes:

> >BUT the real problem comes from the fact, that STL doesn't HANDLE
> >exceptions in any way. That simply means every STL object is
> >undefined after an exception if even if the exception comes from
> >the elements of the container.
> >So vector<string> is something that may result in undefined
> >behavior. I can't event destroy the vector or free its memory.
>
> If a library does not handle an exception and NEEDS to, then it
> quite simply contains a bug !
>
> Post a concrete example if you have one.

Let's try vector< string >:

  vector< string >      vs( 100 , string( "Some text" ) ) ;

Now think of what happens if memory runs out on the 50th copy of string,
and operator new throws bad_alloc.

The HP implementation of vector simply ignores the exception, and at
present, there is nothing in the standard that says what it should do.
Of course, ignoring the exception means that the 49 strings already
constructed will not be destructed, so you have a monsterous memory leak
(in a system where, apparently, memory is tight).  There is also no way
for the user to avoid this problem.

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J. Kanze wrote:
>
> Willy Wood <ofile@aquanet.co.il> writes:
>
> > >BUT the real problem comes from the fact, that STL doesn't HANDLE
> > >exceptions in any way. That simply means every STL object is
> > >undefined after an exception if even if the exception comes from
> > >the elements of the container.
> > >So vector<string> is something that may result in undefined
> > >behavior. I can't event destroy the vector or free its memory.
> >
> > If a library does not handle an exception and NEEDS to, then it
> > quite simply contains a bug !
> >
> > Post a concrete example if you have one.
>
> Let's try vector< string >:
>
>                 vector< string >      vs( 100 , string( "Some text" ) ) ;
>
> Now think of what happens if memory runs out on the 50th copy of string,
> and operator new throws bad_alloc.
>
> The HP implementation of vector simply ignores the exception, and at
> present, there is nothing in the standard that says what it should do.
> Of course, ignoring the exception means that the 49 strings already
> constructed will not be destructed, so you have a monsterous memory leak
> (in a system where, apparently, memory is tight).  There is also no way
> for the user to avoid this problem.
>

Does it ignore the exception or does it expect the exception to invoke
the vector destructor and leaves the deallocation problem to the
destructor?  (I'm being lazy.  My machine is mostly tied up at the
moment and searching the STL code for the vector destructor would
take a looong time at the moment.)

mtew@cds.duke.edu
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <32480337.4FF1@cds.duke.edu> Max TenEyck Woodbury
<mtew@cds.duke.edu> writes:

|> J. Kanze wrote:
|> >
|> > Willy Wood <ofile@aquanet.co.il> writes:
|> >
|> > > >BUT the real problem comes from the fact, that STL doesn't HANDLE
|> > > >exceptions in any way. That simply means every STL object is
|> > > >undefined after an exception if even if the exception comes from
|> > > >the elements of the container.
|> > > >So vector<string> is something that may result in undefined
|> > > >behavior. I can't event destroy the vector or free its memory.
|> > >
|> > > If a library does not handle an exception and NEEDS to, then it
|> > > quite simply contains a bug !
|> > >
|> > > Post a concrete example if you have one.
|> >
|> > Let's try vector< string >:
|> >
|> >                 vector< string >      vs( 100 , string( "Some text" ) ) ;
|> >
|> > Now think of what happens if memory runs out on the 50th copy of string,
|> > and operator new throws bad_alloc.
|> >
|> > The HP implementation of vector simply ignores the exception, and at
|> > present, there is nothing in the standard that says what it should do.
|> > Of course, ignoring the exception means that the 49 strings already
|> > constructed will not be destructed, so you have a monsterous memory leak
|> > (in a system where, apparently, memory is tight).  There is also no way
|> > for the user to avoid this problem.
|> >

|> Does it ignore the exception or does it expect the exception to invoke
|> the vector destructor and leaves the deallocation problem to the
|> destructor?  (I'm being lazy.  My machine is mostly tied up at the
|> moment and searching the STL code for the vector destructor would
|> take a looong time at the moment.)

The vector destructor will not be called, since we have not returned
from the constructor.  A good thing, too, since the vector destructor
would probably try and destruct the 50 strings not yet constructed, thus
calling the destructor on raw memory.

To be implemented correctly, the vector constructor must maintain the
index outside of the try block, do the construction in a try block, and
back out by hand before rethrowing the exception in the catch block.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
>STL is still fairly new; most implementors are happy to have *any*
>implementation of it.  Long term, however, I would expect that most
>implementations will deliver two versions of the library, one with
>checking, and one without.  By default, you would use the checking
>version; in specific applications, where performance is critial, you
>would switch to the non-checking version once the application was
>debugged.

A better way probably would be to have a different namespace for both,
so you could access both in a single application as needed, and change
your using declarations to change between the two as appropriate.
Generally only particular sections of code are speed-critical.

Alternatively, the STL class could have safe and unsafe member funcs,
and you only use the unsafe ones when you know you need the speed.
Again, you can use multiply namespaced versions so you can have safe
access even with the unsafe funcs while you are testing, or while you
are testing for accuracy, not performance.

>Again, this is true of current implementations.  The problem here is
>that the draft standard itself does not specify what is to be supported,
>etc.

Indeed.  If the draft standard does not specify these things, then I
cannot be even reasonably assured of getting a safe version of the
code, since there is no standard basis for comparison.  It makes the
STL much less useful, and much less likely that I will use it.

Andrew Bell
abell@mindspring.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Hi,

the STL does (even in the actual draft) nothing for
a proper exception handling. After more and more disussions
with several students, customers and other people
I see a big problem grow and grow:
 I can't use STL in commercial applications!

OK, one thing is not to check possible runtime errors
to save time in the STL objects.
It would not change the complexity, so I don't understand
that design solution. We take all the old pointer problems to C++.
It seems we didn't learn anything from the problems in the past.

BUT the real problem comes from the fact, that STL doesn't HANDLE
exceptions in any way. That simply means every STL object is
undefined after an exception if even if the exception comes from
the elements of the container.
So vector<string> is something that may result in undefined
behavior. I can't event destroy the vector or free its memory.

How should I handle this in commercial applications?
It means that any application may have memory leaks or resource
leaks if I use STL. Even if a higher level library hides STL,
its usage is a general problem. And I can't write applications
that may run for a large time, when the danger of memory leaks
exist.

To summarize: STL is a nice concept but as far as it is
       in the standard it is simply worthless.
OK, OK, it may be an overstatement, but the problem exists IMO
and several people, I did discuss with, did argue that way.

BTW, Safe STL is a senseful way to fix that problems.
Does any of the commerical library developers
(RogueWave, ObjectSpace, Modena, ...) does it better ?

Best regards
--------
Nico                             address: BREDEX GmbH
email:   nico@bredex.de                   Nicolai Josuttis
                                          Fallersleber-Tor-Wall 23
phone:   +49 531 24330-0                  D-38100 Braunschweig
fax:     +49 531 24330-99                 Germany
--------


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <199609090911.LAA03990@bredex.bredex.de> Nico Josuttis
<nico@bredex.de> writes:

|> the STL does (even in the actual draft) nothing for
|> a proper exception handling. After more and more disussions
|> with several students, customers and other people
|> I see a big problem grow and grow:
|>  I can't use STL in commercial applications!

|> OK, one thing is not to check possible runtime errors
|> to save time in the STL objects.
|> It would not change the complexity, so I don't understand
|> that design solution. We take all the old pointer problems to C++.
|> It seems we didn't learn anything from the problems in the past.

This is implementation dependant.  In vector, for example, calling
operator[] with an out of bounds index is undefined behavior.  The
implementation is allowed (but not required) to catch it and throw an
exception.  At least one implementation (by Cay Horsman, I think) does
do error checking in such cases.

STL is still fairly new; most implementors are happy to have *any*
implementation of it.  Long term, however, I would expect that most
implementations will deliver two versions of the library, one with
checking, and one without.  By default, you would use the checking
version; in specific applications, where performance is critial, you
would switch to the non-checking version once the application was
debugged.

|> BUT the real problem comes from the fact, that STL doesn't HANDLE
|> exceptions in any way. That simply means every STL object is
|> undefined after an exception if even if the exception comes from
|> the elements of the container.
|> So vector<string> is something that may result in undefined
|> behavior. I can't event destroy the vector or free its memory.

Again, this is true of current implementations.  The problem here is
that the draft standard itself does not specify what is to be supported,
etc.  Thus, for example, must the implementation handle an exception
coming from a destructor or a const function?  If an exception is
thrown, must the implementation leave everything in the state that it
had before the function was called, or is it sufficient that the object
is in some logically coherent state (destructable)?

I presume that this will be fixed in the final version of the standard.

|> How should I handle this in commercial applications?

Write your own STL which handles exceptions as you think correct:-).
Seriously, I don't know.

|> It means that any application may have memory leaks or resource
|> leaks if I use STL. Even if a higher level library hides STL,
|> its usage is a general problem. And I can't write applications
|> that may run for a large time, when the danger of memory leaks
|> exist.

Correct.

|> To summarize: STL is a nice concept but as far as it is
|>        in the standard it is simply worthless.
|> OK, OK, it may be an overstatement, but the problem exists IMO
|> and several people, I did discuss with, did argue that way.

|> BTW, Safe STL is a senseful way to fix that problems.
|> Does any of the commerical library developers
|> (RogueWave, ObjectSpace, Modena, ...) does it better ?

Check out Cay Horstman's implementation.  I don't know what it does with
regards to exceptions, but it does do a lot of checking.

I haven't actually seen any of the commercial libraries, but if they do
not do some exception handling, then they are bordering on fraud (IMHO).
Disclaimers not withstanding, they are selling something that they claim
to be useful, but is not.  (One does not expect everything to be
perfect, but one does expect a minimum of professionalism.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

>BUT the real problem comes from the fact, that STL doesn't HANDLE
>exceptions in any way. That simply means every STL object is
>undefined after an exception if even if the exception comes from
>the elements of the container.
>So vector<string> is something that may result in undefined
>behavior. I can't event destroy the vector or free its memory.

If a library does not handle an exception and NEEDS to, then it
quite simply contains a bug !

Post a concrete example if you have one.



--
Willy Wood, ObjectFile, Israel.

http://www.aquanet.co.il/web/ofile/ofile.html



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]