Boost logo

Boost :

From: Ion Gaztañaga (ion_g_m_at_[hidden])
Date: 2005-03-24 18:53:05

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, March 24, 2005 7:15 PM
Subject: [boost] Re: How much should I care about allocators?

> Dan Rosen <dan.rosen_at_[hidden]> 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

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:

 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":

For background on the rvalue reference see:

 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



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

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;

Boost list run by bdawes at, gregod at, cpdaniel at, john at