Re: [boost] request for interest in a garbage collection library

Subject: Re: [boost] request for interest in a garbage collection library
From: Achilleas Margaritis (axilmar_at_[hidden])
Date: 2009-04-24 10:07:38

"Sid Sacek" <ssacek_at_[hidden]> wrote in message 
news:85E89441B9FBAB4489AE98D0001A7FE902526F95_at_SW24MAIL.securewatch24.local...
> My 2-cents.
>
>
> My first penny:
> Although the thought of having memory-leaks become a concept of the past
> is pretty nifty to me by using a memory-managing programming language,
> the "garbage collectors" of today make no promises to the programmer
> about any other type of resource. Brute-force programming and RAII are
> our current protections against mismanaging these other resource types.
> If we end up using RAII in our apps because object destructors must be
> called in deterministic fashion, then the advantage of GC almost becomes
> irrelevant.

Except if you have cycles.

>
>
> My second penny:
> There is one feature of an advanced GC that is super-beneficial to me
> however. The C++/CLI garbage collector has the ability to perform data
> compaction. Basically, when the GC activates, it removes the unused
> objects, and then fills in the vacated memory gaps with existing live
> objects, thus compressing memory usage. This ability can help you create
> applications that can run 24/7 ( basically forever ) without having any
> memory fragmentation. This to me is a better feature of the garbage
> collector. I personally don't know how the CLI engine performs this neat
> trick but it works, and the code generated by the compiler is crisp,
> compact and efficient. I don't know if there's a C++ based GC library
> out there that does this sort of thing.

No need for compaction, if you use pools.

>
>
> Ok, one final cent:
> The GC's provided within programming languages are much more compelling
> than library-based ones. For me, the way they can be improved is by
> following these simple rules:
>
> 1) Eliminate all object memory that is no longer referenced ( standard
> feature )
> 2) Have destructor functions be called in a deterministic manner (
> finalizers optional )
> 3) Have data compaction within the memory manager
> 4) Have the ability to manage other system resources as well
> 5) Provide the ability to manually manage specific resources ( for RTOS
> )
>
> The "Garbage Collector" should be ideally renamed to "Resource Manager".
> Until these features mentioned above are given to me by a single
> language infrastructure, I believe I will be forced to resort to RAII as
> my most-trusted tool.

Well, in some situations even a library gc solution is better than nothing.

__________ Information from ESET Smart Security, version of virus signature database 4033 (20090424) __________

The message was checked by ESET Smart Security.

http://www.eset.com