How to manage the internal memory allocation in boost libraries?
Hello, I am seeking a way to manage the internal memory allocation in boost libraries, and it seems that most of boost libraries do not support allocator parameter, so they can not be handled like STL library. But for my project, our memory management need to control all the memory allocation even it happens in the third-party libraries. Could somebody give me some suggestions to accomplish that? Regards, Tang Jiang Jun
On 10/09/2010 10:04, Tang Jiang Jun wrote:
Hello,
I am seeking a way to manage the internal memory allocation in boost libraries, and it seems that most of boost libraries do not support allocator parameter, so they can not be handled like STL library.
What libraries are you thinking of?
But for my project, our memory management need to control all the memory allocation even it happens in the third-party libraries. Could somebody give me some suggestions to accomplish that?
You could redefine operator new.
Such as any, asio, etc. But redefining global new operator is dangerous, and prone to conflict with global static objects which use the memory heap before custom memory heap manager get initialization. Actually why do most of boost libraries not provide the allocator interface to help users to manage their memory, as the way STL offers? On Fri, Sep 10, 2010 at 1:05 PM, Mathias Gaunard < mathias.gaunard@ens-lyon.org> wrote:
On 10/09/2010 10:04, Tang Jiang Jun wrote:
Hello,
I am seeking a way to manage the internal memory allocation in boost libraries, and it seems that most of boost libraries do not support allocator parameter, so they can not be handled like STL library.
What libraries are you thinking of?
But for my project, our memory management need to control all the memory
allocation even it happens in the third-party libraries. Could somebody give me some suggestions to accomplish that?
You could redefine operator new.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 10/09/2010 15:21, Tang Jiang Jun wrote:
Such as any, asio, etc.
But redefining global new operator is dangerous
How so?
and prone to conflict with global static objects which use the memory heap before custom memory heap manager get initialization.
Then initialize your heap manager first, or initialize it at the first allocation, or upon allocation, check whether it is initialized and if it isn't, fallback to some other allocation mechanism. You said you wanted all objects to be allocated using a particular function: the easiest way to achieve that is to replace the default allocation function by that you want to use.
Actually why do most of boost libraries not provide the allocator interface to help users to manage their memory, as the way STL offers?
While it makes sense for containers, and eventually for any, I don't see why it is really important in general. Asio allocating memory behind the scenes to do its work is fine as long as it's small, fixed, and doesn't appear to the user. Taking allocators wouldn't hurt, but I'm unsure that's necessary for fairly high-level libraries, where there isn't even a notion of what the memory would be used for.
Hi,
On Fri, Sep 10, 2010 at 11:45 PM, Mathias Gaunard
Taking allocators wouldn't hurt, but I'm unsure that's necessary for fairly high-level libraries, where there isn't even a notion of what the memory would be used for.
Well, we are planning to use boost in a highly resource constrained environment (embedded system but user space). Ability to control and track memory usage is very important. I would like some ideas on developing an ability to track the memory usage pattern at library level. Example, if I use different allocator instances with differing logging, I can segregate the information on a per library basis. -dhruva
participants (3)
-
dhruva -
Mathias Gaunard -
Tang Jiang Jun