From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-10-18 10:28:37
David M. Jones wrote:
> Thank you for your reply, Peter.
> Let me be more specific about the problem I ran into. I am using MSVC 7.1
> and the implementation of the STL that comes with it. When I tried to
> create and use an object of type
> std::list<int, my_allocator<int> >,
> I received a compiler error because the STL code contains
> _Myhead = 0;
> where _Myhead is of type
> my_allocator<node>::pointer (ie. boost::shared_ptr<node>)
> and node is the class that defines the nodes in the linked list.
> So the STL is not calling operator=() for a boost::shared_ptr with
> just any pointer type on the right-hand side. In fact, it's not even
> a T* -- it is specially setting it to null.
> Are you telling me that this STL implementation is (slightly) invalid? Or
> are you telling me that I should not expect boost::shared_ptr to be a
> valid type for use as a custom allocator::pointer? Or both?
> I have read that Scott Meyers (Effective STL; Item 10) says that
> custom allocators should always have
> typedef T* pointer
> but I have also read that Matt Austern (December 2000 CUJ column)
> says that custom allocators can sometimes be "some pointer-like
> class"; it seems to me that boost:shared_ptr is a "pointer-like
The Standard says (in Table 32, Allocator requirements) that
Allocator::pointer must be a "pointer to T", but doesn't go into more
detail. It is not clear what requirements must a type P meet in order to be
considered a valid "pointer to T".
The Standard also says in 20/4 that implementations are permitted to assume
that Allocator::pointer is T*.
20/5 goes on to inform us that implementors are encouraged to support "more
general memory models" and that in those cases the semantics are
implementation defined. "Implementation defined" means that they can do
whatever they choose, as long as it is documented.
So. This STL implementation is valid. It makes an attempt to support
::pointer types that are not T*. However, it places a requirement on these
types to support the expression
p = 0;
which shared_ptr does not.
It is possible to add this capability to shared_ptr, but it's also possible
to rewrite the STL so that it uses the alternate syntax:
p = pointer();
thereby relaxing the requirements placed on ::pointer types. From where I
sit, the second option seems more "correct", but the STL authors may not
As to your question:
> Or are you telling me that I should not expect boost::shared_ptr to be a
> valid type for use as a custom allocator::pointer?
Well, I don't know. It might or might not work, depending on how you use it
and what else implicit requirements the STL has. Try adding
shared_ptr & operator=(unspecified_bool_type)
to your copy of shared_ptr.hpp and see what happens.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk