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