|
Boost : |
Subject: Re: [boost] Does Boost.Pool have a maintainer ?
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2012-06-29 17:06:53
AMDG
On 06/27/2012 06:15 AM, DUPUIS Etienne wrote:
> Greetings,
>
> Does Boost.Pool have a maintainer ? If no, what happens in that case, who decides to include bug fixes for open bugs ?
>
> If there is no maintainer, can I become the maintainer ?
>
> If the answer to the latter question is yes, can someone volunteer to be my "mentor" to help me with issues related to the way boost development work ? I have already fixed pool bugs in the sandbox and added related test programs.
>
I have a few comments on your changes:
- Why did you remove the valgrind sections?
- You used the textbook implementation of merge
sort. Mergesort for lists generally looks
more like this (untested):
void * sort(void * arg) {
void * stack[64];
void * limit = stack;
while (arg) {
void * carry = arg;
void * * iter = stack;
while (true) {
if (iter == limit) {
++limit;
break;
} else if (*iter) {
carry = merge(*iter, carry);
*iter = 0;
} else {
break;
}
++iter;
}
*iter = carry;
arg = next(arg);
}
void * result = 0;
for (void * * iter = stack; stack < limit; ++stack) {
result = merge(result, *iter);
}
return result;
}
- You've duplicated sort in simple_segregated_storage
and PODPtr.
- You should use std::less<void*> in sort to match the
sorting done by ordered_free.
- pool::ordered should be set in the constructor
initializer list.
- I don't think that boost::pool should track whether
it is ordered. This tracking is only needed by
object_pool, so object_pool should maintain it.
Also, I don't think that this flag affects the
behavior of object_pool at all, since object_pool
will always call pool::malloc, thus setting ordered
to false.
- I don't think that a user specified value of
next_size or max_size which is too large should
be silently truncated. It should be an error.
- I have no idea what static_pool is supposed to do.
- array_pool::memory has to be aligned.
In Christ,
Steven Watanabe
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk