deleteall

[bob]

why can't there be a deleteall keyword in c++ that
deletes all the memory previously allocated by
the new keyword?

wouldn't this solve a lot of memory leak issues?

[peter koch]

bo*@coolgroups.com skrev:

why can't there be a deleteall keyword in c++ that
deletes all the memory previously allocated by
the new keyword?

wouldn't this solve a lot of memory leak issues?

No - why do you believe so? All memory allocated would be invalid
suddenly and there would not really be any option but to terminate the
program (which typically releases all resources anyway).

/Peter

[bob]

it would be called before termination usually. i don't think
termination typically releases all resources.

[dan2online]

bo*@coolgroups.com wrote:

it would be called before termination usually. i don't think
termination typically releases all resources.

deleteall doesn't make sense because it doesn't control its behaviors
itself.
Modern OS' memory management can handle the release of memory resource
after terminating a process. Memory leakage is fatal while the process
is running so the programmer should avoid the memory leakage.

[Greg]

bo*@coolgroups.com wrote:

why can't there be a deleteall keyword in c++ that
deletes all the memory previously allocated by
the new keyword?

wouldn't this solve a lot of memory leak issues?

If a program makes a series of memory allocations of equal size, then
it can use a memory "pool" (such as boost's "pool" library) so that all
of the allocations are fulfilled from the same block of reserved
memory. A program can then deallocate the entire pool and thereby free
all of the pooled allocations at once. And indeed this approach is not
only very efficient but also eliminates the chance that any of pooled
allocations could leak.

Unfortunately, relatively few applications actually have memory
allocation patterns that could be implemented by a pool. Instead most
programs create and delete objects in such a way that their life spans
overlap; as a consequence, a typical program is constantly allocating
and deallocating memory in various sizes and without adhering to any
discernable pattern. Therefore there is never a point in most programs'
execution in which all allocations up to that point could safely be
freed at once. So while your idea certainly has merit, it is applicable
only to relatively few programs.

Greg

[Markus Schoder]

bo*@coolgroups.com wrote:

it would be called before termination usually. i don't think
termination typically releases all resources.

Most modern general purpose operating systems do certainly release
allocated memory upon process termination.

[REH]

dan2online wrote:

bo*@coolgroups.com wrote:

it would be called before termination usually. i don't think
termination typically releases all resources.

deleteall doesn't make sense because it doesn't control its behaviors
itself.
Modern OS' memory management can handle the release of memory resource
after terminating a process.

Modern hosted systems typically do so. Most modern embedded OSes do
not.

REH

[Phlip]

bob wrote:

why can't there be a deleteall keyword in c++ that
deletes all the memory previously allocated by
the new keyword?

wouldn't this solve a lot of memory leak issues?

The point of delete is "deterministic destruction". Under RAII (look it up),
an object's destructor should have useful side effects.

A complete program should have some 'new'-ed object that should last for the
life of the program, and should have some 'new'-ed objects that should come
and go. (And most objects should either be on the stack, or should be
members of other objects. So most object should not be created by 'new'.)

When a program ends, many OSs will free all its resources. (And many will
not. These OSs are often referred to as "embedded" these days.) These OSs
will not call destructors for all leaked objects.

The point of C++'s memory allocation system is to lead programmers to build
a coherent object model where objects own sub-objects, and manage their
lifespans. A 'deleteall' keyword will not improve these designs.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[REH]

Phlip wrote:

When a program ends, many OSs will free all its resources. (And many will
not. These OSs are often referred to as "embedded" these days.)
Though, not for that reason.
These OSs will not call destructors for all leaked objects.

I don't believe there is *any* OS that will call the destructors for an
application, even though they may reclaim the memory.

REH

[dan2online]

REH wrote:

dan2online wrote:

bo*@coolgroups.com wrote:

it would be called before termination usually. i don't think
termination typically releases all resources.

deleteall doesn't make sense because it doesn't control its behaviors
itself.
Modern OS' memory management can handle the release of memory resource
after terminating a process.

Modern hosted systems typically do so. Most modern embedded OSes do
not.

How embedded systems do will depend on MMU hardware and OS which
supports MMU.

[Phlip]

dan2online wrote:

Modern hosted systems typically do so.Â*Â*MostÂ*modernÂ*embeddedÂ*OSesÂ*do
not.

How embedded systems do will depend onÂ*Â*MMUÂ*hardwareÂ*andÂ*OSÂ*which
supports MMU.

Can we make a guideline out of "the smaller the embedded system, the lower
the chances it will free resources that you leak"?

The point is C++ enables very small embedded systems by allowing programs to
clean up their resources the most efficient way - by releasing them in
destructors.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[REH]

dan2online wrote:

REH wrote:

dan2online wrote:

bo*@coolgroups.com wrote:
> it would be called before termination usually. i don't think
> termination typically releases all resources.

deleteall doesn't make sense because it doesn't control its behaviors
itself.
Modern OS' memory management can handle the release of memory resource
after terminating a process.

Modern hosted systems typically do so. Most modern embedded OSes do
not.

How embedded systems do will depend on MMU hardware and OS which
supports MMU.

That can be said for any OS.

REH

[Ivan Vecerina]

"Greg" <gr****@pacbell.net> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...
: bo*@coolgroups.com wrote:
: > why can't there be a deleteall keyword in c++ that
: > deletes all the memory previously allocated by
: > the new keyword?
: >
: > wouldn't this solve a lot of memory leak issues?
:
: If a program makes a series of memory allocations of equal size, then
: it can use a memory "pool" (such as boost's "pool" library) so that all
: of the allocations are fulfilled from the same block of reserved
: memory.
NB: there is no need for all objects in the pool to be of equal size.

: A program can then deallocate the entire pool and thereby free
: all of the pooled allocations at once. And indeed this approach is not
: only very efficient but also eliminates the chance that any of pooled
: allocations could leak.
:
: Unfortunately, relatively few applications actually have memory
: allocation patterns that could be implemented by a pool. Instead most
: programs create and delete objects in such a way that their life spans
: overlap; as a consequence, a typical program is constantly allocating
: and deallocating memory in various sizes and without adhering to any
: discernable pattern. Therefore there is never a point in most programs'
: execution in which all allocations up to that point could safely be
: freed at once. So while your idea certainly has merit, it is applicable
: only to relatively few programs.
Well: pooled allocations were an integral part of the Objective C
library on NeXT and MacOSX, and I think the feature is well taken
advantage of.
For example, a web browser could have one pool per rendered document.
Several apps could have one pool per document.

The Apache web server also heavily uses a memory pooling system,
they have some C libraries to support that.

Also, any function that allocates temporary data as part of its
processing could use a memory pool. Although, in C++, we tend to
use RAII and stack-based objects instead.
But another issue that needs to be addressed when using memory
pools (just as for garbage collection), is how to deal with
destructors that may have to be called (to release non-memory
resources). This typically requires some system to register
destructors, and ends up being more complex than classic RAII
with stack-based objects.
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
Brainbench MVP for C++ <> http://www.brainbench.com

[Michiel.Salters]

bo*@coolgroups.com wrote:

why can't there be a deleteall keyword in c++ that
deletes all the memory previously allocated by
the new keyword?

Because you can't get the order right.

HTH,
Michiel Salters