«

On Feb 28, 6:17*pm, jacob navia <ja...@spamsink.net> wrote:
> Le 28/02/11 16:46, Leigh Johnston a crit :
>
> >> There is no point in deleting anything since it is the main() function
> >> and the OS will cleanup stuff anyway.
>
> > Here are three adjectives that describe you as a programmer:
>
> > 1) cowboy
> > 2) sloppy
> > 3) slapdash
>
> > I will let you choose which one you want.
>
> > /Leigh
>
> There are several memory management and memory use strategies. I have
> enumerated the most used ones in my tutorial (about the C language,
> not the C++ language) available here:
>
> http://www.cs.virginia.edu/~lcc-win32/
>
> Some of the principles there apply here, specifically the 'Never free()'
> strategy.
>
> This strategy avoids all problems associated with free() (in C++
> "delete") by never freeing or deleting any memory and allowing the
> OS to clean up everything much more efficiently.
>
> This strategy is indicated for transient programs, that allocate a
> lot of memory, and almost never release anything until they exit.

Yes, but this fails when:

* code is run on an OS where closing a process does not free said
memory (yes, that exists, and you seem to presume it does not)
* total heap needed surpasses total heap available, but peak heap does
not; that can happen e.g. when
** code is changed
** data set got bigger
** code is run in an environment where available heap is reduced by
administrative means
* objects not deleted hold otherwise scarce resources (e.g. DB
connection etc handles). By the way, are you sure that OS cleans up
such resources? I sure am not, OS knows nothing of such things
* code is taken out to be used in a different context (e.g. something
long-running)

It's bad advice, __especially__ when given to students (your link is
coming from an "edu" domain). It's exactly cowboy style, as evoked:
play fast and loose, damn the consequences. No thanks. How about at
least starting and ending the lecture on this strategy with "don't do
this at home"?

Goran.

Goran <> writes:
>> This strategy avoids all problems associated with free() (in C++
>> "delete") by never freeing or deleting any memory and allowing the
>> OS to clean up everything much more efficiently.
>>
>> This strategy is indicated for transient programs, that allocate a
>> lot of memory, and almost never release anything until they exit.
>
> Yes, but this fails when:
>
> * code is run on an OS where closing a process does not free said
> memory (yes, that exists, and you seem to presume it does not)
> * total heap needed surpasses total heap available, but peak heap does
> not; that can happen e.g. when
> ** code is changed
> ** data set got bigger
> ** code is run in an environment where available heap is reduced by
> administrative means
> * objects not deleted hold otherwise scarce resources (e.g. DB
> connection etc handles). By the way, are you sure that OS cleans up
> such resources? I sure am not, OS knows nothing of such things
> * code is taken out to be used in a different context (e.g. something
> long-running)

Another issue is debugging -- one very good way to identify memory leaks
is to use a tool like valgrind, but the presence of "harmless"
intentional leaks make this more difficult.

-Miles

--
Saa, shall we dance? (from a dance-class advertisement)

On Mar 3, 12:28*pm, Miles Bader <mi...@gnu.org> wrote:
> Goran <goran.pu...@gmail.com> writes:
> >> This strategy avoids all problems associated with free() (in C++
> >> "delete") by never freeing or deleting any memory and allowing the
> >> OS to clean up everything much more efficiently.
>
> >> This strategy is indicated for transient programs, that allocate a
> >> lot of memory, and almost never release anything until they exit.
>
> > Yes, but this fails when:
>
> > * code is run on an OS where closing a process does not free said
> > memory (yes, that exists, and you seem to presume it does not)
> > * total heap needed surpasses total heap available, but peak heap does
> > not; that can happen e.g. when
> > * ** code is changed
> > * ** data set got bigger
> > * ** code is run in an environment where available heap is reduced by
> > administrative means
> > * objects not deleted hold otherwise scarce resources (e.g. DB
> > connection etc handles). By the way, are you sure that OS cleans up
> > such resources? I sure am not, OS knows nothing of such things
> > * code is taken out to be used in a different context (e.g. something
> > long-running)
>
> Another issue is debugging -- one very good way to identify memory leaks
> is to use a tool like valgrind, but the presence of "harmless"
> intentional leaks make this more difficult.

