Re: [boost] Re: How much should I care about allocators?

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 
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;
};