As I understand it, if I have a List that exists for the duration of
Steven Watanabe wrote: the program, and I am often
adding and removing elements, then the memory for the elements will just build up until the List is destroyed. In fact, with some implementations of std::list will support this behavior with a suitable allocator. See pg 31 of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2486.pdf for an example. So the idea has been around for some time -- an allocator could allocate live objects and not just raw memory.
One thing that has always struck me, was that C++ from day one had the ability to override allocators everywhere in all sort of interesting ways, but there remains to this day no real understanding of just what you can do with them. Techniques like shiwei xu illustrated should be commonplace. However, just about all attempts at allocator writing are "malloc replacements." In other words, if it isn't a drop in replacement for malloc, the preception is that it just isn't a serious allocator. The fact is that the vast majority of C++ use cases do not require contiguous memory allocations of arbitrary sizes determined at runtime, which drastically simplies allocator writing. This enable smart programmers to make phenomenal performance gains, and keeps C++ in business. Given that the lockfree library I am interesting in collaborating on heavily relies on specialty allocators, I would also be interested in collborating on a expanded boost allocator library. Lance -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Tuesday, April 22, 2008 2:45 PM To: boost@lists.boost.org Subject: Re: [boost] C++ Memory Management Innovation: GC Allocator AMDG shiwei xu wrote:
Most of the C++ programmers do not benefit from "Garbage Collection" technique (GC). They are sick of deleting objects but have to do this. There are some C/C++ memory GC implementations, but they are complex and are not widely used.
I am going to introduce a new memory management technique named "GC Allocator". "GC Allocator" isn't an implementation, but a concept. Now, we have two "GC Allocator" implementations, named "AutoFreeAlloc" and "ScopeAlloc".
This article consists of three parts:
1. What is GC Allocator? 2. GC Allocator implementations: ScopeAlloc and AutoFreeAlloc 3. Applications based on GC Allocator For more information, see http://www.codeproject.com/KB/cpp/gc-allocator.aspx
To obtain a copy of this paper in pdf format click here<http://xushiwei.com/local--files/gc-allocator/GCAllocator.pdf>(or from google code <http://code.google.com/p/stdext/downloads/list>).
If I understand correctly, your GC allocators delete all allocated blocks when the allocator itself is destroyed, or can be explicitly forced to free everything. Basically, this works by imposing a hard upper bound on the lifetime of a group of objects, rather than dealing with them separately. I think that this is useful in some contexts. (Enough that I implemented a simple version about a year ago). However, it is not always applicable. Consider your List template. As I understand it, if I have a List that exists for the duration of the program, and I am often adding and removing elements, then the memory for the elements will just build up until the List is destroyed. In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mails are not encrypted and cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.