-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of DUPUIS Etienne Sent: Monday, June 11, 2012 6:46 AM To: boost@lists.boost.org Cc: DUPUIS Etienne Subject: Re: [boost] [pool] Improvements to boost.pool
Now that changes have been made to boost::pool in the sandbox, what is the next step to get them approved/amended/rejected ?
Regards, Étienne
-----Message d'origine----- De : DUPUIS Etienne Envoyé : mercredi 16 mai 2012 12:43 À : boost@lists.boost.org Objet : [pool] Improvements to boost.pool
Greetings,
In the boost sandbox, under the /pool folder, I have committed a few small improvements and a few fixes for open tickets. Here is what I have changed :
1. I added boost::static_pool, a pool whose maximum size is known when initializing the pool; in which case all memory is allocated when calling the constructor. This is useful for software that must manage memory with great care. The implementation is a simple subclass of boost::pool. In the same vein, I also added boost::static_object_pool.
2. I also added boost::array_pool, a pool whose maximum size is known at compile time. The array_pool object hence already contains all memory it needs. Same for boost::array_object_pool. I am not sure that this is really useful and I am not sure I have picked a good name for it.
3. I handled ticket #3789 (https://svn.boost.org/trac/boost/ticket/3789). In short, releasing objects from a boost::object_pool was O(n) instead of expected O(1) and this constraint was required to keep the pool ordered so that the destructor of object_pool could destroy all objects that the calling program did not released. To solve this problem, I created an O(n log n) function which orders an unordered pool, a function that I called in the destructor. Thus, with my modification, releasing objects is O(1) and the destructor is O(n log n), or O(1) is the calling program was kind enough to release all objects. Although this does not change the API, it could have a negative impact on software that allocate large number of objects (using object_pool) but that never releases them. However, my modification greatly improves programs who repeatedly requests and releases objects. This modification also handles ticket #6610 (https://svn.boost.org/trac/boost/ticket/6610).
4. I added a pool.get_size() function (https://svn.boost.org/trac/boost/ticket/6865) that returns the current number of elements/objects for which the pool has allocated memory.
5. I clarified the meaning of the 'max_size' parameter, a recent addition to limit the amount of memory a pool can allocate with a single call to the allocator. See ticket #6867 (https://svn.boost.org/trac/boost/ticket/6867) for details.
6. I fixed miscellaneous minor tickets : #5902 (division by zero when requesting null sized buffers), #6561 (crash when releasing a null pointer), #6710 (integer overflows and possible crashes when requesting too many elements).
7. I added test cases for all modifications. I manually tested each case on Windows and used bjam on Linux, although I am not exactly sure that bjam did anything as it did not even report which test it ran.
8. I still need to update the documentation. Before doing that, I thought that I should submit my changes to the Boost community to see whether they are approved or not. And more prosaically, I still need to figure out how to generate the said documentation !
I can help with the docs (I translated the old Pool docs) but I have no more than superficial knowledge of Pool. But I am on holiday for a while, so mail me privately and I will reply when I get back.
Now that these changes have been made in the sandbox, what is the next step to get them approved/amended/rejected ?
Before any changes can be moved to boost-trunk, IMO we need input from pool library users. Some of the changes look very useful, but may break old code? Ask on boost-users list for support? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com