C++ Memory Management Innovation: GC Allocator
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>).
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
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.
AMDG Lance.Diduck@ubs.com wrote:
Steven Watanabe wrote:
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 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.
I understand that, and I can see that it may make lists run faster. /depending on the circumstances/. This is a useful idea and I would support a boost submission. I just wanted to point out that it is not a panacea for all memory problems. In Christ, Steven Watanabe
I agree you. But you know "GC Allocator" is OPTIONAL, not a MUST. I don't think it is all of C++ memory management. Regards, Shiwei Xu On Wed, Apr 23, 2008 at 2:44 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
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
Steven Watanabe wrote:
Basically, this works by imposing a hard upper bound on the lifetime of a group of objects, rather than dealing with them separately.
You can benefit from that without garbage collection, region allocation is enough. For example, allocate all nodes of a container in the same region and free that region in the container destructor.
AMDG Mathias Gaunard wrote:
Steven Watanabe wrote:
Basically, this works by imposing a hard upper bound on the lifetime of a group of objects, rather than dealing with them separately.
You can benefit from that without garbage collection, region allocation is enough. For example, allocate all nodes of a container in the same region and free that region in the container destructor.
Basically, what it does. Calling it "garbage collection" is misleading, IMO. In Christ, Steven Watanabe
shiwei xu wrote:
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
I only went through your article now. First, this is not Garbage Collection at all. As a matter of fact, it does not collect garbage at any time. Second, this is no innovation. This is a single-threaded stack allocator with private instances. Basically the fastest thing ever, indeed. Having multiple instances or regions by itself has many advantages, such as faster freeing, since you just have to free the whole regions without walking the tree of objects, for example. Stack allocation is simply the simplest algorithm and is extremely fast, yet - you waste lots of memory - you can't really give the memory back to the OS - you can only free in the reverse order you allocated in. For example, shared ownership is out of the question. Single-threaded allocators are cool as long as you use a private heap (or region) per thread, which of course has some cost in memory usage, especially with stacks, and that you will be able to free what you allocated with the same allocator you used to allocate it, that is to say in the same thread. That certainly does not fulfill any of the aims of the allocators and smart pointers you've been comparing it too, since your "innovation" has so many usage restrictions. For example, you compared it to smart pointers such as auto_ptr and shared_ptr (which are totally different and have different goals). auto_ptr being deprecated in C++0x in favor of unique_ptr, I will thus consider this one. An unique_ptr actually owns the pointed-to value. A shared_ptr co-owns the pointed-to value. That allows for example to put smart pointers into standard containers. When the smart pointer is removed from the container, it's also destructed and freed. You cannot do that with your solution (and it couldn't work with a stack anyway, containers don't expect LIFO usage restriction) The only thing your allocators can really do is dynamically allocating scope bound objects, just like when you declare variables on the stack. That certainly is a good thing and can solve most problems. Except your solution exposes pointers while it is not needed at all, and thus is fairly unsafe and inelegant. You should make your allocators not copyable, by the way. Also in theory it is suboptimal, since you could simply allocate on the execution stack; C++ however does not allow having objects of dynamic size, which could potentially be problematic because of the compile-time/run-time differentiation. Actually, in all of your examples, there is no valid reason why one should use dynamic memory allocation at all. Just declare those variables on the execution stack. Stack allocation also has an obvious issue: moving becomes as expensive as copying. Same for swapping, you need to move three times. Also, you claimed this { std::auto_ptr<MyObj> obj(new MyObj); std::auto_ptr<AnotherObj> obj2(new AnotherObj); ... // use obj and obj2 to do something. } was somewhat equivalent to this, MyObj* obj = new MyObj; AnotherObj* obj2 = new AnotherObj; try { ... // use obj and obj2 to do something. } catch (...) { delete obj; delete obj2; throw; } delete obj; delete obj2; Which is incorrect. A possible equivalence would be: { MyObj* obj = new MyObj; try { AnotherObj* obj2 = new AnotherObj; } catch(...} { delete obj; throw; } try { ... // use obj and obj2 to do something. } catch(...) { delete obj2; delete obj; throw; } delete obj2; delete obj; } This certainly demonstrates that scope-bound resource management (aka RAII) certainly reduces the annoyance in writing exception-safe code.
On Thu, Apr 24, 2008 at 8:29 AM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
shiwei xu wrote:
I only went through your article now.
First, this is not Garbage Collection at all. As a matter of fact, it does not collect garbage at any time.
Yes, it's not. Second, this is no innovation. This is a single-threaded stack allocator
with private instances. Basically the fastest thing ever, indeed.
I know that region allocators are no innovation. But: This (ScopeAlloc) is not a normal region allocator. All ScopeAlloc instances in the same thread share their freelist. This makes you can define a lot of ScopeAlloc instances (depends your needs). You even can define a ScopeAlloc instance for each allocation. Most allocators optimize allocating a lot of objects. If ONE allocator instance only allocates ONE object instance, they become slower than a normal new/delete allocation.
Stack allocation is simply the simplest algorithm and is extremely fast, yet - you waste lots of memory
Since you can define a lot of ScopeAlloc instances as you need, So It doesn't waste too much memory as normal region allocators. ScopeAlloc is useful. And I don't think it is all of C++ memory management. If you implement algorithms that are related to t (that is, how many time of the algorithm spent is unsure.), ScopeAlloc doesn't fit you directly.
- you can't really give the memory back to the OS
No. You can change limit of freelist size for each thread.
- you can only free in the reverse order you allocated in. For example, shared ownership is out of the question.
I don't think shared ownership is a requirement. It is only a memory management technique. Why don't Java programmers care such a question?
Also, you claimed this
{ std::auto_ptr<MyObj> obj(new MyObj); std::auto_ptr<AnotherObj> obj2(new AnotherObj); ... // use obj and obj2 to do something. }
was somewhat equivalent to this,
MyObj* obj = new MyObj; AnotherObj* obj2 = new AnotherObj; try { ... // use obj and obj2 to do something. } catch (...) { delete obj; delete obj2; throw; } delete obj; delete obj2;
Which is incorrect.
A possible equivalence would be:
{ MyObj* obj = new MyObj; try { AnotherObj* obj2 = new AnotherObj; } catch(...} { delete obj; throw; }
try { ... // use obj and obj2 to do something. } catch(...) { delete obj2; delete obj; throw; } delete obj2; delete obj; }
This certainly demonstrates that scope-bound resource management (aka RAII) certainly reduces the annoyance in writing exception-safe code.
Thanks for pointing out my mistakes. I revised my article now.
On Fri, Apr 25, 2008 at 5:08 AM, shiwei xu <xushiweizh@gmail.com> wrote:
I don't think shared ownership is a requirement. It is only a memory management technique. Why don't Java programmers care such a question?
They don't care because it is solved by the virtual machine. Dividing available memory into per-thread blocks and allocating from there avoids the need for a lock mechanism on each allocation. That does not mean that memory is not shared among threads, only that empty space is not shared. Memory is actually shared among threads. In Java shared ownership is not a requirement, it is a fact. Garbage collector does not consider which thread has what references, only that there are references to the object. David
Hello all, I add a new class: TlsBlockPool. And now you can define a ScopeAlloc instance without given parameters: ScopeAlloc alloc; It is same as: ScopeAlloc alloc(TlsBlockPool::instance()); --- class TlsBlockPool { public: TlsBlockPool() { init(); } ~TlsBlockPool() { term(); } static void init(); static void term(); static BlockPool& instance(); }; Note: TlsBlockPool::init() can be called more than once. each call to TlsBlockPool::init() must be balanced by a corresponding call to TlsBlockPool::term(). On Tue, Apr 22, 2008 at 8:58 PM, shiwei xu <xushiweizh@gmail.com> 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>).
I think the best thing to do is package up your allocators, and present them for a boost peer review. I have a strong interest in seeing more specialty allocators in C++ so I will be glad to help, and even donate some of my own, as I am sure others would to. Even bringing up HeapLayers to boost quality standards would be worthwhile. There are lots of ways of getting C++ classes and libraries to use specialty allocators, but hardly any allocators nor docs on why you might want to. Nor ways to actually write an allocator that could be used in a library. For some reason people attach a lot of unwarranted hype to GC and allocators -- esp to try and sell new "revolutionary" programming models. Sigh. All we really need is a library of allocators and ways to apply them without getting in trouble, and keep them out of sight when I don't care. That is all the innovation I want. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of shiwei xu Sent: Friday, April 25, 2008 5:01 AM To: boost@lists.boost.org Subject: Re: [boost] C++ Memory Management Innovation: GC Allocator Hello all, I add a new class: TlsBlockPool. And now you can define a ScopeAlloc instance without given parameters: ScopeAlloc alloc; It is same as: ScopeAlloc alloc(TlsBlockPool::instance()); --- class TlsBlockPool { public: TlsBlockPool() { init(); } ~TlsBlockPool() { term(); } static void init(); static void term(); static BlockPool& instance(); }; Note: TlsBlockPool::init() can be called more than once. each call to TlsBlockPool::init() must be balanced by a corresponding call to TlsBlockPool::term(). On Tue, Apr 22, 2008 at 8:58 PM, shiwei xu <xushiweizh@gmail.com> 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>).
_______________________________________________ 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.
Thank you for your good suggestion. On Fri, Apr 25, 2008 at 9:55 PM, <Lance.Diduck@ubs.com> wrote:
I think the best thing to do is package up your allocators, and present them for a boost peer review. I have a strong interest in seeing more specialty allocators in C++ so I will be glad to help, and even donate some of my own, as I am sure others would to. Even bringing up HeapLayers to boost quality standards would be worthwhile.
There are lots of ways of getting C++ classes and libraries to use specialty allocators, but hardly any allocators nor docs on why you might want to. Nor ways to actually write an allocator that could be used in a library. For some reason people attach a lot of unwarranted hype to GC and allocators -- esp to try and sell new "revolutionary" programming models. Sigh. All we really need is a library of allocators and ways to apply them without getting in trouble, and keep them out of sight when I don't care. That is all the innovation I want.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of shiwei xu Sent: Friday, April 25, 2008 5:01 AM To: boost@lists.boost.org Subject: Re: [boost] C++ Memory Management Innovation: GC Allocator
Hello all,
I add a new class: TlsBlockPool. And now you can define a ScopeAlloc instance without given parameters:
ScopeAlloc alloc;
It is same as:
ScopeAlloc alloc(TlsBlockPool::instance());
---
class TlsBlockPool { public: TlsBlockPool() { init(); } ~TlsBlockPool() { term(); }
static void init(); static void term();
static BlockPool& instance(); };
Note: TlsBlockPool::init() can be called more than once. each call to TlsBlockPool::init() must be balanced by a corresponding call to TlsBlockPool::term().
On Tue, Apr 22, 2008 at 8:58 PM, shiwei xu <xushiweizh@gmail.com> 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>).
_______________________________________________ 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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm glad to say that now "GC Allocator" is a sandbox library of boost. To gain the source code, please svn checkout http://svn.boost.org/svn/boost/sandbox/memory/. Examples: - simple_examples.cpp<http://svn.boost.org/svn/boost/sandbox/memory/libs/memory/test/memory/simple_examples.cpp> - stl_containers.cpp<http://svn.boost.org/svn/boost/sandbox/memory/libs/memory/test/memory/stl_containers.cpp> Welcome to give me some suggestions or report defects. I'm a beginner of boost development. And I don't know the process of boost peer review, and how a library is accepted (upgraded). Anyone can help me? On Fri, Apr 25, 2008 at 9:55 PM, <Lance.Diduck@ubs.com> wrote:
I think the best thing to do is package up your allocators, and present them for a boost peer review. I have a strong interest in seeing more specialty allocators in C++ so I will be glad to help, and even donate some of my own, as I am sure others would to. Even bringing up HeapLayers to boost quality standards would be worthwhile.
There are lots of ways of getting C++ classes and libraries to use specialty allocators, but hardly any allocators nor docs on why you might want to. Nor ways to actually write an allocator that could be used in a library. For some reason people attach a lot of unwarranted hype to GC and allocators -- esp to try and sell new "revolutionary" programming models. Sigh. All we really need is a library of allocators and ways to apply them without getting in trouble, and keep them out of sight when I don't care. That is all the innovation I want.
AMDG shiwei xu wrote:
I'm a beginner of boost development. And I don't know the process of boost peer review, and how a library is accepted (upgraded). Anyone can help me?
http://www.boost.org/development/submissions.html In Christ, Steven Watanabe
shiwei xu wrote:
I'm a beginner of boost development. And I don't know the process of boost peer review, and how a library is accepted (upgraded). Anyone can help me?
Steven wrote: http://www.boost.org/development/submissions.html
According to the submission process I've just reached the refinement stage with my GTL library. Some months back we discussed some of the implementation details of my library, including the unorthodox use of static cast from the unknown template parameter base type to the GTL derived type, which the group concluded was not safe according to the standard. Now that I have *finally* gotten permission to release the library to boost I was hoping that we could resume that discussion, come up with a workable alternative that satisfies everyone, and I can proceed to rewrite the library and "refine" it to the point that it is ready for formal review. I want to rewrite the library so that it will be acceptable for formal review. I was hoping for feedback on what changes you would like to see and whether you still believe pursuing eventual review is worthwhile, now that you can see the code and we can share specifics of the algorithms. Is everyone particularly busy right now preparing for an upcoming release or the boost conference in Aspen? Thanks, Luke
AMDG Simonson, Lucanus J wrote:
According to the submission process I've just reached the refinement stage with my GTL library. Some months back we discussed some of the implementation details of my library, including the unorthodox use of static cast from the unknown template parameter base type to the GTL derived type, which the group concluded was not safe according to the standard.
Now that I have *finally* gotten permission to release the library to boost I was hoping that we could resume that discussion, come up with a workable alternative that satisfies everyone, and I can proceed to rewrite the library and "refine" it to the point that it is ready for formal review.
I want to rewrite the library so that it will be acceptable for formal review. I was hoping for feedback on what changes you would like to see and whether you still believe pursuing eventual review is worthwhile, now that you can see the code and we can share specifics of the algorithms. Is everyone particularly busy right now preparing for an upcoming release or the boost conference in Aspen?
Here's my initial reaction from just looking at README. GTL Programming Conventions section. 2. Camel back capitalization instead of underscores. Why: This was to be consistent with internal policy and comfort of application developers. Changing it is an option. 3. Class names are capitalized, variable names are not. Why: Also consistent with the internal policy, it allows the reader to easily distinguish between type names and variable names. This should be changed for consistency with the rest of Boost. 4. No multiple inclusion protection except on gtl.h. Why: The multitude of header files can be included into different namespaces within the same application along with different typedef declarations for the Unit coordinate data type. This allows both 32 and 64 bit instantiation of the same algorithms (through multiple inclusion rather than template) and for custom data types that extend the built in integer with such things as overflow protection or INF,-INF,NAN special values and behaviors. I definitely prefer templates. At the very least, I want versions of the individual headers that are safe to include directly so that I don't have to include all of gtl. The unsafe versions of the headers should probably go in a separate directory. 8. No abbreviations in function names or class names. Very strongly agree. 13. Class consistency. If a class has a member function with a certain name, and it makes sense for another class to have a member function that could be named the same thing those names should be the same. Why: More intuitive. If a rectangle returns its 2d center point with the center() function, the rectangular prism should also return its 3d center point with a function named center. That way the learning curve is lowered for a developer who is becoming familiar with the API because everywhere he expects to find something he finds what he expects. This important for more than just ease of use. It is absolutely essential for generic code that needs to process rectangles and rectangular prisms polymorphically. There are many more code conventions; most of them trivial like what to do with whitespace in various circumstances and putting private declarations at the end of a class instead of the beginning. Such internal conventions are your affair as the implementor. I don't really care as long as the code is not unreadable. In Christ, Steven Watanabe
2. Camel back capitalization and class names capitalized. This should be changed for consistency with the rest of Boost.
This should be changed for consistency with the rest of Boost.
Clearly, and if an extensive rewrite is undertaken that will give me the opportunity to expunge capitalization.
4. No multiple inclusion protection except on gtl.h.
I definitely prefer templates. At the very least, I want versions of the individual headers that are safe to include directly so that I don't have to include all of gtl. The unsafe versions of the headers should probably go in a separate directory.
Joel also expressed the opinion that generic programming could allow the library to use floating point or integer arithmetic for coordinates. I remain skeptical of that. Also, because the coordinate type template parameter would go on practically everything, I fear it would become onerous to the user (and me.) This isn't CGAL where the whole point is to vary the coordinate data type to do research on numerical types. One thing I have considered is to cluster the header files into useful sub chunks, such as 2D only basic types, manhattan only algorithms, and 45-degree geometry algorithms and polygon types. This way the user can easily choose the subset of the library they are interested in by including the chunks they need. I suppose hiding the other headers would make sense once the documentation is sufficient.
13. Class consistency. If a class has a member function with a certain name, and it makes sense for another class to have a member function that could be named the same thing those names should be the same.
This important for more than just ease of use. It is absolutely essential for generic code that needs to process rectangles and rectangular prisms polymorphically.
I generally don't like to place a requirement on the template parameter that it provide specific functions, and instead prefer to go through adaptors, but I do see your point. In my work, I rarely have the freedom to modify a class in legacy code to conform to the requirements set forth in a generic library I want to use (or write.) One of the things I like about my current design is that it allows the function prototype to disambiguate for the compiler (and the user) what concepts the arguments are supposed to model. For example: template <class T> template <class T2> bool RectangleImpl<T>::contains(const RectangleImpl<T2>& rectangle); requires the T and T2 both provide RectangleInterface adaptors. (Obviously Impl is a mis-nomer and would be changed, but if I throw away the unorthodox design pattern then it doesn't much matter.) I also like that is isn't ambiguous to the user which rectangle is doing the containing vs: template <class T, class T2> bool constains(const T& containing_rectangle, const T& contained_rectangle); where the user will remember that there is a function that takes two parameters, but have to check the header file or documentation to remind themselves what the order means, since it is somewhat arbitrary. I would need to come up with a convention for ordering and be consistent. The other unfortunate thing that happens is overloading of free functions becomes problematic when types are generically polymorphic: template <class T, class T2> bool constains(const T& containing_prism, const T& contained_prism); because a prism should provide both rectangle and prism adaptors and two prisms should satisfy both functions the result in a compiler error even when enable_if is used. If we could induce it to compile, the user is left with no way to call the rectangle version on two prisms whereas with my library they would currently just do: bool containment = prism.mimicRectangle().contains(prism2); to view the prism as a rectangle to get access to the rectangle version of contains. The only solutions I can see are to embed the conceptual types into the function name such as rectangle_contains(a, b) and prism_contains(a, b) or better still, make them into namespaces: namespace rectangle { template <class T, class T2> bool constains(const T& containing_rectangle, const T& contained_rectangle); } namespace prism { template <class T, class T2> bool constains(const T& containing_prism, const T& contained_prism); } which is workable. I'm looking for the boost community's feedback on what approach to rewriting the library they find preferable, and a sort of final decision on whether the generic inheritance/static_cast/mimicry design-pattern I came up with is unacceptable for acceptance into boost, implying that a complete rewrite is truly needed. Is the requirement that code never do anything the standard doesn't guarantee is safe, or is the requirement that code be portable and functional? Are there other considerations that make what I'm doing objectionable? Thanks, Luke
AMDG Simonson, Lucanus J wrote:
Joel also expressed the opinion that generic programming could allow the library to use floating point or integer arithmetic for coordinates. I remain skeptical of that. Also, because the coordinate type template parameter would go on practically everything, I fear it would become onerous to the user (and me.)
How about giving a coordinate type template parameter to everything, but also providing typedefs for all the specializations with the default coordinate type?
I generally don't like to place a requirement on the template parameter that it provide specific functions, and instead prefer to go through adaptors, but I do see your point. In my work, I rarely have the freedom to modify a class in legacy code to conform to the requirements set forth in a generic library I want to use (or write.)
One of the things I like about my current design is that it allows the function prototype to disambiguate for the compiler (and the user) what concepts the arguments are supposed to model. For example: template <class T> template <class T2> bool RectangleImpl<T>::contains(const RectangleImpl<T2>& rectangle); requires the T and T2 both provide RectangleInterface adaptors. (Obviously Impl is a mis-nomer and would be changed, but if I throw away the unorthodox design pattern then it doesn't much matter.) I also like that is isn't ambiguous to the user which rectangle is doing the containing vs: template <class T, class T2> bool constains(const T& containing_rectangle, const T& contained_rectangle); where the user will remember that there is a function that takes two parameters, but have to check the header file or documentation to remind themselves what the order means, since it is somewhat arbitrary. I would need to come up with a convention for ordering and be consistent.
If I need another function that you have not provided, I would need to implement it as a non-member... Another disadvantage is that if I only need one piece of the rectangle functionality, I still need to include everything because it's all in a single class.
The other unfortunate thing that happens is overloading of free functions becomes problematic when types are generically polymorphic: template <class T, class T2> bool constains(const T& containing_prism, const T& contained_prism); because a prism should provide both rectangle and prism adaptors and two prisms should satisfy both functions the result in a compiler error even when enable_if is used.
I'm not entirely convinced that it should be possible to treat a prism as a rectangle without an explicit conversion of some kind. contains for a prism should treat it as as prism. The general solution to this kind of problem is tag dispatching.
If we could induce it to compile, the user is left with no way to call the rectangle version on two prisms whereas with my library they would currently just do: bool containment = prism.mimicRectangle().contains(prism2); to view the prism as a rectangle to get access to the rectangle version of contains.
How important is it to not make a copy of the prism? Alternately, how important is it to be able to copy the whole prism while treating it as a rectangle?
The only solutions I can see are to embed the conceptual types into the function name such as rectangle_contains(a, b) and prism_contains(a, b) or better still, make them into namespaces: namespace rectangle { template <class T, class T2> bool constains(const T& containing_rectangle, const T& contained_rectangle); } namespace prism { template <class T, class T2> bool constains(const T& containing_prism, const T& contained_prism); } which is workable.
That doesn't work well because it ought to be possible to write code that deals with either a rectangle or a prism, as long as it only relies on the common properties--such as contains.
I'm looking for the boost community's feedback on what approach to rewriting the library they find preferable, and a sort of final decision on whether the generic inheritance/static_cast/mimicry design-pattern I came up with is unacceptable for acceptance into boost, implying that a complete rewrite is truly needed. Is the requirement that code never do anything the standard doesn't guarantee is safe, or is the requirement that code be portable and functional?
The absolute minimum requirement is that it should work on several platforms. I think that to the extent that is possible, code should only rely on what the standard guarantees. I believe that if you rely only on non-member functions and reinterpret_cast back and forth, it is possible to make the mimicry legal.
Are there other considerations that make what I'm doing objectionable?
In Christ, Steven Watanabe
I'm not entirely convinced that it should be possible to treat a prism as a rectangle without an explicit conversion of some kind. contains for a prism should treat it as as prism. The general solution to this kind of problem is tag dispatching.
Yes, I can see how defining a prism_tag and rectangle_tag in traits classes would allow template<class T, class T2> bool contains (const T& r1, const T& r2) { return contains_dispatch(r1, r2, traits<T>::type_tag); } to disambiguate through the added layer of abstraction.
How important is it to not make a copy of the prism? Alternately, how important is it to be able to copy the whole prism while treating it as a rectangle?
It is important for performance considerations, but also becomes increasingly important as the size of the object increases. For a polygon which may have anywhere from 4 to 4 million vertices requiring copy conversion simply to satisfy type requirements when viewing it as a polygon with holes vs. polygon without holes the issue is cast in a different light. It is somewhat less important to copy the whole prism when viewing it as a rectangle, but I do use this feature of the design pattern, for instance, to generically treat polygons and polygons with holes as polygons and allow holes to copy through automatically. Otherwise I would need two functions is places where I now have only one.
I'm looking for the boost community's feedback on what approach to rewriting the library they find preferable, and a sort of final decision on whether the generic inheritance/static_cast/mimicry design-pattern I came up with is unacceptable for acceptance into boost, implying that a complete rewrite is truly needed. Is the requirement that code never do anything the standard doesn't guarantee is safe, or is the requirement that code be portable and functional?
The absolute minimum requirement is that it should work on several platforms. I think that to the extent that is possible, code should only rely on what the standard guarantees. I believe that if you rely only on non-member functions and reinterpret_cast back and forth, it is possible to make the mimicry legal.
Can you explain that last part about relying on non-member functions and reinterpret_cast making it possible to be legal? Do you mean what I am already doing with non-member functions providing the interface? What exactly to you mean by legal? Do you mean legal syntax according to the compiler, or standard compliant syntax? The code compiles (and runs correctly) with gcc 3.2.2, 3.4.2, 4.2.2 and 4.3.0, icc 9.0 and 10.0, VC7 and VC8 and runs in ia32, EMT64 and itanium machines in Windows and linux. Other compilers, architectures and OS's should be for the most part OK, but I lack access to them to check. Is this is sufficient to meet the minimum requirement for portability? I would be very happy to keep the broader design as is and focus on naming conventions and more minor improvements such as using output iterators for results of algorithms instead of the less generic method of passing std container by reference. I also have a lot of work to do to bring the documentation up to date. Luke
Steven Watanabe wrote:
AMDG
Simonson, Lucanus J wrote:
Joel also expressed the opinion that generic programming could allow the library to use floating point or integer arithmetic for coordinates. I remain skeptical of that. Also, because the coordinate type template parameter would go on practically everything, I fear it would become onerous to the user (and me.)
How about giving a coordinate type template parameter to everything, but also providing typedefs for all the specializations with the default coordinate type?
It's not just the coordinates. The essence of GP is that you can be able to use class X and class Y from different libraries in your library as long as they both model a certain concept, C. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Fixed. See http://svn.boost.org/trac/boost/ticket/1879 On Wed, Apr 30, 2008 at 9:33 AM, shiwei xu <xushiweizh@gmail.com> wrote:
Thank Steven. I will fix it.
On Wed, Apr 30, 2008 at 5:09 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
Don't use reserved identifiers. (Any name containing a double underscore is reserved).
In Christ, Steven Watanabe
AMDG shiwei xu wrote:
Fixed. See http://svn.boost.org/trac/boost/ticket/1879
I should have given a more complete description of reserved names: * Any identifier containing a double underscore. * Any identifier beginning with an underscore and a capital letter. * All names beginning with an underscore in the global namespace. In Christ, Steven Watanabe
Fixed. See http://svn.boost.org/trac/boost/changeset/44938. And it seems code style of SGI STL (I liked it before) has many conflicts with reserved names. On Wed, Apr 30, 2008 at 10:16 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
shiwei xu wrote:
Fixed. See http://svn.boost.org/trac/boost/ticket/1879
I should have given a more complete description of reserved names:
* Any identifier containing a double underscore. * Any identifier beginning with an underscore and a capital letter. * All names beginning with an underscore in the global namespace.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG shiwei xu wrote:
Fixed. See http://svn.boost.org/trac/boost/changeset/44938. And it seems code style of SGI STL (I liked it before) has many conflicts with reserved names.
You missed a few. st;_alloc::_Charalloc, _Getalloc at least. The STL can use these conventions because the STL is part of the standard library. That's what the names are reserved for. In Christ, Steven Watanabe
Yes, I forgot _Getalloc (see http://svn.boost.org/trac/boost/changeset/44940). _Charalloc is needed by STL of VC++ 6.0. Most classes of SGI STL is part of the standard library. But some are not. For example, std::rope, std::hash_map, etc. On Wed, Apr 30, 2008 at 11:57 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
shiwei xu wrote:
Fixed. See http://svn.boost.org/trac/boost/changeset/44938. And it seems code style of SGI STL (I liked it before) has many conflicts with reserved names.
You missed a few.
st;_alloc::_Charalloc, _Getalloc
at least.
The STL can use these conventions because the STL is part of the standard library. That's what the names are reserved for.
"shiwei xu" <xushiweizh@gmail.com> wrote:
Welcome to give me some suggestions or report defects.
I'm a beginner of boost development. And I don't know the process of boost peer review, and how a library is accepted (upgraded). Anyone can help me?
I don't think that the things that you are putting into Trac are "bugs". They seem to be "announcements". http://svn.boost.org/trac/boost/ticket/1879 http://svn.boost.org/trac/boost/ticket/1885 -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
AMDG shiwei xu wrote:
I'm glad to say that now "GC Allocator" is a sandbox library of boost.
To gain the source code, please svn checkout http://svn.boost.org/svn/boost/sandbox/memory/.
Since, stl_alloc holds a pointer to the real allocator, shouldn't stl_alloc<void, ...> also have such a pointer and the appropriate constructors? You should partially specialize: template<class Alloc> class stl_alloc<void, Alloc> { ... }; Also, the typedefs and rebind template of stl_alloc<void, ...> should be public. I would also ask that everything go in namespace boost::memory, rather than directly in namespace boost. My personal preference would be to spell out stl_allocator entirely rather than abbreviating it to stl_alloc. In Christ, Steven Watanabe
On Wed, Apr 30, 2008 at 10:25 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
Since, stl_alloc holds a pointer to the real allocator, shouldn't stl_alloc<void, ...> also have such a pointer and the appropriate constructors?
You should partially specialize: template<class Alloc> class stl_alloc<void, Alloc> { ... };
Also, the typedefs and rebind template of stl_alloc<void, ...> should be public.
My personal preference would be to spell out stl_allocator entirely rather than abbreviating it to stl_alloc.
In Christ, Steven Watanabe
AMDG shiwei xu wrote:
On Wed, Apr 30, 2008 at 10:25 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
Since, stl_alloc holds a pointer to the real allocator, shouldn't stl_alloc<void, ...> also have such a pointer and the appropriate constructors?
??
boost/config.hpp provides BOOST_NO_PARTIAL_SPECIAILIZATION Your macros, should all be prefixed with BOOST_MEMORY to avoid conflicts. In Christ, Steven Watanabe
On Wed, Apr 30, 2008 at 12:16 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
boost/config.hpp provides BOOST_NO_PARTIAL_SPECIAILIZATION
I know that. But boost can't be complied by VC++ 6.0. So I don't include any boost header files.
Your macros, should all be prefixed with BOOST_MEMORY to avoid conflicts.
Of course. I will do this when I have time.
Sorry. I made a typo. It is http://svn.boost.org/trac/boost/changeset/4439, NOT http://svn.boost.org/trac/boost/changeset/4493. On Wed, Apr 30, 2008 at 12:27 PM, shiwei xu <xushiweizh@gmail.com> wrote:
On Wed, Apr 30, 2008 at 12:16 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
Sorry! It is http://svn.boost.org/trac/boost/changeset/44939. On Wed, Apr 30, 2008 at 12:33 PM, shiwei xu <xushiweizh@gmail.com> wrote:
Sorry. I made a typo. It is http://svn.boost.org/trac/boost/changeset/4439, NOT http://svn.boost.org/trac/boost/changeset/4493.
On Wed, Apr 30, 2008 at 12:27 PM, shiwei xu <xushiweizh@gmail.com> wrote:
On Wed, Apr 30, 2008 at 12:16 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
support BOOST_NO_PARTIAL_SPECIAILIZATION now. See http://svn.boost.org/trac/boost/changeset/44945. On Wed, Apr 30, 2008 at 12:27 PM, shiwei xu <xushiweizh@gmail.com> wrote:
On Wed, Apr 30, 2008 at 12:16 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
boost/config.hpp provides BOOST_NO_PARTIAL_SPECIAILIZATION
I know that. But boost can't be complied by VC++ 6.0. So I don't include any boost header files.
Your macros, should all be prefixed with BOOST_MEMORY to avoid conflicts.
Of course. I will do this when I have time.
[44948]: BOOST_MEMORY_NO_PARTIAL_SPECIAILIZATION On Wed, Apr 30, 2008 at 12:46 PM, shiwei xu <xushiweizh@gmail.com> wrote:
support BOOST_NO_PARTIAL_SPECIAILIZATION now. See http://svn.boost.org/trac/boost/changeset/44945.
On Wed, Apr 30, 2008 at 12:27 PM, shiwei xu <xushiweizh@gmail.com> wrote:
On Wed, Apr 30, 2008 at 12:16 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
boost/config.hpp provides BOOST_NO_PARTIAL_SPECIAILIZATION
I know that. But boost can't be complied by VC++ 6.0. So I don't include any boost header files.
Your macros, should all be prefixed with BOOST_MEMORY to avoid conflicts.
Of course. I will do this when I have time.
shiwei xu wrote:
[44948]: BOOST_MEMORY_NO_PARTIAL_SPECIAILIZATION
Can we please stop sending these short "notifications" to the list. The people whom are interested in knowing about such minutia already subscribe to the trac and/or svn mail notifications. The thousands of people on the dev list would be most appreciative of reduced traffic ;-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
I need some suggestions. I put some stuffs (eg. threadmodel, winapi, etc) that are not memory components into boost::memory namespace. Now I move them into boost::detail namespace. Is there a better choice? (See http://svn.boost.org/trac/boost/changeset/45165) 1. move threadmodel, winapi to boost::detail 2. add log, debug, performance_counter to boost::detail On Thu, May 1, 2008 at 8:20 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
shiwei xu wrote:
I know that. But boost can't be complied by VC++ 6.0. So I don't include any boost header files.
Some headers (including config.hpp) still work on VC++ 6.0
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Apr 30, 2008 at 10:25 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
I would also ask that everything go in namespace boost::memory, rather than directly in namespace boost.
In Christ, Steven Watanabe
Update: 1. macros are all prefixed with BOOST_MEMORY to avoid conflicts. 2. everything goes into namespace boost::memory, rather than directly in namespace boost.
Hello all, Recently I write a new class named "boost::gc_alloc" (see http://svn.boost.org/trac/boost/browser/sandbox/memory/boost/memory/gc_alloc...). Here is its specification: class gc_alloc { public: gc_alloc(); // same as: gc_alloc(tls_block_pool::instance()); gc_alloc(block_pool& pool); // initialize by given a pool instance gc_alloc(gc_alloc& a); // initialize by given a indirect pool instance ~gc_alloc(); // clear void* allocate(size_t cb); // allocate memory without cleanup function void* allocate(size_t cb, destructor_t fun); // allocate memory with cleanup function void deallocate(void* p, size_t cb); template <class Type> void destroy(Type* obj); template <class Type> void destroyArray(Type* array, szie_t count); void clear(); // cleanup and release all memory allocated by the allocator void swap(gc_alloc& o); // swap two instances }; Comparing with boost::scope_alloc ( http://svn.boost.org/trac/boost/browser/sandbox/memory/boost/memory/scoped_a...), It append these methods: { void deallocate(void* p, size_t cb); template <class Type> void destroy(Type* obj); template <class Type> void destroyArray(Type* array, szie_t count); } Yes, it allows you to delete objects manually. But this is OPTIONAL, not a MUST. You don't need to delete objects, if you don't want or forget to do. However, I have some additional NOTES: 1. boost::auto_alloc (its old name is "AutoFreeAlloc") and boost::scoped_alloc (its old name is "ScopeAlloc") are implemented for four years (from 2004). And they are widely used and tested. They are proved in practice. 2. boost::gc_alloc was implemented yesterday. It is complexer than boost::auto_alloc and boost::scoped_alloc. Is it useful? Maybe, but it needs to be proved itself. If you are interested in it, refer the source code: http://svn.boost.org/trac/boost/browser/sandbox/memory/boost/memory/gc_alloc... On Fri, Apr 25, 2008 at 9:55 PM, <Lance.Diduck@ubs.com> wrote:
I think the best thing to do is package up your allocators, and present them for a boost peer review. I have a strong interest in seeing more specialty allocators in C++ so I will be glad to help, and even donate some of my own, as I am sure others would to. Even bringing up HeapLayers to boost quality standards would be worthwhile.
There are lots of ways of getting C++ classes and libraries to use specialty allocators, but hardly any allocators nor docs on why you might want to. Nor ways to actually write an allocator that could be used in a library. For some reason people attach a lot of unwarranted hype to GC and allocators -- esp to try and sell new "revolutionary" programming models. Sigh. All we really need is a library of allocators and ways to apply them without getting in trouble, and keep them out of sight when I don't care. That is all the innovation I want.
Documentation: http://cpp.winxgui.com/boost-gc-alloc. On Wed, Apr 30, 2008 at 9:47 AM, shiwei xu <xushiweizh@gmail.com> wrote:
Hello all,
Recently I write a new class named "boost::gc_alloc" (see http://svn.boost.org/trac/boost/browser/sandbox/memory/boost/memory/gc_alloc...). Here is its specification:
class gc_alloc { public: gc_alloc(); // same as: gc_alloc(tls_block_pool::instance()); gc_alloc(block_pool& pool); // initialize by given a pool instance gc_alloc(gc_alloc& a); // initialize by given a indirect pool instance ~gc_alloc(); // clear
void* allocate(size_t cb); // allocate memory without cleanup function void* allocate(size_t cb, destructor_t fun); // allocate memory with cleanup function
void deallocate(void* p, size_t cb);
template <class Type> void destroy(Type* obj);
template <class Type> void destroyArray(Type* array, szie_t count);
void clear(); // cleanup and release all memory allocated by the allocator
void swap(gc_alloc& o); // swap two instances };
Comparing with boost::scope_alloc ( http://svn.boost.org/trac/boost/browser/sandbox/memory/boost/memory/scoped_a...), It appends these methods:
{ void deallocate(void* p, size_t cb);
template <class Type> void destroy(Type* obj);
template <class Type> void destroyArray(Type* array, szie_t count); }
Yes, it allows you to delete objects manually. But this is OPTIONAL, not a MUST. You don't need to delete objects, if you don't want or forget to do.
However, I have some additional NOTES:
1. boost::auto_alloc (its old name is "AutoFreeAlloc") and boost::scoped_alloc (its old name is "ScopeAlloc") had been implemented for four years (from 2004). And they are widely used and tested. They are proved in practice.
2. boost::gc_alloc was implemented yesterday (just a pre-alpha version). It is complexer than boost::auto_alloc and boost::scoped_alloc. Is it useful? Maybe, but it needs to be proved itself.
If you are interested in it, refer the source code: http://svn.boost.org/trac/boost/browser/sandbox/memory/boost/memory/gc_alloc...
participants (9)
-
David Rodríguez Ibeas -
Joel de Guzman -
Lance.Diduck＠ubs.com -
Marshall Clow -
Mathias Gaunard -
Rene Rivera -
shiwei xu -
Simonson, Lucanus J -
Steven Watanabe