On Thu, Jun 16, 2011 at 3:55 AM, wrote:

Yeah, and I would like to fine override some libc functions for just some classes: maybe all boost functions should have all possible libc function pointers as optional parameters? Just accept you're trying to do something unordinary, which is not worthy to support generally. IMO of course. Try to implement what you need through compiler support or some cunny compiler/linker tricks.

No need for the sarcasm here. His suggestion really was not odd at all. As for having such requirements as a part of required boost coding standards, I don't think that's necessary as it should be handled on a library-by-library basis (speak up during review if you have a strong opinion on it). For specific, accepted libraries for which you feel the need for such behavior, you should talk to the library maintainer. Having control over allocators is a very reasonable request. -- -Matt Calabrese

On Thu, Jun 16, 2011 at 3:55 PM, wrote:

Yeah, and I would like to fine override some libc functions for just some classes: maybe all boost functions should have all possible libc function pointers as optional parameters? Just accept you're trying to do something unordinary, which is not worthy to support generally. IMO of course. Try to implement what you need through compiler support or some cunny compiler/linker tricks.

For being rational, Boost Pool Allocator is being provided by Boost. So do you mean to say that a person using the Boost Pool allocator should refrain from using other Boost libraries and declare that he is doing something 'unordinary'. All it takes to implement the allocator support in most cases is a typedef. I can't understand the reasoning behind your argument. Thanks.

On Fri, Jun 17, 2011 at 5:49 PM, Daniel James wrote:

That isn't true. Correctly supporting allocators is more difficult than normal memory management since they can use custom pointers and C++03 allocators were poorly specified. C++11 is a lot better in this regard, but support isn't wide spread enough.

Supporting allocators also makes your templates more complicated, resulting in worse error message, longer compile times and an increased testing burden. It also reduces the code that you can separately compile, since things that weren't templates have to become templates in order to support allocators.

Hmmm.. may be i am ignorant here. But here we are referring to classes

which contain containers like string and vector and deque. So if the vector, deque and string are already supporting allocators, then what extra testing might be required for boost libraries ( say boost::format / boost::filesystem )? If we are talking about a container and if we are saying that it won't support allocators, then that's a different stuff. May be i am missing something. Thanks...

The more general point is that adding any extra feature to a library increases its complexity and with each new feature this accumulates. So no extra feature is ever just a simple change.

But shouldn't memory management be the choice of the end user? std::allocator doesn't perform as well as other allocators like Boost Pool on the multi-core processors. Anyways, i think we are in different paradigms. Thanks a lot for the reply. Thanks, Gokul.

On Sun, Jun 19, 2011 at 4:10 AM, Gottlob Frege wrote:

On Fri, Jun 17, 2011 at 8:05 AM, Daniel James wrote:

...

On 17 June 2011 12:37, Gokulakannan Somasundaram wrote:

...

Hmmm.. may be i am ignorant here. But here we are referring to classes which contain containers like string and vector and deque.

Then you're restricting future changes to the implementation by saying that memory can only managed using containers. You've also still got the problems I mentioned with separate compilation and increased complexity. For example, boost::filesystem::path is not a template and is largely compiled separately. If allocator support was required, that wouldn't be possible.

The more general point is that adding any extra feature to a library increases its complexity and with each new feature this accumulates. So no extra feature is ever just a simple change.

Custom allocation doesn't always need to be done via template arguments. If, for example, boost::filesystem only needs to allocate a string at some point, maybe a specific "string supplier" could be passed in. Just something to customize allocation. Might not work in all cases - I don't think we can enforce custom allocation for every boost library - but we can encourage it in whatever way works for the problem at hand.

Tony

On the other hand C++ is so flexible, that you just can specialize the std::allocator for the character class you need (which is e.g. used by boost::path), and all the characters will be allocated by your own allocator specialization. Additionally, there might be some pitfalls, since this approach is more general and involves all character sequences to be allocated with your allocator. If such string objects are passed outside of .dll or .so libraries it might introduce problems, since these string objects must be destroyed accordingly with new allocator and not the default one. But anyway it should be possible even now ;) With Kind Regards, Ovanes