The allocator the serialize library seems to call is global new. (At least that's what happens when I compiled the samples.) The first three come from: boost::archive::basic_text_oprimitive<std::ostream>::basic_text_oprimitive$base () std::locale::locale<boost::archive::codecvt_null<char> > std::locale::_Impl::_Impl For our own interrnal uses of STL we provide our own STL allocators, which resolve to malloc/free callback functions provided to our library through its public interface. However, without recompiling the source to the serialization library, I don't think I can make the library use these allocators. (Right?) Generally speaking, because I work on embedded systems, we need to monitor and control memory usage very carefully. We can't have any dependencies on libraries that make naked calls to malloc/free or global new/delete since on many of the platforms we target the OS does not provide a heap, or must use a particular one of manys available heaps each of which may reference physically different memory. If all allocations went to boost::archive::details::heap_allocator<>, and this in turn called out to malloc/free style callbacks provided in the public interface, then that would solve my problems. More generally, if the whole of boost could make its allocations via externally provided allocators, it would be much more useful to me. So, for now it looks like I need to modify the the serialization library for boost and incorporate it into my build system. (Right?) Cheers, - Stu On Sat, Jun 21, 2008 at 5:37 PM, Robert Ramey <ramey@rrsd.com> wrote:
which allocator are we talking about?
If one use STL containers, the allocators associated with the container type are used so if specify particular allocators for your own collections, those allocators will be used when data is recovered and rebuilt.
The library uses a couple of STL containers for tracking objects and class ids. The currently would not be accessible. No one has ever asked about this before. We are only now starting to profile serialization performance tests so we will know for the first time ever if there is anything to be gained in this area. Its possible that a future version might permit one to specify an allocator when the archive is instantiated - but for now, usage of the standard allocator is built in.
Robert Ramey
Stuart Reynolds wrote:
I'm interested in using Boost's serialization for a middleware library that receives allocators from the application that uses it. Is it possible to specify which allocators for the serialization library to uses?
I can't override global new/delete -- the application reserves the right to do this.
Cheers, - Stuart
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users