When is it time for a 1.0 feature freeze?

Helmut Leitner leitner at wikiservice.at
Fri Sep 8 01:28:09 PDT 2006

Walter Bright wrote:
> Serg Kovrov wrote:
>> But that not worst part. Although I'm personally from C++ camp and I 
>> get used to GC. and see it as good thing. But, there is one big BUT! 
>> Currently GC do not return memory to OS, and that thing even I can't 
>> subdue. The only reason I choose 'native' (as opposite to VM) 
>> programming language is effective resource usage. I hate Java/.net gui 
>> applications because their memory consuming. I really appreciate 
>> developers that choose c/c++ to write small, memory effective, but yet 
>> feature-reach applications like FileZilla Server, uTorrent or Miranda IM.
>> Most desktop applications (like text editors, news readers, web 
>> browsers, etc) must coexist with each other. That is, to use memory 
>> wisely and give it back if it not needed anymore. This 'upper water 
>> mark' approach in GC is just not acceptable.
> 1) Few programmers realize that C/C++'s malloc/free/new/delete *never* 
> (and I emphasize NEVER) return memory to the operating system. All 
> free/delete do is return memory to the memory pool managed by the 
> runtime library, not the operating system. In order to actually return 
> memory to the operating system, one has to write their own memory 
> management code, which is a significant (and necessarily non-portable) 
> effort. Hardly anyone does that.

I think this doesn't give a complete picture of the situation.

There is the need to give memory back to the OS (e. g. if a user
has just stopped working with a couple of 100 MB pictures).

Operating systems sometimes do offer mechanisms for this (e. g.
Windows has the GlobalAlloc/GlobalReAlloc/GlobalFree set of functions).
If you use a wrapper for memory allocation it is very easy to use
this efficiently (pure or mixed with malloc/realloc/free).

More information about the Digitalmars-d mailing list