|
Boost Users : |
From: Babi Seal (sseal73_at_[hidden])
Date: 2008-04-17 14:29:41
Hi,
I would like to avoid fragmentation and perhaps reduce the time spent entering and leaving state in my state machine by leveraging the fast_pool_allocator.
My very limited understanding of allocators comes from Scott Meyer's Effective STL and his references to articles on the Web. From reading the implementation of state_machine, I am not clear what the template-arguments for the UserAllocator should be if I wish to use the fast_pool_allocator as the UserAllocator parameter for state-machine. If I specified boost::fast_pool_allocator<int> does the library take care of somehow doing a rebind and allocating the right amount of memory for the states ?
>From reading the changeset documentation (Point 2, Breaking Change of 14 August 2005) I see that
" this considerably simplifies memory management customization. A user now only needs to pass his own allocator to state_machine<> and no longer has to separately overload operator
new/delete for his state classes"
Any guidance would be really appreciated ?
Thanks
#ifndef __STATE_H_INCL__
#define __STATE_H_INCL__
#include <boost/statechart/state_machine.hpp>
#include <boost/statechart/state.hpp>
#include <boost/statechart/transition.hpp>
#include <boost/pool/pool_alloc.hpp>
namespace sc = boost::statechart;
// We need to forward-declare the initial state because it can
// only be defined at a point where the state machine is
// defined.
struct Enabled;
struct Machine : sc::state_machine< Machine,
Enabled,
boost::fast_pool_allocator< int > > /* ??? is this right ? */
{
Machine();
~Machine() {
terminate();
}
int ContextAssociatedwithStateMachine;
};
#endif
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net