----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: <boost@lists.boost.org> Sent: Thursday, March 24, 2005 7:15 PM Subject: [boost] Re: How much should I care about allocators?
Dan Rosen <dan.rosen@gmail.com> writes:
It seems like using allocators properly does impose some real design decisions and restrictions. I think I'll study the Dinkumware STL implementation
I suggest you look at Dinkumware and one other side-by-side, since Dinkumware does something almost no other STL does: they implemented the optional support for allocators of the same type that don't always compare equal.
Hi Dan, Apart from that feature pointed by David, Dinkum is also very close (specially std::vector) to be able to instantiate containers with an smart pointer as allocator::pointer typedef. Other containers (list, map family) need very little tweaks. When I first proposed Shmem in boost mailing list I was working in containers in shared memory with the following library/article: http://ice.prohosting.com/newfunk/boost_shmemSTL.zip that explains needed changes to make Dinkum containers totally free of (pointer == T*). Last time I checked STLPort and libstdc++ used raw pointers as container members, maybe because of their SGI background. I also know that Metrowerks STL supports pointer typedefs. Although you never know until you instantiate a class with an allocator that defines pointer as something different than T* if the abstraction is good enough. For the moment, all implementations that I checked (STLPort, libstc++ and Dinkum) didn't fully support that. Shmem library containers (vector, list, ...) are modified SGI containers using pointer typedefs, you can have a look if you want to take any idea (Shmem is in boost vault). Another issue with allocators is what to do if allocators are not equal as discussed here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html Last time I discussed this with Howard Hinnant, the showed me links to some very interesting papers regarding to "move" semantics and allocators, written by some well known boosters: "Impact of the rvalue reference on the Standard Library": http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1771.html For background on the rvalue reference see: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm Really allocator interface is not very clear (current "construct" function is a pain since it only allows a copy construction and not a construction from convertible types), but rvalue opens some very interesting options to avoid temporaries and reduce the number of needed allocator instances to abstract the memory model when building containers (specially node containers). Regards, Ion P.D.: Regarding your code, in my list container I define the node outside the containers class, maybe that can help you with your instantation problem: template <class T, class A> struct shmem_list_node { typedef typename boost::detail::allocator:: rebind_to<A, shmem_list_node<T, A> >::type NodeAlloc; typedef typename NodeAlloc::pointer pointer; T m_data; pointer m_next; pointer m_prev; };