I have also used to leak absolutely everything for performance reasons
of a little program. The code however leaked nothing in debug version.
The whole trick was to make free()/operator delete() to do nothing in
release version to gain such effect.

marusja marusjake <> writes:
>> Another issue is debugging -- one very good way to identify memory leaks
>> is to use a tool like valgrind, but the presence of "harmless"
>> intentional leaks make this more difficult.
>
> I have also used to leak absolutely everything for performance reasons
> of a little program. The code however leaked nothing in debug version.
> The whole trick was to make free()/operator delete() to do nothing in
> release version to gain such effect.

Sure, one can do that, and if it's OK to make _every_ allocation leak,
then it might even be really easy...

In a more typical program, where one can't just leak everything, another
way to gain performance by intentional "leaking" of certain allocations
is to make those allocations from a special arena that's later freed in
bulk at appropriate times. So the memory _is_ eventually freed, just
not using the same granularity as the allocations. [And allocations can
be much faster too, e.g. just an inlined bounds-check and
pointer-increment.]

-Miles

--
Advice, n. The smallest current coin.

Le 04/03/11 04:44, Miles Bader a écrit :
> marusja marusjake<> writes:
>>> Another issue is debugging -- one very good way to identify memory leaks
>>> is to use a tool like valgrind, but the presence of "harmless"
>>> intentional leaks make this more difficult.
>>
>> I have also used to leak absolutely everything for performance reasons
>> of a little program. The code however leaked nothing in debug version.
>> The whole trick was to make free()/operator delete() to do nothing in
>> release version to gain such effect.
>
> Sure, one can do that, and if it's OK to make _every_ allocation leak,
> then it might even be really easy...
>
> In a more typical program, where one can't just leak everything, another
> way to gain performance by intentional "leaking" of certain allocations
> is to make those allocations from a special arena that's later freed in
> bulk at appropriate times. So the memory _is_ eventually freed, just
> not using the same granularity as the allocations. [And allocations can
> be much faster too, e.g. just an inlined bounds-check and
> pointer-increment.]
>
> -Miles
>
Yes, you have rediscovered pool managed memory allocation strategy. In
the tutorial I mentioned I described that strategy, and why it is easy
to pass from my "never free" strategy to a pool managed strategy.

Suppose that you got a program written in the (much criticized)
"leaking" strategy. You absolutely do NOT want to have leaks in your
program.

Thye solution is to allocate a pool for the concerned software,
and after it is finished to free the allocated pool in a single
call to free().

This remains efficient but it is compatible with a non-transient
program.

Other ways of "upgrading" a leaking program without fixing all
leaks is the garbage collector. Boehm has provided one for C
and C++. I understand that in C++ is more difficult to integrate it
but it can be really useful in plain C.

On Mar 4, 10:49*am, jacob navia <ja...@spamsink.net> wrote:
> Le 04/03/11 04:44, Miles Bader a crit :
>

>
> > In a more typical program, where one can't just leak everything, another
> > way to gain performance by intentional "leaking" of certain allocations
> > is to make those allocations from a special arena that's later freed in
> > bulk at appropriate times. *So the memory _is_ eventually freed, just
> > not using the same granularity as the allocations. *[And allocations can
> > be much faster too, e.g. just an inlined bounds-check and
> > pointer-increment.]
>
> Yes, you have rediscovered pool managed memory allocation strategy. In
> the tutorial I mentioned I described that strategy, and why it is easy
> to pass from my "never free" strategy to a pool managed strategy.
>

He actually gives that more careful explanation, as you go on doing
now, but didn't before.
Saying only "it's ok to skip deallocation" to a c++ student is
dangerous, even more so as you said "skip delete".

itaj

Le 04/03/11 15:08, itaj sherman a écrit :
> Saying only "it's ok to skip deallocation" to a c++ student is
> dangerous, even more so as you said "skip delete".
>
> itaj

Yes, you are right. I should have qualified better my statement.