[Boost-users] Serialization allocator
Stuart Reynolds
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...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Robert Ramey
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
Pfligersdorffer, Christian
since a while I am using a specialised version of
boost::archive::details::heap_allocator<> for deserialization of my
objects. The reason I do this is preformance: I have a bunch of small
objects that I read in one by one, use it and discard it. The custom
allocator simply tells the serialization library to place it always at
the same address. This works fine using boost 1.33.1.
Regards,
--
Christian Pfligersdorffer
Software Engineering
http://www.eos.info
Robert Ramey on Sunday, June 22, 2008 2:37 AM:
--
Christian Pfligersdorffer
Software Engineering
http://www.eos.info
Stuart Reynolds
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
Robert Ramey
> 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?)
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<>,
they don't. heap allocator is used only for resurrection objects saved
through pointers.
> So, for now it looks like I need to modify the the serialization
> library for boost and incorporate it into my build system. (Right?)
Right
Robert Ramey
Emil Dotchevski
<bo...@stuartreynolds.net> wrote:
> So, for now it looks like I need to modify the the serialization
> library for boost and incorporate it into my build system. (Right?)
Can't you override global new/delete? This will catch all STL
allocations as well as anything from Boost.
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
Stuart Reynolds
reserves the right do that. I'm making a library. If a library
overrides new and delete, the application that links against it cannot
(multiply defined linker references will result as the error).
Often, in embedded applications, it is not safe to ever call the
global allocator -- allocations must be routed to specific heaps for
particular purposes. For example, if you have a solid state hard
drive, portions of it may be reserved to function as a heap. You want
certain pieces of memory to allocated there (where accesses are slow
and made infrequently), and certain other pieces to be allocated in
the main RAM (where accesses are frequent and fast.)
Or, as another example, if you use a library you may want to be able
to profile the memory used by it (for example to provide high-speed
pools for frequent allocation sizes, or to see how close you are to
running up against the limits of the memory available in a particular
heap). This is only really straightforward to do if the library is
provided allocators through which all its allocations are made.
- Stuart